UKIs can run on UEFI systems and simplify the distribution of small kernel images. For example, they simplify network booting with iPXE. UKIs make rootfs and kernels composable, making it possible to derive a rootfs for multiple kernel versions with one file for each pair.
A Unified Kernel Image (UKI) is a combination of a UEFI boot stub program, a Linux kernel image, an initramfs, and further resources in a single UEFI PE file (device tree, cpu µcode, splash screen, secure boot sig/key, …). This file can either be directly invoked by the UEFI firmware or through a boot loader.
↫ Hugues
If you’re still a bit unfamiliar with unified kernel images, this post contains a ton of detailed practical information. Unified kernel images might become a staple for forward-looking Linux distributions, and I know for a fact that my distribution of choice, Fedora, has been working on it for a while now. The goal is to eventually simplify the boot process as a whole, and make better, more optimal use of the advanced capabilities UEFI gives us over the old, limited, 1980s BIOS model.
Like I said a few posts ago, I really don’t want to be using traditional bootloaders anymore. UEFI is explicitly designed to just boot operating systems on its own, and modern PCs just don’t need bootloaders anymore. They’re points of failure users shouldn’t be dealing with anymore in 2024, and I’m glad to see the Linux world is seriously moving towards negating the need for their existence.
I think the issue is that initramfs is often rebuild based on what people need.
Having 1 file means you need to sign it and have UEFI accept (secureboot) it and how do you do that if people’s need change ?
I guess you only need grub or whatever if you are trying to share a single drive device between multiple operating systems. For so many reasons, I gave up on trying to do that in most cases ages ago. I still can’t seem to keep Windows from messing with other drives in the system during install, so I actually disconnect my Linux drive, whenever I want to reinstall Windows (which I barely use anymore), and install that directly on it’s own drive. Then I use the bios boot drive thingy (press F11) and choose my boot drive from there. It’s not completely clean – grub (I use Nobara, a Fedora derivative, which still uses Grub) seems to find the Windows drive, and puts in the Grub menu, but I don’t need that. I do wonder what would replace that Grub menu. I rarely need to actually use it, but it does let you easily get in to older kernels or a kind of Linuxy safe mode.
No i am not doing that. I will not be using pulseaudio nor systemd.
No, not ever as long as i live. ALSA, runit and KDE is fast enough, and actually faster in most cases.
Well, everything still pretty much uses ALSA under the hood. So it of course will be faster as long as you are only trying to do very simple things. You will certainly get your wish on PulseAudio as you would clearly just use Pipewire these days. I am a big Pipewire fan.
I am less excited by Systemd so I hope you continue to enjoy runit. In my case, I am cheering for dinit but we will see.
tanishaj,
I wrote my own init system back in the 2000s following KISS principals. It’s also what I like about runit.
This is the first I hear of dinit, it’s worth a link…
https://davmac.org/projects/dinit/
I bolded parts that appeal to me contrasted with systemd.
I feel like the complaints about bootloader stem from grub being over engineered rather than bootloaders being problematic in general. There was a time when bootloaders like syslinux were much less complex. Of course, it was a problem that microsoft decided to always overwrite everyone else’s bootloaders even though they could boot windows just fine without microsoft doing that.
As far as replacing bootloaders with UEFI, I’d be ok with it except that customization might take a toll. I don’t want to have to buy new hardware to change the way the “bootloader” works.
ZFSBootMenu ships as a UKI because it lets us do something like https://docs.zfsbootmenu.org/en/v2.3.x/general/portable.html . Copy the file to a USB drive at a specific well-known path, and 99.9% of UEFI implementations will just boot it. That makes it trivial to have a recovery drive, or to even give your entire disk/disks to ZFS with out cluttering them up with an ESP. UEFI + UKI is pretty decent on modern hardware.
It’s like sure, if in some future a system like UEFI adds functionality to boot and you would like to use things like TPM, due to it existing, trying to put as much things in a single signed image and booting that directly, believing you are getting unmodified results. Why not, when all that becomes a possibility. Until then obviously Grub doing a good job. Still knowing UEFI is buggy and TPM is something you should i guess just trust … In my opinion it doesn’t really reduce complexity and in term of security, it does add new possibilities, such as vendor providing signed UKI image and making sure only such image to run on the hardware, or end user setting up some use case alone. Currently i see it as a good option to run on servers. As for home users there in my opinion Grub can work just fine, for a couple of years more. Home users sometimes don’t even care about things like running a signed image or application sandboxing, especially when running FOSS. Once GNU/Linux distros take the complexity away, most end users likely not to care, as long as it works for them. If it’s Grub or UEFI that is booting … Until end user would like to modify something, then i guess one needs to understand all this new complexity, to make that happen.
https://arstechnica.com/security/2024/07/secure-boot-is-completely-compromised-on-200-models-from-5-big-device-makers/
And then they have the nerve to call Grub insecure and as such to actively promote against its usage, due to fancy things like systemd, UEFI, Secure Boot and TPM. Just give us Stallman back, please. ASAP.
Today, Phoronix just posted about something I don’t think you’d be able to get with UKI without basically doing what ZFSBootMenu does and having a whole other Linux kernel as your bootloader… boot loop detection and automatic (i.e. suitable for non-technical users) fallback to a known good system state, even if the new kernel is bad.
(In essence, if you boot directly into the kernel, then your boot loop protection is akin to a software watchdog while, if you have an otherwise minimal bootloader that tracks boot success/failure, then it’s closer to a hardware watchdog.)