Fedora 40 Eyes The Ability To Boot Unified Kernel Images Directly

[AdamW]

I might be missing the point, but why worry about secure boot? All of the *BSDs work just fine with UEFI and secure boot disabled. Why try to ingest the Microsoft proitary BS?

You worry about secure boot if you care about security. If you don't care whether your system is secure, then don't use it. Of course it will work fine, right up until somebody compromises it.

[kylew77]

Because in some environments (gov, enterprise, etc...) it's required to be running a "signed" kernel even if we all know you're hopping from UEFI to a shim loader signed by MS to the Linux kernel which is signed with a key inside the shim loader. see: https://wiki.debian.org/SecureBoot

I see. Thanks.

[CommunityMember]

I don't know what their plans are but I suppose the "unified kernel" could still check for a specific keyboard code and if present, pause for a command line to be entered.

It is slightly more complicated, as being able to enter arbitrary command arguments can impact the security of the kernel.

[guspitts]

Wow. I have started with LILO, then grub took over. And now it seems grub will be gone soon.

Ah, LILO. The dreaded point after "LI": will it find my kernel? 20 years of nostalgia makes it look like the good old time... For me GRUB is already gone. Using unified kernel on Arch for a couple of years already.

[SilverBird775]

Just use systemd-boot?

This sounds like its going to be writing into EFIVars each time there's a kernel update, which doesn't sound like a good idea as EFI firmware has bugs and the variables can be on a crap bit of flash memory that won't take many writes before mucking up.

Using UKI's is optional, they don't cancel traditional kernels. It seems for a moment unified kernels are most useful for virtualization use cases where the boot configuration is as straightforward as it can get. Perhaps in time all the bugged EFI instances retire and EFI vars and firmware's boot menu would become more reliable. On future systems the properly tuned EFI Vars manager and overall matured associated bits and tools would come handy.

[anolting]

Ah, LILO. The dreaded point after "LI": will it find my kernel? 20 years of nostalgia makes it look like the good old time... For me GRUB is already gone. Using unified kernel on Arch for a couple of years already.

Thanks EFI_stub

[fallingcats]

correct me if I'm wrong but I remember hearing about self contained EFI files with the kernel initrd and command line built into them as a single file. is this a further development on that? I don't remember them called UKI and the arch wiki oldest entry on UKI is from 2020 but I remember toying with them on my 2009 macbook so that would tops have been on 2012

That's exactly what what this is. I'm also currently using it on arch (albeit unsigned) and it works perfectly fine. In my case I'm using it in conjunction with Ventoy, so a singular .efi file per kernel is much easier to handle than getting Ventoy to boot it using a traditional approach.

[billyswong]

The shim already exists (and is the first thing run on boot of any UEFI install of Fedora or almost any Linux distro, actually). That's not the new part here.

I think for people who are still using GRUB, which is the majority of Linux users, the UEFI bootloader is grubx64.efi

[Britoid]

There's also the ZFSBootMenu approach where a very minimal Linux OS is booted by the EFI which is used to load a boot environment from a zpool. In Fedora's case, change a ZFS pool to Stratis, BTRFS, etc. That allows you to keep the EFI small in size, use boot environments, and you can place kernels an environment's /boot folder. Configured correctly, all you'd have to do is boot up your last working environment if an update messes something up.

systemd-boot can boot images from ext 4, xfs and btrfs as long as it has an efi driver, which are already available. My kernel stubs are in a ext4 partition

dont need any pre boot environment

[skeevy420]

systemd-boot can boot images from ext 4, xfs and btrfs as long as it has an efi driver, which are already available. My kernel stubs are in a ext4 partition

dont need any pre boot environment

You just listed 3 files systems I don't use. Two of those three aren't supported by systemd-homed. That's what I meant in that other thread about systemd limitations and a protocol so there could be alternative methods and ways of doing things systemd upstream doesn't care to support.

Even with extra EFI file systems people will still run into GRUB's limitations since some of them are using the GRUB FS drivers. That's worth taking note of if you boot from a ZFS root like myself. It's the difference between limiting your pool to ZFS 0.8.0 or ZFS 2.2. That would be like being stuck with BTRFS from 2015 and not being able to use Zstd compression.

That's why I think the ZFSBootMenu approach is better than systemd-boot -- it runs an actual Linux kernel with the same file systems and drivers we use on our running systems so we don't have to deal with the differences between bootloader drivers and system drivers.