Comment by jchw | Hacker News Reader

Comment by jchw | Hacker News Reader

Parent Full thread

It is a bit more complex, though. Quoting "nmbl: we don’t need a bootloader" from last month[1]:

> - Possibility to chainload from Linux while using Secure / Trusted boot: Dual-booting, although not supported on RHEL, is important for Fedora. While there are attempts to kexec any PE binary, our plan is to set BootNext and then reset, which will preserve the chain of trust that originates in firmware, while not interfering with other bootloaders.

It could be seen as an advantage to do chainloading by setting BootNext and resetting. I think Windows even does this now. However, it certainly is a different approach with more moving parts (e.g. the firmware has to not interfere or do anything stupid, harder than you'd hope) and it's definitely slower. It'd be ideal if both options were on the table (being able to `kexec` arbitrary UEFI PE binaries) but I can't imagine kexec'ing random UEFI binaries will ever be ideal. It took long enough to really feel like kexec'ing other Linux kernels was somewhat reliable.

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

Let's say I have a dual-boot system with two totally independent OSes, Systems A and B. It is powered down. I want to boot into System B but the EFI is configured to boot into System A by default.

Am I correct in understanding that the offered solution here is to first boot into System A, find some well-hidden EFI configuration utility (which varies from OS to OS, if it even exists), and then tell EFI to boot into System B on the next reboot?

If so, that's a pretty terrible experience.

Presumably nmbl would show you a menu to select the which OS start if you’re dual booting. You wouldn’t have to manually set some UEFI variable

Sort of, except it's automated.

Basically, System A's kernel boots. But, instead of immediately loading the System A userland, it loads a boot menu of systems that it reads from UEFI NVRAM and presents it to the user. So you select System B from the list, the menu sets BootNext in NVRAM and issues a reboot.

In practice, the main UX difference is that it takes a bit longer and you'll see the UEFI vendor splash screen again after selecting the boot option.

I'm not a user of Windows anymore but I seem to recall Windows doing something quite similar, where it had a boot menu that felt suspiciously like it was inside of Windows, and to actually change the boot target, it had to reboot.

> instead of immediately loading the System A userland

I mean, it kind of is loading the System A userland. At least the initramfs of it. AFAICT in the proposal the bootloader would now be a regular userland program living in the initramfs.

I get the impression that the eventual goal would be to make this bootloader program into the "init(8) but for the initramfs phase of boot" — i.e. rather than there being a tool like update-grub that calls mkinitramfs, feeding it a shell-script GRUB generated (which then becomes the /init of the initramfs); instead, there'd be a tooling package you'd install that's related to the kernel itself, where you call e.g. kernel-update(8) and that would call mkinitramfs — and the /init shoved inside it would be this bootloader. This bootloader would then be running for the whole initramfs phase of boot, "owning" the whole bootstrap process.

What the architecture is at that point, I'm less clear on. I think either way, this initramfs userland, through this bootloader program, will now handle both the cases of "acting like a bootloader" and "acting like the rest of initramfs-based boot up to pivot-root." That could mean one monolithic binary, or an init daemon and a hierarchy of services (systemd: now in your bootloader), or just a pile of shell scripts like GRUB gives you, just now written by Redhat.

Yes of course. I really mean to say, before/instead of pivoting to the OS root. It sounds like this will synergize well with the UKI effort too, at least from a Secure Boot perspective.

I wonder if I have ever had a laptop where the UEFI worked correctly and without bugs. It always required some workaround somewhere to get stuff working.

> I think Windows even does this now.

Why? What advantage is there for Windows to do this?

I'm not entirely sure, to be honest. If you google something like "windows 11 advanced startup settings" you'll see what I mean, though: the boot menu is now in Windows.

I guess it allows the bootloader to be much simpler, at least in theory.

Reply on news.ycombinator.com