1 files changed, 117 insertions, 0 deletions
diff --git a/app-misc/calamares-config-redcore/files/settings.conf b/app-misc/calamares-config-redcore/files/settings.conf
new file mode 100644
index 00000000..91f9fe80
--- /dev/null
+++ b/app-misc/calamares-config-redcore/files/settings.conf
@@ -0,0 +1,117 @@
+# 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 LIBDIR/calamares/modules with 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.
+# 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.
+# WARNING: when upgrading from Calamares 1.1, this section requires manual
+# intervention. There are no fixed prepare/install/postinstall phases any more,
+# and all limitations on the number of phases, number of pages, and number of
+# instances are lifted.
+# 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
+  - 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.
+# 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 is considered experimental, and it
+# 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.
+# Packagers beware, here be dragons.
+# Default is false.
+# YAML: boolean.
+dont-chroot: false