diff options
7 files changed, 526 insertions, 94 deletions
diff --git a/app-misc/calamares-config-redcore/files/modules/bootloader.conf b/app-misc/calamares-config-redcore/files/modules/bootloader.conf index 6ac9c94d..6de28fa9 100644 --- a/app-misc/calamares-config-redcore/files/modules/bootloader.conf +++ b/app-misc/calamares-config-redcore/files/modules/bootloader.conf @@ -1,26 +1,53 @@ +# Bootloader configuration. The bootloader is installed to allow +# the system to start (and pick one of the installed operating +# systems to run). --- # Define which bootloader you want to use for EFI installations -# Possible options are 'grub' and 'systemd-boot'. +# Possible options are 'grub', 'sb-shim' and 'systemd-boot'. efiBootLoader: "grub" # systemd-boot configuration files settings, set kernel and initramfs file names # and amount of time before default selection boots -kernel: "/boot/vmlinuz-5.1.20-redcore" -img: "/boot/initrd-5.1.20-redcore" +kernel: "/boot/vmlinuz-5.6.13-redcore" +img: "/boot/initrd-5.6.13-redcore" timeout: "10" + # Optionally set the menu entry name and kernel name to use in systemd-boot. # If not specified here, these settings will be taken from branding.desc. +# # bootloaderEntryName: "Generic GNU/Linux" # kernelLine: ", with Stable-Kernel" # fallbackKernelLine: ", with Stable-Kernel (fallback initramfs)" # GRUB 2 binary names and boot directory # Some distributions (e.g. Fedora) use grub2-* (resp. /boot/grub2/) names. +# These names are also used when using sb-shim, since that needs some +# GRUB functionality (notably grub-probe) to work. As needed, you may use +# complete paths like `/usr/bin/efibootmgr` for the executables. +# grubInstall: "grub2-install" grubMkconfig: "grub2-mkconfig" grubCfg: "/boot/grub/grub.cfg" -# Optionally set the --bootloader-id to use for EFI. If not set, this defaults -# to the bootloaderEntryName from branding.desc with problematic characters -# replaced. If an efiBootloaderId is specified here, it is taken to already be a -# valid directory name, so no such postprocessing is done in this case. +grubProbe: "grub2-probe" +efiBootMgr: "efibootmgr" + +# Optionally set the bootloader ID to use for EFI. This is passed to +# grub-install --bootloader-id. +# +# If not set here, the value from bootloaderEntryName from branding.desc +# is used, with problematic characters (space and slash) replaced. +# +# The ID is also used as a directory name within the EFI environment, +# and the bootloader is copied from /boot/efi/EFI/<dirname>/ . When +# setting the option here, keep in mind that the name is sanitized +# (problematic characters, see above, are replaced). +# # efiBootloaderId: "dirname" + +# Optionally install a copy of the GRUB EFI bootloader as the EFI +# fallback loader (either bootia32.efi or bootx64.efi depending on +# the system). This may be needed on certain systems (Intel DH87MC +# seems to be the only one). If you set this to false, take care +# to add another module to optionally install the fallback on those +# boards that need it. +installEFIFallback: true diff --git a/app-misc/calamares-config-redcore/files/modules/displaymanager.conf b/app-misc/calamares-config-redcore/files/modules/displaymanager.conf index 04c3c220..18250fd0 100644 --- a/app-misc/calamares-config-redcore/files/modules/displaymanager.conf +++ b/app-misc/calamares-config-redcore/files/modules/displaymanager.conf @@ -1,11 +1,39 @@ +# Configure one or more display managers (e.g. SDDM) +# with a "best effort" approach. +# +# This module also sets up autologin, if the feature is enabled in +# globalstorage (where it would come from the users page). --- -#The DM module attempts to set up all the DMs found in this list, in that precise order. -#It also sets up autologin, if the feature is enabled in globalstorage. -#The displaymanagers list can also be set in globalstorage, and in that case it overrides anything set up here. +# The DM module attempts to set up all the DMs found in this list, in the +# precise order listed. The displaymanagers list can also be set in +# globalstorage, and in that case it overrides the setting here. +# +# If *sysconfigSetup* is set to *true* (see below, only relevant for +# openSUSE derivatives) then this list is ignored and only sysconfig +# is attempted. You can also list "sysconfig" in this list instead. +# displaymanagers: - sddm -#Enable the following settings to force a desktop environment in your displaymanager configuration file: +# Enable the following settings to force a desktop environment +# in your displaymanager configuration file. This will attempt +# to configure the given DE (without checking if it is installed). +# The DM configuration for each potential DM may **or may not** +# support configuring a default DE, so the keys are mandatory +# but their interpretation is up to the DM configuration. +# +# Subkeys of *defaultDesktopEnvironment* are (all mandatory): +# - *executable* a full path to an executable +# - *desktopFile* a .desktop filename +# +# If this is **not** set, then Calamares will look for installed +# DE's and pick the first one it finds that is actually installed. +# +# If this **is** set, and the *executable* key doesn't point to +# an installed file, then the .desktop file's TryExec key is +# used instead. +# + #defaultDesktopEnvironment: # executable: "startkde" # desktopFile: "plasma" @@ -14,3 +42,11 @@ displaymanagers: #display manager are set up correctly. This is normally done by the distribution #packages, and best left to them. Therefore, it is disabled by default. basicSetup: false + +# If true, setup autologin for openSUSE. This only makes sense on openSUSE +# derivatives or other systems where /etc/sysconfig/displaymanager exists. +# +# The preferred way to pick sysconfig is to just list it in the +# *displaymanagers* list (as the only one). +# +sysconfigSetup: false diff --git a/app-misc/calamares-config-redcore/files/modules/finished.conf b/app-misc/calamares-config-redcore/files/modules/finished.conf index dbbd88a9..3c6ca4ff 100644 --- a/app-misc/calamares-config-redcore/files/modules/finished.conf +++ b/app-misc/calamares-config-redcore/files/modules/finished.conf @@ -1,14 +1,41 @@ # Configuration for the "finished" page, which is usually shown only at # the end of the installation (successful or not). --- +# DEPRECATED +# # The finished page can hold a "restart system now" checkbox. -# If this is false, no checkbox is show and the system is not restarted +# If this is false, no checkbox is shown and the system is not restarted # when Calamares exits. -restartNowEnabled: true -# Initial state of the checkbox "restart now". -restartNowChecked: false +# restartNowEnabled: true + +# DEPRECATED +# +# Initial state of the checkbox "restart now". Only relevant when the +# checkbox is shown by restartNowEnabled. +# restartNowChecked: false + +# Behavior of the "restart system now" button. +# +# There are four usable values: +# - never +# Does not show the button and does not restart. +# This matches the old behavior with restartNowEnabled=false. +# - user-unchecked +# Shows the button, defaults to unchecked, restarts if it is checked. +# This matches the old behavior with restartNowEnabled=true and restartNowChecked=false. +# - user-checked +# Shows the button, defaults to checked, restarts if it is checked. +# This matches the old behavior with restartNowEnabled=true and restartNowChecked=true. +# - always +# Shows the button, checked, but the user cannot change it. +# This is new behavior. +# +# The three combinations of legacy values are still supported. +restartNowMode: user-unchecked + # If the checkbox is shown, and the checkbox is checked, then when # Calamares exits from the finished-page it will run this command. +# If not set, falls back to "shutdown -r now". restartNowCommand: "shutdown -r 0" # When the last page is (successfully) reached, send a DBus notification diff --git a/app-misc/calamares-config-redcore/files/modules/machineid.conf b/app-misc/calamares-config-redcore/files/modules/machineid.conf index 341caf7e..13ba17df 100644 --- a/app-misc/calamares-config-redcore/files/modules/machineid.conf +++ b/app-misc/calamares-config-redcore/files/modules/machineid.conf @@ -1,8 +1,24 @@ +# Machine-ID and other random data on the target system. +# +# This module can create a number of "random" things on the target: +# - a systemd machine-id file (hence the name of the Calamares module) +# with a random UUID. +# - a dbus machine-id file (or, optionally, link to the one from systemd) +# - an entropy file +# --- # Whether to create /etc/machine-id for systemd. systemd: false + # Whether to create /var/lib/dbus/machine-id for D-Bus. dbus: true # Whether /var/lib/dbus/machine-id should be a symlink to /etc/machine-id # (ignored if dbus is false, or if there is no /etc/machine-id to point to). +dbus-symlink: true +# this is a deprecated form of *dbus-symlink* symlink: true + +# Whether to create an entropy file +entropy: false +# Whether to copy entropy from the host +entropy-copy: false diff --git a/app-misc/calamares-config-redcore/files/modules/packages.conf b/app-misc/calamares-config-redcore/files/modules/packages.conf index 8d45706b..52ef498e 100644 --- a/app-misc/calamares-config-redcore/files/modules/packages.conf +++ b/app-misc/calamares-config-redcore/files/modules/packages.conf @@ -8,10 +8,38 @@ # - urpmi - Mandriva package manager # - apt - APT frontend for DEB and RPM # - pacman - Pacman -# - portage - Gentoo package manager -# - entropy - Sabayon package manager +# - portage - Gentoo package manager +# - entropy - Sabayon package manager +# - apk = Alpine Linux package manager +# - dummy - Dummy manager, only logs # backend: portage + +# +# Often package installation needs an internet connection. +# Since you may allow system installation without a connection +# and want to offer OPTIONAL package installation, it's +# possible to have no internet, yet have this packages module +# enabled in settings. +# +# You can skip the whole module when there is no internet +# by setting "skip_if_no_internet" to true. +# +# You can run a package-manager specific update procedure +# before installing packages (for instance, to update the +# list of packages and dependencies); this is done only if there +# is an internet connection. +# +# Set "update_db" to 'true' for refreshing the database on the +# target system. On target installations, which got installed by +# unsquashing, a full system update may be needed. Otherwise +# post-installing additional packages may result in conflicts. +# Therefore set also "update_system" to 'true'. +# +skip_if_no_internet: false +update_db: false +update_system: false + # # List of maps with package operations such as install or remove. # Distro developers can provide a list of packages to remove @@ -22,19 +50,121 @@ backend: portage # packages that need to be installed or removed can run before # this one. Distro developers may want to install locale packages # or remove drivers not needed on the installed system. -# This job will populate a list of dictionaries in the global -# storage called "packageOperations" and it is processed -# after the static list in the job configuration. +# Such a job would populate a list of dictionaries in the global +# storage called "packageOperations" and that list is processed +# after the static list in the job configuration (i.e. the list +# that is in this configuration file). +# +# Allowed package operations are: +# - *install*, *try_install*: will call the package manager to +# install one or more packages. The install target will +# abort the whole installation if package-installation +# fails, while try_install carries on. Packages may be +# listed as (localized) names, or as (localized) package-data. +# See below for the description of the format. +# - *localInstall*: this is used to call the package manager +# to install a package from a path-to-a-package. This is +# useful if you have a static package archive on the install media. +# The *pacman* package manager is the only one to specially support +# this operation (all others treat this the same as *install*). +# - *remove*, *try_remove*: will call the package manager to +# remove one or more packages. The remove target will +# abort the whole installation if package-removal fails, +# while try_remove carries on. Packages may be listed as +# (localized) names. +# One additional key is recognized, to help netinstall out: +# - *source*: ignored, does get logged +# Any other key is ignored, and logged as a warning. +# +# There are two formats for naming packages: as a name or as package-data, +# which is an object notation providing package-name, as well as pre- and +# post-install scripts. +# +# Here are both formats, for installing vi. The first one just names the +# package for vi (using the naming of the installed package manager), while +# the second contains three data-items; the pre-script is run before invoking +# the package manager, and the post-script runs once it is done. +# +# - install +# - vi +# - package: vi +# pre-script: touch /tmp/installing-vi +# post-script: rm -f /tmp/installing-vi +# +# The pre- and post-scripts are optional, but you cannot leave both out +# if you do use the *package* key: using "package: vi" with neither script +# option will trick Calamares into trying to install a package named +# "package: vi", which is unlikely to work. +# +# The pre- and post-scripts are **not** executed by a shell unless you +# explicitly invoke `/bin/sh` in them. The command-lines are passed +# to exec(), which does not understand shell syntax. In other words: +# +# pre-script: ls | wc -l +# +# Will fail, because `|` is passed as a command-line argument to ls, +# as are `wc`, and `-l`. No shell pipeline is set up, and ls is likely +# to complain. Invoke the shell explicitly: +# +# pre-script: /bin/sh -c \"ls | wc -l\" +# +# The above note on shell-expansion applies to versions up-to-and-including +# Calamares 3.2.12, but will change in future. +# +# Any package name may be localized; this is used to install localization +# packages for software based on the selected system locale. By including +# the string `LOCALE` in the package name, the following happens: +# +# - if the system locale is English (any variety), then the package is not +# installed at all, +# - otherwise `$LOCALE` or `${LOCALE}` is replaced by the 'lower-cased' BCP47 +# name of the 'language' part of the selected system locale (not the +# country/region/dialect part), e.g. selecting "nl_BE" will use "nl" +# here. +# +# Take care that just plain `LOCALE` will not be replaced, so `foo-LOCALE` will +# be left unchanged, while `foo-$LOCALE` will be changed. However, `foo-LOCALE` +# **will** be removed from the list of packages (i.e. not installed), if +# English is selected. If a non-English locale is selected, then `foo-LOCALE` +# will be installed, unchanged (no language-name-substitution occurs). +# +# The following installs localizations for vi, if they are relevant; if +# there is no localization, installation continues normally. +# +# - install +# - vi-$LOCALE +# - package: vi-${LOCALE} +# pre-script: touch /tmp/installing-vi +# post-script: rm -f /tmp/installing-vi +# +# When installing packages, Calamares will invoke the package manager +# with a list of package names if it can; package-data prevents this because +# of the scripts that need to run. In other words, this: +# +# - install: +# - vi +# - binutils +# - package: wget +# pre-script: touch /tmp/installing-wget +# +# This will invoke the package manager three times, once for each package, +# because not all of them are simple package names. You can speed up the +# process if you have only a few pre-scripts, by using multiple install targets: +# +# - install: +# - vi +# - binutils +# - install: +# - package: wget +# pre-script: touch /tmp/installing-wget +# +# This will call the package manager once with the package-names "vi" and +# "binutils", and then a second time for "wget". When installing large numbers +# of packages, this can lead to a considerable time savings. # operations: - remove: - - app-admin/calamares - - app-misc/calamares-config-redcore - - app-misc/calamares-runtime - - app-misc/redcore-live - - x11-themes/redcore-artwork-calamares -# - install: -# - pkg1 -# - pkg2 -# - localInstall: -# - /path/to/pkg1 + - app-admin/calamares + - app-misc/calamares-config-redcore + - app-misc/redcore-live + - x11-themes/redcore-artwork-calamares diff --git a/app-misc/calamares-config-redcore/files/modules/users.conf b/app-misc/calamares-config-redcore/files/modules/users.conf index d91e6858..8a016a3a 100644 --- a/app-misc/calamares-config-redcore/files/modules/users.conf +++ b/app-misc/calamares-config-redcore/files/modules/users.conf @@ -1,4 +1,18 @@ +# Configuration for the one-user-system user module. +# +# Besides these settings, the user module also places the following +# keys into the globalconfig area, based on user input in the view step. +# +# - hostname +# - username +# - password (obscured) +# - autologinUser (if enabled, set to username) +# +# These globalconfig keys are set when the jobs for this module +# are created. --- +# Used as default groups for the created user. +# Adjust to your Distribution defaults. defaultGroups: - lp - lpadmin @@ -17,7 +31,121 @@ defaultGroups: - portage - messagebus - smbshare -autologinGroup: autologin -doAutologin: false + +# Some Distributions require a 'autologin' group for the user. +# Autologin causes a user to become automatically logged in to +# the desktop environment on boot. +# Disable when your Distribution does not require such a group. +# autologinGroup: autologin +# You can control the initial state for the 'autologin checkbox' here. +# Possible values are: +# - true to check or +# - false to uncheck +# These set the **initial** state of the checkbox. +doAutologin: true + +# When *sudoersGroup* is set to a non-empty string, Calamares creates a +# sudoers file for the user. This file is located at: +# `/etc/sudoers.d/10-installer` +# Remember to add the (value of) *sudoersGroup* to *defaultGroups*. +# +# If your Distribution already sets up a group of sudoers in its packaging, +# remove this setting (delete or comment out the line below). Otherwise, +# the setting will be duplicated in the `/etc/sudoers.d/10-installer` file, +# potentially confusing users. +# sudoersGroup: wheel + +# Setting this to false, causes the root account to be disabled. +# When disabled, hides the "Use the same password for administrator" +# checkbox. Also hides the "Choose a password" and associated text-inputs. setRootPassword: true + +# You can control the initial state for the 'reuse password for root' +# checkbox here. Possible values are: +# - true to check or +# - false to uncheck +# +# When checked, the user password is used for the root account too. +# +# NOTE: *doReusePassword* requires *setRootPassword* to be enabled. doReusePassword: false + +# These are optional password-requirements that a distro can enforce +# on the user. The values given in this sample file set only very weak +# validation settings. +# +# - nonempty rejects empty passwords +# - there are no length validations +# - libpwquality (if it is enabled at all) has no length of class +# restrictions, although it will still reject palindromes and +# dictionary words with these settings. +# +# Checks may be listed multiple times; each is checked separately, +# and no effort is done to ensure that the checks are consistent +# (e.g. specifying a maximum length less than the minimum length +# will annoy users). +# +# The libpwquality check relies on the (optional) libpwquality library. +# Its value is a list of configuration statements that could also +# be found in pwquality.conf, and these are handed off to the +# libpwquality parser for evaluation. The check is ignored if +# libpwquality is not available at build time (generates a warning in +# the log). The Calamares password check rejects passwords with a +# score of < 40 with the given libpwquality settings. +# +# (additional checks may be implemented in CheckPWQuality.cpp and +# wired into UsersPage.cpp) +# +# - To disable specific password validations: +# comment out the relevant 'passwordRequirements' keys below. +# - To disable all password validations: +# set both 'allowWeakPasswords' and 'allowWeakPasswordsDefault' to true. +# (That will show the box *Allow weak passwords* in the user- +# interface, and check it by default). +# passwordRequirements: +# nonempty: true +# minLength: -1 # Password at least this many characters +# maxLength: -1 # Password at most this many characters +# libpwquality: +# - minlen=0 +# - minclass=0 + +# You can control the visibility of the 'strong passwords' checkbox here. +# Possible values are: +# - true to show or +# - false to hide (default) +# the checkbox. This checkbox allows the user to choose to disable +# password-strength-checks. By default the box is **hidden**, so +# that you have to pick a password that satisfies the checks. +allowWeakPasswords: true +# You can control the initial state for the 'strong passwords' checkbox here. +# Possible values are: +# - true to uncheck or +# - false to check (default) +# the checkbox by default. Since the box is labeled to enforce strong +# passwords, in order to **allow** weak ones by default, the box needs +# to be unchecked. +allowWeakPasswordsDefault: true + +# Shell to be used for the regular user of the target system. +# There are three possible kinds of settings: +# - unset (i.e. commented out, the default), act as if set to /bin/bash +# - empty (explicit), don't pass shell information to useradd at all +# and rely on a correct configuration file in /etc/default/useradd +# - set, non-empty, use that path as shell. No validation is done +# that the shell actually exists or is executable. +# userShell: /bin/bash + +# Hostname setting +# +# The user can enter a hostname; this is configured into the system +# in some way; pick one of: +# - *None*, to not set the hostname at all +# - *EtcFile*, to write to `/etc/hostname` directly +# - *Hostnamed*, to use systemd hostnamed(1) over DBus +# The default is *EtcFile*. +setHostname: EtcFile + +# Should /etc/hosts be written with a hostname for this machine +# (also adds localhost and some ipv6 standard entries). +writeHostsFile: true diff --git a/app-misc/calamares-config-redcore/files/settings.conf b/app-misc/calamares-config-redcore/files/settings.conf index ba9e42b7..38726d6f 100644 --- a/app-misc/calamares-config-redcore/files/settings.conf +++ b/app-misc/calamares-config-redcore/files/settings.conf @@ -1,36 +1,62 @@ # Configuration file for Calamares # Syntax is YAML 1.2 --- -# Modules can be job modules (with different interfaces) and QtWidgets view modules. -# They could all be placed in a number of different paths. -# "modules-search" is a list of strings, each of these can either be a full path to a -# directory or the keyword "local". -# "local" means LIBDIR/calamares/modules with settings in SHARE/calamares/modules or -# /etc/calamares/modules. +# Modules can be job modules (with different interfaces) and QtWidgets view +# modules. They could all be placed in a number of different paths. +# "modules-search" is a list of strings, each of these can either be a full +# path to a directory or the keyword "local". +# +# "local" means: +# - modules in $LIBDIR/calamares/modules, with +# - settings in SHARE/calamares/modules or /etc/calamares/modules. +# In debug-mode (e.g. calamares -d) "local" also adds some paths +# that make sense from inside the build-directory, so that you +# can build-and-run with the latest modules immediately. +# +# Strings other than "local" are taken as paths and interpreted +# relative to wherever Calamares is started. It is therefore **strongly** +# recommended to use only absolute paths here. This is mostly useful +# if your distro has forks of standard Calamares modules, but also +# uses some form of upstream packaging which might overwrite those +# forked modules -- then you can keep modules somewhere outside of +# the "regular" module tree. +# +# # YAML: list of strings. modules-search: [ local ] -# Instances section. This section is optional, and it defines custom instances for -# modules of any kind. An instance entry has an instance name, a module name, and -# a configuration file name. -# The primary goal of this mechanism is to allow loading multiple instances of the -# same module, with different configuration. If you don't need this, the instances -# section can safely be left empty. -# Module name plus instance name makes an instance key, e.g. "webview@owncloud", -# where "webview" is the module name (for the webview viewmodule) and "owncloud" -# is the instance name, which loads a configuration file named "owncloud.conf" from -# any of the configuration file paths, including the webview module directory. -# This instance key can then be referenced in the sequence section. -# For all modules without a custom instance specification, a default instance is -# generated automatically by Calamares. Therefore a statement such as "webview" in -# the sequence section automatically implies an instance key of "webview@webview" -# even without explicitly defining this instance, and the configuration file for -# this default instance "<modulename>@<modulename>" is always assumed to be -# "<modulename>.conf". -# For more information on running module instances, run Calamares in debug mode -# and check the Modules page in the Debug information interface. +# Instances section. This section is optional, and it defines custom instances +# for modules of any kind. An instance entry has an module name, an instance +# name, and a configuration file name. The primary goal of this mechanism is +# to allow loading multiple instances of the same module, with different +# configuration. If you don't need this, the instances section can safely be +# left empty. +# +# Module name plus instance name makes an instance key, e.g. +# "webview@owncloud", where "webview" is the module name (for the webview +# viewmodule) and "owncloud" is the instance name. In the *sequence* +# section below, use instance-keys to name instances (instead of just +# a module name, for modules which have only a single instance). +# +# Every module implicitly has an instance with the instance name equal +# to its module name, e.g. "welcome@welcome". In the *sequence* section, +# mentioning a module without a full instance key (e.g. "welcome") +# means that implicit module. +# +# An instance must specify its configuration file (e.g. `webview-home.conf`). +# The implicit instances all have configuration files named `<module>.conf`. +# This (implict) way matches the source examples, where the welcome +# module contains an example `welcome.conf`. +# +# For more information on running module instances, run Calamares in debug +# mode and check the Modules page in the Debug information interface. +# +# A module that is often used with instances is shellprocess, which will +# run shell commands specified in the configuration file. By configuring +# more than one instance of the module, multiple shell sessions can be run +# during install. +# # YAML: list of maps of string:string key-value pairs. - #instances: #- id: owncloud # module: webview @@ -38,27 +64,26 @@ modules-search: [ local ] # Sequence section. This section describes the sequence of modules, both # viewmodules and jobmodules, as they should appear and/or run. +# # A jobmodule instance key (or name) can only appear in an exec phase, whereas # a viewmodule instance key (or name) can appear in both exec and show phases. -# There is no limit to the number of show or exec phases. However, the same module -# instance key should not appear more than once per phase, and deployers should -# take notice that the global storage structure is persistent throughout the -# application lifetime, possibly influencing behavior across phases. -# A show phase defines a sequence of viewmodules (and therefore pages). These -# viewmodules can offer up jobs for the execution queue. -# An exec phase displays a progress page (with brandable slideshow). This progress -# page iterates over the modules listed in the *immediately preceding* show phase, -# and enqueues their jobs, as well as any other jobs from jobmodules, in the order -# defined in the current exec phase. -# It then executes the job queue and clears it. If a viewmodule offers up a job -# for execution, but the module name (or instance key) isn't listed in the +# There is no limit to the number of show or exec phases. However, the same +# module instance key should not appear more than once per phase, and +# deployers should take notice that the global storage structure is persistent +# throughout the application lifetime, possibly influencing behavior across +# phases. A show phase defines a sequence of viewmodules (and therefore +# pages). These viewmodules can offer up jobs for the execution queue. +# +# An exec phase displays a progress page (with brandable slideshow). This +# progress page iterates over the modules listed in the *immediately +# preceding* show phase, and enqueues their jobs, as well as any other jobs +# from jobmodules, in the order defined in the current exec phase. +# +# It then executes the job queue and clears it. If a viewmodule offers up a +# job for execution, but the module name (or instance key) isn't listed in the # immediately following exec phase, this job will not be executed. -# WARNING: when upgrading from Calamares 1.1, this section requires manual -# intervention. There are no fixed prepare/install/postinstall phases any more, -# and all limitations on the number of phases, number of pages, and number of -# instances are lifted. +# # YAML: list of lists of strings. -sequence: - show: - welcome - locale @@ -89,30 +114,73 @@ sequence: - show: - finished -# A branding component is a directory, either in SHARE/calamares/branding or in -# /etc/calamares/branding (the latter takes precedence). The directory must contain a -# YAML file branding.desc which may reference additional resources (such as images) as -# paths relative to the current directory. -# A branding component can also ship a QML slideshow for execution pages, along with -# translation files. -# Only the name of the branding component (directory) should be specified here, Calamares -# then takes care of finding it and loading the contents. +# A branding component is a directory, either in SHARE/calamares/branding or +# in /etc/calamares/branding (the latter takes precedence). The directory must +# contain a YAML file branding.desc which may reference additional resources +# (such as images) as paths relative to the current directory. +# +# A branding component can also ship a QML slideshow for execution pages, +# along with translation files. +# +# Only the name of the branding component (directory) should be specified +# here, Calamares then takes care of finding it and loading the contents. +# # YAML: string. branding: redcore_branding -# If this is set to true, Calamares will show an "Are you sure?" prompt right before -# each execution phase, i.e. at points of no return. If this is set to false, no prompt -# is shown. -# Default is false. +# If this is set to true, Calamares will show an "Are you sure?" prompt right +# before each execution phase, i.e. at points of no return. If this is set to +# false, no prompt is shown. Default is false, but Calamares will complain if +# this is not explicitly set. +# # YAML: boolean. prompt-install: true -# If this is set to true, Calamares will execute all target environment commands in the -# current environment, without chroot. This setting is considered experimental, and it -# should only be used when setting up Calamares as a post-install configuration tool, as -# opposed to a full operating system installer. -# Some official Calamares modules are not expected to function with this setting. -# Packagers beware, here be dragons. -# Default is false. +# If this is set to true, Calamares will execute all target environment +# commands in the current environment, without chroot. This setting should +# only be used when setting up Calamares as a post-install configuration tool, +# as opposed to a full operating system installer. +# +# Some official Calamares modules are not expected to function with this +# setting. (e.g. partitioning seems like a bad idea, since that is expected to +# have been done already) +# +# Default is false (for a normal installer), but Calamares will complain if +# this is not explicitly set. +# # YAML: boolean. dont-chroot: false + +# If this is set to true, Calamares refers to itself as a "setup program" +# rather than an "installer". Defaults to the value of dont-chroot, but +# Calamares will complain if this is not explicitly set. +oem-setup: false + +# If this is set to true, the "Cancel" button will be disabled entirely. +# The button is also hidden from view. +# +# This can be useful if when e.g. Calamares is used as a post-install +# configuration tool and you require the user to go through all the +# configuration steps. +# +# Default is false, but Calamares will complain if this is not explicitly set. +# +# YAML: boolean. +disable-cancel: false + +# If this is set to true, the "Cancel" button will be disabled once +# you start the 'Installation', meaning there won't be a way to cancel +# the Installation until it has finished or installation has failed. +# +# Default is false, but Calamares will complain if this is not explicitly set. +# +# YAML: boolean. +disable-cancel-during-exec: false + +# If this is set to true, then once the end of the sequence has +# been reached, the quit (done) button is clicked automatically +# and Calamares will close. Default is false: the user will see +# that the end of installation has been reached, and that things are ok. +# +# +quit-at-end: false |