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