[PATCH v3 0/7] init: discoverable root partitions

[PATCH v3 0/7] init: discoverable root partitions

[Vincent Mailhol]

DPS [1] defines GPT partition type UUIDs for OS partitions and
attributes that control whether such partitions should be
automatically discovered. The specification states that:

  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.

DPS is already implemented in systemd-gpt-auto-generator [2], which,
when embedded in an initrd, indeed allows automatic detection of the
root filesystem through its partition type UUID.

This series adds root discovery directly into the kernel so that people
who are not using an initrd can still benefit from it.

The scope is deliberately limited to block devices that the kernel can
already mount through the root= parameter. Other DPS features, such as
setting up LUKS-encrypted partitions, mounting partitions other than
root or container setup, remain userspace responsibilities, with no
future plan to implement them in the kernel. The intended usage is
thus a hybrid approach in which the kernel DPS only mounts the root
partition and leaves the remaining setup to userspace (either with DPS
or with a classic fstab), just as it does today when root= specifies
the root device.

The benefit is being able to boot a kernel with no accompanying
bootloader configuration: no root= parameter and no initramfs. The root
partition is identified from the existing on-disk metadata instead.

This is useful for booting a kernel manually, for example from the edk2
file browser, or recovering from a lost or corrupted bootloader
configuration without having to supply the correct root= argument or
load an initrd from the bootloader shell. Finally, it allows systems
that otherwise need no initrd to discover their root partition through
DPS without introducing an early userspace environment solely for that
lookup.

The implementation follows these rules:

  - GPT partition type UUIDs are used for automatic discovery policy
    only. No root=PARTTYPEUUID=xxx cmdline option or similar syntax is
    added.

  - An initramfs providing an early userspace init, a root= command-line
    option, or a root device supplied by the boot loader takes
    precedence. Existing working boot configurations therefore retain
    their current behaviour. Automatic discovery triggers only when
    booting without any of these, where the kernel would otherwise panic
    because no root device was specified.

  - As required by DPS, discovery is restricted to the disk containing
    the active EFI System Partition, identified through the
    LoaderDevicePartUUID EFI variable. This avoids inadvertently
    selecting a root partition on another disk, assuming partition UUIDs
    are unique. This is not a security feature: an attacker could
    duplicate the ESP's PARTUUID on another disk, just as with
    root=PARTUUID=xxx today.

  - If several eligible partitions have the selected type, the first
    match in block-device enumeration order is used.

  - The native architecture's root partition type takes precedence.
    Where the kernel supports compatible 32-bit userspace, its root
    partition type is accepted as a fallback.

  - Partitions carrying the DPS no-auto attribute are excluded.

  - The DPS read-only attribute is intentionally not enforced. The
    kernel already mounts the root filesystem read-only by default and
    if the command line requests rw, it takes precedence over the DPS
    attribute. User space remains responsible for deciding whether a
    discovered root should later be remounted read-write based on DPS
    metadata and local policy.

Patch 1 retains GPT partition type UUIDs in partition metadata for early
block lookup.

Patch 2 defines the architecture-specific DPS root partition type UUIDs
and the derived DPS_ROOT_AUTO_DISCOVERY symbol in Kconfig.

Patch 3 factors out lookup_root_device() so initial root lookup and
rootwait retries share the same lookup policy.

Patch 4 implements DPS root discovery through early_lookup_dps_root()
and integrates it into the root mount path.

Patch 5 excludes partitions marked no-auto.

Patch 6 adds the compatible 32-bit root partition type UUID as a
fallback when no partition with the native type UUID can be found.

Finally, patch 7 documents automatic root discovery.

Tested with the Linux EFI stub [3] and with GRUB [4], which both expose
the LoaderDevicePartUUID EFI variable.

[1] The Discoverable Partitions Specification (DPS)
Link: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/

[2] systemd-gpt-auto-generator
Link: https://www.freedesktop.org/software/systemd/man/latest/systemd-gpt-auto-generator.html

