Let GPT Partition Types Drive systemd Mounts Safely

On a UEFI machine with a GUID Partition Table (GPT), systemd-gpt-auto-generator can turn recognised partition type GUIDs into mount and swap units. This guide shows how to inspect that arrangement, understand what will be mounted, and disable discovery when it is not appropriate. The installed machine used for these examples has systemd 255.4-1ubuntu8.17. Allow about 15 minutes for inspection. Changing partition metadata or the kernel command line needs a maintenance window and a tested recovery path.

1. Check the prerequisites

The generator does nothing on a non-GPT system. Automatic root discovery also needs the EFI System Partition (ESP) and a boot loader that provides the LoaderDevicePartUUID EFI variable. Other recognised partitions are searched on the same physical disk as the root partition, so a multi-disk root layout, including a Btrfs RAID root, is outside this mechanism.

Start with read-only inspection as an ordinary user:

lsblk -o NAME,PATH,TYPE,FSTYPE,PARTTYPE,PARTTYPENAME,MOUNTPOINTS
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS
swapon --show

Look for gpt as the partition-table type, an ESP, and type names such as Linux root, Linux home, Linux server data, Linux variable data, Linux temporary data, or Linux swap. Distribution labels vary, so PARTTYPE, the GUID column, is the useful evidence. Do not infer that a partition will be mounted merely because its filesystem label looks familiar.

2. Know which GUIDs cause which actions

The generator uses the first matching partition for most filesystem roles. Architecture-specific root GUIDs map to /. The standard roles are:

The ESP uses c12a7328-f81f-11d2-ba4b-00a0c93ec93b. An Extended Boot Loader Partition uses bc13c2ff-59e6-4262-a352-b275fd6f7172. An XBOOTLDR partition is made available at /boot/; the ESP goes to /boot/ when that directory exists and is not being used by XBOOTLDR, otherwise it goes to /efi/. These boot partitions use automount units, so seeing no active mount until the path is accessed can be expected.

3. Check the boundaries before changing metadata

No generated configuration is created when a mount point is already configured in /etc/fstab, or when the target directory contains files. This protects existing configuration, but it can also make a correct-looking partition appear to be ignored. Check both before troubleshooting the partition table:

grep -E '^[[:space:]]*[^#].*[[:space:]]/(home|srv|var|var/tmp)[[:space:]]' /etc/fstab || true
for d in /home /srv /var /var/tmp; do
    printf '%s: ' "$d"
    find "$d" -mindepth 1 -maxdepth 1 -print -quit 2>/dev/null
done

The command is read-only. An empty line after a directory name means the directory had no visible entry, not that the generator has already mounted anything.

Partition attributes add two important controls. The read-only flag makes the root, home, server-data, variable-data, temporary-data, or XBOOTLDR filesystem mount read-only. The no-auto flag prevents automatic mounting for those roles. The ESP has a separate no-block-IO-protocol flag. Changing these attributes is storage administration, not a harmless lab test: verify the target device twice, take a backup, and use the partition editor's documented undo or restore path before writing changes.

4. Verify what systemd actually generated

Generators run while systemd builds its early boot transaction. Use the live system as the source of truth after a boot:

systemctl status home.mount srv.mount var.mount var-tmp.mount --no-pager
findmnt /home /srv /var /var/tmp /boot /efi
swapon --show

A unit can be absent because no matching GUID was found, the partition was on the wrong disk, a mount point was blocked by fstab or existing files, or the generator was disabled. A failed unit needs its normal systemd diagnostics, for example journalctl -b -u var.mount. Do not repeatedly restart mounts while investigating a filesystem or encryption problem.

Home, server data, variable data, temporary data, and swap partitions may be LUKS-encrypted. The generator expects mapper names such as /dev/mapper/home, /dev/mapper/srv, /dev/mapper/var, /dev/mapper/tmp, and /dev/mapper/swap. Check /etc/crypttab for a conflicting name before adding a separate cryptsetup entry:

grep -vE '^[[:space:]]*(#|$)' /etc/crypttab

5. Disable discovery deliberately when required

Automatic discovery is enabled by default. If another boot or storage design owns these mounts, add a boolean kernel command-line setting through your distribution's boot-loader configuration. The generator recognises systemd.gpt_auto=0; in an initrd, use rd.systemd.gpt_auto=0 as appropriate. systemd.swap=0 disables automatic GPT swap discovery. Changes to boot-loader configuration affect the next boot and can prevent a system from starting, so keep a known-good previous entry and console or rescue access.

Conversely, root=gpt-auto, or omitting root=, enables GPT root discovery. Any other root= value disables that root logic. rootfstype= and rootflags= select the filesystem type and mount options for an automatically discovered root. The ro and rw settings apply initially; systemd may remount later. On systemd 255, systemd.image_policy= can also constrain how discovered images are dissected.

Done means

• lsblk confirms GPT, the ESP, and the intended partition type GUIDs.
• The same-disk and boot-loader requirements are satisfied for automatic root discovery.
• fstab, non-empty target directories, Btrfs subvolume defaults, and cryptsetup name conflicts have been checked.
• findmnt and swapon --show match the intended mounts and swap devices.
• Any kernel command-line change has a recovery entry and has been verified after reboot.