I really like the idea the nmbl project is exploring.
Basically grub gets replaced with a uki. And if the kernel in the uki is the same as the one the os being booted uses, a lot of code is removed from the bootstrap process.
Even if the kernel the os being booted uses is a different kernel there are a lot of benefits. No more grub. No systemd-boot. Just linux.
If you are lucky enough to be able to use coreboot you could be running nothing but linux.
Who else has been exposed to the nmbl-poc project here? What did you think?
See the information published by fizuxchyk by following the provided hyperlinks as I am positive I could not do justice to the topic on my own.
systemd-boot is currently not signed and would not be a good candidate to sign directly by MS so would likely also use shim if it ever gets included in fedora as a signed efi binary.
The uki of nmbl could kexec to a different linux kernel for the OSs use. Or it could switchroot if the kernel stays the same.
The uki of nmbl could be used in place of grub to boot other OSs though without chainloading. That is also explained. One use case would have nmbl set next boot efivars to obtain similar effect. Lots of flexibility in what could be included in the nmbl uki like menu, graphics, network boot, or whatever.
The nmbl uki would have all the hardware support of linux and all the developer community of linux which is not the case for other boot loaders.
I assumed that because both links are named nmbl they referred to the same url, I had followed the 2nd nmbl link. Marta’s explanation is very helpful.
Funny, Fedora Atomic Distros could just skip systemd-boot. But with all the bootc images I am not sure how the update and boot process is done anymore.
Ive been booting fedora like this for a few years. It works fantastic.
See this post for more info and a link to some codes I wrote to facilitate this, but on a very basic level you use dracut --uefi <...> to create the UKI and then enroll it as an option in your UEFI boot menu using efibootmgr.
I like your thinking. Forgoing even nmbl is yet a better fit for what I like. Building an esp with the uki at the path
/EFI/BOOT/BOOTX64.EFI
should be all that is needed. This should work well with VM automation where the uefi nvram is a fresh copy of /usr/share/edk2/ovmf/OVMF_VARS.fd each time. No need to install or run efibootmgr. I still need to setup some test cases. To date I have only used this uefi feature when copying /usr/lib/systemd/boot/efi/systemd-bootx64.efi to EFI/BOOT/BOOTX64.EFI but then I also need the loader files.
I never thought to put the UKI at <esp>/EFI/BOOT/BOOTX64.EFI, but Id imagine that would work…It works for booting live USB’s without explicitly addig a dedicated boot entry, so it should work with a UKI too.
Only issue here is that you can only do this for a single UKI…without efibootmgr or some 1st stage boot loader / boot manager you’ll only be able to boot a single kernel (even though by default 3 are installed). It also means that if that UKI doesnt build right for whatever reason there is no backup/recovery boot entry you can use.
For the VM case I am interested in there are never any updates applied. Rebuild from scratch only. I think bootc will work for this too though bootupd is grub only last I checked.
Another option would be to select a different uki from UEFI setup. This may come into play on bare metal installs for troubleshooting as I am interested in rebuild from scratch only there too.
This is what I do. The code I linked previously will set this all up for you. But getting the boot entries to be available in the UEFI does require efibootmgr
Where you around for the pre-UEFI EFI stuff that came out with merced (itanic)? It has been a long haul but x86 migrating to UEFI makes provisioning a lot different.
I guess getting the boot entries without efibootmgr will be UEFI implementation dependent. Some UEFI implementation even include an efi shell which makes it quite easy. I have also run the tianocore efi shell on UEFI hardware. I’ve worked with systems that do not include an efi shell but do support typing in a path. In some scenarios, like when running ansible playbooks, rather than going into the UEFI, using efibootmgr would be more reasonable. There are a lot more ways to go about it than BIOS ever supported.
Now if the system has a BMC yet another world of possibilities opens up. There are even software BMCs that can be used with VMs.
I never got the opportunity to use any of the itanium chips (which is too bad…they really look like they could have been fun). In general Ive never really looked into / tried to implement something like “direct booting a UKI” from a system with just BIOS (no UEFI). By the time I started being interested in doing that sort of thing UEFI was already fairly standard for new systems, and the handful of older BIOS-only system Ive dealt with since then I just set up to boot with a standard GRUB setup
Thanks. Though, its worth mentioning that this isnt a particuarly recent change for me…I forget when exactly I first got everything (re: direct booting UKI’s) working right, but I want to say 4-5 years ago…maybe even slightly longer. IIRC I set this up not too long after dracut added the --uefi flag to allow it to build UKI’s
My motivation to set this up stemmed from a need to have booting be reliable. My fedora system uses zfs on root and (at the time) used a LUKS2-encrypted /boot. Between the encrypted /boot and the root filesystem being on zfs, GRUB regularly shat itself when trying to boot. I had grown really tired of getting dropped into a GRUB emergency shell seemingly every other boot. And, as they say, “necessity is the mother of all invention”, and direct booting UKI’s was my solution to get booting to be reliable. And it worked wonderfully…so much more stable and as a bonus a good bit faster too.
TBH im surprised there arent more people doing this, being that doing so has been possible for a good chunk of time. I guess the obvious answer is “because getting it all set up right took a LOT of time, and for 99.9% of fedora users with less exotic setups the standard GRUB approach works reliably enough that they dont need to figure this out like I did”. But, Id still think that I would have encountered at least 1 or 2 other people doing this on Fedora over the years…
Also - just an FYI - I tested out copying a UKI to /EFI/BOOT/BOOTX64.EFI and rebooted and sure enough a new boot option (“UEFI OS”) came up as an option on my UEFI boot menu automatically. Upon being selected, this option booted up the system just fine.
So, just adding the UKI to /EFI/BOOT/BOOTX64.EFI does seem to be a viable “zero config” option (for a single UKI at least).