Re: [PATCH 00/19] init: discoverable root partitions, a.k.a. an omittable "root=" cmdline option
Al Viro <[email protected]> Mon, 15 Jun 2026 18:04:32 +0100
| Newsgroups | gmane.linux.ports.riscv,gmane.linux.kernel,gmane.linux.block,gmane.linux.kernel.efi,gmane.linux.file-systems,gmane.linux.ports.alpha,gmane.linux.kernel.arc,gmane.linux.ports.arm.kernel,gmane.linux.ports.mips,gmane.linux.ports.parisc,gmane.linux.ports.ppc64.devel,gmane.linux.documentation |
|---|---|
| Message-ID | <20260615170432.GW2636677@ZenIV> |
On Mon, Jun 15, 2026 at 06:08:56PM +0200, Vincent Mailhol wrote: > Tested with GRUB, which implements the LoaderDevicePartUUID EFI variable > in its bli module [3]. With this, I was able to boot a kernel with a > completely empty cmdline and no initrd. > > [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] GRUB -- ยง16.2 bli > Link: https://www.gnu.org/software/grub/manual/grub/html_node/bli_005fmodule.html So what does that thing, tied to EFI as it is, have to do with architectures where * firmware is rather unlike EFI * firmware wouldn't know what to do with GPT * GRUB is *not* ported to, let alone used such as, say it, the very first one mentioned at your [1]? Or is that conditional upon "if anyone wants to design replacement firmware for those, and if they agree to follow our wishlist"?