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