NMBL: The End Of The Linux Bootloader

40 thoughts on “NMBL: The End Of The Linux Bootloader”

• I always wondered why on earth GRUB is still used. I've set up my own thing with UKI, self signed secure boot and no bootloader in the middle, but it's a huge pain to set up. I really wish this becomes the default, or at least easily supported configuration, in the future

• Geeks will to continue to make things even more geek complex.

• I use kexec to "reboot" I love the speed of the hot reload of the kernel.

• The thing is, I like the custom software that is the bootloader, that allows me to do hacky things with my boot system, like I don't want to rely on vendors for my boot tooling, I mean I get it… I use the vendor boot system to load another boot system… I get it. But… Its interface is uniform and stable and it's convenient for me.

• What about Nvidia drivers, don’t’ they modify initrd qu’en they compile?

• And what if you need a kernel parameter? Not only software can have bugs, but hardware also. Sometimes you are forced to use some extra kernel parameter, and GRUB fully supports this.

• the main advantage is that drivers for file systems and other devices are already in the kernel, so no duplication necessary in the boot loader.
  And EFI already has those drivers, so it reduces driver maintenance (and sources for errors) from 3 places to 2.

  I once experimented with a minmal linux system with only the kernel and a text shell, some basic tools and a text menu as a boot loader.
  That worked fairly well.
  Unfortunately at that time kexec didn't exist, and EFI wasn't common, yet, so I couldn't do what I wanted.

  Then came EFI and after some time with grub and other boot loaders, I discovered refind, and fortunately some EFI drivers -> end of the story.
  EFI drivers get more love from hardware companies than grub drivers (though with EFI grub this problem is probably gone, not sure).

• /chrmz 2''x vk fsx'' vtd(4''px cnt-2 inch tk pn) vfr stat kuiry tub~tmp paas mrkt/
  /dub paas 2''x vk fsx'' < thrm mrk~tmp vk + cnt-2 inch tk pn < 4''px int=cjx pn kolmn/
  /+ vfr chrmz stat tub < 2''x vktd vfr kuiry < cholmn arch buoy < lk cnt-2 inch tk pn/

• What if the multiple kernels were kept as separate mini-partitions and you picked them from the UEFI boot selection thingy when things go bad and you need to go back to the previous version or fire up a recovery-mode shell?

• 35s in: oh, a Red Hat employee? h o w s u r p r i s i n g .
  so the rest will probably be as expected: attempt to re-invent, or ditch, the wheel…
  why should i bother watching more – only because it's you, Brodie, i'll watch the rest of the video mate.

• You would checksum the bootloader kernel, and you would use LTS release.

• if you dont want cops to install malware, you should use secureboot (with custom keys) or even better, verified boot (like with Heads)

• rEFInd

• Sound's like LiLo with extra steps

• "no more bootloader", and by that I mean use EFI which is a proprietary bootloader built into the firmware

• I don't want to wait to boot Linux when I want to get into the memory tester (especially when I am trying to see how a memory stick that I have some questions about will work with the hardware) and also not when I want to go into Windows (which I reluctantly keep around, with various snoopy parts snipped out, because there are some things that only work there). How long do all those extra process blocks really take anyhow compared with the whole? Except for the menu response (which could be set to something really brief like 2 seconds, to give just enough time to hit the down arrow key, stopping the timeout, only requiring the eagle eye when something other than the default is desired) the CPU will whip through BIOS/UEFI and GRUB like the low level stuff it is, quickly landing in the more leisurely kernel startup process.

  My druthers? Keep GRUB, if anything perhaps adding an optional friendlier interface to it like grub-customizer at least tried to be.

• If Fedora dumps grub, I dump Fedora. I heavely rellay on Grub and I like using it!
  I tried other bootloader but grup works for me the best.

