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

101–110 of 460 posts

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

#101

Post by vlovich123 »

mjg59 wrote: post #90
vlovich123 wrote: post #85

Earlier quoted context omitted.

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.

Does the kernel actually support doing that? The pitch is that they already have all the pieces and don’t need to do any kernel work to enable this.

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

#102

Post by benstoltz »

One can trade run-time flexibility for size, speed, and small attack surface.

Taken to the limit, Oxide Computer boots using the [Pico Host Boot Loader](https://github.com/oxidecomputer/phbl) which is probably not suitable for your personal system where you would want to boot many OS images from many devices on many different mainboards using very similar or modular boot flash images.

Phbl transfers control to a partial Unix image, also in the boot flash, which brings in the rest of the OS from a well-known boot device. There is no UEFI, CoreBoot, PXE boot etc. The AMD PSP code does run, but that's the only early external blob in the boot path. This does mean that the OS has to understand its hardware, there is minimal "free" initialization.

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

#103

Post by Dwedit »

You had the bootloader because first you needed executable code in the first sector of the partition, and you can't fit much in those 512 bytes. But moving to UEFI means you never execute that code anymore. Instead, you load a BOOT.EFI file off of a FAT16/FAT32 partition. If there's a restriction on size for that, then you proceed to a bootloader instead of the real kernel.

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

#104

Post by Delk »

201984 wrote: post #38

What'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.

Entering the BIOS menu takes several seconds on my ThinkPad, and getting to the EFI boot menu from there takes a few more. That's after hitting the key during the correct time during the boot process, which sometimes takes guessing.

In principle, the EFI multiboot mechanism should be the way to handle basic multiboot options. It would of course be nicer and cleaner from a design perspective not to have redundant mechanisms on top of each other. In practice, though, using the EFI boot menu can be clumsy. The real solution would be for it to not be clumsy but it doesn't look like we're necessarily there.

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

#105

Post by Dwedit »

mjg59 wrote: post #80
Denvercoder9 wrote: post #79

Earlier quoted context omitted.

What kind of machines are people using that entering the UEFI boot menu is difficult? On all three of mine I just press F10 during the first 5 or seconds the vendor logo shows, and I end up in a nice menu where I could select Windows, other kernels, memtest, or the EFI shell or setup.

One easy way to meet Microsoft's boot time requirements is to skip input device enumeration, so there's a lot of machines meeting the Windows sticker requirements where entering the firmware either requires a bunch of failed boots or getting far enough into the boot process that you can be offered an opportunity to reboot into the setup menu.

I have a system where you need to hold down power when turning on the PC to get out of "Quick Boot" mode, and get the ability to get to the bios screen. It's a Sandy-Bridge-era Intel motherboard.

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

#106

Post by spockz »

Denvercoder9 wrote: post #79
alerighi wrote: post #45

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…

What kind of machines are people using that entering the UEFI boot menu is difficult? On all three of mine I just press F10 during the first 5 or seconds the vendor logo shows, and I end up in a nice menu where I could select Windows, other kernels, memtest, or the EFI shell or setup.

On my last two uefi boards, if I press F12 or F8 too soon after power on it either stalls the boot, or it makes it restart. When the latter happens, I’m always too careful in pressing it causing me to miss the window of opportunity and booting right to the OS. Entering the bios or choosing the boot drive regularly takes me 3 tries. (Gigabyte with Intel and Asus with AMD.)

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

#107

Post by mjg59 »

vlovich123 wrote: post #101
mjg59 wrote: post #90

Earlier quoted context omitted.

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.

Does the kernel actually support doing that? The pitch is that they already have all the pieces and don’t need to do any kernel work to enable this.

Module loading is handled by udev, so udev merely needs to support enumerating a subset of the hardware to (eg) ensure input devices are available.

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

#108

Post by bityard »

jchw wrote: post #68
ec109685 wrote: post #52

Earlier quoted context omitted.

Just because the boot loader is using Linux, it doesn’t prevent an alternative OS from being booted into, so there is nothing fundamentally stopping all of grub’s features from working in this new scheme.

It is a bit more complex, though. Quoting "nmbl: we don’t need a bootloader" from last month[1]: > - Possibility to chainload from Linux while using Secure / Trusted boot : Dual-booting, although not supported on RHEL, is important for Fedora. While there are attempts to kexec any PE binary, our plan is to set BootNext and then reset, which will preserve the chain of trust that originates in firmware, while not inter…

Let's say I have a dual-boot system with two totally independent OSes, Systems A and B. It is powered down. I want to boot into System B but the EFI is configured to boot into System A by default.

Am I correct in understanding that the offered solution here is to first boot into System A, find some well-hidden EFI configuration utility (which varies from OS to OS, if it even exists), and then tell EFI to boot into System B on the next reboot?

If so, that's a pretty terrible experience.

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

#109

Post by Sesse__ »

throwway120385 wrote: post #76
alerighi wrote: post #45

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…

If you embed an x86 system somewhere then you might find yourself not wanting to use GRUB because you don't want to display any boot options anywhere other than the Linux kernel. The EFI stub is really handy for this use case. And on platforms where UBoot is common UBoot supports EFI which makes GRUB superfluous in those cases. Many of the Linux systems I support don't have displays and EFI is supported through UBoot…

I must admit that on U-Boot platforms, I use U-Boot EFI to load grub-efi, so that I can have a non-terrible bootloader…

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

#110

Post by medstrom »

kbolino wrote: post #81
drewg123 wrote: post #74

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

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?

Post reply on HN