Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No more boot loader: Please use the kernel instead

pretalx.com

Post reply on HN
Print view View original

181–190 of 460 posts

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

#181

Post by lmm »

aaronmdjones wrote: post #127
medstrom wrote: post #110

Earlier quoted context omitted.

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?

> But to load it at boot time it absolutely must be done through an initramfs. Is that right? Yes, because it cannot be part of the kernel image, or it would be illegal (a violation of the GPL license) to distribute that kernel. Therefore, it must be a module, and that module has to live somewhere and be loaded by something. If root is on ZFS, this must therefore live in an initramfs and be loaded by it so that the i…

One could have the equivalent of DKMS build the modules into the kernel image instead of building the initramfs. I don't know how much practical overhead there is to the initramfs and pivot_root dance, but it feels far uglier than it should need to be to just load some modules.

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

#182

Post by E39M5S62 »

yjftsjthsd-h wrote: post #30

This kinda sounds like zfsbootmenu but without the ZFS. Which makes me wonder how hard it would be to factor out the ZFS bits and just use zfsbootmenu on other filesystems.

It'd be doable, but not with out a whole lot of hacking on it. The internals of ZFSBootMenu are tied very tightly to ZFS. Though at that point you'd largely be reimplementing https://github.com/open-power/petitboot - which probably would be easier to port to x86_64 as an EFI application.

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

#183

Post by teo_zero »

linsomniac wrote: post #92
ta8645 wrote: 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.

I build my own kernel. I did invest some time to select the right configuration, but now it's just a question of copying over the old .config and running "make". What's annoying about that?

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

#184

Post by lmm »

jagrsw wrote: post #142

I get truly confused when using GRUB. Maybe it’s just me being unwilling to dive into all the details, but seriously, why are there like 30 packages starting with 'grub' under Debian? All I want is to boot my kernel under EFI, and the package choices are overwhelming. grub-common grub2 grub2-common grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed grub-efi-amd64-signed-template grub-efi-amd64-unsigned grub-efi…

> Maybe it’s just me being unwilling to dive into all the details, but seriously, why are there like 30 packages starting with 'grub' under Debian? All I want is to boot my kernel under EFI, and the package choices are overwhelming.

Debian packaging policy is insane, that's nothing to do with grub. On a regular distribution there is one (1) grub package (e.g. I just checked Slackware and Gentoo).

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

#185

Post by raggi »

raggi wrote: post #178

An 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 perform assertions, so keep your A/B/R kernel and ramfs objects in there (as UKIs, as separate files, whatever). It can make a choice and boot the thing.

If you want user choice you could put menus into that program too, but you don't need them for most users, so leave them out, that's a ton of deps gone.

A basic program to do this isn't more than 1000 lines, it'll be low on maintenance and exceptionally low on critical flaws.

It's not hard writing even fairly complex things for EFI, here's Fuchsia's UEFI stage which is designed for development and has far more features (fastboot, mdns discovery, etc) than most of these things need. It's still tiny compared to the grub stuff: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/s...

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

#186

Post by andrewmcwatters »

rcxdude wrote: post #180
andrewmcwatters wrote: post #173

Earlier quoted context omitted.

It’s in the post, can’t you read? Also, something being low-level has nothing to do with documentation.

You've complained about a lot of things, but I can only guess at what you are actually trying to accomplish, and you explicitly reject solutions which would actually resolve your problem. The first-party documentation for the linux kernel boot process is: https://www.kernel.org/doc/Documentation/x86/boot.txt . It's not the kernel's job to get itself into memory and pass it the required information about the system. T…

[flagged]

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

#187

Post by nmstoker »

kragen wrote: post #169
yjftsjthsd-h wrote: post #95

Earlier quoted context omitted.

If I'm understanding correctly, it might help to point out that in spite of the title they are proposing a bootloader, which can still let you modify the cmdline, boot to other OSs, etc. It's just that the bootloader is itself using the Linux kernel so it can do things like read all Linux filesystems for "free" without having to rewrite filesystem drivers.

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.

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

#188

Post by E39M5S62 »

It's nice to see more people embracing the capabilities of UEFI and Linux. ZFSBootMenu has been shipping an EFI application (really, a UKI masquerading as one) for almost four years now - https://docs.zfsbootmenu.org/en/v2.3.x/ . The neat part is that the first stage kernel boots in roughly 1.5 to 2 seconds. It's not really appreciably slower than other boot methods while at the same time exposing a substantial amount of pre-boot functionality.

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

#189

Post by raggi »

mjg59 wrote: post #83
vlovich123 wrote: post #78

I really like the idea and the approach. I’m a little concerned however about the compatibility issues with kexec. For example, here’s what Arch says about the NVidia module: > The graphics driver needs to be unloaded before a kexec, or the next kernel will not be able to gain exclusive control of the device. This is difficult to achieve manually because any programs which need exclusive control over the GPU (Xorg, d…

There's no reason to load things like the nvidia driver if all you want to do is offer a choice to kexec into another kernel, which makes things easier - you can continue just using the display environment the firmware set up.

you bet though that as soon as the grub types are forced into userspace they're going to want to do fancy userspace things, like give me a fancy framebuffer driver and the ability to push a shader into the gpu to animate while the second kernel stage boots, etc etc.

the more rope given here, the more will be taken, a rich programming environment of a whole kernel will I'm sure raise temptation to new levels of stuff here, and the natural progression from the shader framebuffer is hand-off to the next kernel stage so it can keep the animation going until wayland starts or whatever. maybe i'm paranoid.

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

#190

Post by rcxdude »

dataflow wrote: post #155
rcxdude wrote: post #149

Earlier quoted context omitted.

Booting linux directly just boots you into that install. It doesn't give you a boot menu or any of the other functionality GRUB provides. This project is basically proposing building that in a small initramfs userland instead (which has the advantage of requiring much less effort and code duplication). It's functionally very similar to GRUB, including with regard to your last point: generally speaking at the moment o…

> Booting linux directly just boots you into that install. It doesn't give you a boot menu or any of the other functionality GRUB provides. This project is basically proposing building that in a small initramfs userland instead I indeed understood that part, but their motivation for this was security . If you want security, you should want to boot directly into the kernel. And if you're the occasional user who has mu…

They have to cater to a pretty wide set of users, and deal with a wide array of hardware and scenarios. UEFI, especially whatever random implementations of UEFI their users have, can't cover all of it. Addressing those needs currently requires something like GRUB (or a customised initramfs, which would be my preferred solution, but it requires more know-how), but GRUB effectively has to duplicate a large subset of the work that the kernel does, and inevitably (if only due to lack of resources), does so poorly, hence their argument that this is good for security: it's better than the status quo of GRUB. Indeed, if you have a UEFI firmware and it supports your use case, and it's well implemented, then this project is of no extra use (though it seems designed to just get out of the way in that situation and more or less just boot directly), but Red Hat's userbase does not entirely consist of people who are in that situation.
Post reply on HN