• Actually I made my own bootloader based on rust + kexec on linux. That way I can have my kernel in an encrypted drive and only have to put my password in once (the initramfs will be modified with the volume key of the drive within a few milliseconds).
  (Also if I have a mainboard that is supported in coreboot in the future, I can also just use that directly. I mean, I can't just update my bios chip at every kernel update. Development is just too fast for that)

• Awesome! I had no idea this was possible. Followed the amazing Arch Wiki and whoop running unified kernel image boot thingy.

• I miss LILO.

• I initially thought that this was cool, mainly because it means I can have my pc boot near instantly if it weren't for grub. However I need the option to boot from other kernels because nvidia drivers nearly always die after a kernel update. Since the way you would do this on nmbl is to just make a different type of boot loader then whats the point

• I installed EndeavourOS with systemd-boot and their official instructions for configuring it to dual-boot with Windows were (and I'm paraphrasing, but not exaggerating) "Figure it out on your own!". Unfortunately it seems they just don't fully support NVMe drives. They are detected, you can list them, but they don't have the exact type of UUID for them to be used for booting. The two-part 4-byte one like 52CC-E135. They do have the really long PARTUUID, but it can't be used in the config.

• wouldn't it be faster to load a small program made to load a kernel (grub) compared to fully loading even a light kernel just to load another kernel like that's basically a bootloader with extra steps

• LIL

• You need to update the outro to where the system doesn't boot off of grub, so no grub rescue at the end :v

• Limine looks very nice

• the real end of the linux bootloader is using coreboot

• I'm no fan of Secure Boot. So yes that is turned off. I do like the rest of UEFI though.

• I boot the kernel directly from UEFI without an initramfs.

• Sooo, we'll build EFI stubs (which are actually boot loaders) and sign them by MS keys because we must, in order to get a marginal (or basically nonexistent) burst of speed while booting? As if the boot process takes 10 minutes and hence needs to be quickened. Also, how does this resolve the problem with other systems (for instance variants of BSD)? If switching between different kernels will each require an EFI entry along with its EFI stub, the EFI partiition will very quickly become full of garbage with no sense.

• "we don't need a bootloader it's just bloat!!!!!!!1!!!1!1!!"
  "WHY WON'T MY SYSTEM BOOT?!?!?!?! 😭 😭 😭 😭"

• nmbl… still a bootloader.

• NixOS uses the bootloader for kernel/system snapshots, and I am sure other projects use it for that purpose or other purposes as well.

• Almost like we've gone full circle from straight-off-a-floppy kernels (still possible with 2.2.x, not sure if I ever tried it with 2.4.x).

• These people mean 'THE COMPUTER' does not need a bootloader. This does not mean that WE don't need one! I am already imagining how terrible being dependent even more on the all utterly cr*ppy UEFI implentations of any arbitrary vendor is going to be! Not just successfully booting …but what about setting parameters? Or flexible configuration of your boot order and whatever..? Actually computers' UEFI(BIOS setups are getting worse and worse each year .. most PCs and especially notebooks I have seen last ten years had like no configurabililty at all anymore, and the little bit that is left even is horribly bugged very often!
  So this is the utterly worst way to go! Like UEFI already was. Being dependent on hardware vendors that never where even remotely able to produce acceptbale software …

• Secure boot is useful outside of enterprise environments because it can (if the system is configured correctly) prevent a thief from literally stealing all your cookies (and therefor all your accounts) when stealing your laptop.

  "Configured correctly" involves encrypting the SSD and not storing the key in the TPM and because basically no one enters a password before the OS boots, secure boot doesn't really do anything for anyone but kernel level anticheat developers and the like because they use it to make sure they have more control over your computer than you do.

  TLDR: You don't care about secure boot.

• i gotta wonder: (how) will this ever work on nixos?

• For normal desktop, grub will still be welcome even for those who used modified kernels for gaming but for stuff like webservers or VM's that need to be spun up quickly the time savings and security savings would be massive, on a webserver you're probably not changing kernels on the fly like you are with a desktop so it would thrive there.

• >redhat employee
  Why are they hell bent on destroying linux?

• 2:50 You mean "Gummiboot" (german for rubber boat)? 🙂
  I use it on my arch linux laptop

Comments are closed.