Live data from Hacker News

No more boot loader: Please use the kernel instead

pretalx.com

31–40 of 460 posts

Re: No more boot loader: Please use the kernel instead

#31

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.

It's not that it defeated you, it's literally undocumented what you're supposed to do.

Re: No more boot loader: Please use the kernel instead

#32
post #5

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 networ…

Right before that paragraph, they cite issues with GRUB as a motivation for this work. What confuses me is that Redhat already has a GRUB replacement in systemd-boot. Is this work intended to obviate that as well, or is it going to relate to it somehow? I imagine doing all this and tying it to systemd would generate some backlash like usual (although at this point, it seems unlikely that this would affect the plans given how few distros don't use systemd).

Re: No more boot loader: Please use the kernel instead

#33
post #23
post #2

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 t…

FWIW, Grub has a read-only ZFS implementation to allow booting: https://git.savannah.gnu.org/cgit/grub.git/tree/include/grub...

Grub uses an ancient version of zfs code, it's tied to Oracle's zfs and they refuse to update it to current openzfs.

Re: No more boot loader: Please use the kernel instead

#34
post #16
post #6

Earlier quoted context omitted.

Via EFI probably.

Does that mean the UI you will use to choose the kernel will probably be the bios?

Yes. If your UEFI doesn't have a good enough interface for selecting entries or temporarily modifying a kernel bootline, you can still use a bootloader, but a minimal one like systemd-boot instead of GRUB. All it does is show the text menu and then execute the UEFI binary for that entry, which in this case is the kernel's UKI binary, so all the heavy-lifting of LUKS, filesystem drivers, password entry, etc is done by the kernel and there's no complexity or duplication in the bootloader.

Re: No more boot loader: Please use the kernel instead

#35
post #9
post #2

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 t…

> I'd rather have "NMIRFS" (no more initramfs). In many cases, you don't need initramfs. I rarely use one in embedded systems.

I use them in embedded systems because they allow me to mount encrypted volumes without exposing the keys.

Re: No more boot loader: Please use the kernel instead

#36
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

Re: No more boot loader: Please use the kernel instead

#37

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.

Complexity, indeed. I haven't looked into this stuff in literally decades, but: I thought the purpose of a boot loader was to pass control to code belonging to the OS - which would then be responsible for loading it's own drivers, etc.. This solution sounds like starting an entire OS, only to boot the next OS.

But then I think UEFI is also stupidly complicated, and ought to be whacked down to its core functions. Dinosaur, am I.

Re: No more boot loader: Please use the kernel instead

#40
post #7
post #2

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 t…

The Linux kernel does not require an initramfs. You can build a kernel with everything compiled in; with no modules needed at all. Initramfs is used for generic kernels where you don't know beforehand which features will be required. This allows you to avoid wasting RAM on features you don't use. But it is optional.

> Initramfs is used for generic kernels where you don't know beforehand which features will be required.

And also for e.g. cases where you've got some custom stack of block devices that you need to set up before the root FS and other devices can be mounted. It's not just about loading kernel modules.

Post reply on HN