Live data from Hacker News

No more boot loader: Please use the kernel instead

pretalx.com

201–210 of 460 posts

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

#201
post #116

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.

I have to say I find Lennart's arguments quite unconvincing. As another person said, the vast majority of people just want default boot to the most recent kernel (which this proposal could do well).

But then when it comes to the other points, yes I want to be able to reliably boot into other systems, but both systemd-boot and grub are notoriously bad at detecting other systems on disks (both use install-time detection IIRC). The only one which does a reasonable job is rEFInd. But even more a kernel with appropriate drivers could even add kernels/systems on usb disks to the selections (why do I have to go to the UEFI selection to boot from USB).

The next thing he completely ignores is booting into zfs or btrfs snapshots, which is not possible using systemd-boot AFAIK, and again would be much nicer to do with a kernel.

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

#202
post #169

Earlier quoted context omitted.

you seem to be saying that they are using two separate kernels, one for the bootloader and one for the final boot target the title text says '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' which sounds like they're not talking about using two separate kernels, one for the bootloa…

>> you seem to be saying that they are using two separate kernels, one for the bootloader and one for the final boot target This doesn't make sense. There's nothing in the post you responded to which could realistically be interpreted as making that point. And there haven't been any edits, which might have explained your confusion.

the comment says 'they are proposing a bootloader, which can still let you modify the cmdline, (...) the bootloader is itself using the Linux kernel'

possibly you don't know this, but in order to run a kernel with a modified command line, the bootloader-kernel would need to run a second kernel, for example using kexec; linux doesn't have a useful way to modify the command line of the running kernel. that's why i interpreted the comment as saying that they are proposing using two separate kernels. in https://news.ycombinator.com/item?id=40910796 comex clarifies that they are in fact proposing using two separate kernels; the reason i was confused is that that's not the only configuration they're proposing

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

#203
post #81

Earlier quoted context omitted.

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…

You're talking about something like ZFS, and I get that they can't just compile it in, but a distro can still ship the module, if I'm not mistaken. ...But to load it at boot time it absolutely must be done through an initramfs. Is that right?

Yes, as this is the closest equivalent to "dynamic linking" that can happen at boot time.

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

#204

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

This code already exists in UEFI in the form of secure boot. The 'bootloader' (more accurately 'boot menu' IMO) kernel and its initramfs would be authenticated and unlocked by the system firmware, and then authenticate and unlock the rootfs and (optionally) different kernel for that system. It's basically going "hey, GRUB is more or less re-inventing the linux kernel, why don't we just write a simple userland for lin…

Actually I don’t think UEFI firmware validates the initramfs — that is loaded by the kernel’s efi stub.

One can make a UKI image which glues the two together in a single file along with a tiny bit of code for booting it.

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

#205

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, yo…

You left out the most important reason I went back to using grub: some motherboards have dodgy UEFI support, and having an extra layer of indirection seems to be more robust sometime for some reason.

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

#206
post #7

Earlier quoted context omitted.

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.

Is anyone really wanting to get back into the business of building their own kernels? I started using Linux heavily in '92, and I've built a lot of kernels, and am quite happy to not be building them anymore.

https://www.funtoo.org/Support_Matrix#Kernels

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

#207
post #202

Earlier quoted context omitted.

>> you seem to be saying that they are using two separate kernels, one for the bootloader and one for the final boot target This doesn't make sense. There's nothing in the post you responded to which could realistically be interpreted as making that point. And there haven't been any edits, which might have explained your confusion.

the comment says 'they are proposing a bootloader, which can still let you modify the cmdline, (...) the bootloader is itself using the Linux kernel' possibly you don't know this, but in order to run a kernel with a modified command line, the bootloader-kernel would need to run a second kernel, for example using kexec; linux doesn't have a useful way to modify the command line of the running kernel. that's why i inte…

What I know or don't know is irrelevant, because what matters is that your statement rests of bringing in external knowledge/assumptions, so it's clearly not what the commenter is saying (alone).

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

#208
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…

I agree, I don't think this is actually 'new' at all. We have had EFI Stubs, KExec/KSplice (Heads as a loader distro for example) and non-GRUB options for a while.

At best, this approach doesn't make the boot loader 'go away', it just moves that task to EFI. Which means you depend on EFI instead of GRUB. This isn't really different from say, U-Boot, where you have a bootrom (usually in the SoC or ROM) that does bringup, then U-boot as an intermediary, and then the Linux Kernel. Same deal with BSP and Coreboot, or Bochs or any of the other boot protocol launchers.

Maybe if their scope is the narrowest of all the scopes (only x86 and only UEFI 2.0 and higher and only specific distros) it might make sense, just to have it be invented in-house as a fake moat. But the end-user doesn't really benefit (as there is no change), and other distros are unlikely to care. You do get a dependency on IBVs and OEMs to implement their UEFI correctly, which most have a hard time doing as it is. And you can't re-use it anywhere else, except maybe SystemReady ARM servers.

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

#209
post #202

Earlier quoted context omitted.

the comment says 'they are proposing a bootloader, which can still let you modify the cmdline, (...) the bootloader is itself using the Linux kernel' possibly you don't know this, but in order to run a kernel with a modified command line, the bootloader-kernel would need to run a second kernel, for example using kexec; linux doesn't have a useful way to modify the command line of the running kernel. that's why i inte…

What I know or don't know is irrelevant, because what matters is that your statement rests of bringing in external knowledge/assumptions, so it's clearly not what the commenter is saying (alone).

[dead]

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

#210
post #202

Earlier quoted context omitted.

the comment says 'they are proposing a bootloader, which can still let you modify the cmdline, (...) the bootloader is itself using the Linux kernel' possibly you don't know this, but in order to run a kernel with a modified command line, the bootloader-kernel would need to run a second kernel, for example using kexec; linux doesn't have a useful way to modify the command line of the running kernel. that's why i inte…

What I know or don't know is irrelevant, because what matters is that your statement rests of bringing in external knowledge/assumptions, so it's clearly not what the commenter is saying (alone).

Using external knowledge to interpret the meaning of sentences is how every communication works.
Post reply on HN