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

[mdedetrich]

That still sounds like it doesn't match reality. For example, nVidia's GSP firmware is ABI unstable and must match the kernel version.

And thats because the Linux kernel doesn't have a stable ABI in the first place, similar with explicit sync it might end up becoming a reality due to how increasingly problematic its becoming.

[discordian]

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.

the painful detail is that you are bound to use fat32 for /boot since that is the only fs supported. debian's apt tries to switch files in a safe manner where the old copy is only deleted after the new one is fully written. it does so using hardlinks, means with fat32 every once a while your update will fail (downstream security fix for kernel -> same filename).

that being said, i would prefer just the essential drivers to be included in the ramdisk - to mount the rootfs.

if special drivers / userspace tools are needed they should be on their own partition - and ramdisk only needs to mount *that* partition.

[ahrs]

And thats because the Linux kernel doesn't have a stable ABI in the first place, similar with explicit sync it might end up becoming a reality due to how increasingly problematic its becoming.

You've got this backwards. The issue is on the Nvidia side not the kernel side. The kernel just matches whatever the firmware does. There should be no reason why it has to change so much other than Nvidia choosing to do so from time to time. Why should the firmware care about the Linux kernel ABI? It's just platform initialisation stuff. It's the kernel that has to interact with the firmware not the other way round.

It's interesting how Intel and AMD don't have this problem.

[chithanh]

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.

Then put the firmware squashfs next to where the initramfs resides now. You don't even need multiple copies of it, with few exceptions newer linux-firmware tree will work fine with older kernels. And if it is an issue you can use squashfs deltas.

No need for graphics drivers in the initramfs.

The issue is that UEFI will typically produce display output only on the system's primary monitor on the primary GPU. This works for most but there are a few situations where it doesn't work. One is described in the blog post, a docked laptop with the lid closed. Another would be some computers with Kaby Lake-G.

The kernel then has no idea of the device it booted from, unless told.

This is not correct. UEFI boot protocol tells the kernel this information, and besides that you can look it up after boot with efibootmgr which tells you the currently active boot entry and its EFI system partition.

Then you have the signing requirements for secureboot pushed by Microsoft and others this is minor.

Secure boot is a solved problem (except on Apple T2 Macs). If you install out-of-tree (e.g. proprietary) drivers then Fedora, Ubuntu and others will offer to generate signing keys for you, and sign the modules automatically.

It's interesting how Intel and AMD don't have this problem.

Intel does have this problem. Look in /lib/firmware to find multiple versions of Intel Wifi firmware for the same chip. The driver chooses the latest firmware that it supports based on filename.

With AMD GPUs they also have firmware versions but instead of a proper versioning scheme they use kinda wacky naming. They use capital letter filenames for the older firmware and small letter filenames for the newer one, and new firmware versions replace the older ones. Sometimes they append a "2" when there are incompatible changes. But sometimes there are incompatible changes and they don't append or increase the "2", which causes older kernel radeon/amdgpu driver to not work with newer linux-firmware. Plus this scheme prevents linux-firmware from residing on case insensitive filesystems.

I asked agd5f and linux-firmware maintainers to do proper versioning like Intel, a few years back when this scheme was still in prerelease kernels. But this request was rejected, and now it is forever enshrined in kernel and firmware repositories.

[hacker1024]

I need Intel drivers in my initramfs on my OLED laptop so that I can turn down the brightness during boot to avoid burn in.

There's no way to do so using efifb, or probably SimpleDRM.

[agd5f]

With AMD GPUs they also have firmware versions but instead of a proper versioning scheme they use kinda wacky naming. They use capital letter filenames for the older firmware and small letter filenames for the newer one, and new firmware versions replace the older ones. Sometimes they append a "2" when there are incompatible changes. But sometimes there are incompatible changes and they don't append or increase the "2", which causes older kernel radeon/amdgpu driver to not work with newer linux-firmware. Plus this scheme prevents linux-firmware from residing on case insensitive filesystems.

