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

141–150 of 460 posts

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

#141

Post by LH9000 »

pavon wrote: post #94
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.

I was working on my Dad's Dell laptop this weekend, and no matter how quickly I spammed the correct key (F12 in this case) it would miss it and continue to a full boot about 3/4 times. I never figured out if it is just picky about timing, or if it had different types of reboots where some of them entering BIOS wasn't even an option.

I start tapping as soon as the screen blanks, probably twice a second. I find this to be best for all BIOS/UEFI interfaces.

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

#142

Post by jagrsw »

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
  grub-pc
  grub-pc-bin
Do I need to mix grub2 and grub packages to get it to work? Currently I do, and a bit afraid to remove one or the other :)

Usually, I end up trying things randomly (leaving some funny mess in /boot/EFI b/c not sure if --efi-directory should contain /boot/EFI prefix, or just /boot or nothing), then running some semi-random grub-install command, and eventually, it starts to work. But this is far from intuitive.

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

#143

Post by rcxdude »

drewg123 wrote: post #2

I personally think they're moving in the wrong direction. I'd rather have "NMIRFS" (no more initramfs). Eg, a smarter bootloader that understands all bootable filesystems and cooperates with the kernel to pre-load modules needed for boot and obviates the need for initramfs. FreeBSD's loader does this, and its so much easier to deal with. Eg, it understands ZFS, and can pre-load storage driver modules and zfs.ko for t…

Does FreeBSD's loader share code with the kernel? It does seem like a lot of duplication of systems to make it work in comparison to just using the same code.

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

#144

Post by nubinetwork »

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?

https://github.com/openzfs/zfs/tree/master/cmd/zpool/compati...

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

#145

Post by Sakos »

Denvercoder9 wrote: post #91
mjg59 wrote: post #80

Earlier quoted context omitted.

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.

Huh, today I learned. I'll consider myself lucky I didn't come across one of these machines yet.

I've encountered way too many of these and I hate them with all my being.

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

#146

Post by derefr »

jchw wrote: post #140
bityard wrote: post #108

Earlier quoted context omitted.

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

Sort of, except it's automated. Basically, System A's kernel boots. But, instead of immediately loading the System A userland, it loads a boot menu of systems that it reads from UEFI NVRAM and presents it to the user. So you select System B from the list, the menu sets BootNext in NVRAM and issues a reboot. In practice, the main UX difference is that it takes a bit longer and you'll see the UEFI vendor splash screen…

> instead of immediately loading the System A userland

I mean, it kind of is loading the System A userland. At least the initramfs of it. AFAICT in the proposal the bootloader would now be a regular userland program living in the initramfs.

I get the impression that the eventual goal would be to make this bootloader program into the "init(8) but for the initramfs phase of boot" — i.e. rather than there being a tool like update-grub that calls mkinitramfs, feeding it a shell-script GRUB generated (which then becomes the /init of the initramfs); instead, there'd be a tooling package you'd install that's related to the kernel itself, where you call e.g. kernel-update(8) and that would call mkinitramfs — and the /init shoved inside it would be this bootloader. This bootloader would then be running for the whole initramfs phase of boot, "owning" the whole bootstrap process.

What the architecture is at that point, I'm less clear on. I think either way, this initramfs userland, through this bootloader program, will now handle both the cases of "acting like a bootloader" and "acting like the rest of initramfs-based boot up to pivot-root." That could mean one monolithic binary, or an init daemon and a hierarchy of services (systemd: now in your bootloader), or just a pile of shell scripts like GRUB gives you, just now written by Redhat.

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

#147

Post by lern_too_spel »

josephcsible wrote: post #119
mjg59 wrote: post #112

Earlier quoted context omitted.

grub consumes a bunch of untrusted material (splash pictures, fonts, filesystems, executables, and more) and parses them. grub's also written in C, which is pretty much the worst case for writing parsers. Someone able to replace any of these with something that triggers a vulnerability in grub is then able to, for instance, take control of your boot process and obtain your disk encryption key or user password or any…

Isn't everything that GRUB reads only writable by root? Is the threat model that root is the attacker?

Or potentially by another user loading that partition if you boot into another OS.

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

#148

Post by garaetjjte »

derefr wrote: post #139
garaetjjte wrote: post #132

Earlier quoted context omitted.

It could kexec other kernels but probably won't be able to jump to other OS bootloaders after it already called ExitBootServices.

The sibling comments who think you need to jump back to EFI to solve this, are thinking in layer-ossified terms. This is Redhat proposing this, and they're perfectly confident in upstreaming kernel patches to make this happen. I would assume that in their proposed solution, the kernel would have logic to check for a CMDLINE flag (or rather, lack of any CMDLINE flags!) to indicate that it's operating in bootloader mod…

>and if decides that it is, then it never calls ExitBootServices

That's unlikely, I think that would mean you cannot use native drivers, at which point you're just writing another bootloader. I suspect they only planning to kexec into target kernel, not chainloading other EFI bootloaders.

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

#149

Post by rcxdude »

dataflow wrote: post #131

I've thought about something like this before, but I have so many questions on just the basic premise... First: Linux could already be booted directly from the UEFI manager. You don't need GRUB at all. So why a new scheme - why weren't they just doing that? Second (and third, etc.): If I have multiple Linux installations along with a Windows installation, wouldn't this mean one of them now has to be the one acting as…

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 one OS needs to be managing the boot menu, and when they fight over it things go badly (see the status quo where Windows will occasionally just insert itself as the default after an update). UEFI could in principle have fixed this, but the inconsistent implementation between vendors makes it an unreliable option for OS developers.

(And in principle this system could load other linux distros assuming there was some co-ordination in how to do so. Windows is more difficult, as is interaction with secure boot)

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

#150

Post by adtac »

TylerE wrote: post #135
garaetjjte wrote: post #132

Earlier quoted context omitted.

It could kexec other kernels but probably won't be able to jump to other OS bootloaders after it already called ExitBootServices.

Theoretically, couldn't it just write to a "boot this image next time" field (is the legacy MBR area available?) and trigger a reboot?

The target image would need to reset that field so that a second reboot puts you back into the bootloader because otherwise you'll be stuck booting that image forever.
Post reply on HN