Hacker News Reader

Comment by londons_explore | Hacker News Reader

It seems lame that UEFI firmware needs to 'mount' a filesystem to load a bootloader.

That bootloader needs to mount a filesystem to find the kernel.

The kernel needs to mount the filesystem to run the system.

Each of those mount operations is done with different code, and normally each involves some config or search process to find the right disk/partition. If any of the searches finds the wrong partition or is misconfigured, you get a boot failure.

It really feels like the boot process is more complex than it needs to be, with more opportunities for failure than necessary.

View on HN

The firmware can execute UEFI binaries from any filesystem it can read. The spec mandates FAT32 as a supported filesystem, but nothing prevents additional filesystems from being supported - Apple's firmware for example understands APFS (and previously, HFS+).

The Linux kernel can act as an EFI binary/application using a mechanism/feature called EFISTUB and thus can be loaded directly. The concept of a "bootloader" in UEFI-based Linux system is mostly vestigial (to enable feature-parity with non-UEFI systems or work around broken firmware). On a non-defective UEFI firmware, a bootloader is unnecessary, the UEFI firmware can load your kernel and initrd directly from the EFI system partition.

Ideally you'd want your UEFI to be able to read and understand your main filesystem (ZFS in this case) which means you no longer need a separate EFI system partition to store your kernel/initrd (and can enjoy the redundancy and features provided by your filesystem of choice). UEFI is actually extensible so you can have third-party drivers (you'd need to store those drivers somewhere, but a USB stick/memory card would do, or you could technically embed it in your firmware)?

The problem when it comes to ZFS specifically is that there is no UEFI-based driver with feature parity to the main ZfsOnLinux project. GRUB has a primitive implementation (extracted as stand-alone EFI drivers here: https://efi.akeo.ie) but it lacks support for many features, effectively forcing you to have a separate boot-time ZFS partition with all unsupported features disabled (if you're going to use a separate partition, why not just use FAT32 which is natively supported).

There's not really a way around it unless you hardcode the bootloader rather than store it on disk.

That said, there are only two steps in the modern boot process on a PC: the UEFI firmware loading a basic FAT driver and the kernel mounting the other filesystems. The UEFI bootloader can use the existing FAT driver to load the kernel and the initramfs which will use the same code to mount partitions.

You can skip the UEFI bootloader and directly boot unified kernel images after putting them on the UEFI partition.

I'd quite like UEFI to be able to pass some kind of argv[0] to the direct-loaded kernel, so the kernel knows exactly which file on which partition of which disk it was loaded from. That would then become the default root filesystem.

That effectively removes all config from the process - and means that any disk with a uefi executable kernel can be booted without the mystery step of "lets try to figure out where we're booting from".

This does work inside of rEFInd, which can load a kernel EFI blob directly, and supply it args.

> I'd quite like UEFI to be able to pass some kind of argv[0] to the direct-loaded kernel, so the kernel knows exactly which file on which partition of which disk it was loaded from. That would then become the default root filesystem.

I think UEFI gives an EFI application (such as the Linux kernel) everything it would need for this already - but I guess Linux doesn't use it.

The EFI application entry point includes a handle to your own image [0], and the EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL_GUID [1] protocol allows you to query the path it was loaded from. It is possible for an image to be loaded without a path, but it looks like EDK2 provides it at least [2].

[0] - https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.h...

[1] - https://uefi.org/specs/UEFI/2.10/09_Protocols_EFI_Loaded_Ima...

[2] - https://github.com/tianocore/edk2/blob/991515a0583f65a64b3a6...

I think discoverable partitions are intended to solve this problem.

https://uapi-group.org/specifications/specs/discoverable_par...

That bootloader needs to mount a filesystem to find the kernel.
The kernel needs to mount the filesystem to run the system.

Each of those mount operations is done with different code...

Not on FreeBSD. Our bootloader reuses kernel code (because, you know, developing the entire operating system together makes this possible).

I always feel one of the under appreciated features of zfs on freebsd was how nicely it was integrated into the whole operating system. that is, it is easy to boot off a zfs drive in freebsd.

ZFSBootMenu "reuses kernel code", too. It actually reuses kernel binaries, because it is nothing more than a collection of init scripts in a small Linux initramfs to enumerate ZFS filesystems and allow you to kexec one of the kernels found within. When using `generate-zbm` to build a custom image, your copy of ZFSBootMenu will use the very same kernel and ZFS driver that your system is running. When using the the prebuilt UEFI or separate kernel/initramfs that we provide as a convenience, the image is built from a Void Linux container using whatever kernel and ZFS driver was current at the time the container image was created.

I'm not sure what the complaints are about mounting filesystems. Unless you want to raw-dump your kernel and other components necessary for booting to some known offset on the disk, you'll always have to walk some filesystem to find the kernel. This even happens in the FreeBSD boot process, where one of the stages has to go looking at the filesystem for a kernel.

This is precisely why UEFI is a heap of garbage, and things like coreboot, u-boot are much more appealing. It is far too complicated, and the complexity of the standard, coupled with half-assed vendor code, mean that not only is the boot process more fragile, it's also much less secure.

It's so, so, SO, unnecessarily complicated while providing me no new features (like a faster boot). LILO worked. Even with LVM. As the bootloader, of course it exists outside of the kernel, initrd, my rootfs. That code would run, find the kernel, run that.

GRUB has some slight improvements like running other operating systems, but that's about it. Unsure if it's worth the price...

None of this crazy modern boot-time ouroboros. Too many layers, too much software.

At least we should _get_ something for this. How about a 2s cold boot on my thinkpad?

>It really feels like the boot process is more complex than it needs to be

You can use EFISTUB kernels directly (through efibootmgr) and use UEFI bios as the bootloader. There is no automatic kernel discovery with this method of course.

More people than just you are starting to feel that way:

"I have come to bury the BIOS, not to open it: The need for holistic systems" https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-...

This also talks about how you need a boot processor to do things like train up the RAM interface just so you can boot the main processor.

Not to mention the initrd, another filesystem that need to be mounted and must be kept aligned with the rest.

I've long switched to compiling my kernel including all needed modules and the EFI stub. I don't have initrd or bootloader anymore, and can boot in a few seconds.

Is the bootloader itself considered as an operating system?

Does it have a kernel too?

Can be. A bootloader is just a baremetal application, so called not by architecture but its primary purpose of loading much larger images, jumping to it and not coming back. If the CPU is coming back, it's called a monitor program, if it's going back and forth, it's a supervisor, or a kernel. Old/mainframe folks sometimes call operating system kernel a supervisor program.

Theoretically it should be possible to flash Linux Kernel onto BIOS Flash ROM to directly load and run it from there. But x86 being x86, you also have to have bunch of circus tricks to initialize motherboard and to get out of 16-bit 8086 compatible mode and to load Kernel from disk, in such hypothetical Kernel image. BIOS/UEFI and bootloader each do parts of those.

Reply on news.ycombinator.com