No more boot loader: Please use the kernel instead

It's something you can do since a lot of years. I used to do so 10 years ago, when I've got the first motherboard with UEFI. But is it useful? It saves a minimal time in the boot sequence, but at what cost?

The bootloader (being it grub, or something more simple as systemd-boot) is useful to me for a couple of reasons:

- it allows to dual-boot with Windows easily: motherboard boot menu is often not easy to access, you need to perform some key combination in a short window, also modern bootloader save the last boot option such that if Windows reboots for an update Linux does not start

- it allows to edit the cmdline of the kernel to recover a system that does not boot, e.g. start in single user mode. That can really save your day if you don't have on hand an USB stick and another PC to flash it

- it allows you to choose between multiple kernels and initrd images easily, again for recovery purposes

- it has a voice for entering the UEFI setup menu: in most modern systems again entering the UEFI with a keyboard combination is unnecessarily difficult and has a too short timeout

- it allows you to boot any other EFI application, such as memtest, or efi shell. Most UEFI firmwares doesn't have a menu to do so.

I personally think they're moving in the wrong direction. I'd rather have "NMIRFS" (no more initramfs). Eg, a smarter bootloader that understands all bootable filesystems and cooperates with the kernel to pre-load modules needed for boot and obviates the need for initramfs.

FreeBSD's loader does this, and its so much easier to deal with. Eg, it understands ZFS, and can pre-load storage driver modules and zfs.ko for the kernel, so that the kernel has everything it needs to boot up. It also understands module dependencies, and will preload all modules that are needed for a module you specify (similar to modprobe).

A lot of the commentary here is based on misunderstandings of the capabilities and constraints of a UEFI environment and what the actual goals of this project are, and I think miss the mark to a large degree. Lennart's written some more explicit criticism at https://lwn.net/Articles/981149/ and I think that's a much more interesting set of concerns.

This reminds me of MILO for booting Linux on some (?) DEC Alpha systems back in the 90s. I don't remember much about the actual firmware anymore. Much like today with UEFI, the system had some low-level UI and built-in drivers to support diagnostics, disk and network booting, etc.

MILO could be installed as a boot entry in the firmware-level boot menu. MILO was a sort of stripped down Linux kernel that used its drivers to find and load the real kernel, ending with a kexec to hand over the system.

No matter how you slice it, I think you'll always come around to wanting this sort of intermediate bootloader that has a different software maintenance lifecycle from the actual kernel. It is a fine idea to reuse the same codebase and get all the breadth of drivers and capabilities, but you want the bootloader to have a very "stability" focused release cycle so it is highly repeatable.

And, I think you want a data-driven, menu/config layer to make it easy to add new kernels and allow rollback to prior kernels at runtime. I hope we don't see people eventually trying to push Android-style UX onto regular Linux computers, i.e. where the bootloader is mostly hidden and the kernel treated as if it is firmware, with at most some A/B boot selection option.

My previous laptop was a Chromebook running Linux+Coreboot. Unfortunately the usual Tianocore UEFI BIOS people use had some bugs in the nvme and keyboard drivers, which I gave up fixing or working around (at the time). Obviously Linux had working drivers because that's all ChromeOS is, so we setup a minimal Linux install as the Coreboot payload in the firmware flash, and I wrote a little Rust TUI to mount all visible partitions and kexec anything that looked like a kernel image. It worked like a charm and had all kinds of cool features, like wifi and a proper terminal for debugging in the BIOS! Based on that experience I don't see any reason why we don't just use Linux direct instead for everything. Why duplicate all the drivers?

The code is here although it hasn't been touched it years: https://gitlab.com/samsartor/alamode-boot

Does anyone still remember when you could just dd the Linux kernel to a floppy and it would be its own bootloader?

https://yosemitefoothills.com/LinuxBoot/BD-1Disk.htm

Here's some more documentation on this: https://www.kernel.org/doc/Documentation/x86/boot.txt

What's old is new again... except 100x more complex and likely more than necessary.

I'm curious if they're proposal will be capable of handling multi-os boots. I know grub can, I can have Linux and windows and possibly even a third OS if I want. I am concerned that red hats solution the well-intended, may be rather myopic, and be commercial only. What I failed to understand, is what problem this solves for systems that I probably only reboot once or twice a year. (Given that it only works with Linux only systems)

I've thought about something like this before, but I have so many questions on just the basic premise...

First: Linux could already be booted directly from the UEFI manager. You don't need GRUB at all. So why a new scheme - why weren't they just doing that?

