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

81–90 of 460 posts

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

#81

Post by kbolino »

drewg123 wrote: post #74
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.

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 that Linux cannot.

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

#82

Post by UnlockedSecrets »

nubinetwork wrote: post #33
zdw wrote: post #23

Earlier quoted context omitted.

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.

Are there any instances of features being utilized that the old version of the code is unable to cope with well enough to be able to boot the system?

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

#83

Post by mjg59 »

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.

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

#85

Post by vlovich123 »

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.

I think you’re missing the broader point I was trying to make by hyperfocusing on 1 example of an issue that can arise from kexec and is solvable in a number of ways. Ultimately the critique raised in the video about focusing on the VM and not trying this on real HW yet is a very real one and is the single hardest problem here I suspect, so punting on it can’t go on for too long.

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

#86

Post by yjftsjthsd-h »

nubinetwork wrote: post #33
zdw wrote: post #23

Earlier quoted context omitted.

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.

Refuse, or legally can't? Oracle doesn't own the copyrights on commits made after illumos forked from the corpse of opensolaris.

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

#87

Post by upon_drumhead »

UnlockedSecrets wrote: post #82
nubinetwork wrote: post #33

Earlier quoted context omitted.

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

Are there any instances of features being utilized that the old version of the code is unable to cope with well enough to be able to boot the system?

Native ZFS encryption is the major one I'm aware of

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

#89

Post by Aissen »

Considering distros serious about booting are effectively shipping grub forks with tens (debian) to over a hundred (ubuntu) to hundreds (fedora) of patches on top, it might be time to invest a bit more into Open Source early-stage booting. I'm doubtful that efistub + UKIs will solve all the problems, but I'm cautiously optimistic. Wait and see!

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

#90

Post by mjg59 »

vlovich123 wrote: post #85
mjg59 wrote: post #83

Earlier quoted context omitted.

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.

I think you’re missing the broader point I was trying to make by hyperfocusing on 1 example of an issue that can arise from kexec and is solvable in a number of ways. Ultimately the critique raised in the video about focusing on the VM and not trying this on real HW yet is a very real one and is the single hardest problem here I suspect, so punting on it can’t go on for too long.

My broader point is that the majority of kexec issues are associated with the difficulty in quiescing the hardware, and there's simply no need to load the majority of drivers before offering this option which constrains the problem significantly.
Post reply on HN