LWN: Comments on "Last-minute /boot boost for Fedora 43"

What about EFI?

ibukanov — Fri, 10 Oct 2025 22:12:27 +0000

Fedora boots fine with systemd-boot. It is available even as an option during installation when using the advanced installer.

Trade-offs

smurf — Fri, 10 Oct 2025 19:29:55 +0000

> That's solved by a simple application of NFKD (before you hash).

Yes. That's the basic idea. The question is, however, whether everything in the stack bothers to do that.

I'm too unsure of the answer to that question being "yes" to risk adding diacriticals (or whatever) to my password. More's the pity, since that would add another fun layer to password cracking attempts (which in turn would allow me to get the same level of security with a shorter password).

Trade-offs

WolfWings — Fri, 10 Oct 2025 17:57:20 +0000

For a boot/text console the dimensions flatly do not matter, nothing except the reported screen resolution matters for font selection IMHO.

If it's at least 1280x800? Chuck the 16x32 font at it. Always. 8x16 fonts were from the 640x400 days, not even 640x480. And the 4x6 kernel font was added to handle early low-res 320x200 and similar micro-screens.

I don't want my letters to be 4x6 pixels just because I'm on a cheap hotel 40" 720p TV for the night and it tries to pick the font closest to 12 points tall.

If I've got the pixel budget for large, readable fonts the text console should use it as long as I get at least 80x25, or some other tunable if Linux decides a larger console is the minimum now.

Trying to match to a specific physical size is a printing/publishing issue and only tangentially a window-manager one, not a text console one. If anything I'm constantly fighting the "fixed physical size" attempts because they result in blurry webpages and other things from trying to force-rescale bitmaps by single digit percentages.

Trade-offs

WolfWings — Fri, 10 Oct 2025 17:53:46 +0000

The 16x32 font supports the exact same character encodings as all the other built-in Linux framebuffer console fonts, so encoding concerns are moot.

If the framebuffer console works (which on anything remotely recent that has working UEFI it will) then the font will display properly.

They literally added it to deal with the 'retina macbook' issue of a 15" 4K screen becoming common on laptops, so the console was readable again.

Just a lot of distro's decided "It's not VGA! YEET!" and it's taken a while to get them to leave it enabled like they should have from the start.

Trade-offs

NYKevin — Fri, 10 Oct 2025 17:13:35 +0000

That's solved by a simple application of NFKD (before you hash).

Yes, that does mean that attackers don't have to guess whether your password uses combining or precomposed diacritical marks (assuming arguendo that your password even has diacritical marks to begin with), but that is at most a few extra bits of entropy on top of a (hopefully) much stronger password. You should not be depending on the lack of normalization for password entropy.

You might also worry that this will somehow break in a future version of Unicode, but it is actually pretty safe. The Unicode stability policy provides that, when a string contains only code points defined in version X of Unicode (for reasonably recent X), the normalization of that string according to Unicode version X will be identical to the normalization in version Y >= X. In plain English: The normalization form is not allowed to change, provided that all of the characters in the input string are mapped in the version of Unicode that you used to normalize it.

This does, however, imply that you need to scan the input string for invalid or unmapped code points, and reject them. This is far less restrictive than most password input boxes, because it still accepts every real character that anyone could use for any serious purpose, including private use characters (so we even support the people who insist on using Klingon etc. despite Unicode having rejected it multiple decades ago). Given the relative lack of stability in third-party private use standards (i.e. different organizations have proposed different private use code points for substantially or exactly identical characters), I think we would be within our rights to reject those, but it's more debatable.

I'm sure somebody will now reply and say that a key derivation function (or password hasher) should just accept raw blobs of bytes and not care about any of this Unicode nonsense. That is correct, such a function should accept arbitrary bytes and totally ignore Unicode. The above comment is not about the KDF. It is about the UI that sits in front of the KDF. That UI has to consistently turn the same text into the same bytes, or else users will get locked out of their accounts. This is exactly the same problem as "make sure the password is always UTF-8, or some other specific fixed encoding," just at a slightly higher level of abstraction.