Second (and third, etc.): If I have multiple Linux installations along with a Windows installation, wouldn't this mean one of them now has to be the one acting as the boot loader? Could it load the other one regardless of what distro it is, without requiring e.g. an extra reboot? And wouldn't this mean they would no longer be on equal footing, since one of them would now become the "primary" one when booting? Would its kernel have to be on the UEFI partition...?

It's nice to see more people embracing the capabilities of UEFI and Linux. ZFSBootMenu has been shipping an EFI application (really, a UKI masquerading as one) for almost four years now - https://docs.zfsbootmenu.org/en/v2.3.x/ . The neat part is that the first stage kernel boots in roughly 1.5 to 2 seconds. It's not really appreciably slower than other boot methods while at the same time exposing a substantial amount of pre-boot functionality.

What's the point of using this over plain EFISTUB? I use it with Arch, and whenever I want to boot to Windows, I just use the BIOS menu. I don't see what benefit a Linux-based bootloader provides.

I really like the idea and the approach. I’m a little concerned however about the compatibility issues with kexec. For example, here’s what Arch says about the NVidia module:

> The graphics driver needs to be unloaded before a kexec, or the next kernel will not be able to gain exclusive control of the device. This is difficult to achieve manually because any programs which need exclusive control over the GPU (Xorg, display managers) must not be running. Below is an example systemd service that will unload the KMS driver right before kexec, which requires that you use systemctl kexec.

It also talks about ACPI issues and there was a question in the presentation although it was unintelligible. More generally, I could imagine more back and forward compat issues that wouldn’t arise from a simpler bootloader that is only initializing a very constrained amount of hardware whereas the kernel will try to boot the full HW twice. I hope they figure out how to make it work, but I suspect they’ll run into pretty significant challenges running this on real “legacy” HW until this is in the ecosystem enough that HW vendors will support it better. A bonus would be that kexec will become better supported and more robust over time if there’s broader adoption.

I also wonder if there’s any back/forward compat issues kexec between very different kernel versions, but I’m guessing the kexec mechanism was intentionally designed to support that as best as it can.

https://wiki.archlinux.org/title/Kexec

>"Although GRUB is quite versatile and capable, its features create complexity that is difficult to maintain, and that both duplicate and lag behind the Linux kernel while also creating numerous security holes."

We agree thus far -- that GRUB may create unnecessary complexity and security holes (Note the relationship between "complexity" and "security holes" -- where you find one, you will usually find the other... they're intertwined like Yin and Yang -- you usually don't get one aspect alone by itself -- without also getting the other...)...

>"Loaded by the EFI stub on UEFI"

"Er, begging the question Governor" but isn't EFI and UEFI also a bootloader?

Aren't those systems also complex?

I think the article is trying to make the point that a small EFI stub program which loads a larger program, in this case, a modified version of the Linux Kernel itself could easily be audited for security issues, and yes, that's sort of true -- but remember that the EFI loader, no matter how small, still has to run in the UEFI environment, and the entire UEFI environment is anything but not complex...

Phrased another way, running a tiny open source, secure program on a gigantic, complex black-box VM with many undocumented/opaqued/"black box" parts -- may not be all that secure...

Still, any small part of a system that could be made simpler despite there being other obscure "black box" undocumented or poorly documented complex components at play -- is definitely a step in the right direction towards full future transparency and auditability...

It’s a pity we aren’t really there yet with boot loading. In 2024 if I install an OS it places a boot loader in my EFI System Partition but in a way that still feels only partially complete.

What I want is for each OS to install its loader in a unique directory to that OS instance, not unique to the OS vendor. Multiple Debians etc will argue over who controls /debian. You also have to bless UEFI with magic NVRAM variables when it could just scan my EFI System Partitions for any file named “loader” and present that as a boot option.

Perhaps I should just chain from UEFI to something smarter that skips the UEFI-standard and does this smarter thing instead? Debianised GRUB tries to be smart at update-grub time in order to detect OSs but it would be neater if the loader did it.

Edit: In fact I see this is exactly the goal of rEFInd https://www.rodsbooks.com/refind/ …in particular it laments how “EFI implementations should provide boot managers [but] are often so poor as to be useless” so it tries to do a better job for you. I’ll give it a go.

I will translate the doublespeak from redhat, which is similar to how they started to push systemd (really).

> [grub] features create complexity that is difficult to maintain, and that both duplicate and lag behind the Linux kernel while also creating numerous security holes.

