dracut

dracut copied to clipboard

Describe the bug When I use a standalone usr partition and also use systemd-repart to setup the remainder of the partition table (root and swap partitions mainly), the unit sysusr-usr.mount does not become activated. After several hours debugging I can confirm that the issue comes from ordering issues between:

• local-fs-pre.target (the FS check for sysusr-usr.mount is done by systemd-fsck-usr.service which is waiting on local-fs-pre.target)
• [email protected] which is waiting on /dev/disk/by-partlabel/swap and should run before local-fs-pre.target
• /dev/disk/by-partlabel/swap which will not get generated until systemd-repart.service runs.

The unit sysusr-usr.mount does have the correct path to mount and points to the correct partition.

If I remove resume=PARTLABEL=swap everything works. I should note that after the initial partition setup everything works just fine since both the root and swap partitions exist.

Distribution used Ubuntu 22.10 (in development). Happy to try another distribution on request. Ubuntu 22.04 does not have systemd-repart.

Dracut version 056-3

Init system systemd v251 but I believe v249 supports systemd-repart.

To Reproduce

1. Create a disk image that only has: 1. A UEFI partition 2. A usr partition
2. Populate /usr/lib/repart.d files to create a root and swap partition. See the documentation here.
3. Set a mount.usr= kernel command line argument, along with a resume= argument. The full kernel command line does not require any other arguments and should not have a root= argument. I'd recommend setting rd.timeout=15.
4. Boot into the dracut image. The job /dev/gpt-auto-root will timeout.

Expected behavior

The ordering of units should go roughly like this:

1. Verity protection creates /dev/mapper/usr.
2. The usr partition is properly checked.
3. The usr partition is mounted at /sysusr/usr from the generated unit that systemd-fstab-generator created.
4. Once /sysusr/usr is mounted the systemd-repart.service unit should run which will create the root and swap partitions along with the subsequent file systems.
5. Any extra setup via /etc/crypttab should now take place. systemd-repart could for example be configured to use a key that is part of the RAM disk (yes I know that is unwise) or there could be relevant settings to load.
6. /sysroot should be mounted.
7. Somewhere in there /sysusr/usr should either be unmounted or moved to /sysroot/usr.
8. By now everything for initrd-fs.target should be lined up and ready for boot.

Additional context

In theory this should all work. I've been taking inspiration from the Fitting Everything Together blog post from Lennart Poettering.

Why not just edit the kernel command line later after the initial setup? Good question. Because secure boot doesn't allow editing the kernel command line and we really don't want to bundle two kernels to get things setup if that can be avoided.

The "cheapest" solutions I have found so far after looking at the code for systemd-hibernate-resume-generator is to automatically create an fstab line similar to the following which would need to run quite early:

# Label line taken straight from the command line
# Specifies a timeout to wait for the swap partition to be available
PARTLABEL=swap sw swap x-systemd.device-timeout=15 0 0

The other (possibly better) option is the kernel command line argument resumeflags=x-systemd.device-timeout=15.