# 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/moduleswith
#   - settings in SHARE/calamares/modules or /etc/calamares/modules.
#
# 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 instance name, a module
# 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, which loads a configuration
# file named "owncloud.conf" from any of the configuration file paths,
# including the webview module directory. This instance key can then be
# referenced in the sequence section.
#
# For all modules without a custom instance specification, a default instance
# is generated automatically by Calamares. Therefore a statement such as
# "webview" in the sequence section automatically implies an instance key of
# "webview@webview" even without explicitly defining this instance, and the
# configuration file for this default instance "<modulename>@<modulename>" is
# always assumed to be "<modulename>.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 dummyprocess, which will
# run a single (shell) command. By configuring more than one instance of
# the module, multiple shell commands 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
#  - dummypythonqt
  - locale
  - keyboard
  - partition
  - users
#  - tracking
  - summary
- exec:
#  - dummycpp
#  - dummyprocess
#  - dummypython
#  - dummypythonqt
  - partition
  - mount
  - unpackfs
  - machineid
  - fstab
  - locale
  - keyboard
  - localecfg
#  - luksbootkeyfile
#  - luksopenswaphookcfg
#  - dracutlukscfg
#  - plymouthcfg
  - initcpiocfg
  - initcpio
  - users
  - displaymanager
  - networkcfg
  - hwclock
  - services-systemd
#  - dracut
  - initramfs
#  - grubcfg
  - bootloader
  - 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: default

# 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.
#
# 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).
#
# YAML: boolean.
dont-chroot: false

# If this is set to true, the "Cancel" button will be disabled.
# 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.
#
# YAML: boolean.
disable-cancel: false