Why a separate partition at all?

ballombe — Fri, 10 Oct 2025 17:06:46 +0000

Nothing, I do the same. Since the kernel modules are not in /boot anyway there is little advantage to have /boot separated from /.

Trade-offs

daroc — Fri, 10 Oct 2025 15:44:47 +0000

I wonder whether it would make sense for LUKS screens and similar to unconditionally scale themselves to be as large as possible — it would result in comically large password entry fields on big monitors, but better a too-large user interface than a too-small one.

Trade-offs

farnz — Fri, 10 Oct 2025 15:27:01 +0000

It's not even implemented reliably in screens - I've had more than one screen report itself as 16cm x 9cm, even though the diagonal is very obviously a lot more than that (even a 11" laptop screen is 25cm diagonal).

If the very screen itself misreports its dimensions, you're stuck.

Trade-offs

intelfx — Fri, 10 Oct 2025 14:25:42 +0000

> <...> or they will hit another problem that prevents usable output on their hardware. Traditional driver-less console is a walking corpse <...>

The "tiny font on a 4K screen" problem actually won't go away just because you swap the UEFI GOP driver for a proper one. The only thing it might help with is if the proper driver communicates the physical screen dimensions/DPI, which in turn might prompt the splash screen renderer to adjust its scaling factor. However, I have no idea if this is actually implemented anywhere; my bet is "no".

Trade-offs

nim-nim — Fri, 10 Oct 2025 12:56:08 +0000

While you’re sort of right, most users won’t do it, or discover that whatever special font is needed is broken encoding-wise, or they will hit another problem that prevents usable output on their hardware. Traditional driver-less console is a walking corpse that has not noticed it’s dead yet.

Why a separate partition at all?

smurf — Fri, 10 Oct 2025 11:50:37 +0000

I habitually move the "root" file system to /_r. (Actually if you install Debian to a btrfs it does that out of the box.) Along that I'm using an OS independent /home subvolume and a /btrfs subvolume and the encfs subvolume and … you get the idea.

This makes way the root FS is fairly clean; also I can clone the subvolume and then run a test installation, either directly or via systemd-nspawn, without the test stuff being visible from the root *or* vice versa.

Trade-offs

smurf — Fri, 10 Oct 2025 11:38:28 +0000

… and then there's canonicalization. Is the letter ü a simple \u00fc, or u plus combining diaeresis ¨?

File systems care, except that it mostly doesn't matter because one clicks on or copy-pastes or autocompletes these things.
Not so for passwords.

Why a separate partition at all?

gray_-_wolf — Fri, 10 Oct 2025 10:55:48 +0000

It is mentioned that GRUB cannot handle btrfs subvolume, but at that point, why even have a separate partition? On my laptop, /boot is just a directory. What am I missing on by not having a separate partition?

Trade-offs

WolfWings — Fri, 10 Oct 2025 09:48:36 +0000

The 'tiny font on a 4K screen' is just because most distro's don't enable the Terminus 16x32 console font or otherwise aren't switching to it.

fbcon=font:TER16x32 as a kernel command-line argument will switch to it, and honestly it should likely be the default these days unless dealing with something smaller than a 1280x800 screen where you'd drop below 80x25.

Trade-offs

geert — Fri, 10 Oct 2025 09:39:28 +0000

> I do wish manufacturers stopped bloating their firmware. When it gets so fat init takes more time than the various boot prompts you have a problem.

I guess open-sourcing would help. Cfr. how much some Linux drivers shrunk during upstreaming.

Trade-offs

nim-nim — Fri, 10 Oct 2025 09:09:36 +0000

GFX driver belongs in the intramfs because legacy Vesa graphics plain do not work on a lot of modern displays. At best you end up with ridiculously small and illegible text on 4K+ screens

I do wish manufacturers stopped bloating their firmware. When it gets so fat init takes more time than the various boot prompts you have a problem.

Rescue images

nim-nim — Fri, 10 Oct 2025 09:03:30 +0000

The rescue image is pretty easy to use, nothing to install, login as admin, google the problem and run whatever commands are required. Quite often the “problem” is just to run fsck when loss of power for example resulted in unclean umount.

The live image typically does not understand anything but the most recent OS version, or is confused by updates on top of the initial install, so it’s a short trip to full reinstall and complete reconfiguration or even data loss. Plus it requires a bootable media and access to ports where to plug this bootable media (which is not quick or easy for anything which is not a laptop designed to be moved).

Trade-offs

farnz — Fri, 10 Oct 2025 08:24:26 +0000

Out of interest, how does Windows handle it when it needs a Bitlocker recovery key?

I can see online that it prompts you for it via a GUI screen, but I'm not clear on whether it uses UEFI graphics, or whether it's able to load enough Windows kernel bits to run the hardware-native display driver at this point.

Put differently, are we trying to be better than Windows on the same hardware (a worthy goal, but one that can perhaps be deferred a bit), or is this a case where not using the native display driver makes us clearly worse than Windows on a given machine (where we need to be equal or clearly better to be a competitive alternative)?

What about EFI?

proski — Fri, 10 Oct 2025 07:04:02 +0000

systemd-boot supports XBOOTLDR partition to avoid changing the EFI partition on every kernel update. I use XBOOTLDR on NixOS, a distro that defaults to systemd-boot. I'm not sure if Fedora would support it; I would stick with GRUB to boot Fedora.

Trade-offs

josh — Fri, 10 Oct 2025 06:59:44 +0000

It would be nice to, for instance, prompt on the external monitor you have plugged in, rather than the closed laptop screen. (Yes, I've seen laptops whose firmware graphics has this problem.)

Trade-offs

xecycle — Fri, 10 Oct 2025 06:59:29 +0000

On-screen keyboards actually vary by vendor. I used two 360-flip laptops, one from Lenovo which is able to pop up an OSK for entering bitlocker PIN, another one from ASUS does not.

As for characters I think it doesn't matter if we draw characters in initramfs software; but if user decides to include special characters in their password that will be fun to support.

Trade-offs

Cyberax — Fri, 10 Oct 2025 06:34:12 +0000

UEFI has problems displaying the UI on my AMD video card, it seemed to use only the built-in Intel. I think it might be configurable somewhere in BIOS, though.

Another reason is localization. UEFI doesn't have characters outside of ASCII. Neither does it support alternative input methods, such as on-screen keyboards.

Trade-offs

vasi — Fri, 10 Oct 2025 06:16:01 +0000

Oh "fun"! That is a good reason.

Though this is starting to feel like we'll eventually need an extra stage of loading Linux. Eg:

Stage 1: Get to a bootloader. (Obviously there's earlier steps, but let's start here.)
Stage 2: Load Linux and initrd into memory. We need just enough in initrd to access some real storage in early userland.
Stage 3: Initrd loads further modules from storage, for things like LUKS passwords. Eventually loads root fs and boots to full userland.

Our forced-memory-resident initrd could be much smaller. Our big stage3 modules could live anywhere that Linux supports, instead of being reliant on the minimal filesystem drivers in bootloaders.

Trade-offs

mjg59 — Fri, 10 Oct 2025 06:13:28 +0000

You don't, it's just that it looks much nicer if the display you're looking at is actually in native resolution when prompting you (UEFI has no way to know which of the displays you have attached is the one you actually care about at that point)

Trade-offs

vasi — Fri, 10 Oct 2025 06:08:07 +0000

Thanks, that's good context.

Trade-offs

vasi — Fri, 10 Oct 2025 06:07:45 +0000

I imagine if you have a system that usually has three displays attached, you don't want to unplug two of them just so the UEFI can ask you for a password.

Trade-offs

mb — Fri, 10 Oct 2025 06:05:09 +0000

Why would I need multiple displays to enter a password?

Trade-offs

mjg59 — Fri, 10 Oct 2025 05:48:39 +0000

UEFI doesn't really have a good concept of multiple displays and tends to make sub-optimal compromises if you have several active displays plugged in, so aesthetically there's a significant benefit to having a proper driver running

Trade-offs

mb — Fri, 10 Oct 2025 04:58:25 +0000

UEFI manages to draw quite good looking GUI elements and I doubt it includes hundreds of megabytes of graphics firmware.

Trade-offs

mathstuf — Fri, 10 Oct 2025 02:20:03 +0000

> But why does graphics firmware belong there?

If there's a LUKS passphrase in the way, you want to have a UI to ask for it. *I'm* fine with a TTY-alike, but that is certainly not the norm…

De-rescuing

jannex — Thu, 09 Oct 2025 19:28:38 +0000

The proper way is removing dracut-config-rescue. Nothing depends on that package and deinstalling it will remove /usr/lib/dracut/dracut.conf.d/02-rescue.conf.

Trade-offs

vasi — Thu, 09 Oct 2025 19:20:52 +0000

Full boot is just one problem caused by a giant initramfs. There's also:

* Boot gets slower
* Kernel upgrades get slower
* Machines with low RAM lose the ability to boot

It doesn't sound like anyone is evaluating the trade-offs here, instead it's just growing by accident. Which is fair, distro maintainers are busy! But maybe it's time to start adding specific release criteria around initramfs sizes, so nobody is surprised next time.

Also, I might be confused about what initramfs is even for these days! To my understanding, we try to put just enough drivers in initramfs to load the root filesystem. Maybe that means a bunch of different disk and filesystem drivers, maybe even network drivers for network filesystems. But why does graphics firmware belong there?

What about EFI?

ebee_matteo — Thu, 09 Oct 2025 18:52:31 +0000

What happens for those of us that are generating UKI kernel images directly in the EFI boot partition?

I don't have a separate boot partition anymore (I use systemd-boot).

A lot of us are stuck with 512 MBs for the system EFI. I guess we need a way to move firmware out of the way or also start resizing EFI default partitions...

Time to move the GPU drivers out of the initrd and rely on EFI framebuffer in the initrd

shalem — Thu, 09 Oct 2025 18:10:03 +0000

I believe that the time really has come to move the GPU drivers out of the initrd and rely on EFI framebuffer in the initrd.

There are some downsides to it, but I believe we have reached a point where the upsides easily outway the downsides, see my blog post from 2 years ago for a detailed listing of pros and cons: https://hansdegoede.dreamwidth.org/28291.html

De-rescuing

smurf — Thu, 09 Oct 2025 18:01:49 +0000

> then set "dracut_rescue_image="no"" in /usr/lib/dracut/dracut.conf.d/02-rescue.conf.

Huh. Is it not possible to override this via /etc/, instead of messing with /usr and risk that your change is silently reverted when dracut gets updated?

All drivers present?

mb — Thu, 09 Oct 2025 17:31:35 +0000

Does Fedora always include all drivers/firmwares in the initramfs?

Rescue images

ballombe — Thu, 09 Oct 2025 17:16:29 +0000

Can non-expert likely to use successfully rescue images in the first place ?

Seems legit

donaldh — Thu, 09 Oct 2025 16:15:23 +0000

45% used just now. I tend to build and test release candidates if there is anything I care about in them. I've also needed in the past to bisect across 13 kernel builds and wanted to keep them all in case I needed to restart the bisection. That's on top of the three fedora packaged kernels and a rescue kernel that are currently installed.

Seems legit

jzb — Thu, 09 Oct 2025 15:56:19 +0000

8GB... wow. I really hope that's just overkill and you're not getting anywhere near filling /boot now.

Seems legit

donaldh — Thu, 09 Oct 2025 15:53:57 +0000

I have run afoul of the 1GB partition size so now have an 8GB boot partition on my Fedora server. It used to only take 3 kernels + initramfs images to run out of space.