Fedora 39 Wants To Ensure Your ESP Is Big Enough

[Alexmitter]

I wonder what the problem is with FAT32, on that partition are the grub.efi and possibly uefi capsule binaries for firmware updates. This is not where you store kernel images.
Let Grub be the layer that supports Ext3/4, BTRFS and so on. Its updateable whenever needed unlike your systems firmware.

[Britoid]

I wonder what the problem is with FAT32, on that partition are the grub.efi and possibly uefi capsule binaries for firmware updates. This is not where you store kernel images.
Let Grub be the layer that supports Ext3/4, BTRFS and so on. Its updateable whenever needed unlike your systems firmware.

I don't see the problem with putting kernel images on FAT32 as long as they're signed and verifiable. Bootloaders and even the system should just mount these partitions read-only and only write when needed.

[Jabberwocky]

So just allocate 1G to the ESP. Problem solved.

But of course Linux dumdums won't have that. Got to start bitching about unrelated things like FAT32 or how 1GB infringes on their self-declared right to have artificially small ESP

Initially Microsoft recommended 128mb ESP. Later that got bigger. Now it's smaller again (100mb but you also need a MSR partition of 16MB and a recovery partition for winre.wim which is currently 100mb but you should actually use 250mb for future updates. That can also very based on drivers, language support and other customization........) ok so things change all the time. Arch recommend this, Ubuntu that, Fedora this.

Setting the partition to 1GB will help but only until it becomes a problem again.

Linux dumdums don't like workarounds. They like to understand root causes and make proper improvements. Why does ESP exist. What's the alternative? Would firmware size increase again in a few years. etc. Taking the path of least resistance is not in our blood. We like to question and learn. Yes a lot of the time we bitch about unrelated things, but I would rather have that than sheep just silently accepting everything. Take the good with the bad.

[Sonadow]

Linux dumdums don't like workarounds.

What a bloody joke.

Everything about Linux is a workaround. So just stop using Linux already.

[jabl]

Why would UKI need more ESP space? All it does is to combine the kernel and initrd into one file.

I think part of the entire UKi proposal is to also get rid of grub and instead boot straight from UEFI firmware to the Linux kernel (in the UKI). Thus the kernel + initrd need to move from wherever they now are to the ESP.

[stiiixy]

I don't see the problem with putting kernel images on FAT32 as long as they're signed and verifiable. Bootloaders and even the system should just mount these partitions read-only and only write when needed.

Verified at write time with ye ol hashing?

Honestly, seems a lot of ways around the FAT32 usage, regardless of the idealism (which doesnt seem emtirely unwarranted, considering its age and almost ineffective nature as a filesystem itself).

[archkde]

I think part of the entire UKi proposal is to also get rid of grub and instead boot straight from UEFI firmware to the Linux kernel (in the UKI). Thus the kernel + initrd need to move from wherever they now are to the ESP.

I thought Fedora already uses the ESP as the boot partition, but I just checked and it seems you're right: at least on my VM that was originally Fedora 36, the ESP only contains shim- and GRUB-related files (apart from /mach_kernel and /System/Library/CoreServices/SystemVersion.plist, which I assume are for Apple firmware compatibility). But still, calling the move just "UKIs" seems highly misleading to me.

[archkde]

I don't see the problem with putting kernel images on FAT32 as long as they're signed and verifiable. Bootloaders and even the system should just mount these partitions read-only and only write when needed.

They should be signed and verifiable anyway. It's called Secure Boot.

[Old Grouch]

Why would UKI need more ESP space? All it does is to combine the kernel and initrd into one file.

Because not all set-ups currently put the kernel and initramfs on the ESP. It is not necessary. If you use GRUB2, you can have a minimal grubx64.efi which brings in everything else from other partitions, potentially on RAID, LVM, and/or encrypted.

The proposed Unified Kernel puts the kernel and initramfs on the ESP, and I don't think there is an option to put the combined agglomeration anywhere else. For people used to having a minimal ESP, it is a large change. Sometimes large changes are not welcome, and that might be for good reasons, possibly not anticipated by the UKI proposers, or outside the use-cases they are targetting.

The set of use-cases the systemd ecosystem is targetted at providing solutions for is a subset of Linux use-cases, and every so often this shows up as requirements incompatible with some people's use. Such is life.

Using Secure Boot signatures as your only tool to assure data-integrity of your booting O/S kernel is an interesting approach. Personally, I'd prefer the boot device to use erasure codes, and for the code transfer mechanisms (buses, RAM, registers) to be at least ECC protected so that bit-rot can be detected and repaired before you even get to the cryptographic signatures. FAT32-alike file systems (the ESP is UEFI FAT, which is subtly different to standard FAT) are not robust where bit-rot is concerned.

[Jabberwocky]

What a bloody joke.

Everything about Linux is a workaround. So just stop using Linux already.

What made you so salty?

For work I am using Windows 10, macOS 10.15, Kubuntu 22.04 and Android 12 on most workdays. No workarounds, using default settings. Everything works.

For home I have a **** ton of customization on almost every level, boot, to full disk encryption automatically unlocked via network, custom session/login management, multiple desktop environments, CPU pinning specific to my CPU model for KVM vfio hosting multiple gaming VMs that can be booted dynamically with IO threads locked to fastest clocked CPU cores and hugepages with kernel address space layout randomization disabled... I enjoy hacking and learning at home.

You can make the same argument about Linux being a workaround if you compare Windows to Consoles. Why bother with all the state management just use Play Station, trade convenience and time for lack of choice and other vendor-lock-in crap. I don't judge people who consciously make that choice. Hell with the PC hardware prices 2 years ago I considered that too. Get home, sit on the couch in front of the TV and play some games, simple and easy. You can do the same with SteamOS or Windows Steam big picture, but I agree it's not as convenient as plug and play that consoles offer for the limited amount of games designed/adapted for it.

One simple rule, buy hardware with good OS support what ever OS you are using. Many people don't follow this rule and then they get mad.