123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149 |
- # 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
- # - 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
|