Punting GPU Drivers From The Initramfs Due To Ever Increasing Firmware Bloat

[Luke]

I've done this for a while, initially to kill the modeswitch between my GRUB 2 splash screen and plymouth. I use dracut to build the initramfs, so I modify
/usr/lib/dracut/modules.d/50drm/module-setup.sh
to exclude graphics drivers/firmware, then set a graphical mode in GRUB 2. This takes tens of MB out of my initramfs and reduces the number of screen blanks on boot by one. The one just before X11 or wayland starts (not sure what SDDM uses for itself) does get a little longer but overall boot time is reduced, and I do get graphical passphrase entry just fine without having to include not only all the AMD firmware but all the Nvidia firmware too in the initramfs.

No need for graphics drivers in the initramfs. If we can get the wayland and/or xorg drivers not to clear the screen again (like in 2010), we get seamless boot without loading graphics drivers until they are truly needed.

[Weasel]

I honestly don't understand, why do we need an initramfs again? For most generic setups (i.e. no network boot or fde) building the filesystem in kernel seems to be enough? ChromeOS doesn't use an initramfs either.

What if you boot from USB? You need USB drivers. You need USB drivers for HID input in case of emergency breakage, and so on.

The real issue is why doesn't Linux fucking use the UEFI APIs that provide all this and more, at least as a fallback? Why it insists on using its own drivers for everything?

[oleid]

Grub does actually have drivers for LUKS and LVM/RAID, but they're much slower and more limited than Linux's. At least as of ~2 years ago (when I tried it), Grub only supported LUKSv1 (which is very old and no longer the default) and it took several minutes to open an encrypted device instead of a few seconds. Its LVM/RAID support is much better, and I've been using it for several years to assemble a RAID1 holding my Initramfs.

Yeah, I stopped using grub in favour of systemd-boot and never looked back. Its driver implementations were too far behind IMHO. At some point I changed the encryption of btrfs and grub couldn't boot anymore. That's when I changed to something differently.

[Weasel]

How long before a "universal" graphics driver is shoehorned into systemd?

initramfs is loaded before systemd isn't it? The whole point of initramfs is to mount the actual root and then execute init there (which is systemd).

You guys also seem to lack understanding how the kernel has legit no idea where it was even booted from, without drivers. What loads the kernel and initramfs is the bootloader, which either has its own drivers (legacy) or uses UEFI.

The kernel then has no idea of the device it booted from, unless told. It's told typically via UUID command line arg, so then it needs to search for it and mount it. But to do that it needs drivers and firmware for a ton of stuff needed on the way: bridges, device drivers (e.g. USB, SATA, etc), filesystems, RAID, encryption and so on.

And you need graphics to display stuff on screen like the password mentioned in the article if you use encryption.

The thing is, what I do not understand is why doesn't the kernel fallback to UEFI APIs to do this during initramfs? UEFI provides ways to render basic text on screen, get input (including from USB HID), and access drives including the one you boot from, that's how the bootloader works. UEFI is a mini OS.

But no, Linux instead has to load its own drivers for it, for everything. Including HID and everything. WTF?

[Weasel]

Yeah, I stopped using grub in favour of systemd-boot and never looked back. Its driver implementations were too far behind IMHO. At some point I changed the encryption of btrfs and grub couldn't boot anymore. That's when I changed to something differently.

systemd-boot uses UEFI APIs, doesn't provide its own drivers, so that's a good point and I love it as well, how simple it is.

Of course, UEFI knows how to boot and access your disk, else it wouldn't boot at all. It also knows how to use keyboard input and mouse, else your BIOS input wouldn't work at all. It also knows how to render basic stuff on screen, else you'd have no display in the BIOS. So why not make use of this? I don't get why Linux doesn't. See my post above.

[CommunityMember]

It's still commonplace for installers to create 512MiB EFI system partitions with an on-disk partition ordering that makes it maximally inconvenient to grow them.

Some boot loaders support an XBOOTLDR partition to provide a place for larger images if you can't just (re)create the ESP somewhere else on the disk (the ESP typically does not need to be the first partition).

[ssokolow]

The real issue is why doesn't Linux fucking use the UEFI APIs that provide all this and more, at least as a fallback? Why it insists on using its own drivers for everything?

I assumed it's because they had to write them for all the non-UEFI platforms, including BIOS (eg. CSM-mode boot on UEFI systems) and they're just reusing code they need to keep around anyway because putting the system into a known state across all the variations reduces testing complexity.

[muncrief]

Oh wow, this seems like such a very, very, bad idea.

The boot system of Linux evolved to be what it is for many critical reasons. And tearing it apart and altering it should be only be done for critical or insurmountable issues, not simply to save an insignificant amount of storage space.

[caligula]

my /boot partition is 500MiB, I can fit 3 kernels in. 1 kernel with a fallback initramfs, 2 others without a fallback it's getting kinda absurd

My boot partition is 32 MiB. It can fit 2 kernels, the most recent one and a fallback kernel. All firmware and GPU drivers included in the bzImage. No initramfs. Well, I guess the CPU microcode update is a initramfs style package.

[caligula]

why not get rid of initramfs entirely?
During installation build a kernel from the hardware in the system (precompiled, so it just needs to be linked together), make the rest modules. Suddenly you have everything to boot in the kernel. Yay.

This is what the advanced power users do. Zstd compressed bzImage with all necessary firmware and GPU drivers is pretty compact. Less than 15 MB.