Don Zickus wrote:
I suspect that (for now) we should make the kernel binary packages depend on kernel-firmware?
Should the package own the /lib/firmware/ directory?
Ideally we'll want kernel-firmware to be a .noarch.rpm, but we can't get that until we start to build it from a separate srpm.
I assume the %install would cause a rebuild of the initrd to deal with storage device firmware on bootup?
The kernel install already does that. Perhaps we should ensure that kernel-firmware gets updated before the kernel proper, to ensure that the new firmware is included.
Or maybe always rebuild initrd when installing kernel-firmware? It's a little overkill but handles scenarios when the vendor updates their storage blob but we have no new kernel update to go with it (that's probably a little long term thinking to handle the scenario when you actually separate the srpms..).
I'd stick to rebuilding initrds only for a new kernel. Your issue of 'what do I do if the new firmware is bunk' pops up if installing kernel-firmware triggers a new initrd for an already functioning kernel. :)
We were trying to do this with RHEL (jcm was working on this). One of the issues I brought up (which no one had a solution for) was the case for a bad firmware for storage devices. Currently they are built into the kernel. So if you stumble upon bad firmware, you just boot the previous working kernel. How would this be handled with everything under /lib/firmware? I guess a previously working initrd image might suffice.
Yeah, the previous kernel would have had its initrd generated when that kernel was installed. That initrd should continue to work.
Yeah, not sure why I didn't think of this months ago when I was discussing this with folks internally.
Could still be an issue for any device that doesn't get brought up until we've already spun up the kernel and initrd -- i.e., system boots off internal disk, later during boot, brings up external storage on fibre channel adapter, which loads its firmware from /lib/firmware.