184 lines
6.9 KiB
Plaintext
184 lines
6.9 KiB
Plaintext
# 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:
|
|
# - 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 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
|
|
# 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
|
|
- luksopenswaphookcfg
|
|
- luksbootkeyfile
|
|
- plymouthcfg
|
|
- initcpiocfg
|
|
- initcpio
|
|
- users
|
|
- displaymanager
|
|
- mhwdcfg
|
|
- networkcfg
|
|
- hwclock
|
|
- services
|
|
- grubcfg
|
|
- bootloader
|
|
- postcfg
|
|
- 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: tromjaro
|
|
|
|
# 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: true
|
|
|
|
# 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
|