settings.conf

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