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

241–250 of 460 posts

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

#241

Post by 8n4vidtmkvmk »

Am4TIfIsER0ppos wrote: post #117
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.

Grub is the same everywhere. Motherboard bios/uefi is not. It isn't F10 for me.

How many computers are you operating though? Maybe you'll have to reboot a couple times until you figure out the proper key but then you'll know it. And if you forget it, you clearly aren't doing this often enough for it to be a problem either

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

#242

Post by ssl-3 »

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.

I'm more-or-less just a dumb user in these matters, but I've been using Linux to boot Linux with my semi-elaborate desktop rig because that's how ZFSBootMenu[0] do. Keeping [fairly] quiet about unnecessary hardware (like nVidia drivers) during this bootloader phase seems to be doing the trick for me.

Or, at least: I certainly didn't have to do anything to the kernel for it to work. I'm just running whatever Void Linux is rolling with right now.

[0]: https://docs.zfsbootmenu.org/en/v2.3.x/

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

#243

Post by [deleted] »

kragen wrote: post #191
comex wrote: post #176

Earlier quoted context omitted.

I watched the video. They have two different configurations, one where there’s only one kernel, one where there are indeed two separate kernels with one kexec’ing to the other.

thank you for your sacrifice and for the resulting correction to my error

[deleted]

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

#244

Post by mixmastamyk »

ta8645 wrote: post #152
arp242 wrote: post #99

Earlier quoted context omitted.

What's the reason it doesn't load those modules from the regular filesystem? That's what FreeBSD does, and seems to work well enough?

Because there are a lot of different types of filesystems supported. And you'd have to compile them all into the kernel. Which of course you can do, that is supported by the build system today. But Distros typically prefer to keep their kernels small, and not waste the RAM that would be taken up by compiling it all into the kernel.

It must already have vfat and the ESP, so why not just copy a basic set of modules to a subfolder there?

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

#245

Post by Timber-6539 »

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…

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

This is an indication of bad admin choice. The kernel defaults should not corrupt the boot process and if you add further experimental flags for testing you ought to have a recovery mechanism in place beforehand.

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

#247

Post by egberts1 »

TheDong wrote: post #233
egberts1 wrote: post #231

I prefer my bootloader (be that it may, GRUB, lilo, or even BusyBox) because thosr image will go away once the kernel is started. Nothing for hacker to see and analyze the bootloader, assuming you did not load a driver to the NVRAM/Flash/UEFI/EFI. Nice security compartment alization. Redhat is smothering this easential security abstraction of 1st stage loader: not a good security model.

Can you explain more what security vector you're talking about here, because I just don't see it? Like, as far as I can tell, grub or whatever is a bundle of filesystem and device drivers, with enough info to then execute a kernel. Linux also is a bundle of filesystem and device drivers, but better tested ones I think. To me, it seems like using the kernel's filesystem drivers, which you have to use already anyway on…

It is the same security abstraction where you don’t allow support for network socket in process ID 1.

(Looking at you, systemd.)

You don’t allow access to the bootloader from any kernel, thereby afford a relative security in starting 2nd stage (kernels). One abstraction is that TPM, et. al., can lockstep assurances on each stage. At a minimum, you have a bootloader, in case of SNAFU/FOOBAR.

Bricking (or worse, malicious kernel) seems more a possibility with upcoming Redhat design.

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

#248

Post by creshal »

mixmastamyk wrote: post #246

I recently moved to sdboot and prefer its simplicity compared to grub. However they still missed the mark a bit, its folder tree on the ESP is a mess. I’ll look into this but prefer kernels managed automatically by apt/dnf etc.

sd-boot on Debian 12+ is mostly self-configuring, and the folder structure is just one folder? Not sure what's messy about that.

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

#249

Post by creshal »

dvhh wrote: post #228
Dwedit wrote: post #103

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.

That's for the case for MBR partition type, I really hope we moved to more modern alternatives

GPT puts no size limitations on the FAT32 EFI System Partition. Your bootloader can be as big as you want it to be, which is why just booting off of a Linux kernel image with an initrd in the same file has been a valid option for years. Not sure why Lennart feels compelled to reinvent this particular wheel again.

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

#250

Post by creshal »

juped wrote: post #222
nardi wrote: post #218

Meta: Can someone with Linux/bootloader knowledge tell me whether most of these comments are as clueless as they seem?

Many seem a bit confused but I have only skimmed the comments. I don't understand the point of the thing described in the OP (I have not watched the talk, just skimmed the notes), myself. Linux kernels can EFI load themselves; if you want more flexibility than a precompiled kernel command line, or to load from ext4/other non-FAT filesystems, refind exists, fits on the ESP (kernel + initramfs can get big; I keep mine…

If I had a nickel for every time the RedHat ecosystem overengineered itself into a corner and decided the only possible solution was more overengineering, I could probably buy IBM.
Post reply on HN