Commit 35bdf088 authored by Matthias Klumpp's avatar Matthias Klumpp

Update settings

parent b6ccee26
# Configuration file for Calamares
# Configuration file for Tanglu 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.
# "local" is LIBDIR/calamares/modules with settings in SHARE/calamares/modules
modules-search: [ local, /path/to/dir/with/more/modules ]
# "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 ]
# We define the module names in the order they should show up (QtWidget view modules,
# with one or more pages) OR be executed if enqueued (all other modules).
# Pages can also enqueue jobs for delayed execution in the order specified for the
# install phase.
# 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.
# Phase 1 - prepare.
# View modules are shown as UI pages, jobs from job modules are executed immediately in
# the background.
# Jobs should be executed sparingly (if at all) in this phase.
prepare:
- welcome
- locale
- keyboard
- partition
- users
- summary
#instances:
#- id: owncloud
# module: webview
# config: owncloud.conf
# Phase 2 - install.
# View modules are not shown. Only the view modules shown in the previous phase are
# allowed, their names should be added here as placeholders to specify the order in
# which view module jobs should be enqueued. Job modules are also allowed.
install:
- partition
- mount
- unpackfs
- machineid
- fstab
- locale
- keyboard
- packages
- localecfg
- users
#- displaymanager
- networkcfg
- hwclock
- services
- initramfs
- grubcfg
- bootloader
- umount
# Phase 3 - postinstall.
# View modules are shown as UI pages, jobs from job modules are executed immediately in
# the background.
# Jobs should be executed sparingly (if at all) in this phase.
postinstall: #TODO: actually use this
- finished
# 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
- partition
- users
- summary
- exec:
- partition
- mount
- unpackfs
- machineid
- fstab
- locale
- keyboard
- packages
- localecfg
- users
# - displaymanager
- networkcfg
- hwclock
- services
- initramfs
# - 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: tanglu
# If this is set to true, Calamares will show an "are you sure?" prompt right before the
# install phase, i.e. at the point of no return. If it's false, no prompt is shown.
# 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
---
userGroup: users
defaultGroups:
- cdrom
- floppy
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment