1
0
mirror of https://github.com/systemd/systemd.git synced 2024-12-23 21:35:11 +03:00
systemd/man/systemd-gpt-auto-generator.xml

349 lines
21 KiB
XML
Raw Normal View History

<?xml version="1.0"?> <!--*-nxml-*-->
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
<refentry id="systemd-gpt-auto-generator" conditional='HAVE_BLKID'
xmlns:xi="http://www.w3.org/2001/XInclude">
2013-08-13 23:57:43 +04:00
2015-02-04 05:14:13 +03:00
<refentryinfo>
<title>systemd-gpt-auto-generator</title>
<productname>systemd</productname>
</refentryinfo>
<refmeta>
<refentrytitle>systemd-gpt-auto-generator</refentrytitle>
<manvolnum>8</manvolnum>
</refmeta>
<refnamediv>
<refname>systemd-gpt-auto-generator</refname>
<refpurpose>Generator for automatically discovering and mounting root, <filename>/home/</filename>,
<filename>/srv/</filename>, <filename>/var/</filename> and <filename>/var/tmp/</filename> partitions, as
well as discovering and enabling swap partitions, based on GPT partition type GUIDs</refpurpose>
2015-02-04 05:14:13 +03:00
</refnamediv>
<refsynopsisdiv>
<para><filename>/usr/lib/systemd/system-generators/systemd-gpt-auto-generator</filename></para>
2015-02-04 05:14:13 +03:00
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para><filename>systemd-gpt-auto-generator</filename> is a unit generator that automatically discovers
gpt-auto-generator: rework/simplify logic for picking /efi or /boot I started looking into https://github.com/uapi-group/specifications/issues/35. BLS says: > Otherwise [no existing XBOOTLDR partition], if on GPT and an ESP is found and > it is large enough (let’s say at least 1G) it should be used as $BOOT and > used as primary location to place boot loader menu resources in. > It is recommended to mount $BOOT to /boot/, and the ESP to /efi/. DPS says: > The ESP used for the current boot is automatically mounted to /efi/ (or > /boot/ as fallback), unless a different partition is mounted there (possibly > via /etc/fstab, or because the Extended Boot Loader Partition — see below — > exists) or the directory is non-empty on the root disk. I don't think we want to mount the same partition in two places. If the same partition is not mounted in two places, then the two specs are contradictory. The code in gpt-auto-generator implemented the logic from the DPS. It is modified to implement the logic from BLS. Effectively: - if both /boot and /efi are available: - if both XBOOTLDR and ESP exist: ESP on /efi, XBOOTLDR on /boot - if only ESP exists: ESP on /boot - if only XBOOTLDR exists: XBOOTLDR on /boot - if only /boot is available: - if XBOOTLDR exists: XBOOTLDR on /boot - if only ESP exists: ESP on /boot - if only /efi is available: - if ESP exists: ESP on /efi "Available" means that it the mount point is not mounted over and does not contain files. If the directory doesn't exist, it is also "available" and will be created later when the mount or automount unit is started. Thus, the generator attempts to match the partitions and mount points to the extent possible. In all cases, /boot is the primary place to install kernels. ESP can be found on /boot or /efi, depending on the situation. If this patch is merged, I'll submit fixes for BLS and DPS to describe the same logic.
2023-04-05 18:10:16 +03:00
the root partition, <filename>/home/</filename>, <filename>/srv/</filename>, <filename>/var/</filename>,
<filename>/var/tmp/</filename>, the EFI System Partition (ESP), the Extended Boot Loader Partition
(XBOOTLDR), and swap partitions and creates mount and swap units for them, based on the partition type
GUIDs of GUID partition tables (GPT). See <ulink url="https://uefi.org/specifications">UEFI
Specification</ulink>, chapter 5 for more details. It implements the <ulink
gpt-auto-generator: rework/simplify logic for picking /efi or /boot I started looking into https://github.com/uapi-group/specifications/issues/35. BLS says: > Otherwise [no existing XBOOTLDR partition], if on GPT and an ESP is found and > it is large enough (let’s say at least 1G) it should be used as $BOOT and > used as primary location to place boot loader menu resources in. > It is recommended to mount $BOOT to /boot/, and the ESP to /efi/. DPS says: > The ESP used for the current boot is automatically mounted to /efi/ (or > /boot/ as fallback), unless a different partition is mounted there (possibly > via /etc/fstab, or because the Extended Boot Loader Partition — see below — > exists) or the directory is non-empty on the root disk. I don't think we want to mount the same partition in two places. If the same partition is not mounted in two places, then the two specs are contradictory. The code in gpt-auto-generator implemented the logic from the DPS. It is modified to implement the logic from BLS. Effectively: - if both /boot and /efi are available: - if both XBOOTLDR and ESP exist: ESP on /efi, XBOOTLDR on /boot - if only ESP exists: ESP on /boot - if only XBOOTLDR exists: XBOOTLDR on /boot - if only /boot is available: - if XBOOTLDR exists: XBOOTLDR on /boot - if only ESP exists: ESP on /boot - if only /efi is available: - if ESP exists: ESP on /efi "Available" means that it the mount point is not mounted over and does not contain files. If the directory doesn't exist, it is also "available" and will be created later when the mount or automount unit is started. Thus, the generator attempts to match the partitions and mount points to the extent possible. In all cases, /boot is the primary place to install kernels. ESP can be found on /boot or /efi, depending on the situation. If this patch is merged, I'll submit fixes for BLS and DPS to describe the same logic.
2023-04-05 18:10:16 +03:00
url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable
Partitions Specification</ulink>.</para>
<para>Note that this generator has no effect on non-GPT systems. It will also not create mount point
configuration for directories which already contain files or if the mount point is explicitly configured
in <citerefentry
project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Additionally
no unit will be created for the ESP or the XBOOTLDR partition if mount entries are found in the
<filename>/boot/</filename> or <filename>/efi/</filename> hierarchies in <citerefentry
project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
<para>If the units this generator creates are overridden, for example by units in directories with higher
gpt-auto-generator: rework/simplify logic for picking /efi or /boot I started looking into https://github.com/uapi-group/specifications/issues/35. BLS says: > Otherwise [no existing XBOOTLDR partition], if on GPT and an ESP is found and > it is large enough (let’s say at least 1G) it should be used as $BOOT and > used as primary location to place boot loader menu resources in. > It is recommended to mount $BOOT to /boot/, and the ESP to /efi/. DPS says: > The ESP used for the current boot is automatically mounted to /efi/ (or > /boot/ as fallback), unless a different partition is mounted there (possibly > via /etc/fstab, or because the Extended Boot Loader Partition — see below — > exists) or the directory is non-empty on the root disk. I don't think we want to mount the same partition in two places. If the same partition is not mounted in two places, then the two specs are contradictory. The code in gpt-auto-generator implemented the logic from the DPS. It is modified to implement the logic from BLS. Effectively: - if both /boot and /efi are available: - if both XBOOTLDR and ESP exist: ESP on /efi, XBOOTLDR on /boot - if only ESP exists: ESP on /boot - if only XBOOTLDR exists: XBOOTLDR on /boot - if only /boot is available: - if XBOOTLDR exists: XBOOTLDR on /boot - if only ESP exists: ESP on /boot - if only /efi is available: - if ESP exists: ESP on /efi "Available" means that it the mount point is not mounted over and does not contain files. If the directory doesn't exist, it is also "available" and will be created later when the mount or automount unit is started. Thus, the generator attempts to match the partitions and mount points to the extent possible. In all cases, /boot is the primary place to install kernels. ESP can be found on /boot or /efi, depending on the situation. If this patch is merged, I'll submit fixes for BLS and DPS to describe the same logic.
2023-04-05 18:10:16 +03:00
precedence, drop-ins and additional dependencies created by this generator might still be used.</para>
2015-02-04 05:14:13 +03:00
<para>This generator will only look for the root partition on the same physical disk where the EFI System
Partition (ESP) is located. Note that support from the boot loader is required: the EFI variable
<varname>LoaderDevicePartUUID</varname> of the <constant>4a67b082-0a4c-41cf-b6c7-440b29bb8c4f</constant>
gpt-auto-generator: rework/simplify logic for picking /efi or /boot I started looking into https://github.com/uapi-group/specifications/issues/35. BLS says: > Otherwise [no existing XBOOTLDR partition], if on GPT and an ESP is found and > it is large enough (let’s say at least 1G) it should be used as $BOOT and > used as primary location to place boot loader menu resources in. > It is recommended to mount $BOOT to /boot/, and the ESP to /efi/. DPS says: > The ESP used for the current boot is automatically mounted to /efi/ (or > /boot/ as fallback), unless a different partition is mounted there (possibly > via /etc/fstab, or because the Extended Boot Loader Partition — see below — > exists) or the directory is non-empty on the root disk. I don't think we want to mount the same partition in two places. If the same partition is not mounted in two places, then the two specs are contradictory. The code in gpt-auto-generator implemented the logic from the DPS. It is modified to implement the logic from BLS. Effectively: - if both /boot and /efi are available: - if both XBOOTLDR and ESP exist: ESP on /efi, XBOOTLDR on /boot - if only ESP exists: ESP on /boot - if only XBOOTLDR exists: XBOOTLDR on /boot - if only /boot is available: - if XBOOTLDR exists: XBOOTLDR on /boot - if only ESP exists: ESP on /boot - if only /efi is available: - if ESP exists: ESP on /efi "Available" means that it the mount point is not mounted over and does not contain files. If the directory doesn't exist, it is also "available" and will be created later when the mount or automount unit is started. Thus, the generator attempts to match the partitions and mount points to the extent possible. In all cases, /boot is the primary place to install kernels. ESP can be found on /boot or /efi, depending on the situation. If this patch is merged, I'll submit fixes for BLS and DPS to describe the same logic.
2023-04-05 18:10:16 +03:00
vendor UUID is used to determine from which partition, and hence the disk, from which the system was
booted. If the boot loader does not set this variable, this generator will not be able to detect the root
partition. See the <ulink url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>
for details.</para>
2015-02-04 05:14:13 +03:00
<para>Similarly, this generator will only look for the other partitions on the same physical disk as the
root partition. In this case, boot loader support is not required. These partitions will not be searched
for on systems where the root file system is distributed on multiple disks, for example via btrfs RAID.
</para>
2015-02-04 05:14:13 +03:00
<para><filename>systemd-gpt-auto-generator</filename> is useful for centralizing file system
configuration in the partition table and making configuration in <filename>/etc/fstab</filename> or on
the kernel command line unnecessary.</para>
2015-02-04 05:14:13 +03:00
<para>This generator looks for the partitions based on their
partition type GUID. The following partition type GUIDs are
identified:</para>
<table>
<title>Partition Type GUIDs</title>
<tgroup cols='5' align='left' colsep='1' rowsep='1'>
<colspec colname="type" />
2015-02-04 05:14:13 +03:00
<colspec colname="guid" />
<colspec colname="name" />
<colspec colname="where" />
2015-02-04 05:14:13 +03:00
<colspec colname="explanation" />
<thead>
<row>
<entry>Partition Type</entry>
<entry>GUID</entry>
2015-02-04 05:14:13 +03:00
<entry>Name</entry>
<entry>Mount Point</entry>
2015-02-04 05:14:13 +03:00
<entry>Explanation</entry>
</row>
</thead>
<tbody>
<row>
<entry><constant>SD_GPT_ROOT_X86_64</constant></entry>
<entry><constant>4f68bce3-e8cd-4db1-96e7-fbcaf984b709</constant></entry>
2015-02-04 05:14:13 +03:00
<entry><filename>Root Partition (x86-64)</filename></entry>
<entry><filename>/</filename></entry>
<entry>The first partition with this type UUID, located on the same disk as the ESP used for booting, is used as the root file system <filename>/</filename> on AMD64 / 64-bit x86 systems.</entry>
2015-02-04 05:14:13 +03:00
</row>
<row>
<entry><constant>SD_GPT_ROOT_ARM64</constant></entry>
<entry><constant>b921b045-1df0-41c3-af44-4c6f280d3fae</constant></entry>
2015-02-04 05:14:13 +03:00
<entry><filename>Root Partition (64-bit ARM)</filename></entry>
<entry><filename>/</filename></entry>
<entry>The first partition with this type UUID, located on the same disk as the ESP used for booting, is used as the root file system <filename>/</filename> on AArch64 / 64-bit ARM systems.</entry>
2015-02-04 05:14:13 +03:00
</row>
<row>
<entry><constant>SD_GPT_ROOT_ALPHA</constant> <constant>SD_GPT_ROOT_ARC</constant> <constant>SD_GPT_ROOT_ARM</constant> <constant>SD_GPT_ROOT_ARM64</constant> <constant>SD_GPT_ROOT_IA64</constant> <constant>SD_GPT_ROOT_LOONGARCH64</constant> <constant>SD_GPT_ROOT_MIPS</constant> <constant>SD_GPT_ROOT_MIPS64</constant> <constant>SD_GPT_ROOT_MIPS_LE</constant> <constant>SD_GPT_ROOT_MIPS64_LE</constant> <constant>SD_GPT_ROOT_PARISC</constant> <constant>SD_GPT_ROOT_PPC</constant> <constant>SD_GPT_ROOT_PPC64</constant> <constant>SD_GPT_ROOT_PPC64_LE</constant> <constant>SD_GPT_ROOT_RISCV32</constant> <constant>SD_GPT_ROOT_RISCV64</constant> <constant>SD_GPT_ROOT_S390</constant> <constant>SD_GPT_ROOT_S390X</constant> <constant>SD_GPT_ROOT_TILEGX</constant> <constant>SD_GPT_ROOT_X86</constant> <constant>SD_GPT_ROOT_X86_64</constant> <constant>SD_GPT_USR_ALPHA</constant> <constant>SD_GPT_USR_ARC</constant> <constant>SD_GPT_USR_ARM</constant> <constant>SD_GPT_USR_IA64</constant> <constant>SD_GPT_USR_LOONGARCH64</constant> <constant>SD_GPT_USR_MIPS_LE</constant> <constant>SD_GPT_USR_MIPS64_LE</constant> <constant>SD_GPT_USR_PARISC</constant> <constant>SD_GPT_USR_PPC</constant> <constant>SD_GPT_USR_PPC64</constant> <constant>SD_GPT_USR_PPC64_LE</constant> <constant>SD_GPT_USR_RISCV32</constant> <constant>SD_GPT_USR_RISCV64</constant> <constant>SD_GPT_USR_S390</constant> <constant>SD_GPT_USR_S390X</constant> <constant>SD_GPT_USR_TILEGX</constant> <constant>SD_GPT_USR_X86</constant></entry>
<entry></entry>
<entry>Root partitions for other architectures</entry>
2021-06-16 11:44:38 +03:00
<entry><filename>/</filename></entry>
<entry>The first partition with the type UUID matching the architecture, located on the same disk as the ESP used for booting, is used as the root file system <filename>/</filename>. For the full list and constant values, see <ulink url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions Specification</ulink>.</entry>
2021-06-16 11:44:38 +03:00
</row>
<row>
<entry><constant>SD_GPT_HOME</constant></entry>
<entry><constant>933ac7e1-2eb4-4f13-b844-0e14e2aef915</constant></entry>
2015-02-04 05:14:13 +03:00
<entry>Home Partition</entry>
<entry><filename>/home/</filename></entry>
<entry>The first partition with this type UUID on the same disk as the root partition is mounted to <filename>/home/</filename>.</entry>
2015-02-04 05:14:13 +03:00
</row>
<row>
<entry><constant>SD_GPT_SRV</constant></entry>
<entry><constant>3b8f8425-20e0-4f3b-907f-1a25a76f98e8</constant></entry>
2015-02-04 05:14:13 +03:00
<entry>Server Data Partition</entry>
<entry><filename>/srv/</filename></entry>
<entry>The first partition with this type UUID on the same disk as the root partition is mounted to <filename>/srv/</filename>.</entry>
</row>
<row>
<entry><constant>SD_GPT_VAR</constant></entry>
<entry><constant>4d21b016-b534-45c2-a9fb-5c16e091fd2d</constant></entry>
<entry>Variable Data Partition</entry>
<entry><filename>/var/</filename></entry>
<entry>The first partition with this type UUID on the same disk as the root partition is mounted to <filename>/var/</filename> — under the condition its partition UUID matches the first 128 bit of the HMAC-SHA256 of the GPT type uuid of this partition keyed by the machine ID of the installation stored in <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</entry>
</row>
<row>
<entry><constant>SD_GPT_TMP</constant></entry>
<entry><constant>7ec6f557-3bc5-4aca-b293-16ef5df639d1</constant></entry>
<entry>Temporary Data Partition</entry>
<entry><filename>/var/tmp/</filename></entry>
<entry>The first partition with this type UUID on the same disk as the root partition is mounted to <filename>/var/tmp/</filename>.</entry>
2015-02-04 05:14:13 +03:00
</row>
<row>
<entry><constant>SD_GPT_SWAP</constant></entry>
<entry><constant>0657fd6d-a4ab-43c4-84e5-0933c84b4f4f</constant></entry>
2015-02-04 05:14:13 +03:00
<entry>Swap</entry>
<entry>n/a</entry>
<entry>All partitions with this type UUID on the same disk as the root partition are used as swap.</entry>
2015-02-04 05:14:13 +03:00
</row>
<row>
<entry><constant>SD_GPT_ESP</constant></entry>
<entry><constant>c12a7328-f81f-11d2-ba4b-00a0c93ec93b</constant></entry>
<entry>EFI System Partition (ESP)</entry>
<entry><filename>/efi/</filename> or <filename>/boot/</filename></entry>
<entry>The first partition with this type UUID located on the same disk as the root partition is mounted to <filename>/boot/</filename> or <filename>/efi/</filename>, see below.</entry>
</row>
<row>
<entry><constant>SD_GPT_XBOOTLDR</constant></entry>
<entry><constant>bc13c2ff-59e6-4262-a352-b275fd6f7172</constant></entry>
<entry>Extended Boot Loader Partition</entry>
<entry><filename>/boot/</filename></entry>
<entry>The first partition with this type UUID located on the same disk as the root partition is mounted to <filename>/boot/</filename>, see below.</entry>
</row>
2015-02-04 05:14:13 +03:00
</tbody>
</tgroup>
</table>
<para>This generator understands the following attribute flags for partitions:</para>
<table>
<title>Partition Attribute Flags</title>
<tgroup cols='4' align='left' colsep='1' rowsep='1'>
<colspec colname="flag" />
<colspec colname="value" />
<colspec colname="where" />
<colspec colname="explanation" />
<thead>
<row>
<entry>Flag</entry>
<entry>Value</entry>
<entry>Applicable to</entry>
<entry>Explanation</entry>
</row>
</thead>
<tbody>
<row>
<entry><constant>SD_GPT_FLAG_READ_ONLY</constant></entry>
<entry><constant>0x1000000000000000</constant></entry>
<entry><filename>/</filename>, <filename>/home/</filename>, <filename>/srv/</filename>, <filename>/var/</filename>, <filename>/var/tmp/</filename>, Extended Boot Loader Partition</entry>
<entry>Partition is mounted read-only</entry>
</row>
<row>
<entry><constant>SD_GPT_FLAG_NO_AUTO</constant></entry>
<entry><constant>0x8000000000000000</constant></entry>
<entry><filename>/</filename>, <filename>/home/</filename>, <filename>/srv/</filename>, <filename>/var/</filename>, <filename>/var/tmp/</filename>, Extended Boot Loader Partition</entry>
<entry>Partition is not mounted automatically</entry>
</row>
<row>
<entry><constant>SD_GPT_FLAG_NO_BLOCK_IO_PROTOCOL</constant></entry>
<entry><constant>0x0000000000000002</constant></entry>
<entry>EFI System Partition (ESP)</entry>
<entry>Partition is not mounted automatically</entry>
</row>
</tbody>
</tgroup>
</table>
<para>The <filename>/home/</filename>, <filename>/srv/</filename>, <filename>/var/</filename>,
<filename>/var/tmp/</filename> and swap partitions may be encrypted in LUKS format. In this case, a
device mapper device is set up under the names <filename>/dev/mapper/home</filename>,
<filename>/dev/mapper/srv</filename>, <filename>/dev/mapper/var</filename>,
<filename>/dev/mapper/tmp</filename> or <filename>/dev/mapper/swap</filename>. Note that this might
create conflicts if the same partition is listed in <filename>/etc/crypttab</filename> with a different
device mapper device name.</para>
<para>When systemd is running in the initrd the <filename>/</filename> partition may be encrypted with
LUKS as well. In this case, a device mapper device is set up under the name
gpt-auto-generator: rework/simplify logic for picking /efi or /boot I started looking into https://github.com/uapi-group/specifications/issues/35. BLS says: > Otherwise [no existing XBOOTLDR partition], if on GPT and an ESP is found and > it is large enough (let’s say at least 1G) it should be used as $BOOT and > used as primary location to place boot loader menu resources in. > It is recommended to mount $BOOT to /boot/, and the ESP to /efi/. DPS says: > The ESP used for the current boot is automatically mounted to /efi/ (or > /boot/ as fallback), unless a different partition is mounted there (possibly > via /etc/fstab, or because the Extended Boot Loader Partition — see below — > exists) or the directory is non-empty on the root disk. I don't think we want to mount the same partition in two places. If the same partition is not mounted in two places, then the two specs are contradictory. The code in gpt-auto-generator implemented the logic from the DPS. It is modified to implement the logic from BLS. Effectively: - if both /boot and /efi are available: - if both XBOOTLDR and ESP exist: ESP on /efi, XBOOTLDR on /boot - if only ESP exists: ESP on /boot - if only XBOOTLDR exists: XBOOTLDR on /boot - if only /boot is available: - if XBOOTLDR exists: XBOOTLDR on /boot - if only ESP exists: ESP on /boot - if only /efi is available: - if ESP exists: ESP on /efi "Available" means that it the mount point is not mounted over and does not contain files. If the directory doesn't exist, it is also "available" and will be created later when the mount or automount unit is started. Thus, the generator attempts to match the partitions and mount points to the extent possible. In all cases, /boot is the primary place to install kernels. ESP can be found on /boot or /efi, depending on the situation. If this patch is merged, I'll submit fixes for BLS and DPS to describe the same logic.
2023-04-05 18:10:16 +03:00
<filename>/dev/mapper/root</filename>, and a <filename>sysroot.mount</filename> is set up that mounts the
device under <filename>/sysroot</filename>. For more information, see
<citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
</para>
<para>The root partition can be specified by symlinking <filename>/run/systemd/volatile-root</filename>
to <filename>/dev/block/$major:$minor</filename>. This is especially useful if the root mount has been
replaced by some form of volatile file system (overlayfs).
</para>
gpt-auto-generator: rework/simplify logic for picking /efi or /boot I started looking into https://github.com/uapi-group/specifications/issues/35. BLS says: > Otherwise [no existing XBOOTLDR partition], if on GPT and an ESP is found and > it is large enough (let’s say at least 1G) it should be used as $BOOT and > used as primary location to place boot loader menu resources in. > It is recommended to mount $BOOT to /boot/, and the ESP to /efi/. DPS says: > The ESP used for the current boot is automatically mounted to /efi/ (or > /boot/ as fallback), unless a different partition is mounted there (possibly > via /etc/fstab, or because the Extended Boot Loader Partition — see below — > exists) or the directory is non-empty on the root disk. I don't think we want to mount the same partition in two places. If the same partition is not mounted in two places, then the two specs are contradictory. The code in gpt-auto-generator implemented the logic from the DPS. It is modified to implement the logic from BLS. Effectively: - if both /boot and /efi are available: - if both XBOOTLDR and ESP exist: ESP on /efi, XBOOTLDR on /boot - if only ESP exists: ESP on /boot - if only XBOOTLDR exists: XBOOTLDR on /boot - if only /boot is available: - if XBOOTLDR exists: XBOOTLDR on /boot - if only ESP exists: ESP on /boot - if only /efi is available: - if ESP exists: ESP on /efi "Available" means that it the mount point is not mounted over and does not contain files. If the directory doesn't exist, it is also "available" and will be created later when the mount or automount unit is started. Thus, the generator attempts to match the partitions and mount points to the extent possible. In all cases, /boot is the primary place to install kernels. ESP can be found on /boot or /efi, depending on the situation. If this patch is merged, I'll submit fixes for BLS and DPS to describe the same logic.
2023-04-05 18:10:16 +03:00
<para>Mount and automount units for the EFI System Partition (ESP) and Extended Boot Loader Partition
(XBOOTLDR) are generated on EFI systems. If the disk contains an XBOOTLDR partition, as defined in the
<ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader
Specification</ulink>, it is made available at <filename>/boot/</filename>. This generator creates an
automount unit; the mount will only be activated on-demand when accessed. The mount point will be created
if necessary.</para>
<para>The ESP is mounted to <filename>/boot/</filename> if that directory exists and is not used for
XBOOTLDR, and otherwise to <filename>/efi/</filename>. Same as for <filename>/boot/</filename>, an
automount unit is used. The mount point will be created if necessary.</para>
<para>No configuration is created for mount points that are configured in <citerefentry
project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry> or when
the target directory contains files.</para>
2015-02-04 05:14:13 +03:00
<para>When using this generator in conjunction with btrfs file
systems, make sure to set the correct default subvolumes on them,
using <command>btrfs subvolume set-default</command>.</para>
<para>If the system was booted via
<citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> and the
stub reported to userspace that the kernel image was measured to a TPM2 PCR, then any discovered root and
<filename>/var/</filename> volume identifiers (and volume encryption key in case it is encrypted) will be
automatically measured into PCR 15 on activation, via
<citerefentry><refentrytitle>systemd-pcrfs@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
2015-02-04 05:14:13 +03:00
<para><filename>systemd-gpt-auto-generator</filename> implements
<citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
2015-02-04 05:14:13 +03:00
</refsect1>
<refsect1>
<title>Kernel Command Line</title>
<para><filename>systemd-gpt-auto-generator</filename> understands the following kernel command line
parameters:</para>
<variablelist class='kernel-commandline-options'>
<varlistentry>
<term><varname>systemd.gpt_auto</varname></term>
<term><varname>rd.systemd.gpt_auto</varname></term>
<listitem><para>Those options take an optional boolean argument, and default to yes.
The generator is enabled by default, and a false value may be used to disable it
(e.g. <literal>systemd.gpt_auto=0</literal>).
</para>
<xi:include href="version-info.xml" xpointer="v242"/></listitem>
</varlistentry>
<varlistentry>
<term><varname>systemd.image_policy=</varname></term>
<term><varname>rd.systemd.image_policy=</varname></term>
<listitem><para>Takes an image dissection policy string as argument (as per
<citerefentry><refentrytitle>systemd.image-policy</refentrytitle><manvolnum>7</manvolnum></citerefentry>),
and allows enforcing a policy on dissection and use of the automatically discovered GPT partition
table entries.</para>
<xi:include href="version-info.xml" xpointer="v254"/></listitem>
</varlistentry>
<varlistentry>
<term><varname>root=</varname></term>
<term><varname>rootfstype=</varname></term>
<term><varname>rootflags=</varname></term>
<listitem><para>When <varname>root=</varname> is used with the special value
<literal>gpt-auto</literal> (or if the parameter is not used at all), automatic discovery of the root
partition based on the GPT partition type is enabled. Any other value disables this
logic.</para>
<para>The <varname>rootfstype=</varname> and <varname>rootflags=</varname> are used to select the
file system type and options when the root file system is automatically discovered.</para>
<xi:include href="version-info.xml" xpointer="v242"/></listitem>
</varlistentry>
<varlistentry>
<term><varname>rw</varname></term>
<term><varname>ro</varname></term>
<listitem><para>Mount the root partition read-write or read-only <emphasis>initially</emphasis>.</para>
<para>Note that unlike most kernel command line options these settings do not override configuration
in the file system, and the file system may be remounted later. See
<citerefentry><refentrytitle>systemd-remount-fs.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
</para>
<xi:include href="version-info.xml" xpointer="v242"/></listitem>
</varlistentry>
<varlistentry>
<term><varname>systemd.swap=</varname></term>
<listitem><para>Takes a boolean argument or enables the option if specified without an argument.
If disabled, automatic discovery of swap partition(s) based on GPT partition type is disabled.
Defaults to enabled.</para>
<xi:include href="version-info.xml" xpointer="v254"/></listitem>
</varlistentry>
</variablelist>
</refsect1>
2015-02-04 05:14:13 +03:00
<refsect1>
<title>See Also</title>
<para><simplelist type="inline">
<member><citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
<member><citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
<member><citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
<member><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
<member><citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
<member><citerefentry><refentrytitle>systemd-pcrfs@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
<member><citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
<member><citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
<member><citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
<member><citerefentry project='url'><refentrytitle url='https://btrfs.readthedocs.io/en/latest/btrfs.html'>btrfs</refentrytitle><manvolnum>8</manvolnum></citerefentry></member>
</simplelist></para>
2015-02-04 05:14:13 +03:00
</refsect1>
2013-08-13 23:57:43 +04:00
</refentry>