154 lines
		
	
	
		
			5.9 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			154 lines
		
	
	
		
			5.9 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
# 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, /run/current-system/sw/lib/calamares/modules ]
 | 
						|
 | 
						|
# 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
 | 
						|
  - users
 | 
						|
  - partition
 | 
						|
  - summary
 | 
						|
- exec:
 | 
						|
  - partition
 | 
						|
  - mount
 | 
						|
  - desk_os
 | 
						|
  - users
 | 
						|
  - 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: desk_os
 | 
						|
 | 
						|
# 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
 |