app-misc/calamares-config-redcore : update installer configuration

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