Firmware

[Don Zickus]

On Mon, Jun 09, 2008 at 11:08:57AM -0400, Jarod Wilson wrote:
> 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. :)

Hmm, that would cause issues.  But then when folks like qlogic have new
fw, how do you update it successfully?  A stub kernel?

Perhaps creating a new initrd based on the same kernel and a corresponding
new grub entry (entry would consist of old kernel / new initrd image)
would allow people to fallback to the old initrd image if the new one was
bunk?

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

I didn't find that scenario interesting because you already have your
rootfs mounted so you could do other tricks to recover from that.

Cheers,
Don