auto detect root device according to Discoverable Partitions Specification (DPS) (boot without `root=` and without `/etc/fstab`)

[adrelanos]

By supporting the Discoverable Partitions Specification (DPS) the following things would be possible:

• booting without the root device (root=) on the kernel command line, and
• without /etc/fstab.

The benefit for the user would be that corner cases such as changed disk uuids after backup/restore no longer result in a broken boot with a dracut rescue shell.

It could also simplify operating system build scripts and installers.

DPS is also supported by systemd-boot.

history:

• https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
• https://systemd.io/DISCOVERABLE_PARTITIONS/

related but non-duplicate:

• auto-detect, prompt for potential root devices in case the root= device is misconfigured or missing #2589 (because that would auto-detect legacy systems as well as prompt the user. This ticket however is about supporting DPS.)

[LaszloGombos]

Thanks for raising this issue.

DPS is also supported by systemd-boot.

Do you have a pointer for this for more information ?

I understand that dracut is not only used with systemd-boot, but it would be great to understand what is the current situation with systemd-boot regardless.

If systemd-boot already discovers partitions, wouldn't systemd-boot already correctly set the root= command line argument ?

[adrelanos]

My knowledge on systemd-boot is limited to curiosity, preliminary research.

https://www.freedesktop.org/software/systemd/man/latest/systemd-boot.html mentions Boot Loader Specification ~6 times.

systemd-stub(7) may be used as UEFI boot stub for executed kernels, which is useful to show graphical boot splashes before transitioning into the Linux world. It is also capable of automatically picking up auxiliary credential files (for boot parameterization) and system extension images, as companion files to the booted kernel images.

Quote DPS:

The OS can discover and mount the necessary file systems with a non-existent or incomplete /etc/fstab file and without the root= kernel command line option.

The root= parameter passed to the kernel by the boot loader may be omitted if the root partition is the first one on the disk of its type. If the root partition is not the first one on the disk, the root= parameter must be passed to the kernel by the boot loader.

Quote https://wiki.archlinux.org/title/systemd-boot

options – space-separated command line options to pass to the EFI program or kernel parameters. Optional, but you will need at least root=dev rw if booting Linux where dev is a block device specifier for the root (/) volume. See persistent block device naming for more information. This parameter can be omitted if the root partition is assigned the correct Root Partition Type GUID as defined in Discoverable Partitions Specification and if the systemd mkinitcpio hook is present.

From that I take that systemd-boot might but will not necessarily pass root= to the kernel / initrd.

Therefore I conclude, if dracut wanted to be compatible with DPS it would need to support boot without root= (and probably also without /etc/fstab).

systemd-boot isn't signed yet for compatibility with Secure Boot... Or is it?

• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033725
• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996202
• https://salsa.debian.org/systemd-team/systemd/-/merge_requests/132
• https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2079784
• https://pagure.io/releng/issue/10765

[paravoid]

@adrelanos what is it that does not work for you right now? In Debian, with dracut 060+5-1, I can boot without root=, with both GRUB2 and systemd-boot. I admit I've only superficially tested this, so perhaps you ran into a problem that I haven't?

[adrelanos]

I had no idea that dracut works with systemd-boot and can boot without root=. Is this documented? I haven't tested that yet.

[LaszloGombos]

According to https://github.com/dracutdevs/dracut/blob/master/modules.d/99base/init.sh#L129 root= argument is mandatory (when systemd is not used). At very least this is inconsistent.

@paravoid can you perhaps share more about your setup ? What is the value of /proc/cmdline ? Is the root perhaps set in the kernel itself CONFIG_CMDLINE

Would be useful to understand in what conditions this works.

[LaszloGombos]

The decision of what to mount in the Linux kernel has to be made before it examines the initramfs contents, so root= is used to signal "we are not keeping this initramfs" because that's literally what root= means.

It seems it is expected that root= is not discovered by initramfs, but instead it should be discovered by the firmware or the bootloader before dracut even has a chance to run, so i think this idea is out of scope for dracut.

If root= is not specified, the expectation is that there is no transition to actual rootfs from initramfs - which is a thing that some distributions do - for example http://tinycorelinux.net

Therefore I conclude, if dracut wanted to be compatible with DPS it would need to support boot without root=

without root= or root= with an empty arguments are two very different distinct cases. Please be mindful of that. See for the exact language - https://www.freedesktop.org/software/systemd/man/latest/systemd-gpt-auto-generator.html

root= with an empty argument is the same as root=gpt-auto

missing root= means "we are not keeping this initramfs"

If we want to keep this discussion going, we should probably restate the problem to 'handle root=gpt-auto' in dracut.

[user7z]

Thanks for raising this issue.

DPS is also supported by systemd-boot.

Do you have a pointer for this for more information ?

I understand that dracut is not only used with systemd-boot, but it would be great to understand what is the current situation with systemd-boot regardless.

If systemd-boot already discovers partitions, wouldn't systemd-boot already correctly set the root= command line argument ?

what about uki , dracut seems to not supporting passing to systemd to automount partitions , i dont use bootloaders , i boot the uki with a uefi entery that i create

[user7z]

Thanks for raising this issue.

