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.
--
Jarod Wilson
jwilson@xxxxxxxxxx
_______________________________________________
Fedora-kernel-list mailing list
Fedora-kernel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
