From 2315da16b798197c06be56305dfdbff4ff7321b8 Mon Sep 17 00:00:00 2001 From: V3n3RiX Date: Sun, 6 Nov 2016 11:36:56 +0000 Subject: calamares config && runtime done --- .../calamares-config-redcore/files/settings.conf | 117 +++++++++++++++++++++ 1 file changed, 117 insertions(+) create mode 100644 app-misc/calamares-config-redcore/files/settings.conf (limited to 'app-misc/calamares-config-redcore/files/settings.conf') 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 "@" is always assumed to be +# ".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 -- cgit v1.2.3