From 06bc8df6c0461f422f8187df785bda6d273e5241 Mon Sep 17 00:00:00 2001 From: "Eshan Roy (Eshanized)" Date: Fri, 12 Apr 2024 04:13:19 +0530 Subject: [PATCH] =?UTF-8?q?=E2=8F=B3=20@eshanized=20updated=20the=20reposi?= =?UTF-8?q?tory!!!?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- calamares/settings.conf | 288 ++++++++++++++++++++++++++-------------- 1 file changed, 192 insertions(+), 96 deletions(-) diff --git a/calamares/settings.conf b/calamares/settings.conf index d3b5fee..f2aaae4 100644 --- a/calamares/settings.conf +++ b/calamares/settings.conf @@ -1,100 +1,122 @@ +# 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. +# "packagechooserq@licenseq", where "packagechooserq" is the module name (for the packagechooserq +# viewmodule) and "licenseq" 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 `.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: kernel - module: netinstall - config: netinstall-kernel.conf -- id: drivers - module: netinstall - config: netinstall-drivers.conf -- id: nvidia - module: netinstall - config: netinstall-nvidia.conf -- id: services - module: netinstall - config: netinstall-services.conf -- id: login - module: netinstall - config: netinstall-login.conf -- id: desktop - module: netinstall - config: netinstall-desktop.conf -- id: arcolinux - module: netinstall - config: netinstall-arcolinux.conf -- id: communication - module: netinstall - config: netinstall-communication.conf -- id: development - module: netinstall - config: netinstall-development.conf -- id: office - module: netinstall - config: netinstall-office.conf -- id: fonts - module: netinstall - config: netinstall-fonts.conf -- id: multimedia - module: netinstall - config: netinstall-multimedia.conf -- id: internet - module: netinstall - config: netinstall-internet.conf -- id: theming - module: netinstall - config: netinstall-theming.conf -- id: graphics - module: netinstall - config: netinstall-graphics.conf -- id: gaming - module: netinstall - config: netinstall-gaming.conf -- id: terminals - module: netinstall - config: netinstall-terminals.conf -- id: filemanagers - module: netinstall - config: netinstall-filemanagers.conf -- id: utilitiesusb - module: netinstall - config: netinstall-usb.conf -- id: utilities - module: netinstall - config: netinstall-utilities.conf -- id: applications - module: netinstall - config: netinstall-applications.conf -- id: arcolinuxdev - module: netinstall - config: netinstall-arcolinuxdev.conf -- id: rootfs - module: unpackfs - config: unpackfs1.conf - weight: 50 -- id: vmlinuz - module: unpackfs - config: unpackfs2.conf - weight: 1 -- id: choice - module: packages - config: packages.conf - weight: 20 -- id: before - module: shellprocess - config: shellprocess-before.conf -- id: final - module: shellprocess - config: shellprocess-final.conf -- id: linux - module: initcpio - config: initcpio-linux.conf -- id: linux-zen - module: initcpio - config: initcpio-linux-zen.conf +- id: licenseq + module: packagechooserq + config: licenseq.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 +# - notesqml +# - packagechooserq@licenseq - locale - keyboard - partition @@ -102,7 +124,11 @@ sequence: # - tracking - summary - exec: +# - dummycpp +# - dummyprocess +# - dummypython - partition +# - zfs - mount - unpackfs@rootfs - unpackfs@vmlinuz @@ -113,19 +139,26 @@ sequence: - localecfg - luksbootkeyfile - luksopenswaphookcfg + - shellprocess@before +# - dracutlukscfg +# - plymouthcfg +# - zfshostid - initcpiocfg - - initcpio@linux - - initcpio@linux-zen + - initcpio + # - users + # - displaymanager - networkcfg - hwclock - - services-systemd - - shellprocess@before - packages@choice - removeuser - users - displaymanager - ucode - grubcfg + # - services-systemd +# - dracut + - initramfs +# - grubcfg - bootloader - shellprocess@final - preservefiles @@ -133,18 +166,81 @@ sequence: - 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: snigdhaos -prompt-install: true +# 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 -quit-at-end: 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 \ No newline at end of file