+# SPDX-FileCopyrightText: no
+# SPDX-License-Identifier: CC0-1.0
+#
# Configuration file for Calamares
-# Syntax is YAML 1.2
+#
+# This is the top-level configuration file for Calamares.
+# It specifies what modules will be used, as well as some
+# overall characteristics -- is this a setup program, or
+# an installer. More specific configuration is devolved
+# to the branding file (for the UI) and the individual
+# module configuration files (for functionality).
---
-# 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: [ local, /path/to/dir/with/more/modules ]
-
-# We define the module names in the order they should show up (QtWidget view modules,
-# with one or more pages) OR be executed if enqueued (all other modules).
-# Pages can also enqueue jobs for delayed execution in the order specified for the
-# install phase.
-
-# Phase 1 - prepare.
-# View modules are shown as UI pages, jobs from job modules are executed immediately in
-# the background.
-# Jobs should be executed sparingly (if at all) in this phase.
-prepare:
-- greeting
-- locale
-- keyboard
-- partition
-- summary
-
-# Phase 2 - install.
-# View modules are not shown. Only the view modules shown in the previous phase are
-# allowed, their names should be added here as placeholders to specify the order in
-# which view module jobs should be enqueued. Job modules are also allowed.
-install:
-- dummyprocess
-- dummypython
-- partition
-#- unsquashfs
-- locale
-- keyboard
-#- users
-
-# Phase 3 - postinstall.
-# View modules are shown as UI pages, jobs from job modules are executed immediately in
-# the background.
-# Jobs should be executed sparingly (if at all) in this phase.
-postinstall: #TODO: actually use this
-- finished
+# 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 these keys:
+# - *module* name, which matches the module name from the module descriptor
+# (usually the name of the directory under `src/modules/`, but third-
+# party modules may diverge.
+# - *id* (optional) an identifier to distinguish this instance from
+# all the others. If none is given, the name of the module is used.
+# Together, the module and id form an instance key (see below).
+# - *config* (optional) a filename for the configuration. If none is
+# given, *module*`.conf` is used (e.g. `welcome.conf` for the welcome
+# module)
+# - *weight* (optional) In the *exec* phase of the sequence, progress
+# is reported as jobs are completed. The jobs from a single module
+# together contribute the full weight of that module. The overall
+# progress (0 .. 100%) is divided up according to the weight of each
+# module. Give modules that take a lot of time to complete, a larger
+# weight to keep the overall progress moving along steadily. This
+# weight overrides a weight given in the module descriptor. If no weight
+# is given, uses the value from the module descriptor, or 1 if there
+# isn't one there either.
+#
+# 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 may 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`. Specify a *config* for
+# any module (also implicit instances) to change which file is used.
+#
+# 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
+# config: owncloud.conf
+
+# 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
+# immediately following exec phase, this job will not be executed.
+#
+# YAML: list of lists of strings.
+sequence:
+- show:
+ - welcome
+ - locale
+ - keyboard
+ - partition
+ - users
+ - summary
+- exec:
+ - partition
+ - mount
+ - unpackfs
+ - machineid
+ - fstab
+ - locale
+ - keyboard
+ - localecfg
+ - shellprocess
+ - luksopenswaphookcfg
+ - luksbootkeyfile
+ - plymouthcfg
+ - initcpiocfg
+ - initcpio
+ - removeuser
+ - users
+ - displaymanager
+ - networkcfg
+ - hwclock
+ - services-systemd
+ - grubcfg
+ - bootloader
+ - postcfg
+ - packages
+ - umount
+- 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.
+#
+# YAML: string.
+branding: alter
+
+# 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: 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, the "Next" and "Back" button will be hidden once
+# you start the 'Installation'.
+#
+# Default is false, but Calamares will complain if this is not explicitly set.
+#
+# YAML: boolean.
+hide-back-and-next-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
OSDN Git Service
