source: calamares/trunk/fuentes/settings.conf @ 7538

Last change on this file since 7538 was 7538, checked in by kbut, 13 months ago

sync with github

File size: 5.4 KB
Line 
1# Configuration file for Calamares
2# Syntax is YAML 1.2
3---
4# Modules can be job modules (with different interfaces) and QtWidgets view
5# modules. They could all be placed in a number of different paths.
6# "modules-search" is a list of strings, each of these can either be a full
7# path to a directory or the keyword "local".
8#
9# "local" means:
10#   - modules in $LIBDIR/calamares/moduleswith
11#   - settings in SHARE/calamares/modules or /etc/calamares/modules.
12#
13# YAML: list of strings.
14modules-search: [ local ]
15
16# Instances section. This section is optional, and it defines custom instances
17# for modules of any kind. An instance entry has an instance name, a module
18# name, and a configuration file name. The primary goal of this mechanism is
19# to allow loading multiple instances of the same module, with different
20# configuration. If you don't need this, the instances section can safely be
21# left empty.
22#
23# Module name plus instance name makes an instance key, e.g.
24# "webview@owncloud", where "webview" is the module name (for the webview
25# viewmodule) and "owncloud" is the instance name, which loads a configuration
26# file named "owncloud.conf" from any of the configuration file paths,
27# including the webview module directory. This instance key can then be
28# referenced in the sequence section.
29#
30# For all modules without a custom instance specification, a default instance
31# is generated automatically by Calamares. Therefore a statement such as
32# "webview" in the sequence section automatically implies an instance key of
33# "webview@webview" even without explicitly defining this instance, and the
34# configuration file for this default instance "<modulename>@<modulename>" is
35# always assumed to be "<modulename>.conf".
36#
37# For more information on running module instances, run Calamares in debug
38# mode and check the Modules page in the Debug information interface.
39#
40# A module that is often used with instances is dummyprocess, which will
41# run a single (shell) command. By configuring more than one instance of
42# the module, multiple shell commands can be run during install.
43#
44# YAML: list of maps of string:string key-value pairs.
45#instances:
46#- id:       owncloud
47#  module:   webview
48#  config:   owncloud.conf
49
50# Sequence section. This section describes the sequence of modules, both
51# viewmodules and jobmodules, as they should appear and/or run.
52#
53# A jobmodule instance key (or name) can only appear in an exec phase, whereas
54# a viewmodule instance key (or name) can appear in both exec and show phases.
55# There is no limit to the number of show or exec phases. However, the same
56# module instance key should not appear more than once per phase, and
57# deployers should take notice that the global storage structure is persistent
58# throughout the application lifetime, possibly influencing behavior across
59# phases. A show phase defines a sequence of viewmodules (and therefore
60# pages). These viewmodules can offer up jobs for the execution queue.
61#
62# An exec phase displays a progress page (with brandable slideshow). This
63# progress page iterates over the modules listed in the *immediately
64# preceding* show phase, and enqueues their jobs, as well as any other jobs
65# from jobmodules, in the order defined in the current exec phase.
66#
67# It then executes the job queue and clears it. If a viewmodule offers up a
68# job for execution, but the module name (or instance key) isn't listed in the
69# immediately following exec phase, this job will not be executed.
70#
71# YAML: list of lists of strings.
72sequence:
73- show:
74  - welcome
75#  - dummypythonqt
76  - locale
77  - keyboard
78  - partition
79  - users
80#  - tracking
81  - summary
82- exec:
83#  - dummycpp
84#  - dummyprocess
85#  - dummypython
86#  - dummypythonqt
87  - partition
88  - mount
89  - unpackfs
90  - machineid
91  - fstab
92  - locale
93  - keyboard
94  - localecfg
95#  - luksbootkeyfile
96#  - luksopenswaphookcfg
97#  - dracutlukscfg
98#  - plymouthcfg
99  - initcpiocfg
100  - initcpio
101  - users
102  - displaymanager
103  - networkcfg
104  - hwclock
105  - services
106#  - dracut
107  - initramfs
108#  - grubcfg
109  - bootloader
110  - umount
111- show:
112#  - webview@owncloud
113  - finished
114
115# A branding component is a directory, either in SHARE/calamares/branding or
116# in /etc/calamares/branding (the latter takes precedence). The directory must
117# contain a YAML file branding.desc which may reference additional resources
118# (such as images) as paths relative to the current directory.
119#
120# A branding component can also ship a QML slideshow for execution pages,
121# along with translation files.
122#
123# Only the name of the branding component (directory) should be specified
124# here, Calamares then takes care of finding it and loading the contents.
125#
126# YAML: string.
127branding: default
128
129# If this is set to true, Calamares will show an "Are you sure?" prompt right
130# before each execution phase, i.e. at points of no return. If this is set to
131# false, no prompt is shown. Default is false.
132#
133# YAML: boolean.
134prompt-install: false
135
136# If this is set to true, Calamares will execute all target environment
137# commands in the current environment, without chroot. This setting should
138# only be used when setting up Calamares as a post-install configuration tool,
139# as opposed to a full operating system installer.
140#
141# Some official Calamares modules are not expected to function with this
142# setting. (e.g. partitioning seems like a bad idea, since that is expected to
143# have been done already)
144#
145# Default is false (for a normal installer).
146#
147# YAML: boolean.
148dont-chroot: false
Note: See TracBrowser for help on using the repository browser.