[3] commit 0f7d63d9a725 ("efi/libstub: add initial Boot Loader Interface
    support")
Link: https://git.kernel.org/torvalds/c/0f7d63d9a725

[4] GRUB -- §16.20 bli
Link: https://www.gnu.org/software/grub/manual/grub/html_node/bli_005fmodule.html

Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
Changes in v3:

  - Rebase on v7.4-rc1.

  - Clarify in the cover letter that ESP UUID matching is not a security
    feature.

  - Move the DPS Kconfig symbols from init/Kconfig to block/Kconfig,
    alongside the root discovery implementation.

  - Restrict the LoongArch root partition type UUID to 64-bit kernels,
    since DPS does not define a root partition type UUID for LoongArch32.

  - Reject LoaderDevicePartUUID if it contains trailing characters.

  - Document when automatic discovery stops waiting.

Link to v2: https://patch.msgid.link/20261025-discoverable-root_partitions-v2-0-fb77d0821fab@kernel.org

Changes in v2:

  - Remove all architectures which do not have CONFIG_EFI.

  - Replace the per-architecture UUID headers with Kconfig definitions.

  - Move most of the DPS lookup logic to block/early-lookup.c.

  - Bail out if ROOT_DEV already exists.

  - Hold the disk's open_mutex during lookup so partition scanning
    finishes before reporting -ENODEV. This is a prerequisite for the
    next two changes.

  - Do an early abort when early_lookup_dps_root() returns -ENODEV.

  - Add the secondary partition type UUID as a fallback.

  - Small tweaks in log messages.

  - Documentation is updated accordingly.

Link to v1: https://lore.kernel.org/r/20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org

---
Vincent Mailhol (7):
      block: store GPT partition type UUID
      block: add DPS root partition type UUID definitions
      init: factor out root device lookup into lookup_root_device()
      block: discover root by DPS partition type UUID
      block: skip partitions with DPS no-auto GPT attribute
      block: add secondary DPS root partition type UUID
      docs: document discoverable root partitions

 Documentation/admin-guide/discoverable-root.rst |  46 +++++++++
 Documentation/admin-guide/index.rst             |   1 +
 Documentation/admin-guide/kernel-parameters.txt |   5 +
 block/Kconfig                                   |  21 ++++
 block/early-lookup.c                            | 121 +++++++++++++++++++++++-
 block/partitions/efi.c                          |   2 +
 include/linux/blkdev.h                          |  15 +++
 init/do_mounts.c                                |  44 +++++++--
 8 files changed, 242 insertions(+), 13 deletions(-)
---
base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
change-id: 20260611-discoverable-root_partitions-bdacbada570d

Best regards,
--  
Vincent Mailhol <mailhol@kernel.org>

[PATCH v3 7/7] docs: document discoverable root partitions

[Vincent Mailhol]

Document the automatic root block device discovery feature.

Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: linux-doc@vger.kernel.org
---
 Documentation/admin-guide/discoverable-root.rst | 46 +++++++++++++++++++++++++
 Documentation/admin-guide/index.rst             |  1 +
 Documentation/admin-guide/kernel-parameters.txt |  5 +++
 3 files changed, 52 insertions(+)

diff --git a/Documentation/admin-guide/discoverable-root.rst b/Documentation/admin-guide/discoverable-root.rst
new file mode 100644
index 000000000000..29c93b3526a6
--- /dev/null
+++ b/Documentation/admin-guide/discoverable-root.rst
@@ -0,0 +1,46 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _discoverable_root:
+
+Discoverable root partitions
+============================
+
+On EFI systems, the kernel can discover the root block device from GPT partition
+type UUID metadata on the disk containing the active EFI System Partition.
+
+This follows the `Discoverable Partitions Specification`_ which defines a list
+of architecture-specific root partition type UUIDs.
+
+An initramfs providing an early userspace ``init``, a ``root=`` kernel
+command-line option, or a root device supplied through the boot protocol takes
+precedence over this automatic root partition discovery.
+
+Automatic discovery uses the Boot Loader Interface ``LoaderDevicePartUUID`` EFI
+variable to identify the partition whose disk is searched. This variable is
+provided by the boot loader or, when the kernel is booted directly by EFI
+firmware, by the Linux EFI stub.
+
+The kernel first searches for the native root partition type UUID. On
+architectures that can run compatible 32-bit user space, the matching 32-bit
+root partition type UUID may be used as a fallback if no partition with the
+native type UUID is found. If multiple partitions on that disk match the
+selected type UUID, the kernel selects the first match in block device
+enumeration order, but this may change. Systems should not expose multiple
+eligible root partitions.
+
+Partitions marked with the DPS ``no-auto`` GPT attribute are skipped. This
+allows a partition with an otherwise discoverable type UUID to opt out from
+automatic discovery.
+
+With ``rootwait`` or ``rootwait=<seconds>``, discovery retries while the EFI
+System Partition is unavailable, subject to any specified timeout. Once its disk
+has been scanned, discovery either selects an eligible root partition or stops
+if none was found. Waiting is also disabled if ``LoaderDevicePartUUID`` is not
+available or is malformed.
+
+The DPS read-only attribute is not enforced by kernel root discovery. The
+root filesystem is mounted read-only by default unless ``rw`` is specified,
+and user space remains responsible for later remount policy.
+
+.. _Discoverable Partitions Specification:
+   https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index cd28dfe91b06..0d9c2796ae09 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -50,6 +50,7 @@ Booting the kernel
 
    bootconfig
    kernel-parameters
+   discoverable-root
    efi-stub
    initrd
 
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 0b3c140babd9..2e7b89a05944 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -6746,6 +6746,11 @@ Kernel parameters
 			ramdisk, "nfs" and "cifs" for root on a network file
 			system, or "mtd" and "ubi" for mounting from raw flash.
 
+			If this option is omitted, the kernel may try to
+			discover the root block device from the GPT partition
+			type UUID metadata when additional requirements are met.
+			See Documentation/admin-guide/discoverable-root.rst.
+
 	rootdelay=	[KNL] Delay (in seconds) to pause before attempting to
 			mount the root filesystem
 

-- 
2.56.0

Re: [PATCH v3 0/7] init: discoverable root partitions

[Christian Brauner]

On Mon, Nov 02, 2026 at 10:29:07PM +0100, Vincent Mailhol wrote:
> This series adds root discovery directly into the kernel so that people
> who are not using an initrd can still benefit from it.

Nothing has changed since
https://lore.kernel.org/r/20260617-irritation-rollen-wirst-7d636cbfec92@brauner

-- 

Re: [PATCH v3 0/7] init: discoverable root partitions

[Vincent Mailhol]

On 10/11/2026 at 17:03, Christian Brauner wrote:
> On Mon, Nov 02, 2026 at 10:29:07PM +0100, Vincent Mailhol wrote:
>> This series adds root discovery directly into the kernel so that people
>> who are not using an initrd can still benefit from it.
> 
> Nothing has changed since
> https://lore.kernel.org/r/20260617-irritation-rollen-wirst-7d636cbfec92@brauner

I replied to your earlier message to explain my position but did not
hear back.

Since v1, I have rewritten the cover letter to better explain why I
think implementing a subset of DPS in the kernel makes a
difference. The relevant paragraph is:

  This is useful for booting a kernel manually, for example from the edk2
  file browser, or recovering from a lost or corrupted bootloader
  configuration without having to supply the correct root= argument or
  load an initrd from the bootloader shell. Finally, it allows systems
  that otherwise need no initrd to discover their root partition through
  DPS without introducing an early userspace environment solely for that
  lookup.

Similarly, I clarified the scope to address your concern about the
complexity of DPS:

  The scope is deliberately limited to block devices that the kernel can
  already mount through the root= parameter. Other DPS features, such as
  setting up LUKS-encrypted partitions, mounting partitions other than
  root or container setup, remain userspace responsibilities, with no
  future plan to implement them in the kernel. The intended usage is
  thus a hybrid approach in which the kernel DPS only mounts the root
  partition and leaves the remaining setup to userspace (either with DPS
  or with a classic fstab), just as it does today when root= specifies
  the root device.

I would appreciate hearing whether these use cases and the limited
scope address your concerns.


Yours sincerely,
Vincent Mailhol