Several configuration keys are lists of commands to be executed. Each command can be a string (in which case it is executed via :command:`sh -c`) or a list, in which case it is executed directly. Any command exiting with a non-zero return code is considered an error and aborts the installation (except for error-commands, where it is ignored).
This example stops on the network screen and allows the user to change the defaults. If a value is provided for an interactive section, it is used as the default.
You can use the special section name of ``*`` to indicate that the installer should ask all the usual questions -- in this case, the :file:`autoinstall.yaml` file is an autoinstall file. It just provides a way to change the defaults in the UI.
A list of shell commands to invoke as soon as the installer starts, in particular before probing for block and network devices. The autoinstall configuration is available at :file:`/autoinstall.yaml` (irrespective of how it was provided), and the file is re-read after the ``early-commands`` have run to allow them to alter the configuration if necessary.
The layout of any attached keyboard. The mapping keys correspond to settings in the :file:`/etc/default/keyboard` configuration file. See the :manualpage:`keyboard(5) manual page <man5/keyboard.5.html>` for more details.
Whether the installer searches for available third-party drivers. When set to ``false``, it disables the drivers :ref:`screen and section<ai-drivers>`.
The default is ``true`` for most installations, and ``false`` when a "core boot" or "enhanced secure boot" method is selected (where third-party drivers cannot be currently installed).
`Netplan-formatted <https://netplan.io/reference>`_ network configuration. This is applied during installation as well as in the installed system. The default is to interpret the configuration for the installation media, which runs DHCP version 4 on any interface with a name matching ``eth*`` or ``en*`` but then disables any interface that does not receive an address.
This section historically used the same format as curtin, which is documented in the `APT Source <https://curtin.readthedocs.io/en/latest/topics/apt_source.html>`_ section of the curtin documentation. Nonetheless, some key differences with the format supported by curtin have been introduced:
- Subiquity supports an alternative format for the ``primary`` section, allowing configuration of a list of candidate primary mirrors. During installation, Subiquity automatically tests the specified mirrors and selects the first one that appears usable. This new behaviour is only activated when the ``primary`` section is wrapped in the ``mirror-selection`` section.
If the ``primary`` section is contained within the ``mirror-selection`` section, the automatic mirror selection is enabled. This is the default in new installations.
If ``geoip`` is set to ``true`` and one of the candidate primary mirrors has the special value ``country-mirror``, a request is made to ``https://geoip.ubuntu.com/lookup``. Subiquity then sets the mirror URI to ``http://CC.archive.ubuntu.com/ubuntu`` (or similar for ports) where ``CC`` is the country code returned by the lookup. If this section is not interactive, the request expires after 10 seconds.
If the legacy behaviour (i.e., without mirror-selection) is in use, the geolocation request is made if the mirror to be used is the default, and its URI is replaced by the proper country mirror URI.
Storage configuration is a complex topic, and the description of the desired configuration in the autoinstall file can also be complex. The installer supports "layouts"; simple ways of expressing common configurations.
The ``lvm`` layout, by default, attempts to leave room for snapshots and further expansion. A sizing-policy key may be supplied to control this behaviour.
``reset-partition`` is used for creating a Reset Partition, which is a FAT32 file system containing the entire content of the installer image, so that the user can start the installer from GRUB or EFI without using the installation media. This option is useful for OEM system provisioning.
By default, the size of a Reset Partition is roughly 1.1x the used file system size of the installation media.
An example to enable Reset Partition:
..code-block:: yaml
storage:
layout:
name: direct
reset-partition: true
The size of the reset partition can also be fixed to a specified size. This is an example to fix Reset Partition to 12 GiB:
..code-block:: yaml
storage:
layout:
name: direct
reset-partition: 12G
The installer can also install Reset Partition without installing the system. To do this, set ``reset-partition-only`` to ``true``:
For full flexibility, the installer allows storage configuration to be done using a syntax that is a superset of that supported by curtin, as described in the `Storage <https://curtin.readthedocs.io/en/latest/topics/storage.html>`_ section of the curtin documentation.
The list of actions can be added under the ``config`` key, and the `grub <https://curtin.readthedocs.io/en/latest/topics/config.html#grub>`_ and `swap <https://curtin.readthedocs.io/en/latest/topics/config.html#swap>`_
curtin configuration items can also be included here.
Curtin supported identifying disks by serial numbers (e.g. ``Crucial_CT512MX100SSD1_14250C57FECE``) or by path (e.g. ``/dev/sdc``), and the server installer supports this, too. The installer additionally supports a "match spec" on a disk action, which provides for more flexible matching.
The actions in the storage configuration are processed in the order they are in the autoinstall file. Any disk action is assigned a matching disk -- chosen arbitrarily from the set of unassigned disks if there is more than one, and causing the installation to fail if there is no unassigned matching disk.
*``path: value``: matches a disk based on path (e.g. ``/dev/sdc``), supporting globbing (the globbing support distinguishes this from specifying ``path: value`` directly in the disk action)
*``id_path: value``: matches a disk where ``ID_PATH=value`` in udev, supporting globbing
*``devpath: value``: matches a disk where ``DEVPATH=value`` in udev, supporting globbing
*``serial: value``: matches a disk where ``ID_SERIAL=value`` in udev, supporting globbing (the globbing support distinguishes this from specifying ``serial: value`` directly in the disk action)
*``ssd: true|false``: matches a disk that is or is not an SSD (as opposed to a rotating drive)
*``size: largest|smallest``: take the largest or smallest disk rather than an arbitrary one if there are multiple matches (support for ``smallest`` added in version 20.06.1)
A special sort of key is ``install-media: true``, which takes the disk the installer was loaded from (the ``ssd`` and ``size`` selectors never return this disk). If installing to the installation media, be careful to not overwrite the installer itself.
* For the last partition specified for a particular device, you can specify the size as ``-1`` to indicate that the partition should fill the remaining space.
Configure the initial user for the system. This is the only configuration key that must be present (unless the :ref:`user-data section <ai-user-data>` is present, in which case it is optional).
The encrypted password string must conform to what the ``passwd`` command requires. See the :manualpage:`passwd(1) manual page <man1/passwd.1.html>` for details. Quote the password hash to ensure correct treatment of any special characters.
Whether to install the available OEM meta-packages. The special value ``auto`` -- which is the default -- enables the installation on Ubuntu Desktop but not on Ubuntu Server. This option has no effect on core boot classic.
A list of snaps to install. Each snap is represented as a mapping with a required ``name`` and an optional ``channel`` (default is ``stable``) and classic (default is ``false``) keys. For example:
A list of packages to install into the target system. Specifically, a list of strings to pass to the :command:`apt-get install` command. Therefore, this includes things such as task selection (``dns-server^``) and installing particular versions of a package (``my-package=1-1``).
Shell commands to run after the installation has completed successfully and any updates and packages installed, just before the system reboots. The commands are run in the installer environment with the installed system mounted at ``/target``. You can run ``curtin in-target -- $shell_command`` (with the version of Subiquity
released with 20.04 GA, you need to specify this as ``curtin in-target --target=/target -- $shell_command``) to run in the target system (similar to how plain ``in-target`` can be used in ``d-i preseed/late_command``).
Shell commands to run after the installation has failed. They are run in the installer environment, and the target system (or as much of it as the installer managed to configure) is mounted at ``/target``. Logs will be available in :file:`/var/log/installer` in the live session.
The installer supports reporting progress to a variety of destinations. Note that this section is ignored if there are any :ref:`interactive sections <ai-interactive-sections>`; it only applies to fully automated installations.
The configuration is similar to that used by curtin. See the `Reporting <https://curtin.readthedocs.io/en/latest/topics/reporting.html>`_ section of the curtin documentation.
*``print``: print progress information on ``tty1`` and any configured serial console. There is no other configuration.
*``rsyslog``: report progress via rsyslog. The ``destination`` key specifies where to send output. (The rsyslog reporter does not yet exist.)
*``webhook``: report progress by sending JSON reports to a URL using POST requests. Accepts the same `configuration as curtin <https://curtin.readthedocs.io/en/latest/topics/reporting.html#webhook-reporter>`_.
*``none``: do not report progress. Only useful to inhibit the default output.
Provide cloud-init user data, which will be merged with the user data the installer produces. If you supply this, you don't need to supply an :ref:`identity section <ai-identity>` (in that case, ensure you can log in to the installed system).