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

41–50 of 460 posts

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

#41

Post by Arnavion »

saghm wrote: post #32
Arnavion wrote: 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…

Right before that paragraph, they cite issues with GRUB as a motivation for this work. What confuses me is that Redhat already has a GRUB replacement in systemd-boot. Is this work intended to obviate that as well, or is it going to relate to it somehow? I imagine doing all this and tying it to systemd would generate some backlash like usual (although at this point, it seems unlikely that this would affect the plans g…

>I imagine doing all this and tying it to systemd would generate some backlash like usual (although at this point, it seems unlikely that this would affect the plans given how few distros don't use systemd).

systemd-boot is independent of systemd. It's called "systemd-" because it's under the same "group of core OS software" umbrella named "systemd", but otherwise it can be compiled independently, does not require the OS to be using systemd, etc.

Edit: I also wrote originally that switching to systemd-boot would also require switching the kernel from vmlinuz+initramfs to a UKI, but I forgot systemd-boot does support vmlinuz+initramfs through explicit loader entries config.

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

#42

Post by shadowgovt »

Shorel wrote: post #20

Kudos to the developers involved in this functionality. Faster boot times and more secure installations are always advantageous. I'm all rooting for this development. I've been wondering for a while why grub is still used, given that its basic architecture is outdated.

I believe the two main reasons are

- inertia (don't rewrite something if it works; who really wants to own responsibility for testing this thing on all architectures GRUB currently supports?)

- multi-OS boot scenarios (I assume this new system will support that, but (a) I don't know for sure and (b) I don't really want to boot all the way into Linux just to throw Linux away and boot something else...)

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

#43

Post by _ache_ »

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.

I do the same. The only advantage I can think of is editing kernel boot option on boot.

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

#44

Post by Animats »

Or, really, use the ROM's boot loader.

This is getting closer to the way QNX booted decades ago. The boot image has the kernel and whatever user space programs and .so files you decide to include. For a deeply embedded system, you might not have a file system or networking. For desktop QNX (discontinued), you'd have some disk drivers, a file system driver, a network driver, and a shell, along with a startup script, to get things going.

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

#45

Post by alerighi »

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, you need to perform some key combination in a short window, also modern bootloader save the last boot option such that if Windows reboots for an update Linux does not start

- it allows to edit the cmdline of the kernel to recover a system that does not boot, e.g. start in single user mode. That can really save your day if you don't have on hand an USB stick and another PC to flash it

- it allows you to choose between multiple kernels and initrd images easily, again for recovery purposes

- it has a voice for entering the UEFI setup menu: in most modern systems again entering the UEFI with a keyboard combination is unnecessarily difficult and has a too short timeout

- it allows you to boot any other EFI application, such as memtest, or efi shell. Most UEFI firmwares doesn't have a menu to do so.

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

#46

Post by bayindirh »

lofaszvanitt wrote: post #39

Also create a boot please that rivals w10's almost instant boot process. I just hate the current slow/non parallel boot process.

Many of our systems boot under 10 seconds after GRUB. You can make GRUB menu to timeout quickly or be completely hidden if you want.

A modern system with a connected network can boot quite fast. Windows' instant boot is not boot actually, it's thawing hibernation.

One of the biggest features touted by systemd is "embarrassingly parallel" booting capabilities, which Parallel SYS-V already sported.

IOW, Linux already can boot pretty quickly given no hardware device is holding it back.

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

#47

Post by benwaffle »

andrewstuart wrote: post #11

I’m fairly technical but I have to say grasping the field of partitions , booting, boot loaders grub uefi its alternatives and the various combinations thereof in Linux defeated me. When learning something I try to find the simple path, a reliable minimum that gets to the goal. I never found it. Complexity is the word that comes to mind.

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.

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

#48

Post by bastien2 »

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, extend it to do what you need, and avoid doing the traditional linux folly of Yet Another Unnecessary Reinvention.

Or was systemd vendor lock-in not enough for your shareholders?

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

#49

Post by michaelt »

Ah yes, unified kernel images.

Finally, an end to the tiresome and obsolete notion of Linux running modified versions of the Linux kernel. With unified kernel images, Linux users can finally be confident knowing their kernels are signed by companies with Microsoft's blessing, such as Red Hat and Canonical - and Linux will be have proper support for the use cases of companies like TiVo, who want to run Linux, but also want to ensure the device owner can't make any modifications to the software on their device.

This will be well worth it, to protect against the ever present issue of criminals breaking into my hotel room, finding my unattended laptop, and deciding not to steal it to sell on ebay - but instead to secretly modify my initramfs. I don't know about you, but I've had two covert CIA teams rappel in through my window this week alone.

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

#50

Post by pzmarzly »

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.

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.
Post reply on HN