1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
|
# 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
- luksbootkeyfile
- dracutlukscfg
- openrcdmcryptcfg
- users
- displaymanager
- hwclock
- dracut
- packages
- grubcfg
- bootloader
- 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: redcore_branding
# 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: true
# 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: false
# 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
# If this is set to true, then once the end of the sequence has
# been reached, the quit (done) button is clicked automatically
# and Calamares will close. Default is false: the user will see
# that the end of installation has been reached, and that things are ok.
#
#
quit-at-end: false
|
