To the majority of Ubuntu users, any package update is welcome, irrespective of what it’s for or the how large it is to download — case in point: linux-firmwarewhich, as hardware support files are added or fixes applied, continues to grow in download and install size.
This singular unified firmware package bundles together drivers and microcode for all kinds of hardware devices, from from wi-fi cards and dongles to graphics cards to storage controllers for NVMes and SSDs.
If you’ve ever looked at the Software Updater and seen it needs to pull in 800MB of updates for the second time in a month, chances are the Linux Firmware package has seen an update (however minor the change, it downloads the entire package).
A lot of the firmware blobs bundled inside this critical kernel package are useful. No doubt about that. Not everyone needs everything it contains, though get “all the firmware” anyway. For instance, you probably aren’t using a RISC-V system, but you get RISC-V firmware.
This creates a convenient inefficiency — one with downsides.
For users on slow or limited data connections (as I was from 2023 until November 20241), those semi-frequent >500MB updates are a pain since they’re 99% full of things not relevant to their systems, and they often arrive alongside other larger updates (like kernels).
For Canonical’s infrastructure, bigger updates mean bigger bandwidth costs, and larger packages mean longer build times.
Is it time for a more efficient approach?
One Canonical engineer thinks it might be.
Linux Firmware Sub-Package Proposal
Canonical engineer Juerg Haefliger kicked off a discussion about whether it’s time to split the kernel firmware package into a series of vendor-specific sub-packages. Think separate packages for Intel, AMD, Broadcom, and other hardware makers.
Such an approach would reduce Ubuntu’s overall installed footprint, make updating faster for end-users, and (indirectly) provide a few other efficiencies on Canonical’s end.
But as with most things in life, it’s not quite that simple.
Providing “all the firmware” out-of-the-box is what makes Ubuntu “just work” on a diverse range of hardware. Vendor-specific sub-packages complicate that since if the right firmware isn’t present at boot time the hardware might not work at all.
One idea is to preinstall these (theoretical) vendor-specific packages on the ISO, but enable the Ubuntu Installer to determine which packages are no longer needed after the install is complete (the same way unused language files, apps, etc are yanked post-install).
All firmware packages will remain available in the Ubuntu repos. When new hardware is detected or added, relevant firmware can be pulled in (automatically or manually).
A simpler, coarser approach is to split Linux firmware packages into architecture-specific bundles, so users on Intel/AMD devices don’t get ARM and RISC-V blobs, and vice versa. All other firmware would remain as-is.
Both approaches have their respective merits, though CPU-based segmentation wouldn’t save as much disk space as vendor-based.
If a decision is taken on splitting hardware support files into a modular array, it will have to be done carefully, with thorough testing and signposting in advanced to catch any edge cases.
A growing size challenge
One thing is for sure: linux-firmware is only going to continue to grow in size as new hardware requiring new firmware is released, and existing firmware improved.
For now, this whole discussion is at a formative stage, No decision has been made, no consensus reached, and no timeline set for doing something about it set.
But given the benefits to both end-users and Canonical by tackling it, I’d be surprising if some form of firmware package “optimisation” didn’t feature in a future Ubuntu release.
- My 40GB monthly allowance had significant chunks taken out of thanks to automatic background updates (especially snaps). Even running
apt updatecould pull down a good 50MB if I hadn’t done it for a few weeks. I disabled all updates on all devices, and left major ones to tactically arranged coffee shop visits. ↩︎