Comment 17 for bug 328550

I'm reopening this bug. This is not a wishlist at all; it's a significant regression for users of this hardware, that will affect both new installs and LTS->LTS upgrades. While I agree that doubling the size of all initramfses unreasonably penalizes users without this hardware, we do need to have a solution that works out of the box for users /with/ this hardware - if always including this firmware in the initramfs isn't reasonable, then we should entertain other options, such as using a different policy for server kernels or opportunistically adding the firmware to the initramfs *if* it's detected that the module is needed on the hardware where the initramfs is built (or if it's detected that the root device uses it).

Now, in the udev in Ubuntu 9.10, I see that /usr/share/initramfs-tools/hooks/udev *does* include the following code:

for rules in 50-udev-default.rules 50-firmware.rules 60-persistent-storage.rules 61-persistent-storage-edd.rules 64-device-mapper.rules 80-drivers.rules 95-udev-late.rules; do
    cp -p /lib/udev/rules.d/$rules ${DESTDIR}/lib/udev/rules.d
done
[...]
copy_exec /lib/udev/firmware.sh /lib/udev

So I don't believe udev in 9.10 is actually buggy - the firmware loading hooks are present in the initramfs!

It looks like only initramfs-tools itself has a bug, because only firmware for modules that are explicitly singled out in /usr/share/initramfs-tools/hook-functions are included in the initramfs. There, firmware is *only* copied if it's found in the /lib/modules/$(uname -r) directory - not if it's found in /lib/firmware. This is inconsistent, and appears to be a straightforward bug due to an oversight rather than a design decision.

Correcting this pulls in only 6 more firmware files, adds 684k (unpacked; 315k packed) to the initramfs size, and the change is also included already in the newer version of the update-initramfs package upstream in Debian. So I think this is the obviously correct change to make here.