calamares: settings update for 3.2.10

calamares/etc/calamares/modules/unpackfs.conf

@@ -20,7 +20,7 @@ unpack:
 # Usually you list a filesystem image to unpack; you can use
 # squashfs or an ext4 image.
 #
-    -   source: "/cdrom/LiveOS/squashfs.img"
+    -   source: "/run/initramfs/live/LiveOS/squashfs.img"
         sourcefs: "squashfs"
         destination: ""
 

calamares/etc/calamares/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,25 +64,25 @@ 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:
@@ -66,6 +92,7 @@ sequence:
   - keyboard
   - partition
   - users
+#  - tracking
   - summary
 - exec:
 #  - dummycpp
@@ -102,30 +129,65 @@ sequence:
 #  - webview@owncloud
   - 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: openmamba
 
-# 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