The linux-firmware package 20220119.0c6a7b3-2 implements kernel firmware compression. Linux kernel from 5.3 on support loading from xz compressed firmware.
CONFIG_FW_LOADER_COMPRESS kernel option must be enabled. All official Arch Linux kernel support this for a long time. [1]
The linux-firmware package has been split into smaller packages to further reduce required disk space. Some big firmware files of rarely used hardware have been split into separate packages.
This affects firmware for Mellanox Spectrum switches, Marvell devices, Qualcomm SoCs, Cavium LiquidIO server adapters, QLogic devices, Broadcom NetXtreme II 10Gb ethernet adapters.
Make sure to install additional firmware packages if needed. [2]
This an Arch specific linux-firmware packaging change purely to reduce package size?
So the uncompressed upstream linux-firmware could potentially become an AUR package, or a third party repo package, in order to support lts kernels <= 4.19?
that current package is split into smaller chunks like linux-firmware and linux-firmware-extra
This affects firmware for Mellanox Spectrum switches, Marvell devices, Qualcomm SoCs, Cavium LiquidIO server adapters, QLogic devices, Broadcom NetXtreme II 10Gb ethernet adapters.
Is there a more complete list of which hardware has been separated into extra packages?
Looking into it. 5.4 and 5.10 are fine, earlier kernels will have issues and there’s no clean patch backport available. 4.19 might be easiest as there’s less of a gap between it and 5.4, but the underlying firmware_loader this feature needs doesn’t exist in 4.4, 4.9, or 4.14.
This looks like the easiest option - just need to check it’s OK as it essentially duplicates something in the repos.
yeah, not a big fan of that although I use linux-zen. It notably slows down boot time because it now has to decompress the firmware package with a rather slow decompression standard. I now have a delay between “loading linux-zen” and the “starting systemd” message.
From what I read, the only way of disabling the compression at the moment is by switching to an uncompressed firmware-package?
Edit:
Did you leave out the “whence” package by mistake or by purpose?
So in order to eliminate this delay, one can just install the package linux-firmware-uncompressed provided by @jonathon replacing the one from repos ? And the whence one will be alright as is?
well … Seems like it was only imaginary. Took the time trying to prove my observation and tried several combinations, measuring time using systemd-analyze on my system (Ryzen 2700X on a X470 chipset, 32GB RAM@3466Mhz, booting from a Samsung SSD 960 EVO 500GB)
Booted two times per test:
Interestingly enough, the only thing having a real influence on boot time are my changing wallpapers in KDE (seen in userspace times - i just had a boot outside of the test where userspace took over 2 seconds to load )
And zst compressed mkinitcpio actually is a bit faster then uncompressed / cat mkinitcpio.
Edit: And “loader” only takes over 2 seconds because grub has a 2 second timeout on my machine that I let run out for comparability.
I just upgraded and was surprised with the size difference of linux-firmware, so I searched and found this discussion.
I had a reported difference of about 120MB (the lowest I can be sure, it may have been higher… memory issues…).
The packages info show the difference is not that much. Has anyone noticed the reported size diff during update?
This would have more effect, on times where normal spinning HDDs was popular.
On my System, its not noticeable.
In theory, if you compress your kernel and everything needed by kernel, it should boot faster, because the compressed files get first loaded into ram and then decompressed. The theory says because ram is faster, it should decompress and load faster.
But today? i guess 99% with a “modern” machine use at least a ssd and shouldnt be noticeable.
)