DPS is also supported by systemd-boot.

Do you have a pointer for this for more information ?

I understand that dracut is not only used with systemd-boot, but it would be great to understand what is the current situation with systemd-boot regardless.

If systemd-boot already discovers partitions, wouldn't systemd-boot already correctly set the root= command line argument ?

what about uki , dracut seems to not supporting passing to systemd to automount partitions , i dont use bootloaders , i boot the uki with a uefi entery that i create

The decision of what to mount in the Linux kernel has to be made before it examines the initramfs contents, so root= is used to signal "we are not keeping this initramfs" because that's literally what root= means.

It seems it is expected that root= is not discovered by initramfs, but instead it should be discovered by the firmware or the bootloader before dracut even has a chance to run, so i think this idea is out of scope for dracut.

If root= is not specified, the expectation is that there is no transition to actual rootfs from initramfs - which is a thing that some distributions do - for example http://tinycorelinux.net

Therefore I conclude, if dracut wanted to be compatible with DPS it would need to support boot without root=

without root= or root= with an empty arguments are two very different distinct cases. Please be mindful of that. See for the exact language - https://www.freedesktop.org/software/systemd/man/latest/systemd-gpt-auto-generator.html

root= with an empty argument is the same as root=gpt-auto

missing root= means "we are not keeping this initramfs"

If we want to keep this discussion going, we should probably restate the problem to 'handle root=gpt-auto' in dracut.

i try root=gpt-auto , it shutdown automaticlly , gentoowiki says : Some tools may become confused if there is no root= parameter on the kernel command line at all. To placate such tools add root=/dev/gpt-auto-root to the kernel command line. This trick is also usefull if a swapfile on the root partition is used instead of a swap partition for hibernation, i.e. one may specify the resume target on the kernel command line as resume=/dev/gpt-auto-root resume_offset=xxxxxxxxx.
but https://github.com/dracutdevs/dracut/issues/2659

[nagmat84]

Note, I am not involved with Dracut nor SystemD. I just came by because I wanted to post a totally different issue and this issue caught my attention.

If you use SystemD as the init process inside the Initramfs, i.e. if you use the Dracut modules dracut-systemd systemd systemd-initrd systemd-udevd, then GPT auto-discovery inside the Initramfs works perfectly, even for LUKS-encrypted paritions, incl. an encrypted root partition. (I am a Gentoo user and use it.)

So, I assume the the issue here is only relevant, if one uses Dracuts own, bash-based init script as the init process inside the Initramfs. However, I am not sure what the issue really is and what it means in that case.

GPT-based auto-discovery of partitions is not only about finding the root partition and mounting the root partition, but also finding and mounting all other potential partitions like home, usr, tmp (see Table 1 in Freedesktop: systemd-gpt-auto-generator). However, the later must be done by the final init process after switching to the real root.

In order to make GPT auto-discovery working 100%, the early init process inside the Initramfs and the final init process inside the real work have to work together. If you use SystemD for both, it already works today.

But if ones does not use SystemD for one or the other, we are facing a potentially funny mix of options. If you are a Gentoo or Ach user, you have the choice between SystemD and OpenRC for the final init system, Ubuntu used to support Upstart, on Debian you can use SysVInit, etc. pp. So, I believe the only do-able combination (in terms of practicable maintainability) is to use SystemD for both init systems: inside the Initramfs and as your final init system on the real root. But this already works today.

Now, here is what you have to do to make it work with a pure Systemd-based system. It even works for LUKs-encrypted root partitions:

First a little bit of background informartion: Internally, SystemD uses *.mount-service files to manage the mount points at runtime. There are three possible sources for *.mount-service files.

1. Manual service files: The system administrator can create individual *.mount-service files inside /etc/systemd to manage mount points
2. Generated from /etc/fstab: The system administrator may use the traditional /etc/fstab file. If SystemD finds that file upon boot, SystemD will create a corresponding *.mount-service file for each line in /etc/fstab during a very early stage in the boot process. This way SystemD maintains backward compatibility with /etc/fstab
3. GPT-auto discovery: SystemD generates a *.mount-service file for each auto-discovered GPT parition. However, only if there is no entry in /etc/fstab.

Here is the catch: You cannot combine 2 and 3. As soon as SystemD finds a single entry in /etc/ftsab, SystemD deactivates option 3. You can combine 1 and 2 or 1 and 3, though.

So here are the steps you have to take:

1. Use systemd as the init process inside the Initramfs; the relavant Dracut modules are dracut-systemd systemd systemd-initrd systemd-udevd
2. Use systemd as your real init process (how this is done depends on your distro)
3. Empty your /etc/fstab completely.
   There must not been left a single line, not even for other drives like cdrom, network shares or whatever. If you need those alongside GPT-auto-discovery, then create *. mount-files for them.
4. Call Dracut with --fstab or set use_fstab=yes in the dracut configuration.
   This ensure that the /etc/fstab inside the Initramfs is also empty. Otherwise, Dracuts puts a /etc/fstab into the Initramgs which is based on you currently mounted partitions. However, a non-empty /etc/fstab inside Initramfs will prevent the early SystemD init process inside the Initramgs to use GPT-auto-discovery.

That's it.