settings.conf

   1 # SPDX-FileCopyrightText: no
   2 # SPDX-License-Identifier: CC0-1.0
   3 #
   4 # Configuration file for Calamares
   5 #
   6 # This is the top-level configuration file for Calamares.
   7 # It specifies what modules will be used, as well as some
   8 # overall characteristics -- is this a setup program, or
   9 # an installer. More specific configuration is devolved
  10 # to the branding file (for the UI) and the individual
  11 # module configuration files (for functionality).
  12 ---
  13 # Modules can be job modules (with different interfaces) and QtWidgets view
  14 # modules. They could all be placed in a number of different paths.
  15 # "modules-search" is a list of strings, each of these can either be a full
  16 # path to a directory or the keyword "local".
  17 #
  18 # "local" means:
  19 #   - modules in $LIBDIR/calamares/modules, with
  20 #   - settings in SHARE/calamares/modules or /etc/calamares/modules.
  21 # In debug-mode (e.g. calamares -d) "local" also adds some paths
  22 # that make sense from inside the build-directory, so that you
  23 # can build-and-run with the latest modules immediately.
  24 #
  25 # Strings other than "local" are taken as paths and interpreted
  26 # relative to wherever Calamares is started. It is therefore **strongly**
  27 # recommended to use only absolute paths here. This is mostly useful
  28 # if your distro has forks of standard Calamares modules, but also
  29 # uses some form of upstream packaging which might overwrite those
  30 # forked modules -- then you can keep modules somewhere outside of
  31 # the "regular" module tree.
  32 #
  33 #
  34 # YAML: list of strings.
  35 modules-search: [ local ]
  36
  37 # Instances section. This section is optional, and it defines custom instances
  38 # for modules of any kind. An instance entry has these keys:
  39 # - *module* name, which matches the module name from the module descriptor
  40 #   (usually the name of the directory under `src/modules/`, but third-
  41 #   party modules may diverge.
  42 # - *id* (optional) an identifier to distinguish this instance from
  43 #   all the others. If none is given, the name of the module is used.
  44 #   Together, the module and id form an instance key (see below).
  45 # - *config* (optional) a filename for the configuration. If none is
  46 #   given, *module*`.conf` is used (e.g. `welcome.conf` for the welcome
  47 #   module)
  48 # - *weight* (optional) In the *exec* phase of the sequence, progress
  49 #   is reported as jobs are completed. The jobs from a single module
  50 #   together contribute the full weight of that module. The overall
  51 #   progress (0 .. 100%) is divided up according to the weight of each
  52 #   module. Give modules that take a lot of time to complete, a larger
  53 #   weight to keep the overall progress moving along steadily. This
  54 #   weight overrides a weight given in the module descriptor. If no weight
  55 #   is given, uses the value from the module descriptor, or 1 if there
  56 #   isn't one there either.
  57 #
  58 # The primary goal of this mechanism is to allow loading multiple instances
  59 # of the same module, with different configuration. If you don't need this,
  60 # the instances section can safely be left empty.
  61 #
  62 # Module name plus instance name makes an instance key, e.g.
  63 # "webview@owncloud", where "webview" is the module name (for the webview
  64 # viewmodule) and "owncloud" is the instance name. In the *sequence*
  65 # section below, use instance-keys to name instances (instead of just
  66 # a module name, for modules which have only a single instance).
  67 #
  68 # Every module implicitly has an instance with the instance name equal
  69 # to its module name, e.g. "welcome@welcome". In the *sequence* section,
  70 # mentioning a module without a full instance key (e.g. "welcome")
  71 # means that implicit module.
  72 #
  73 # An instance may specify its configuration file (e.g. `webview-home.conf`).
  74 # The implicit instances all have configuration files named `<module>.conf`.
  75 # This (implict) way matches the source examples, where the welcome
  76 # module contains an example `welcome.conf`. Specify a *config* for
  77 # any module (also implicit instances) to change which file is used.
  78 #
  79 # For more information on running module instances, run Calamares in debug
  80 # mode and check the Modules page in the Debug information interface.
  81 #
  82 # A module that is often used with instances is shellprocess, which will
  83 # run shell commands specified in the configuration file. By configuring
  84 # more than one instance of the module, multiple shell sessions can be run
  85 # during install.
  86 #
  87 # YAML: list of maps of string:string key-value pairs.
  88 #instances:
  89 #- id:       owncloud
  90 #  module:   webview
  91 #  config:   owncloud.conf
  92
  93 # Sequence section. This section describes the sequence of modules, both
  94 # viewmodules and jobmodules, as they should appear and/or run.
  95 #
  96 # A jobmodule instance key (or name) can only appear in an exec phase, whereas
  97 # a viewmodule instance key (or name) can appear in both exec and show phases.
  98 # There is no limit to the number of show or exec phases. However, the same
  99 # module instance key should not appear more than once per phase, and
 100 # deployers should take notice that the global storage structure is persistent
 101 # throughout the application lifetime, possibly influencing behavior across
 102 # phases. A show phase defines a sequence of viewmodules (and therefore
 103 # pages). These viewmodules can offer up jobs for the execution queue.
 104 #
 105 # An exec phase displays a progress page (with brandable slideshow). This
 106 # progress page iterates over the modules listed in the *immediately
 107 # preceding* show phase, and enqueues their jobs, as well as any other jobs
 108 # from jobmodules, in the order defined in the current exec phase.
 109 #
 110 # It then executes the job queue and clears it. If a viewmodule offers up a
 111 # job for execution, but the module name (or instance key) isn't listed in the
 112 # immediately following exec phase, this job will not be executed.
 113 #
 114 # YAML: list of lists of strings.
 115 sequence:
 116 - show:
 117   - welcome
 118   - locale
 119   - keyboard
 120   - partition
 121   - users
 122   - summary
 123 - exec:
 124   - partition
 125   - mount
 126   - unpackfs
 127   - machineid
 128   - fstab
 129   - locale
 130   - keyboard
 131   - localecfg
 132   - shellprocess
 133   - luksopenswaphookcfg
 134   - luksbootkeyfile
 135   - plymouthcfg
 136   - initcpiocfg
 137   - initcpio
 138   - removeuser
 139   - users
 140   - displaymanager
 141   - networkcfg
 142   - hwclock
 143   - services-systemd
 144   - grubcfg
 145   - bootloader
 146   - postcfg
 147   - packages
 148   - umount
 149 - show:
 150   - finished
 151
 152 # A branding component is a directory, either in SHARE/calamares/branding or
 153 # in /etc/calamares/branding (the latter takes precedence). The directory must
 154 # contain a YAML file branding.desc which may reference additional resources
 155 # (such as images) as paths relative to the current directory.
 156 #
 157 # A branding component can also ship a QML slideshow for execution pages,
 158 # along with translation files.
 159 #
 160 # Only the name of the branding component (directory) should be specified
 161 # here, Calamares then takes care of finding it and loading the contents.
 162 #
 163 # YAML: string.
 164 branding: alter
 165
 166 # If this is set to true, Calamares will show an "Are you sure?" prompt right
 167 # before each execution phase, i.e. at points of no return. If this is set to
 168 # false, no prompt is shown. Default is false, but Calamares will complain if
 169 # this is not explicitly set.
 170 #
 171 # YAML: boolean.
 172 prompt-install: false
 173
 174 # If this is set to true, Calamares will execute all target environment
 175 # commands in the current environment, without chroot. This setting should
 176 # only be used when setting up Calamares as a post-install configuration tool,
 177 # as opposed to a full operating system installer.
 178 #
 179 # Some official Calamares modules are not expected to function with this
 180 # setting. (e.g. partitioning seems like a bad idea, since that is expected to
 181 # have been done already)
 182 #
 183 # Default is false (for a normal installer), but Calamares will complain if
 184 # this is not explicitly set.
 185 #
 186 # YAML: boolean.
 187 dont-chroot: false
 188
 189 # If this is set to true, Calamares refers to itself as a "setup program"
 190 # rather than an "installer". Defaults to the value of dont-chroot, but
 191 # Calamares will complain if this is not explicitly set.
 192 oem-setup: false
 193
 194 # If this is set to true, the "Cancel" button will be disabled entirely.
 195 # The button is also hidden from view.
 196 #
 197 # This can be useful if when e.g. Calamares is used as a post-install
 198 # configuration tool and you require the user to go through all the
 199 # configuration steps.
 200 #
 201 # Default is false, but Calamares will complain if this is not explicitly set.
 202 #
 203 # YAML: boolean.
 204 disable-cancel: false
 205
 206 # If this is set to true, the "Cancel" button will be disabled once
 207 # you start the 'Installation', meaning there won't be a way to cancel
 208 # the Installation until it has finished or installation has failed.
 209 #
 210 # Default is false, but Calamares will complain if this is not explicitly set.
 211 #
 212 # YAML: boolean.
 213 disable-cancel-during-exec: false
 214
 215 # If this is set to true, the "Next" and "Back" button will be hidden once
 216 # you start the 'Installation'.
 217 #
 218 # Default is false, but Calamares will complain if this is not explicitly set.
 219 #
 220 # YAML: boolean.
 221 hide-back-and-next-during-exec: false
 222
 223 # If this is set to true, then once the end of the sequence has
 224 # been reached, the quit (done) button is clicked automatically
 225 # and Calamares will close. Default is false: the user will see
 226 # that the end of installation has been reached, and that things are ok.
 227 #
 228 #
 229 quit-at-end: false