I asked agd5f and linux-firmware maintainers to do proper versioning like Intel, a few years back when this scheme was still in prerelease kernels. But this request was rejected, and now it is forever enshrined in kernel and firmware repositories.

I'm not sure what you had in mind, but we have versioning in the firmware used by amdgpu. The firmwares have standardized headers that the driver can parse to get version information, etc. The idea is that the firmwares should always be compatible so a particular firmware always has the same name. You can drop in replace an older firmware with a newer one. That saves space because you don't have multiple versions with different file names and you can easily roll out newer firmware to older kernels. On the off chance a firmware does end up having non-backwards compatible changes, we have added new files with a different name to handle that case, but it's only happened a couple of times.

[oiaohm]

Secure boot is a solved problem (except on Apple T2 Macs). If you install out-of-tree (e.g. proprietary) drivers then Fedora, Ubuntu and others will offer to generate signing keys for you, and sign the modules automatically.

Its not a 100 percent solved problem. Secure boot rules by Microsoft are changing over time. Mote you said signing kernel models/drivers to allow a third party bit to load. Rebuilding a kernel on install as the person was suggesting is not inside the current rules. Vendor by the current rules is meant to build and sign the core kernel image with a single signing. So do have OS build kernel on install that would require going back to Microsoft and negativing change to secure boot rules for use of the key that is on most motherboards. I put it as a minor problem but it is a problem that might take a 2-3 years to get the rule changes worked out. Microsoft is not being a jackass here because they don't want monopoly legal cases but they also want what loading somewhat secure.

[ssokolow]

And thats because the Linux kernel doesn't have a stable ABI in the first place, similar with explicit sync it might end up becoming a reality due to how increasingly problematic its becoming.

No, this is about the unstable ABI between nVidia's driver code and their firmware, not between the kernel and their driver code. It's basically the open-source version of how, when you upgrade your nVidia binary drivers, attempting to start an application will get you non-accelerated graphics out of it and a CLI message along the lines of "Sorry. I'm not giving you accelerated graphics because your kernel module and libGL versions aren't an exact match."

(Ask me how I know.)

[oiaohm]

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?

This all in fact make sense why it was at first done this way when you look at early UEFI. The early UEFI you had a 1 in 5 chance in first generation of UEFI motherboards that when you took over the storage drive that the EFI system partition is on that UEFI provided services would stop. Yes this includes the input and display output provided by UEFI. This kind of screwed up behavior in new motherboards is less than 1 in 100000 chance of being the case and with a new motherboard if the motherboard has this problem . Most likely the new motherboard has some other major problem you don't want to be dealing with if new motherboard has the problem of early disappearance of UEFI provided display and input it most likely has a problem like 1 in 5 boots not booting because is magically failing to find the ram(so defective junk).

The older UEFI motherboards(first to 3 generation/first 3 years of UEFI existence) makes sense to take over everything as soon as possible because before you have even mounted the root partition the UEFI services providing display/input and so on have gone away with way too high of a percentage of users effected. Newer UEFI you can depend on it provided services for longer. Those who attempt to keep a system running just using simple DRM in the linux kernel using the UEFI provided frame-buffer interface still find out that many modern motherboards this works for about 15 to 20 mins before going splat so not a infinity amount of time you can depend on the UEFI provided services. The old bios vesa graphics interfaces were way more stable.

Weasel basically this is a rock and hard place. You want to support every possible UEFI motherboard in existence you have to-do it the way the Linux kernel has been doing it with the cost of expanding image to laod. The trouble making motherboards have dropped under 0.01% of the motherboard in use.. There is going to be some effected user swapping to simpledrm sysfb-simplefb for early boot due to the fact Linux users have habits of operating 10+ year old hardware at times but the benefit the the majority most likely should win out at the point on reduced boot time with custom initramfs and sometimes custom kernels for those who are still using those old systems.

[Old Grouch]

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).

Not only does the ESP not need to be the first partition, is also possible to have more than one partition marked as ESP on a block device. It's a system partition, not a boot partition.

https://devblog.xkern.net/multiple-efi-system-partitions-on-a-single-disk