Calamares - distribution indipendent installer
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

settings.conf 7.1KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191
  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/modules, with
  11. # - settings in SHARE/calamares/modules or /etc/calamares/modules.
  12. # In debug-mode (e.g. calamares -d) "local" also adds some paths
  13. # that make sense from inside the build-directory, so that you
  14. # can build-and-run with the latest modules immediately.
  15. #
  16. # Strings other than "local" are taken as paths and interpreted
  17. # relative to wherever Calamares is started. It is therefore **strongly**
  18. # recommended to use only absolute paths here. This is mostly useful
  19. # if your distro has forks of standard Calamares modules, but also
  20. # uses some form of upstream packaging which might overwrite those
  21. # forked modules -- then you can keep modules somewhere outside of
  22. # the "regular" module tree.
  23. #
  24. #
  25. # YAML: list of strings.
  26. modules-search: [ local ]
  27. # Instances section. This section is optional, and it defines custom instances
  28. # for modules of any kind. An instance entry has an module name, an instance
  29. # name, and a configuration file name. The primary goal of this mechanism is
  30. # to allow loading multiple instances of the same module, with different
  31. # configuration. If you don't need this, the instances section can safely be
  32. # left empty.
  33. #
  34. # Module name plus instance name makes an instance key, e.g.
  35. # "webview@owncloud", where "webview" is the module name (for the webview
  36. # viewmodule) and "owncloud" is the instance name. In the *sequence*
  37. # section below, use instance-keys to name instances (instead of just
  38. # a module name, for modules which have only a single instance).
  39. #
  40. # Every module implicitly has an instance with the instance name equal
  41. # to its module name, e.g. "welcome@welcome". In the *sequence* section,
  42. # mentioning a module without a full instance key (e.g. "welcome")
  43. # means that implicit module.
  44. #
  45. # An instance must specify its configuration file (e.g. `webview-home.conf`).
  46. # The implicit instances all have configuration files named `<module>.conf`.
  47. # This (implict) way matches the source examples, where the welcome
  48. # module contains an example `welcome.conf`.
  49. #
  50. # For more information on running module instances, run Calamares in debug
  51. # mode and check the Modules page in the Debug information interface.
  52. #
  53. # A module that is often used with instances is shellprocess, which will
  54. # run shell commands specified in the configuration file. By configuring
  55. # more than one instance of the module, multiple shell sessions can be run
  56. # during install.
  57. #
  58. # YAML: list of maps of string:string key-value pairs.
  59. #instances:
  60. #- id: owncloud
  61. # module: webview
  62. # config: owncloud.conf
  63. # Sequence section. This section describes the sequence of modules, both
  64. # viewmodules and jobmodules, as they should appear and/or run.
  65. #
  66. # A jobmodule instance key (or name) can only appear in an exec phase, whereas
  67. # a viewmodule instance key (or name) can appear in both exec and show phases.
  68. # There is no limit to the number of show or exec phases. However, the same
  69. # module instance key should not appear more than once per phase, and
  70. # deployers should take notice that the global storage structure is persistent
  71. # throughout the application lifetime, possibly influencing behavior across
  72. # phases. A show phase defines a sequence of viewmodules (and therefore
  73. # pages). These viewmodules can offer up jobs for the execution queue.
  74. #
  75. # An exec phase displays a progress page (with brandable slideshow). This
  76. # progress page iterates over the modules listed in the *immediately
  77. # preceding* show phase, and enqueues their jobs, as well as any other jobs
  78. # from jobmodules, in the order defined in the current exec phase.
  79. #
  80. # It then executes the job queue and clears it. If a viewmodule offers up a
  81. # job for execution, but the module name (or instance key) isn't listed in the
  82. # immediately following exec phase, this job will not be executed.
  83. #
  84. # YAML: list of lists of strings.
  85. sequence:
  86. - show:
  87. - welcome
  88. # - dummypythonqt
  89. - locale
  90. - keyboard
  91. - partition
  92. - users
  93. # - tracking
  94. - summary
  95. - exec:
  96. # - dummycpp
  97. # - dummyprocess
  98. # - dummypython
  99. # - dummypythonqt
  100. - partition
  101. - mount
  102. - unpackfs
  103. - machineid
  104. - fstab
  105. - locale
  106. - keyboard
  107. - localecfg
  108. # - luksbootkeyfile
  109. # - luksopenswaphookcfg
  110. # - dracutlukscfg
  111. # - plymouthcfg
  112. - initcpiocfg
  113. - initcpio
  114. - users
  115. - displaymanager
  116. - networkcfg
  117. - hwclock
  118. - services-systemd
  119. # - dracut
  120. - initramfs
  121. # - grubcfg
  122. - bootloader
  123. - umount
  124. - show:
  125. # - webview@owncloud
  126. - finished
  127. # A branding component is a directory, either in SHARE/calamares/branding or
  128. # in /etc/calamares/branding (the latter takes precedence). The directory must
  129. # contain a YAML file branding.desc which may reference additional resources
  130. # (such as images) as paths relative to the current directory.
  131. #
  132. # A branding component can also ship a QML slideshow for execution pages,
  133. # along with translation files.
  134. #
  135. # Only the name of the branding component (directory) should be specified
  136. # here, Calamares then takes care of finding it and loading the contents.
  137. #
  138. # YAML: string.
  139. branding: default
  140. # If this is set to true, Calamares will show an "Are you sure?" prompt right
  141. # before each execution phase, i.e. at points of no return. If this is set to
  142. # false, no prompt is shown. Default is false, but Calamares will complain if
  143. # this is not explicitly set.
  144. #
  145. # YAML: boolean.
  146. prompt-install: false
  147. # If this is set to true, Calamares will execute all target environment
  148. # commands in the current environment, without chroot. This setting should
  149. # only be used when setting up Calamares as a post-install configuration tool,
  150. # as opposed to a full operating system installer.
  151. #
  152. # Some official Calamares modules are not expected to function with this
  153. # setting. (e.g. partitioning seems like a bad idea, since that is expected to
  154. # have been done already)
  155. #
  156. # Default is false (for a normal installer), but Calamares will complain if
  157. # this is not explicitly set.
  158. #
  159. # YAML: boolean.
  160. dont-chroot: false
  161. # If this is set to true, Calamares refers to itself as a "setup program"
  162. # rather than an "installer". Defaults to the value of dont-chroot, but
  163. # Calamares will complain if this is not explicitly set.
  164. # oem-setup: true
  165. # If this is set to true, the "Cancel" button will be disabled entirely.
  166. # The button is also hidden from view.
  167. #
  168. # This can be useful if when e.g. Calamares is used as a post-install
  169. # configuration tool and you require the user to go through all the
  170. # configuration steps.
  171. #
  172. # Default is false, but Calamares will complain if this is not explicitly set.
  173. #
  174. # YAML: boolean.
  175. disable-cancel: false
  176. # If this is set to true, the "Cancel" button will be disabled once
  177. # you start the 'Installation', meaning there won't be a way to cancel
  178. # the Installation until it has finished or installation has failed.
  179. #
  180. # Default is false, but Calamares will complain if this is not explicitly set.
  181. #
  182. # YAML: boolean.
  183. disable-cancel-during-exec: false