To the majority of Ubuntu users, any package update is welcome, irrespective of what it’s for or the size of the download it requires — case in point: linux-firmware which, as more firmware is added or tweaked, grows and grows in 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.

So 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 quiet 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 all of these (theoretical) firmware vendor packages on the ISO, but let the Ubuntu Installer decide which packages aren’t needed once install is complete (the same way unused language files, apps, etc get removed post-install).

All firmware packages would be available in the Ubuntu repos so, when new hardware is detected or added, the 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 space as vendor-based. They also have their own potential drawbacks.

If a decision is taken it will have to be done carefully, with thorough testing.

A growing 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.

  1. My 40GB monthly allowance had significant chunks taken out of thanks to automatic background updates (especially snaps). Even running apt update could 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. ↩︎