Fedora 40 Eyes The Ability To Boot Unified Kernel Images Directly

[User29]

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

[aviallon]

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?

Well, it always depends on your use-case. Secure Boot is very useful for us in the defense industry. With Microsoft keys removed of course.

[rhavenn]

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?

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

[Britoid]

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.

[andyprough]

Seems like it would be wiser to pour resources into making coreboot work on a lot more boards, and a lot more modern boards.

[CommunityMember]

I've been doing this for years, the only downside is not being able to change bootargs on the fly

There is ongoing work to support (some) flexible command line arguments. Systemd-stub can use addon images and some additional EFI variables can contain kernel command line arguments. It is new functionality in systemd v254.

[mikelpr]

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

[skeevy420]

So it is a plan for replacing GRUB with a "shim.efi", then fill up the EFI partition with Linux kernel images. The "shim" is so barebone that no UI at boot time is available to edit or select which kernel it is going to boot into. You are expected to instruct the shim what to boot next time only after one boot and login to the Linux.

From "security" standpoint, it might be a valid idea? But things may get ugly if a new updated kernel looks booting well to the computer and got marked as "permanent" choice but in fact a failure for proper user interaction.

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.

[indepe]

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.

[AdamW]

So it is a plan for replacing GRUB with a "shim.efi", then fill up the EFI partition with Linux kernel images. The "shim" is so barebone that no UI at boot time is available to edit or select which kernel it is going to boot into. You are expected to instruct the shim what to boot next time only after one boot and login to the Linux.

From "security" standpoint, it might be a valid idea? But things may get ugly if a new updated kernel looks booting well to the computer and got marked as "permanent" choice but in fact a failure for proper user interaction.

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.