NMBL: The End Of The Linux Bootloader
HTML-код
- Опубликовано: 19 авг 2024
- If you're booting linux you're probably using some sort of bootloader to do so, but with these modern UEFI systems that's not required but having a menu is still nice so there is some work going into a system known as NMBL to make efistub booting more convenient
==========Support The Channel==========
► Patreon: brodierobertso...
► Paypal: brodierobertso...
► Liberapay: brodierobertso...
► Amazon USA: brodierobertso...
==========Resources==========
Blog Post: fizuxchyk.word...
Fedora UKI: fedoraproject....
Recording: pretalx.com/de...
=========Video Platforms==========
🎥 Odysee: brodierobertso...
🎥 Podcast: techovertea.xy...
🎮 Gaming: brodierobertso...
==========Social Media==========
🎤 Discord: brodierobertso...
🐦 Twitter: brodierobertso...
🌐 Mastodon: brodierobertso...
🖥️ GitHub: brodierobertso...
==========Credits==========
🎨 Channel Art:
Profile Picture:
/ supercozman_draws
🎵 Ending music
Track: Debris & Jonth - Game Time [NCS Release]
Music provided by NoCopyrightSounds.
Watch: • Debris & Jonth - Game ...
Free Download / Stream: ncs.io/GameTime
#Linux #Bootloader #Grub #FOSS #OpenSource
DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase I may receive a small commission or other compensation.
so "no more bootloader" is actually a bootloader. and actual "no bootloader" is UKI (unified kernel image), which we already had
Best comment
Sounds like a fairly apt, concise breakdown. I guess it's all down to implementation at this point.
I was already interested in UKI, now I'm slightly more interested. Not that I necessarily want to be rid of GRUB, nor do I expect it to fall into disuse, but I'm intrigued by the concept.
Well, kinda, but here the UKI has the ability to switch to other OS's/kernel setups.
I used to do this with Gentoo back when EFISTUB was added to the kernel. The main reason I started using grub again was for btrfs snapshots.
@@9SMTM6What do you mean by UKI can switch to other os/kernel? Isn't that what a bootloader like grub has in form of a boot menu?
You will own no bootloader and be happy hiding in the Z drive to eat the bugs.
OOPS! All glitches!
Inside a UEFI system, this honestly makes a *lot* of sense. UEFI is already kind of a bootloader in it's own right, so things like booting an emergancy kernel works the same a booting another OS. I believe that's even the mechanism being used by "boot next", which just sets the boot id in efi-vars, and tells the system to reboot. That would mean instead of needing GRUB to do the heavy lifting (and create another failure point), you can just make the base system do it.
The only issue I see, and a reason bootloaders will likely exist forever, is that some manufacturers have decided that doing things in-spec is not part of their process. Whether it's not handling the boot next feature correctly, or only allowing one entry in the uefi bootloader, or even just not offering any user facing options for managing boot at all, things can get in the way of a permanent switch, and there's no real workaround. Given that even Microsoft sometimes has issues with these companies not following standards, this is one thing that will always need workaround options.
Exactly! I think it's cool to have additional choices regarding booting our devices, but NMBL will never work on certain devices because of their firmware and kexec() support :c
Systemd-boot loads efi shims and has a lightweight boot picker
The reason MS introduced "Modern Standby" (formaly known as "Connected Standby") was because not a single OEM got the power states right. To have a system were S3 was implemented properly in BIOS/UEFI was like flipping a coin and hoping for heads ten times in a row.
Sometimes SSDs will stop working on a specific power configuration. I had to switch from UEFI (AHCI) to Legacy (IDE/RAID) once, then back again after a few months. I don't know why it happens, I've had it happen on multiple computers.
In a way the UEFI is the biggest hole, burned into your MB's ROM's and somewhat buggy.
I would rather this not be called "no more Linux bootloader" when nmbl is literally, a Linux based bootloader
I mean an entire block of software is being deleted. It's not like Linux doesn't boot itself when you use grub2, but we don't call Linux a bootloader. NMBL isn't is a "Linux based bootloader", it's literally just packaging Linux to boot itself from UEFI. It /is/ Linux.
If anything retains the title "bootloader" here it's your motherboard's UEFI implementation.
@@IanMonroe It is still a bootloader.
@@user-vh8gs1sw1j no its not. it is the kernel executing directly from the firmware.
The problem with "secure" boot is the same as it always has been. The only supported configuration treats the owner as an attacker and software providers as the de-facto owner.
Moreover, as long as you don't have full access to the sourcecode for the BIOS/firmware and a way to reprogram the nvram, you'll always doubt about what else did they add.
Security is against the consumer not for it
@@HUEHUEUHEPony security is against anyone that lacks the proper certs
@@HUEHUEUHEPonywell then it has already failed in it's task then
I can load my own certs for my secure-boot. Admittedly many UEFIs dont allow for that, but mine does.
And the point is to make a person sitting in front of the PC as potential attacker. That is what it was designed for. In a world where noone can mess with the boot process secure boot isn't required. Secureboot can give you certainty that nobody messed with your boot, before you enter secrets etc, since your (should be encrypted) main system can validate the boot files.
I like the idea of direct booting in single target situations. But if there's alternative boot options, I would prefer the menu to be separate from the kernel.
Yes, that already exists as shown, systemd-boot
@@kreuner11 And grub
@@kreuner11 ... or that boot menu in your UEFI that can be triggered by pressing some key during boot
2:25 Really old Linux users might remember LILO or loadlin. Who else does?
Would configure it in my paid-for SuSE with YaST back then...
@@Marc42 Who else remembers:
LIL?
LIL
LI
Lerror...
LIUh-Oh! 😂
LILO is still used on linux for the TI nspire CX-II
I used loadlin yesterday because I was trying to see if I could install Linux inside dosbox (spoiler: turns out due to the way dosbox mounts drives it can't find any drives once it boots)
@@cameronbosch1213I hated LI. Why don't you boot you bastard!! What does LI mean? (I know that there is meaning to every letter but in the moment it was super frustrating)
This is legit what I've been doing on my Gentoo install, I haven't used a boot loader in like 2 years
Same! Also on Gentoo.
So how does this work? What if you have a windows partition as well? Ok, since Gentoo, I'd guess they have tools for UKI build, it's sort of easy? What if you wanna build a UKI on other distros though? Have you tried it?
I have always used a UEFI stub on arch too
Same on Linux 3 times
UKI on Gentoo for the win!
The only issue I have with NMBL is that they claim faster boot, but only for systems that haven't got dual-boot. The whole "boot to userland to get a menu, to boot to another kernel/OS" is IMNSHO a poor way to handle this, and is more complex for installers to deal with. Is GRUB complex? Yes. Could something else better replace it? Probably. Do I think NMBL is what will be that replacement? Not for most distributions.
Yeah, I don't think it will help much on that regard.
Then again you should be able to use UEFI boot selector to boot into whatever os you want and skip userland menu alltogether.
@@BuriBuster I fully agree, this isn't something most users will care for as a feature from the bootloader. many times I ignore Grub and just use my UEFI to boot a different drive or LiveCD or what not. dual booting is already weird to get working on Grub between windows and linux. sometimes windows just nukes it. Most of the time I keep my OSes on separate drives or boot from a Ventoy USB. Never think about GRUB on my main desktop and will usually configure it to just skip the menu.
@@BuriBuster Yeah, but that depens on the hardware manufacturer. I've never find any that implement a proper UEFI menu boot option. The closer I've ever encountered is maybe DELL, which allows you to configure UEFI entries as as "boot devices" on some laptops.
On some others like my old XPS, one have to manually change the UEFI boot every time on the BIOS.
@@acters124 How long since you last tried GRUB? Are you sure is easier to boot from USB every time than just when windows botches the boot?
Never had any issue with GRUB in decades. Also, do you know that you can chain boot bootloaders? And that windows will honor GRUB if it's the first one in the chain and not touch it?
Your outro clearly shows one possible use case for nmbl. If you have full kernel for your boot menu, if something is wrong with the filesystem (like after rm -rf /) and cannot be booted, rescue shell would be way more friendly in nmbl than GRUB.
Yes, if something is wrong with the booting kernel, then it will be bad, but if it works, and not updated then it will most likely keep working. Interesting thing to try.
SystemD BSOD into rescue shell in the "boot loader stage" sounds like a perfect "I can try to ficx this" situation!
i have doubts the boot kernel would survive the rm -fr /* in the first place honestly
Given everything on /boot would be wiped including the kernel, rescue prompts aren’t appearing any time soon.
@VioletRM It would on Clear linux
@@citywitt3202 But does rm -rf go across filesystems? Most of the time, /boot is a separate partition afaik. But I honestly never tried it so... iunno. xD But good point nevertheless.
Just woke up and I can already see a potential problem with this:
You have one kernel. If that lernel won't boot up to show the boot menu (culprit couls be file corruption) then you will have to learn how to navigate various disks using the uefi terminal.
This is not something normal users will want to, most users would just straight up panic.
Grub would at least not have the same problem, as updates are not pushed as often, a kernel update can happen as often as every week. Less updating of files means less chance of file corruption.
I'd kind of expect distros to have as many efi stubs as installed kernels with the latest having the "default" name so that UEFI always tries to use that one, but you have the option (on most systems) to go into UEFI and boot one of the other stubs.
Still a problem for a casual user, but a power user should be able to get back up and running fairly quick.
@@flagramathe best course of action would just be to leave as is and let the powerusers configure existing instead of making it default.
Businesses would be forced to remake PXE routines.
I know one company that would have to restructure it somehow as they are using grub to choose what kind of system they are installing, like is it Ubuntu with or without mvidia drivers, is it X office or Y office and what not.
Their menu is pretty big.
If you were to remove grub or boot loaders then you'd remove that opportunity for companies as well.
Linux overall would loose on doing such a move
Bootloaders used to exist to solve the problem of how to load the kernel into memory and appropriately load and launch it. The kernel and UEFI have all the necessary functionality to accomplish this and they're effectively superfluous for that purpose.
However, by the time the UEFI and Kernel had said necessary functionality available, we had begun to use Bootloaders for other, often more necessary functionality. Things such as OS/Kernel option exposure. As a minimally functional operating system in case of OS/Kernel init failure. Bootstrapping non-kernel present options or parameters. Etc. The fact of the matter is that this approach of eliminating the bootloader is not really an applicable one to the sort of people who you need to be preaching to. The sort of people who will cling to a bootloader are not the sort of people who are just using it to launch their system. They're the sort of people who use it for roll-back capability. Multiboot. Booting into varying configurations of the kernel. Etc. And the fact of the matter is that emulating grub is no less superfluous than just using grub itself.
While it makes sense, GRUB is by far has more niche modules. Unless these kernals are looking towards extensibility (which is its own attack vector), I think people may stick to using bootloaders far far into the future. Either that, or were going to see a lot more bloat in our kernal sizes, and may run into interesting security situations.
Limine is really close to not having a bootloader at all, while still offering some multiboot functionality.
You know it’s insane, I used to talk to
Mintsuki way back in the day it’s awesome they’ve made such a good thing
@@skyliusExcuse me but Whaaaaaat ?
A little more elaboration
Personally, I use rEFInd or systemd-boot. Yes it has the same potential driver issues as GRUB, but those drivers that do exist are UEFI standard drivers.
The major problem I have with this is it will be horrible dual-booting between windows and Linux. Doubly so on any system which takes a long time to boot. 99% of the time, I just need a menu to decide what to boot. Having to wait for a full reboot just because I chose a non-Linux option is a non-starter.
It might serve a niche for booting Linux when the initrd won't fit on the EFI partition, but for almost anything else UEFI already solved this. Then again, that's also my opinion on GRUB.
oh no, HELL NO!, there are many devices with misconfigured firmware (UEFI) that produce errors during the stages of kernel loading, grub may have issues but grub WILL be able to work even with those bad UEFI configs and can be used as a starting point of diagnostic on such systems by either passing kernel flags or being able to launch fwsetup once you've seen the linux kernel really cannot go further into the boot process due to the BAD efi settings that despite there being a standar many manufacturers decide to ignore it and add whatever they feel like.
nonsense, never had issues with uefi.
@@turtlefrog-tn3ek that doesn't mean others didn't
@@turtlefrog-tn3ekah the good-ol "it works on my machine" schtick
Screw of bozo
I agree. I have an ASUS Sabertooth 990FX (version 1.0) board which has a very broken UEFI BIOS which ASUS never bothered to fix. I had to use workarounds to even get it to boot Linux.
@@FineWine-v4.0 try dozens of machines "bozo".
I am using setup with UKI since almost 3 years. At the time it required some more custom scripting do get uki generation done but now there is systemd tool (ukify) for that and even a lot of initramfs generation have it. It was some proof of concept with secure boot and tpm encryption for me but you dont have to do it.
Very coinvent point about it that you can still use any bootloader that can run efi binaries. I use refind for that. Redhat here mentioned other kernel but it can even be grub, efi shell or one build in to uefi (the last comes in handy in case something goes wrong like you mentioned in 11:16 so no need for live cd). This approach is also more compatible with other systems
`ukify` sounds like it should be Brexit-related jargon 😂
So you want me to replace the bootloader with a whole secondary kernel instead ?
And this is somehow simpler ?... Two kernels is simple ?
You want me to place a secondary kernel outside the LUKS encrypted system/userspace ?
This is somehow more secure ?... A kernel in the wild ?
Cutting out the middle-man sounds like a good idea at first. But it just gets replaced with a different middle-man.
you realize bootloaders have their own "kernel" and "drivers" right?
what's your kernel doing inside an encrypted volume? is it confidential?
@@2xsaiko What's your system doing unsecured? Are you really that guy?
Did you forget to click the single checkbox for system encryption during install?
@@turtlefrog-tn3ek Why would a bootloader have a kernel, it doesn't need to provides services to any other software.
And of course it has "drivers", it wouldn't be able to do anything if it couldn't interact with other hardware.
Don't muddy the water, you'll just confuse people.
@@KomradeMikhail I'm talking about the *kernel*, not your user documents and whatever else you may have.
Back in the very, _very_ old days of Linux 2.5, the kernel was actually a bootable image, meaning you could _dd if=bzImage of=/dev/sda_ and just boot off the thing.
I mostly blame Microsoft for the UEFI setup and boot menu panels being as barebone and useless as they are. They would be plenty capable of offering all the recovery options (including adding and removing boot entries and EFI command line overrides) if they weren't so concerned with disabling the USB keyboard drivers to boot a few milliseconds faster. And no need to delay boot a few seconds for user input if OEMs can just check for keys being held. Seriously, most PCs out there don't even bundle the EFI Shell! There is no excuse. The F11 menu could've always had "Windows Recovery" as a menu option, but instead, you have no choice but to reboot to it from Windows or wait until it fails twice and then tries (and fails) the useless auto-repair. It's ridiculous. Windows also pushes the boot menu down into userspace, and bails out with a system reset if the user doesn't pick the preferred option, wasting time.
We don't need to make that same mistake. We could install a secondary boot option that users can enter from the firmware to do recovery actions. It should be the simplest boot manager possible, just offering the ability to boot an alternative UKI, tweak the cmdline or chainload another OS. If everything is fine, and the user doesn't need a dualboot menu, they won't have to, and can boot directly to their system from firmware. That's the approach taken by Apple and Google for their mobile platforms. And similarly to mobile platforms, the kernel can instruct the firmware to reboot to recovery if it finds a problem, and the firmware will default to recovery mode on its own if the main boot option goes missing.
In fact, that's basically what I'm doing on my own setup. UKI as main, GRUB as backup. I am concerned about nmbl's approach of a full Linux kernel/initrd-based bootloader in the worst case scenario of picking a non-Linux OS in the menu to boot into. We should get the Linux kernel to be able to directly chainload into a secondary bootloader, or exit out into EFI while in this bootloader stage. We'll also need the bootloader UKI to be separate and minimal, only containing the necessary components to act as a bootloader.
Embrace, extend..
@@privateagent Not like Microsoft benefits much from BOOTMGR, either. If UEFI firmware could be set to load the boot menu by default as if F11 was always held, you could just have the firmware be your dualboot menu.
It would even make Microsoft's life easier. No need to keep BOOTMGR backwards compatible with older Windows versions if you can just boot an older BOOTMGR.
GRUB and its contemporaries will always stick around for the people on older/broken PCs that still need them.
That would have likely been /dev/hda instead of /dev/sda, right? 😁
@@X_BaronFor a while, yes. But SATA's been around for long enough to coexist with this feature shortly before it was deprecated and removed. And sd* also corresponds to SCSI devices.
They should take the approach macOS takes with the 1TR on Apple RISC, have firmware check for a condition (in Apple's case it's power being held down but ACPI is fun police) and boot into the boot menu OS if that's fulfilled, otherwise read the NVRAM values of the EFI and continue on.
So its just another Linux De-bloat Meme.
Yeah, just use systemd-boot. GRUB was needed to supplement the primitive BIOS
It might be an attempt to enforce a specific Linux configuration. I suspect it has to do with Steam versus DIY graphics support.
I like GRUB because it allows me to install a theme that makes me look like a hacker.
And to anyone with a tidbit of IT knowledge it outs you as the opposite 😂
@@a5centit can look nice. Nothing wrong in doing things just for the look if you line it.
@sprinklednights rEFInd also let you do that, however, it's EFI only and it took me a while to install properly. Systemdboot is also EFI only; pretty much only GRUB is usable on BIOS systems and is actively maintained.
In contrast, I like refind because it has some really beautiful themes and icons and config it is far intuitive then grub.
@@a5cent You say that but then again I have seen it professionals with some rather... explicit furry themes
The problem I see with using this is when you want to boot into other operating systems like Windows or BSD or anything else. It will probably limit wider adoption, since I think, a lot of people like having grub menu to choose if they want windows or linux.
It's also often used to select an older/different kernel at boot time if updating your kernel broke something.
@@jnharton that one would work with solution presented in this video if I am not wrong?
the main reason I don't use a bootloader and boot with UKIs is the redundancy - why would I need a boot menu when I already have it as part of UEFI on my motherboard? it's faster and simpler, though the primary problem is the lack of auto-detection of UKI images, UEFI only detects very specific EFI executable paths as boot options by default and you need to create your own ones with efibootmgr - it's possible to automate but the boot list is on volatile storage so when the CMOS battery dies you will need to boot something to re-create your entries
you did a good job answering why you would need a bootloader
If the UEFI designers were thinking just a little bit more, they would allow efi boot entries to be loaded from a text file on the efs.
@@mks-h bootloader is something you need once in a while, not on every boot
Proud Booster UKI EFISTUB booter
Sounds nice on paper but in practice I don't know... Good luck getting manufacturers handle this properly.
But why the complicated nmbl case? AFAIK all UEFI firmwares come with a menu that allow specifying what UEFI binary you should be booting?
Yeah, you basically only need a program that sets up boot entries (or you can do it yourself), assuming your uefi has a usable menu
There are a lot of reasons why relying on that would be problematic. One of the major ones being that firmware developers often screw up their EFI implementations, thus making them slightly incompatible with things that SHOULD work.
Not all hardware does. Some do it on the BIOS, some have a specific app, some just start the first found ... it's a mess.
The reasons others added, and in addition, there's a bunch of features that grub (supposedly) has that won't work with that setup. Most importantly stuff like network boot.
@@disieh The primary reason is that there are a _lot_ of UEFI implementations out there that are just plain _broken,_ and just barely manage to boot Windows on a good day. If this weren't true, Microsoft wouldn't have had to implement their own boot selection menu so late in the boot process that the only recourse for proceeding with the non-default boot option is to perform a complete reboot.
I doubt Microsoft actually _wants_ to endure the possibility that the system can hose itself before the user ever gets the option to run System Recovery; rather, they would have implemented it as a fallback UEFI boot option and had the firmware start it automatically upon failure; except this standard mechanism does not reliably exist between vendors, let alone actually function as specified.
Brodie: "... But..."
Me: hehe, butt
The kexec-type bootloader also isn't new - ZFSBootMenu also uses it to let you boot using a ZFS root by booting a stage1 kernel that has ZFS support, which can then kexec a kernel of your choice from the ZFS root and also provide a recovery environment (you can even chroot into the rootfs this way!). It doesn't really *do* secure boot stuff, but I suppose you could sign the whole mess in a way that shim would support. It's mostly to make ZFS boot environments and such work on Linux, though.
or as another example: mobile-nixos does this because phones lack a keyboard, no traditional bootloaders (that i know of) support touch, and android phones already boot directly into a kernel, so this approach is easier than adapting another bootloader to support touch and be loadable like a kernel
For secure boot to work this UKI images must be signed by distro or machine owner. Fedora's UKI images build for usage in VM's. If you need to include something like nvidia driver in initramfs then you are on your own. You will need to create keys and hooks to rebuild and sign this UKI image after kernel or akmod driver install/upgrade. So i think things no quite there yet.
I kind of wish enrolling your own keys was THE default way to do it rather then only distros that go through the process of getting the default signing keys.
Heck I wish there was a "trusted" keys and a trust but verify section keys, where the default accepted keys sat that I could get notice when a new signed image tries loading, and my trusted images that I signed just ran.
@@AndrewMorris-wz1vq you can delete microsoft keys if you need to. Making own keys a default way will complicate things for users.
@@x-user3462 Yes it would. It should still be the case that an advanced user generating there own image and enrolling keys should be a greater level of trust on the machine.
The default MS signed keys are fine, but should require user auth to boot to a new image. Just because random image is signed by a distro doesn't mean it should be authorized to run on a machine without user explicit permission. For normal use it's good to have that option imho. Maybe MS shouldn't be the default authority for all time, but that's another issue for another day.
Awesome! I had no idea this was possible. Followed the amazing Arch Wiki and whoop running unified kernel image boot thingy.
"The GRand Unified Bootloader, or 'NAMBLA'"
It would probably be interesting/good to use a minimal hardened version of the kernel as the bootloader that's not kept in-sync with your regular kernel. Then, even if you update your system to something newer that's broken, you can still at least load the bootloader.
An unsigned initramfs isnt the gaping security hole you might think if you properly bind LUKs to your TPM and include a suitable set of PCRs. That will make it impossible to decrypt and boot the root unless everything in the boot chain is untampered with, includijg initramfs, grub.cfg, UEFI drivers, everything.
I just use rEFInd with a nice black graphical theme, I can boot all different kernels automatically detected and boot Windows too. I also have an emergency USB stick with it + a rescueLinux partition. I never ever brick my system like this and there is no horrible text booting. Maybe porting rEFInd on Linux instead of being its standalone UEFI app could make sense?
Sound's like LiLo with extra steps
Every time someone tries to say "improved boot time" is an advantage, I ask them if the two seconds shaved off of the boot up shaves any time off of the two or three minutes of RAM checks, SAS spinups, RAID array sanity checks, etc. I still mourn the passing of serial daemon starts for the parallel starts which caused years of issues.
I believe LILO is still used on Slackware. Can't be sure, mind. I dropped early on in jump to Linux days.
At the moment the standard kernel in Ubuntu is 5.15.0-116. Unfortunately that kernel contains a bug making it impossible to start Virtualbox images. Thanks to GRUB boot loader I can boot a BIOS system by using or a UEFI by I can then load kernel 5.15.0-113 and use Virtualbox until the bug is fixed. Changes always means breaking new things.
mobile-nixos has already done this for a while because on a phone there's no (hardware) keyboard to use a traditional bootloader (and also, android phones directly boot into the kernel, so you'd have to adapt a bootloader to be loadable in the same way as linux), so instead if you hold one of the volume buttons during boot it boots a minimal kernel to show a boot menu with touch support, and then kexecs into the actual kernel/initrd
I've always used efi-stub on my UEFI systems. I do keep a thumb drive around with Grub2 on it for emergencies. Even with dual booting, it's easy enough to have multiple EFI boot targets, I've never seen the point of running a bootloader for Linux under UEFI, and it actually makes UEFI fastboot, fast.
I'm a big fan of bootloaders, particularly U-Boot and GRUB, because as an embedded engineer it makes life a lot easier, it allows doing things at a low level when a custom kernel driver may crash or similar event occurs. As for desktop use though, I enjoy being able to select the kernel prior to bootup, as I sometimes run custom drivers I've written on my desktop, and sometimes they don't exactly agree with the newest kernel, so I have to go back one, remove the driver from modules.d, fix the driver, and boot back up in the new kernel.
I personally do not use UEFI, even today, as it provides no security benefits nor does it enhance the boot process in any manner, my motherboard supports legacy boot so I use it since it follows the KISS principle.
UEFI targets won't let me loop-mount-boot raw ISO files, GRUB2 does.
I just recently had issues with my kernel and I really like the option to just 'roll-back' to the last working one without the need to 'repair' my installation directly.
Overall seems like a cool idea, as long as I will have a dual boot support and be able to costumize the look I'm in.
For the kernel breaking problem I think this can be solved like this:
Once a system is updated to new kernel we boot using the previous one, which boots the new one like on the graph (e.g the first one on the graph is 6.9, and the seconds is 6.10).
If the boot succeeds, and userspace / login manager step is reached the new kernel is marked a working, and now becomes the one to be used from the start.
This should probably do it for most of the problems.
About a decade ago, I set up an old DEC Alpha running linux... It used milo to boot. As I recall, milo was just a stripped down linux kernel and menu userland, all shoved into a UEFI executable. Sound familiar?
It worked so much better than grub! RAID worked before the kernel loaded, I could boot of any partition, any filesystem the kernel supported.This sounds like milo reborn as patches to the kernel rather than separate repo that was a rev or ten behind mainline.
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.
I use EFISTUB on modern UEFI and rEFInd on ancient UEFI.
Looking into the future - using a kernel as a bootloader should be the way to go, indeed. There is very likely going to be less and less non UEFI compliant hardware so this should be good.
With this you can practically have a console-like experience now, from early boot to the userspace all in one go.
For the NMBL case on the left. It would seem that what is happening is you are booting a known good kernel. It could be the final kernel, but it doesn't have to be. I'm playing with atomic desktops, I can see how they would use that. Using your old kernel to boot the new one. But it still sounds like grub with a bunch of stuff you don't need to boot. Isn't that what grub is for? Only the stuff you need to boot. This is keeping a full kernel to do it. I'm not sure how comfortable I am with this. I mean it's pretty easy to hose a system. I have never, short of wiping out the efi partition, broken grub. There is something to be said for dissimilar redundancy.
wouldn't that requires to rebuild the kernel or to have multiple kernels and have kernel calls or maybe it's already in place / in the proposal to switch to/from the "straight up" UEFI -> kernel and the "around way" with UEFI -> kernel -> menu -> kexec and modify kernel boot parameters like "quiet" ; also what's the effects of kexec into a different kernel on a already live system , like can all the systems be initialized twice properly ?
i've also got the malchance of breaking a lot of systems whether it's linux , windows , so i feel like breaking the "root" kernel would happend to me
I watched this just the other day, very interesting
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 ...
You need to update the outro to where the system doesn't boot off of grub, so no grub rescue at the end :v
I use EFISTUB, but have a grub entry for backup.
Still it's nice to have the system boot this fast.
I'm not a thumbnail and title expert but this video is really interesting and almost flew under the radar like this change ;)
Luckily I basically click on all your videos anyway
I like this. The best would be if this approach can hide the difference between the PCIe probing based x86 and devicetree based hw description as well. Imagine, you dont have to deal with FIT image with ATF+kernel image+DTB+u-boot on ARM or GRUB+initramfs on x86: just load the kernel to the memory, set the program couter to the start routine and the rest will be done by the kernel. For example u-boot lagging way behind Linux in device and filesystem support, since everything must be re-implemented. I see people suffering with initalizing network devices, loading the firmware for NICs which works well with Linux since ages...
I think I'll stick with the bootloader. I'm still trying to figure out how to get my second SSD to automatically mount and be accessible without using any GUI tools. This little tidbit is too over my head at the moment.
I like systemd-boot because it allows you to get into recovery modes and it is comically simple to set up.
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.
I like that you didn't think anyone uses kexec already to improve reboot times...
I started using the kernel because I like avoiding the grub screen and it made me feel cool to go directly from the mobo splash screen to Linux. Now I have a splash screen and it looks soooo polished
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.
11:30 It's still easy to switch kernels if the new/default one is broken (even using configuration on the right picture). You can switch kernels using your motherboard's uefi boot menu. (I personally use this configuration, and it works flawlessly)
sounds like a hack
@@someguy9175my point is that even if your kernel broke you can boot into the older kernel in no time no recovery usb, etc. required
@@someguy9175you need to do everything exactly the same with bootloader if it's hidden by default
1) press a key during boot to open the meny
2) choose the kernel version you want
3) boot
@@someguy9175 I don't understand how using built in UEFI functionality as intended sounds like a hack. The UEFI boot menu is practically speaking just a bootloader that is built into UEFI. It's just that it only boots EFI executables. So if you just create a new EFI executable for each kernel/os you use, you basically just have a bootloader.
@@24wherath36 Fair enough, it's just the idea of having 3 separate boot entries for each bootloader kernel version in my UEFI sounded a bit weird.
11:30 the system could have a fail safe to boot into an earlier kernel, similar to ctrl+alt+del in the framebuffer
Doesn't Windows also use a bootloader instead of the Kernel to boot? "Windows Boot Manager" has the NTFS drivers and some other stuff to load kernel.exe and that takes over from there if I'm not mistaken.
you can probably always keep current UKI as a backup when you update to the new one, and select it from uefi boot menu if things go wrong, this way it should be hard to break
I would love to see a working NMBL stack in a distro. Seems like a really cool approach
So my worry with the simple UKI case is that it looks like itʼs hard to change the kernel command line if something goes wrong, while with GRUB I can just edit the menu entry. Probably that works fine with the more complicated case depending on what menu software you use.
I dont think the Kernel breaking would be a problem. You could just keep the old "booter-kernel" around as a second efi Image and select it from your BIOS if things break.
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.
I've been using an UKI for quite a while now, with secure boot.
I found it much easier to set up secure boot with an UKI rather than with grub, and it actually supports LUKS2. (grub is [or was at the time I set up UKI] limited to the old LUKS1)
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).
I use kexec to "reboot" I love the speed of the hot reload of the kernel.
A quite like being able to choose the kernel on a boot screen, seems to have missing. Was very useflu with Debian 12.4, I needed to retor one box, until .5 kernel came out.YMMV.
At the end of the day as long as it boots, and stays out of Systemd which has enough tenticles already, I can live with it.
I avoided the Arch Linux GRUB problem just by no having GRUB in the first place. The "no more bootloader" makes total sense (at least, for any modern PC)
Makes total sense only for arch....
@@CaioOliveira-bc9fr what's arch grub problem? Didn't encounter such (used arch for more than a decade).
@@x-user3462 a bad update of the grub package, Brodie made a video at the time "GRUB Broke My Arch Linux Installation!!"
One benefit I can anticipate with this is that distros and desktop environments will be able to offer rebooting into a different Linux OS and kernel within userspace/GUI apps. It would surely beat having to do it through GRUB, and the associated issues of maintaining a GRUB entry which can often go laughably wrong if you're inexperienced with Linux.
I have made a UKI based Arch Linux install after getting frustrated with plymouth. And now during boot process, it shows a big Arch Linux logo. I am thinking of changing this to something else, like adding BTW, or simply showing a Tux image.
The Plymouth although dynamic just simply don't work correctly.
Edit: And no I do not like booting a temporary kernel as a bootloader. A simple efistub with menu support is enough.
While grub is very useful, and has some really cool features, like mounting a raw image as a loop device and booting into it, I personally haven't used it in years, it really is overcomplicated, especially the configuration for it, and while I already use UKI because it is more secure to do so with secure boot enabled, direct booting is a bit too simple, you want to be able to have a few options when things go wrong, or if you're dual booting, so I've personally been using REFind for about 4 years now and it's great tbh, simple to change configuration, supports theme and has a nicer look overall, I really think everyone should give it a try, especially if you're using arch
It also looks fancier
Sounds interesting, but I want to see how it handles encrypted volumes beforehand, because these are prevalent at the entreprice level (at least for bare-metal machines).
Personally I think it's fine as long as they use a parameter to indicate the UKI has been run and it's time to boot proper. By doing so the default is to fallback when something is broken to something that works, for example from a broken desktop environment to a minimal environment.
I have been doing this years now, it's super fast and works great. I'm on mint by the way.
So, two things:
1) on non UEFI systems (basically any ARM SBC in existence), the bootloader does some stuff the kernel doesn't, so this is only valid for UEFI systems
2) no mention of EFI boot menus? I don't have much experience in this area, but usually the EFI does support selecting between one of multiple systems.
Well... as long as it's a separate minimal static kernel from the one used by the OS, and it's possible to get Snapper working with it, sure. I can see bad things happen if it relied on the kernel that gets updated all the time. I'm also wondering how complex the GRUB emulator is, I guess I should look that up. :) Is it just GRUB with all the I/O stuff and other duplicated functions stripped out? Is that handled by the kernel devs as well?
So long as Snapshots can be easily accessed, which hasn't been the case with SystemD-Boot, I'm probably fine with it, that was the hiccup I hit when having a shot at discarding GRUB a while back.
As much as we enjoy making jokes about Windows Update messing machines up, it's not like we're immune to update problems over here, and reverting to a snapshot, waiting until the bug is resolved and then updating again is such an easy "solution" for end-users.
Thanx for clearing that upp some!. All I know it broke my dual boot when upgrading to 24.04 :/ .. so not doing that again :(
i think a bootloader like grub for multi-OS systems still makes sense, the double kernel shenanigans seem like they would have some problems, though the secure path is interesting, but it definitely is an upgrade for single-OS, but that already existed with uki, this just might bring a bit more attention to that
if i were making a distro, which i've considered, i would add uki to it
This is how Apple dual-boots Machs (and how Asahi chains up), the boot-menu isn't shown by iBoot, it's shown by recoveryOS, which is a full-on Darwin instance
Have been using efi stub for ages, can recommend
You would checksum the bootloader kernel, and you would use LTS release.
EFIStub + UKI is what I recommend if you don't need dual-boot.
This is exactly what ZFSBootMenu does, along with several other kexec based boot menus.
Having switched to a newer filesystem, I already set up a completely self-contained UKI to serve as a rescue image in case the file-system breaks. This UKI however is pretty heavy and takes up a lot of space on the EFI System Partition. Grub and Systemd-boot support booting off of kernels in other partitions, but guess what: my the newer filesystem that my system is on isn't supported by them.
This is when I learned about kexec and kexec-based boot menus. I can use that rescue image _as my boot loader_ and keep the kernel images stored on my normal root filesystem, loaded by the rescue image's kernel driver. I haven't actually touched my code for my own boot-menu, optimized for my particular distro and how it handles multiple versions, but this video reminded me that I should continue working on it.
I'm using UKI with Arch 1 year ago. I love it. Secure boot enabled and follow kiss philosophy
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.
Multiple operating systems? I'm not sure how that chain of trust would work. I'd I understand correctly each Linux distro would have to regenerate the central file with their own signing key? Update a kennel on Fedora, install the Fedora signed bits, reboot into arch and arch signs their kennel bits... Clobbering the previous signature? Surely I must be mistaken.
I've personally never liked GRUB. I haven't daily driven Linux in years but back when I did, I liked rEFInd a lot. Despite it being able to detect efi executables, I still set up manual boot entries in it.
Something like the nmbl approach would be perfect for how I like my configuration.
"no more bootloader", and by that I mean use EFI which is a proprietary bootloader built into the firmware
I use UKIs! Honestly, I just wish motherboards had a setting where you could by default have it boot to the UEFI boot menu by default rather than having to press a button for it.
GRUB sometimes (!) disappears from BIOS's boot loader list after power outages... Which happen few times per day.
So I have to keep the systemd boot from which I can actually reinstall the GRUB every time that happens
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
it's funny how many implementations of directly booting kernels we have, it's almost as if some layer of hardware abstraction has actual value...
Aren't you loading the Linux kernel twice? Isn't the kernel a heavier thing than a bootloader? How is that faster? How do you handle btrfs snapshot booting?
Raw dogging it makes more sense.