diff options
Diffstat (limited to 'linhes/linhes-dev/LinHES9_iso/cust_skel/airootfs/etc/calamares/settings.conf')
| -rw-r--r-- | linhes/linhes-dev/LinHES9_iso/cust_skel/airootfs/etc/calamares/settings.conf | 243 |
1 files changed, 243 insertions, 0 deletions
diff --git a/linhes/linhes-dev/LinHES9_iso/cust_skel/airootfs/etc/calamares/settings.conf b/linhes/linhes-dev/LinHES9_iso/cust_skel/airootfs/etc/calamares/settings.conf new file mode 100644 index 0000000..e7cba3e --- /dev/null +++ b/linhes/linhes-dev/LinHES9_iso/cust_skel/airootfs/etc/calamares/settings.conf @@ -0,0 +1,243 @@ +# SPDX-FileCopyrightText: no +# SPDX-License-Identifier: CC0-1.0 +# +# Configuration file for Calamares +# +# This is the top-level configuration file for Calamares. +# It specifies what modules will be used, as well as some +# overall characteristics -- is this a setup program, or +# an installer. More specific configuration is devolved +# to the branding file (for the UI) and the individual +# module configuration files (for functionality). +--- +# 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 these keys: +# - *module* name, which matches the module name from the module descriptor +# (usually the name of the directory under `src/modules/`, but third- +# party modules may diverge. +# - *id* (optional) an identifier to distinguish this instance from +# all the others. If none is given, the name of the module is used. +# Together, the module and id form an instance key (see below). +# - *config* (optional) a filename for the configuration. If none is +# given, *module*`.conf` is used (e.g. `welcome.conf` for the welcome +# module) +# - *weight* (optional) In the *exec* phase of the sequence, progress +# is reported as jobs are completed. The jobs from a single module +# together contribute the full weight of that module. The overall +# progress (0 .. 100%) is divided up according to the weight of each +# module. Give modules that take a lot of time to complete, a larger +# weight to keep the overall progress moving along steadily. This +# weight overrides a weight given in the module descriptor. If no weight +# is given, uses the value from the module descriptor, or 1 if there +# isn't one there either. +# +# 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 may 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`. Specify a *config* for +# any module (also implicit instances) to change which file is used. +# +# 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. + +instances: +- id: before + module: shellprocess + config: shellprocess-before.conf +- id: final + module: shellprocess + config: shellprocess-final.conf + + +sequence: +- show: + - welcome +# - notesqml + - locale + - keyboard + - partition + - users +# - tracking + - summary +- exec: + - partition +# - zfs + - mount + - unpackfs + - machineid + - fstab + - locale + - keyboard + - localecfg + - luksbootkeyfile + - luksopenswaphookcfg + - initcpiocfg + - initcpio + - removeuser + - users + - displaymanager + - networkcfg + - hwclock +# - services-systemd + - shellprocess@before + - packages + - grubcfg + - bootloader + - shellprocess@final + - preservefiles + - umount +- show: +# - webview@owncloud + - 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: LinHES + +# 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: false + +# 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, the "Next" and "Back" button will be hidden once +# you start the 'Installation'. +# +# Default is false, but Calamares will complain if this is not explicitly set. +# +# YAML: boolean. +hide-back-and-next-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 |