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...
No more boot loader: Please use the kernel instead
211–220 of 460 posts
Re: No more boot loader: Please use the kernel instead
#212An 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…
To state this slightly differently: GRUB has a terrible security story, a key point in the posted presentation. GRUB is huge and has design traps which contribute to regular developer mistakes. Any huge solution here will suffer the same problem, the larger it is the more likely the problem is. You don't really need much to do work here, a UEFI program can walk through the directories in the ESP and make choices, and…
I'd say grub is crap, let's switch to das u-boot, which is not.
Re: No more boot loader: Please use the kernel instead
#213Earlier quoted context omitted.
I realize that. But every distro I've used uses an initramfs, so unless you want to build your own kernels, you're stuck with it, and the painfully slow initramfs updates when you update packages, and dkms (or similar) updates the initramfs with the newer version of your out-of-tree modules.
Given the reason why "out-of-tree modules" exist, there's really no way to eliminate initramfs or something like it entirely in the general case. It might be possible to speed up the process of building the image (as long as the results are not "redistributed"), but this is a licensing and legal problem, not a technical one. FreeBSD is under a much more permissive non-copyleft license and so can legally bundle things…
initramfs can be eliminated if no kernel modules are required to boot the system. In practice, this means drivers for the motherboard, drivers for the block storage system, and the filesystem have to be compiled in as opposed to being modules. Certain 'interesting' disk schemes that require userspace configuration tools aren't possible, including LVM2, dmraid, disk encryption, /etc/fstab has to hardcode the physical path, and probably a dozen other things I can't think of. If you want to do PXE boot over wifi and you have out of tree wifi drivers I don't think that would work, though tbh PXE over wifi sounds insane.
Re: No more boot loader: Please use the kernel instead
#214What'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.
EFISTUB requires recompiling the kernel every time initramfs, microcode or commandline change, no? That would get annoying pretty quickly on desktop PCs, which are not that fast with recompiling, and would need to do all of this quite often, e.g. on nvidia driver updates.
The command line can be part of the UEFI boot entry depending on your particular firmware.
I think I can recompile the Linux kernel in around 15 minutes, but I have a 12400F. And 15 minutes is still 60 times longer than most people are willing to wait.
Re: No more boot loader: Please use the kernel instead
#215I 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.
Re: No more boot loader: Please use the kernel instead
#216I 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.
You absolutely can sign the kernel with your own keys. This would allow you to boot your machine into the first level kernel without the bootloader.
Is this 'couldn't' a self imposed requirement or a technical one I can't think of ?
Re: No more boot loader: Please use the kernel instead
#217Earlier quoted context omitted.
Install arch with a couple of different bootloaders and disk layouts, and you'll learn it all. The simplest option is potentially systemd-boot + an unencrypted rootfs.
The simplest is LILO without an initrd
I actually did a ctrl-f for LILO and this was the only comment that mentioned it. Time flies.
Re: No more boot loader: Please use the kernel instead
#218Meta: Can someone with Linux/bootloader knowledge tell me whether most of these comments are as clueless as they seem?
Re: No more boot loader: Please use the kernel instead
#219Earlier quoted context omitted.
Yeah, look at Windows 10 if you want to see how this can be done poorly. Its boot menu works by booting Windows 10 first and then restarting the computer if you choose another OS. This includes going all the way through POST again. Took something like two minutes end-to-end to get to Windows 7.
I'm not sure I experienced the same with the Windows boot loader so maybe that behavior was something case specific instead of intended?
Not sure, there might have been a fast path if you were booting to another Windows 10 install. The old legacy Windows Boot Manager also doesn't have the issue since it's much simpler and it executes in faux text mode before the OS boots.
Re: No more boot loader: Please use the kernel instead
#220Does 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.