No mention of the alternatives. No mention how useful are those features. Handwaiving "security" arguments.

> Loaded by the EFI stub

All the talk about booting the kernel directly is moot, because by this they mean "we will use systemd-boot" ;)

IMHO, this is part of the RH wider push for PKCS11/TPM2/FIDO2 stuff. So it is not really fixing boot loader, as it is standardizing on their bootloader "as the correct one" but using the kernel reputation on the double speak.

Just like they pushed the equivalent of https://www.tenforums.com/attachments/tutorials/195499d15314... as the interface of init. (i'm not salty on systemd, in fact i already use bootd even. but if you cannot see how systemctl is the same UX as that, you are blind)

One can trade run-time flexibility for size, speed, and small attack surface.

Taken to the limit, Oxide Computer boots using the [Pico Host Boot Loader](https://github.com/oxidecomputer/phbl) which is probably not suitable for your personal system where you would want to boot many OS images from many devices on many different mainboards using very similar or modular boot flash images.

Phbl transfers control to a partial Unix image, also in the boot flash, which brings in the rest of the OS from a well-known boot device. There is no UEFI, CoreBoot, PXE boot etc. The AMD PSP code does run, but that's the only early external blob in the boot path. This does mean that the OS has to understand its hardware, there is minimal "free" initialization.

Considering distros serious about booting are effectively shipping grub forks with tens (debian) to over a hundred (ubuntu) to hundreds (fedora) of patches on top, it might be time to invest a bit more into Open Source early-stage booting. I'm doubtful that efistub + UKIs will solve all the problems, but I'm cautiously optimistic. Wait and see!

An EFI stub that sets up multi-boot, kernel and initrd then jumps into it is pretty simple.

I don't know why people really need to keep putting huge intermediate loaders in every default boot path.

If you want to boot more than one OS, yes you need one of these, but if you don't then there's no need for yet another OS instance in the boot path. The mid-stage should be extremely small and simple.

There's been so much crying over the size of UEFI, well now there's an arbitrarily versioned and maintained entire Linux in there too? Mostly just to avoid some ugly UEFI APIs and a slightly different programming environment? Yuck.

I’m fairly technical but I have to say grasping the field of partitions , booting, boot loaders grub uefi its alternatives and the various combinations thereof in Linux defeated me.

When learning something I try to find the simple path, a reliable minimum that gets to the goal. I never found it.

Complexity is the word that comes to mind.

I developed a tool for managing EFI boot entries for my personal use.

I've been meaning to get it ready to release publicly. It's mostly there, just a bit manual to install.

https://efiboot.cbarrick.dev

This link that has been posted a couple of times is a much better source for those of us who aren't going to watch a video:

https://fizuxchyk.wordpress.com/2024/06/13/nmbl-we-dont-need...

Not sure why loaders are a separate beast any more.

In the bad old days, ROMs had very limited space. Lots of bootloader packages got invented, tiny things that knew just enough about ROM and the filesystem to get the 'real' code loaded, maybe un-zipped, maybe unencrypted. Later, some network-boot options which were handy.

Today? The boot flash is huge (compared to ROMs). You can put an entire OS in there! In fact, nowadays the bootloader is often a flash partition right next to other OS images.

I assert, there's nothing that a bootloader can do that an entire OS e.g. Linux image can't do. Just build a linux image, put a boot-script in there to allow network-boot or reboot-from-another-partition. And be done with it - no more u-boot, no more obscure bootloaders with limited drivers and options.

The day of the bootloader is over.

This approach sounds similar to Petitboot <http://www.kernel.org/pub/linux/kernel/people/geoff/petitboo...> which is a kexec-based bootloader that I used on the Playstation 3 many years ago. Apparently it now targets many other systems and there is a (dead?) fork for Coreboot <https://github.com/ArthurHeymans/petitboot_for_coreboot>.

No, please don't.

Most firmware systems don't enable interrupts, support paging, SMP, or many other things, for a long list of reasons, while at the same time, in order to enable a full Linux environment, ExitBootServices must be called, which is going to make a mess anytime the booting kernel isn't the right one. Kexec breaks a fair amount of the time if the target kernel isn't exactly what was already booted (ex, see kdump failures). Nevermind if the target OS isn't linux.

And for what? So /boot can stick around? A legacy partition left over from the days of BIOS/MBR like systems that have to have a small partition at the beginning of the disk, formatted with something that supports linux file permissions?

No, the right solution is to just place the kernel(s), and a small signed initrd (s) in the ESP, and nothing else besides a boot selector, like say systemd-boot to allow the user to select the correct kernel/OS, and optionally edit debug/etc options. Then, when the correct kernel is booted, it can bring up the network, filesystem, and whatever is needed.

That solves an endless list of Linux and firmware interaction problems that Grub currently solves, without all the file system, network code, etc., that one finds in Grub, which mainly duplicates the functionality already provided by UEFI.

The problem with this solution is that it doesn't work on systems that aren't UEFI, to which I might suggest that those systems (cough, legacy IBM junk, or hyperscalers still using BIOS boot after it has been deprecated everywhere else) have either uboot-uefi or edk2 ported so they can conform to modern boot standards.

Does "security" here mean security from the computer's owner, i.e., Treacherous Computing? If not, then what kinds of security holes are even possible at the point when GRUB is running?

Unix and Xenix did this. Single user mode. This is just a plea to have GNU/GRUB integrated into the kernel. I think it's a very good idea. Not original, but a seriously good idea. Add some more help and documentation. Pre-sets for most of the common scenaros. Multi-mode kernals? Kernals as a service?

And make no mistake, this is a compelling article.

You had the bootloader because first you needed executable code in the first sector of the partition, and you can't fit much in those 512 bytes. But moving to UEFI means you never execute that code anymore. Instead, you load a BOOT.EFI file off of a FAT16/FAT32 partition. If there's a restriction on size for that, then you proceed to a bootloader instead of the real kernel.

I use whatever i want :P that's the nice thing about FOSS. I'll move on to the new cool hipster thing when I feel like it and if I see value in it..

Though generally I prefer the approach of "extend what we have with new features" over "rip out all out and start from scratch" so I spend my time mostly with the BSDs which don't jump full steam ahead into the whatever's the new thing.

Even though something like systemd is undoubtedly better in many things, I also have to wrap my head around it, see how to get at the logs, build those unit files etc. On the BSDs I don't have to bother with that and just keep working as I was and which was not broken for me.

The point is, something new doesn't only have to offer a tangible benefit for me to be worth it. It has to be such a big benefit for me that it offsets the hassle of getting my head around all the new stuff and most of the new Linux inventions fail at this.

A removable physical key: a programmable ROM.

I have programmed the ROM to instantaneously copy my ROM to RAM and run. The entire system is running instantly as soon as I power on. There is absolutely nothing else.

Because everything else is a big mess:

Intel ME, BIOS, UEFI, kernels are signed by companies with Microsoft's blessing, EFI, FAT, TPM, anything with the word "Secure" in it, ...

If I look and think that this is another move by redhat to replace a simple independently developed solution with one that's complex enough to require a red hat issued certification, am I paranoid?

Actually wait. They at least haven't proposed to replace grub with systemd. Or is that buried in one corner of the presentation?

In the "what do we have so far?" slide they explain there are currently two variants of NMBL, one that does a switch_root (like a normal initramfs) and one that does kexec (to boot into a new kernel). It presents a menu for the user to select what to boot. It also will allow rolling back to the old version when boot fails.

I see some other comments in this thread about hypothetically supporting booting other UEFI targets and some ideas on how that would be implemented.

There is a question in the video about chainloading around 27 minutes -- https://youtu.be/ywrSDLp926M?t=1640 but the answer isn't clear to me - "setting FE variables". Is that frontend? firmware environment?

Kudos to the developers involved in this functionality.

Faster boot times and more secure installations are always advantageous. I'm all rooting for this development.

I've been wondering for a while why grub is still used, given that its basic architecture is outdated.

relevant comments from Hector Martin over on Mastodon at https://social.treehouse.systems/@marcan/112754303893998372

> Reminder that not all platforms support or, indeed, can support kexec() sanely at all. Like ours. kexec() requires the ability to reset all peripheral state and that is impossible on Apple Silicon because firmware is loaded by earlier boot stages and cannot be re-loaded later to the reset state without a full system reboot.

I haven't used GRUB since my first EFI system. The EFI itself is already a bootloader after all, why would you need another one, especially one as bloated as the new GRUB.

A slight tangent, but still kind of relevant: given that we're lumbered with UEFI on x86-64, are there any active projects working on a better UEFI shell?

Every time I interact with it, I am struck by how awful it is, but the shell is just an EFI application so presumably one could replace it with something better written. Searching turns up EFI menus aplenty, but no one has (yet) taken a shot at a simpler, cleaner EFI shell from what I can see?

Or, really, use the ROM's boot loader.

This is getting closer to the way QNX booted decades ago. The boot image has the kernel and whatever user space programs and .so files you decide to include. For a deeply embedded system, you might not have a file system or networking. For desktop QNX (discontinued), you'd have some disk drivers, a file system driver, a network driver, and a shell, along with a startup script, to get things going.

I'm a big fan of compiling my own kernel with all needed drivers compiled in, with the EFI stub compiled in, no initram, no grub, a fixed cmdline that works 99% of times.

This allows a boot to happen in less than 5 seconds.

The 1% of times I need something different, I use the boot selector provided by the firmware to boot to grub (that's installed anyway), where I have the usual plethora of choices.

Is there a key to be pressed at the right moment? There is. I even have to insert a password. So what? I can go through such ordeal once in a while for that 1% of "special" boots.

Does anyone have any tips for debugging EFI_STUB kernels when they fail to boot? I've run into BIOS before that I can't get EFI_STUB to work on but grub works fine and I'm not sure why or even how to go about getting any debug info since the bios/firmware is a block box. Is the only option to get in touch for the motherboard vendor and how they care to look into it? It's rare but happens.

Seems to be a trend including work like https://www.linuxboot.org/.

I get truly confused when using GRUB. Maybe it’s just me being unwilling to dive into all the details, but seriously, why are there like 30 packages starting with 'grub' under Debian? All I want is to boot my kernel under EFI, and the package choices are overwhelming.

  grub-common
  grub2
  grub2-common
  grub-efi-amd64
  grub-efi-amd64-bin
  grub-efi-amd64-signed
  grub-efi-amd64-signed-template
  grub-efi-amd64-unsigned
  grub-efi
  grub-pc
  grub-pc-bin

Do I need to mix grub2 and grub packages to get it to work? Currently I do, and a bit afraid to remove one or the other :)

Usually, I end up trying things randomly (leaving some funny mess in /boot/EFI b/c not sure if --efi-directory should contain /boot/EFI prefix, or just /boot or nothing), then running some semi-random grub-install command, and eventually, it starts to work. But this is far from intuitive.

Also create a boot please that rivals w10's almost instant boot process. I just hate the current slow/non parallel boot process.

I prefer my bootloader (be that it may, GRUB, lilo, or even BusyBox) because thosr image will go away once the kernel is started.

Nothing for hacker to see and analyze the bootloader, assuming you did not load a driver to the NVRAM/Flash/UEFI/EFI.

Nice security compartment alization.

Redhat is smothering this easential security abstraction of 1st stage loader: not a good security model.

Meta: Can someone with Linux/bootloader knowledge tell me whether most of these comments are as clueless as they seem?

I've been using `systemd-boot` for many years, which comes with the system. It's a bit simpler than Grub and LILO (team 90s, represent!). Most BIOSes have variable support for booting random images, but last time I got a new system, it was confusing to use and a bit of hit-and-miss.

I use EFISTUB [1] to directly load the Linux kernel. How is nmbl different?

[1] https://wiki.archlinux.org/title/EFISTUB

I recently moved to sdboot and prefer its simplicity compared to grub. However they still missed the mark a bit, its folder tree on the ESP is a mess.

I’ll look into this but prefer kernels managed automatically by apt/dnf etc.

I was about to discuss/joke about the possibility of systemd absorbing this project. And hold and behold turns out there is already systemd-boot project competing in this space. I was not aware of that at all.

Isn't one of the use cases in GRUB choosing which kernel you want to load?

How about people moving away from 16-bit real mode(obviously a change is needed in the CPUs), removing that A20 line forgotten from history patch and actually booting like we are supposed to?

you do not use grub for being fast. you use it for when things go wrong

I use zfsbootmenu. It allows me to boot multiple OSes from different data sets, make and rollback snapshots, and even directly boot from a snapshot. It also has a minimal shell for zfs tasks.

I do UKIs and direct boot them on Arch. Works great. Do have to recompile for every change, but it's very fast on a modern system, takes about 40 seconds on my laptop.

This kinda sounds like zfsbootmenu but without the ZFS. Which makes me wonder how hard it would be to factor out the ZFS bits and just use zfsbootmenu on other filesystems.

This is nice. I want to see Linux replace all kinds of stuff. Especially things like bootloaders, UEFI firmware and even on-device firmware.

This sounds awfully like macOS on Apple Silicon, where the "boot menu" is in fact more or less full-fat macOS with special fullscreen GUI.

Ah yes, unified kernel images.

Finally, an end to the tiresome and obsolete notion of Linux running modified versions of the Linux kernel. With unified kernel images, Linux users can finally be confident knowing their kernels are signed by companies with Microsoft's blessing, such as Red Hat and Canonical - and Linux will be have proper support for the use cases of companies like TiVo, who want to run Linux, but also want to ensure the device owner can't make any modifications to the software on their device.

This will be well worth it, to protect against the ever present issue of criminals breaking into my hotel room, finding my unattended laptop, and deciding not to steal it to sell on ebay - but instead to secretly modify my initramfs. I don't know about you, but I've had two covert CIA teams rappel in through my window this week alone.

Yo Dawg, I herd you like bootloaders, so I put a bootloader in your kernel so you can boot w/a kernel while you boot a kernel.

So, move all of GRUB’s complexity into the kernel

(or tell users to abandon all their use cases that led to the aforementioned complexity)

I have been used similar approach at embedded system to copy data ram and kexec kernel there

No thanks. NixOS lets you pick the generation at boot via GRUB. This is extremely useful.

I can't open the .odp file right now, but:

>We (Red Hat boot loader engineering) will present our solution to this problem, which is to use the Linux kernel as its own bootloader. Loaded by the EFI stub on UEFI, and packed into a unified kernel image (UKI), the kernel, initramfs, and kernel command line, contain everything they need to reach the final boot target. All necessary drivers, filesystem support, and networking are already built in and code duplication is avoided.

That has been doable for a few years already. What's the new part?

Is the motherboard's NVRAM supposed to be written to so often?

I'm not sure about that.

> Although GRUB is quite versatile and capable, its features create complexity that is difficult to maintain

The same is true of the kernel. Perhaps redhat should abandon linux and commit to grub, which has the potential to boot an even more interesting or useful kernel.

See also this project: https://github.com/zhovner/OneFileLinux

Not a bootloader, but a single-file, very light Linux image that can be loaded directly as an .EFI file. Not useful as an actual OS for daily use, but can have specialized uses (I used it to network boot a whole room of PCs to a Linux showing a slideshow on the framebuffer).

Awesome, finally.

I have a bootloader signed with my own keys to boot my kernel. Nothing else will be able to boot the machine. I couldn't have this setup without a bootloader.

Another red hat "improvement" that causes another decade plus of churn and documentation and support chaos?

I can't wait until the big distros decide multi-booting is a feature "nobody uses" that "never worked" and therefore isn't going to be supported because "everyone can use VMs" and containers and whatever other solutions that do not, in point of fact, solve the problem.

https://en.wikipedia.org/wiki/Multi-booting

The Linux kernel is pretty easy to compile[1], but the first-party documentation for getting Linux to boot is total garbage. It's embarrassingly bad.

You end up reading third-party articles to figure out what the modern approach is to building your own Linux-based operating system, but even then, it's effectively undocumented how you're supposed to get out of a RAM fs from a ISO boot. You're on your own.

I completely reject the premise that Linux From Scratch is the way to do things, as walking through those steps, it's clear there are completely arbitrary steps thrown in, and as a result, it's basically its own distribution.

What I'd like to see is official documentation for:

     + Building Linux (exists)
     - Creating an initramfs image (conflicting resources)
     - Making a bootable image (conflicting resources)
     - Installing the bootloader and Linux to a target disk (no resources available)

You can do the first three easily if you know exactly the right magic incantations, and use GRUB, but then you're once again on your own.

Once you've built Linux, the experience is you get to hold it in your hand and go "this is worthless."

The Linux documentation flips between recommending initramfs and not, and also pointing you to documentation that is so old it's completely irrelevant and should be removed from kernel.org.

I am never surprised the Linux desktop experience has been bad for decades, because no one cares about creating a decent installer process to begin with. You fail right out of the gate, and it makes the entire Linux bazar experience look like amateur hack hour.

[1]: https://github.com/andrewmcwatters/linux-workflow/blob/main/...

Except that doesn't work in the real world, where encrypted and authenticated boot disks are increasingly common.

So you'll need a significant amount of code that isn't the permanently-resident kernel that has enough device support to access keys and decrypt and authenticate what holds the kernel that will launch the OS.

IOW, you'll just have to reinvent a bootloader anyway.

Or you can address the problems with GRUB, extend it to do what you need, and avoid doing the traditional linux folly of Yet Another Unnecessary Reinvention.

Or was systemd vendor lock-in not enough for your shareholders?