5:04 a.m.
Been playing with how I'd make the kernel package deal with the new
'make firmware_install' stuff. Currently looks something like this.
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.
Other comments?
(the patch is from git.infradead.org/users/dwmw2/firmware-2.6.git)
Index: config-generic
===================================================================
RCS file: /cvs/pkgs/rpms/kernel/devel/config-generic,v
retrieving revision 1.109
diff -u -p -r1.109 config-generic
--- config-generic 4 Jun 2008 00:22:50 -0000 1.109
+++ config-generic 9 Jun 2008 09:59:12 -0000
@@ -2479,9 +2479,9 @@ CONFIG_SND_ICE1724=m
CONFIG_SND_INTEL8X0=m
CONFIG_SND_INTEL8X0M=m
CONFIG_SND_KORG1212=m
-CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL=y
+# CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL is not set
CONFIG_SND_MAESTRO3=m
-CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL=y
+# CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL is not set
CONFIG_SND_MIRO=m
CONFIG_SND_MIXART=m
CONFIG_SND_NM256=m
@@ -2502,7 +2502,7 @@ CONFIG_SND_VIA82XX_MODEM=m
CONFIG_SND_VIRTUOSO=m
CONFIG_SND_VX222=m
CONFIG_SND_YMFPCI=m
-CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL=y
+# CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL is not set
#
# ALSA USB devices
@@ -3536,3 +3536,14 @@ CONFIG_SOC_CAMERA_MT9M001=m
CONFIG_SOC_CAMERA_MT9V022=m
# MT9V022_PCA9536_SWITCH is not set
+CONFIG_BUILTIN_FIRMWARE=""
+# CONFIG_USB_KAWETH_FIRMWARE is not set
+# CONFIG_DVB_TTUSB_BUDGET_FIRMWARE is not set
+# CONFIG_USB_SERIAL_WHITEHEAT_FIRMWARE is not set
+# CONFIG_USB_SERIAL_KEYSPAN_PDA_FIRMWARE is not set
+# CONFIG_USB_SERIAL_TI_3410_FIRMWARE is not set
+# CONFIG_USB_SERIAL_TI_5052_FIRMWARE is not set
+# CONFIG_USB_SERIAL_XIRCOM_FIRMWARE is not set
+# CONFIG_USB_EMI62_FIRMWARE is not set
+# CONFIG_USB_EMI26_FIRMWARE is not set
+
Index: kernel.spec
===================================================================
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v
retrieving revision 1.679
diff -u -p -r1.679 kernel.spec
--- kernel.spec 7 Jun 2008 01:48:53 -0000 1.679
+++ kernel.spec 9 Jun 2008 09:59:13 -0000
@@ -76,6 +76,8 @@ Summary: The Linux kernel (the core of t
%define with_doc %{?_without_doc: 0} %{?!_without_doc: 1}
# kernel-headers
%define with_headers %{?_without_headers: 0} %{?!_without_headers: 1}
+# kernel-firmware
+%define with_firmware %{?_without_firmware: 0} %{?!_without_firmware: 1}
# kernel-debuginfo
%define with_debuginfo %{?_without_debuginfo: 0} %{!?_without_debuginfo: 1}
# kernel-bootwrapper (for creating zImages from kernel + initrd)
@@ -565,6 +567,7 @@ Patch07: linux-2.6-compile-fixes.patch
#Patch08: linux-2.6-compile-fix-gcc-43.patch
%if !%{nopatches}
+Patch5: linux-2.6-firmware.patch
Patch10: linux-2.6-hotfixes.patch
@@ -693,6 +696,14 @@ header files define structures and const
building most standard programs and are also needed for rebuilding the
glibc package.
+%package firmware
+Summary: Firmware files used by the Linux kernel
+Group: Development/System
+License: Redistributable
+%description firmware
+Kernel-firmware includes firmware files required for some devices to
+operate.
+
%package bootwrapper
Summary: Boot wrapper files for generating combined kernel + initrd images
Group: Development/System
@@ -992,6 +1003,7 @@ fi
%if !%{nopatches}
+ApplyPatch linux-2.6-firmware.patch
ApplyPatch linux-2.6-hotfixes.patch
# Roland's utrace ptrace replacement.
@@ -1581,6 +1593,10 @@ rm -f $RPM_BUILD_ROOT/usr/include/asm*/i
rm -f $RPM_BUILD_ROOT/usr/include/asm*/irq.h
%endif
+%if %{with_firmware}
+make INSTALL_FW_PATH=$RPM_BUILD_ROOT/lib/firmware firmware_install
+%endif
+
%if %{with_bootwrapper}
make DESTDIR=$RPM_BUILD_ROOT bootwrapper_install WRAPPER_OBJDIR=%{_libdir}/kernel-wrapper
WRAPPER_DTSDIR=%{_libdir}/kernel-wrapper/dts
%endif
@@ -1690,6 +1706,12 @@ fi
/usr/include/*
%endif
+%if %{with_firmware}
+%files firmware
+%defattr(-,root,root)
+/lib/firmware/*
+%endif
+
%if %{with_bootwrapper}
%files bootwrapper
%defattr(-,root,root)
--
dwmw2
7:06 a.m.
On Monday 09 June 2008 06:04:08 am David Woodhouse wrote:
Been playing with how I'd make the kernel package deal with the
new
'make firmware_install' stuff. Currently looks something like this.
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.
Other comments?
We actually *can* make it noarch without much effort -- remember, the kernel
is a special beast that actually does get a noarch build pass done on it for
kernel-docs. No reason kernel-firmware couldn't be spit out from the same
build run, so far as I know.
--
Jarod Wilson
jwilson(a)redhat.com
7:07 a.m.
On Mon, 2008-06-09 at 08:06 -0400, Jarod Wilson wrote:
We actually *can* make it noarch without much effort -- remember,
the
kernel is a special beast that actually does get a noarch build pass
done on it for kernel-docs. No reason kernel-firmware couldn't be spit
out from the same build run, so far as I know.
Good point; I'll do it like that. Thanks.
--
dwmw2
7:39 a.m.
On Mon, 2008-06-09 at 13:07 +0100, David Woodhouse wrote:
On Mon, 2008-06-09 at 08:06 -0400, Jarod Wilson wrote:
> We actually *can* make it noarch without much effort -- remember, the
> kernel is a special beast that actually does get a noarch build pass
> done on it for kernel-docs. No reason kernel-firmware couldn't be spit
> out from the same build run, so far as I know.
Good point; I'll do it like that. Thanks.
Actually, it already was -- it was building the kernel-firmware
subpackage for _both_ arch and noarch builds. I just needed to stop it
doing so for the arch builds.
--
dwmw2
9:01 a.m.
Jarod Wilson (jwilson(a)redhat.com) said:
> 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.
We actually *can* make it noarch without much effort -- remember, the kernel
is a special beast that actually does get a noarch build pass done on it for
kernel-docs. No reason kernel-firmware couldn't be spit out from the same
build run, so far as I know.
Well, it means you may end up including various firmwares on architectures
where they're irrelevant. But as long as you're willing to take the installed
space hit, it's not a huge deal.
Bill
9:04 a.m.
On Mon, 2008-06-09 at 10:01 -0400, Bill Nottingham wrote:
Well, it means you may end up including various firmwares on
architectures
where they're irrelevant. But as long as you're willing to take the installed
space hit, it's not a huge deal.
Yeah, it doesn't take much -- and it's better on the file system than in
unswappable kernel memory :)
Besides, I've deliberately kept 'make firmware_install' completely arch-
and config-independent. You get the same bits wherever you run it.
--
dwmw2
7:39 a.m.
David Woodhouse wrote:
Been playing with how I'd make the kernel package deal with the
new
'make firmware_install' stuff. Currently looks something like this.
I suspect that (for now) we should make the kernel binary packages
depend on kernel-firmware?
Yeah, seems the sanest thing to do at least initially, so people don't
suddenly wind up with non-functional devices.
Should the package own the /lib/firmware/ directory?
Not quite sure. udev owns it right now. Could have multiple ownership so as to
not Requires: udev. Could possibly be something that should move to the
filesystem package. I think I might lean toward making that directory owned by
filesystem, so you have singular ownership and both udev and kernel-firmware
can use it without either one explicitly requiring the other.
--
Jarod Wilson
jwilson(a)redhat.com
7:40 a.m.
On Mon, 2008-06-09 at 08:39 -0400, Jarod Wilson wrote:
Not quite sure. udev owns it right now. Could have multiple ownership
so as to
not Requires: udev. Could possibly be something that should move to the
filesystem package. I think I might lean toward making that directory owned by
filesystem, so you have singular ownership and both udev and kernel-firmware
can use it without either one explicitly requiring the other.
I'm content with requiring udev -- since it's udev which is going to
load anything that lives in /lib/firmware anyway, that actually makes
some sense.
--
dwmw2
7:43 a.m.
David Woodhouse wrote:
On Mon, 2008-06-09 at 08:39 -0400, Jarod Wilson wrote:
> Not quite sure. udev owns it right now. Could have multiple ownership so as to
> not Requires: udev. Could possibly be something that should move to the
> filesystem package. I think I might lean toward making that directory owned by
> filesystem, so you have singular ownership and both udev and kernel-firmware
> can use it without either one explicitly requiring the other.
I'm content with requiring udev -- since it's udev which is going to
load anything that lives in /lib/firmware anyway, that actually makes
some sense.
Ah, okay, I figured udev typically would be wanted, but wasn't sure if some of
this could be done sans-udev in some particular case. Just requiring udev does
sound like the way to go then.
--
Jarod Wilson
jwilson(a)redhat.com
8:40 a.m.
On Mon, Jun 09, 2008 at 11:04:08AM +0100, David Woodhouse wrote:
Been playing with how I'd make the kernel package deal with the
new
'make firmware_install' stuff. Currently looks something like this.
Is that something new upstream? It would be great to separate the
firmware from the kernel builds.
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?
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.
Cheers,
Don
9:15 a.m.
On Mon, 2008-06-09 at 09:40 -0400, Don Zickus wrote:
On Mon, Jun 09, 2008 at 11:04:08AM +0100, David Woodhouse wrote:
> Been playing with how I'd make the kernel package deal with the new
> 'make firmware_install' stuff. Currently looks something like this.
Is that something new upstream? It would be great to separate the
firmware from the kernel builds.
http://lwn.net/Articles/284104/
http://lwn.net/Articles/284932/
git.infradead.org/users/dwmw2/firmware-2.6.git
>
> 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.
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.
--
dwmw2
9:46 a.m.
On Mon, 2008-06-09 at 15:15 +0100, David Woodhouse wrote:
On Mon, 2008-06-09 at 09:40 -0400, Don Zickus wrote:
> On Mon, Jun 09, 2008 at 11:04:08AM +0100, David Woodhouse wrote:
http://lwn.net/Articles/284104/
http://lwn.net/Articles/284932/
git.infradead.org/users/dwmw2/firmware-2.6.git
Yup, I was going to reply with those links - especially the reply from
the other Dave on pulling out firmware from the kernel :)
> 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.
Good idea. But yeah, mkinitrd already looks for firmware files (those
tagged with MODULE_FIRMWARE macros) and pulls them in.
> 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.
Another issue that we never really solved was that we really need to
have one firmware package per firmware (group) so that others can
possibly override their firmware without replacing the entire
kernel-firmware package and affecting everyone. Opinion?
Jon.
9:48 a.m.
On Mon, 2008-06-09 at 10:46 -0400, Jon Masters wrote:
Another issue that we never really solved was that we really need to
have one firmware package per firmware (group) so that others can
possibly override their firmware without replacing the entire
kernel-firmware package and affecting everyone. Opinion?
Later. We can't do it now, and it's not a loss. What we're doing makes
it _easier_ to do that later, if we want to. But I don't want to try it
now.
--
dwmw2
9:51 a.m.
On Mon, 2008-06-09 at 15:48 +0100, David Woodhouse wrote:
On Mon, 2008-06-09 at 10:46 -0400, Jon Masters wrote:
> Another issue that we never really solved was that we really need to
> have one firmware package per firmware (group) so that others can
> possibly override their firmware without replacing the entire
> kernel-firmware package and affecting everyone. Opinion?
Later. We can't do it now, and it's not a loss. What we're doing makes
it _easier_ to do that later, if we want to. But I don't want to try it
now.
K. I guess I'm just raising it so we're aware of it. It's not exactly a
loss, but my fear is that once we make it possible for someone else to
replace all the kernel firmware just to update their buggy one, then
they'll rush out and do this as soon as possible :)
Jon.
9:53 a.m.
On Mon, 2008-06-09 at 10:51 -0400, Jon Masters wrote:
K. I guess I'm just raising it so we're aware of it. It's
not exactly
a loss, but my fear is that once we make it possible for someone else
to replace all the kernel firmware just to update their buggy one,
then they'll rush out and do this as soon as possible :)
Better option might be another directory which appears first on udev's
(and mkinitrd's) search patch. That way you can override firmware
without having to split the package.
--
dwmw2
9:54 a.m.
On Mon, 2008-06-09 at 15:53 +0100, David Woodhouse wrote:
On Mon, 2008-06-09 at 10:51 -0400, Jon Masters wrote:
> K. I guess I'm just raising it so we're aware of it. It's not exactly
> a loss, but my fear is that once we make it possible for someone else
> to replace all the kernel firmware just to update their buggy one,
> then they'll rush out and do this as soon as possible :)
Better option might be another directory which appears first on udev's
(and mkinitrd's) search patch. That way you can override firmware
without having to split the package.
And that of course is a nicer fix, yeah, then people can have their own
per-device firmware package if they choose to do so. Coolness.
Jon.
9:58 a.m.
Jon Masters wrote:
On Mon, 2008-06-09 at 15:53 +0100, David Woodhouse wrote:
> On Mon, 2008-06-09 at 10:51 -0400, Jon Masters wrote:
>> K. I guess I'm just raising it so we're aware of it. It's not
exactly
>> a loss, but my fear is that once we make it possible for someone else
>> to replace all the kernel firmware just to update their buggy one,
>> then they'll rush out and do this as soon as possible :)
> Better option might be another directory which appears first on udev's
> (and mkinitrd's) search patch. That way you can override firmware
> without having to split the package.
And that of course is a nicer fix, yeah, then people can have their own
per-device firmware package if they choose to do so. Coolness.
Yeah, something like /lib/firmware/updates/ sounds gravy. I was initially
thinking we could have a kernel-firmware package that was a meta-package,
pulling in umpteen individual firmware packages (a la xorg-x11-drivers), but I
like this idea better.
--
Jarod Wilson
jwilson(a)redhat.com
10:04 a.m.
On Mon, Jun 09, 2008 at 03:53:07PM +0100, David Woodhouse wrote:
On Mon, 2008-06-09 at 10:51 -0400, Jon Masters wrote:
> K. I guess I'm just raising it so we're aware of it. It's not exactly
> a loss, but my fear is that once we make it possible for someone else
> to replace all the kernel firmware just to update their buggy one,
> then they'll rush out and do this as soon as possible :)
Better option might be another directory which appears first on udev's
(and mkinitrd's) search patch. That way you can override firmware
without having to split the package.
Cute hack that might get ugly later when the tarball is actually updated
with a newer version than the one in the 'special' directory leading to
all sorts of confusion about what version is loading..
But I am for the baby steps approach just to get a sense of how this going
to work properly.
Thanks for the effort.
Cheers,
Don
9:59 a.m.
On Mon, Jun 09, 2008 at 03:15:05PM +0100, David Woodhouse wrote:
On Mon, 2008-06-09 at 09:40 -0400, Don Zickus wrote:
> On Mon, Jun 09, 2008 at 11:04:08AM +0100, David Woodhouse wrote:
> > Been playing with how I'd make the kernel package deal with the new
> > 'make firmware_install' stuff. Currently looks something like this.
>
> Is that something new upstream? It would be great to separate the
> firmware from the kernel builds.
http://lwn.net/Articles/284104/
http://lwn.net/Articles/284932/
git.infradead.org/users/dwmw2/firmware-2.6.git
Thanks for the links. The discussion was helpful.
> >
> > 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..).
> 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.
Cheers,
Don
10:08 a.m.
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(a)redhat.com
10:15 a.m.
Jarod Wilson wrote:
>>> 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.
But of course, you've still got a system that at least boots, and can back-rev
the firmware if needed, so not a big issue vs. boot-path-dependent firmware.
--
Jarod Wilson
jwilson(a)redhat.com
10:25 a.m.
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
10:47 a.m.
Don Zickus wrote:
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?
Not sure. What happens in such cases today? Have to install a new kernel or kmod?
A stub kernel?
Ew.
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?
Could get messy, littering /boot with old initrds that aren't cleaned up, and
your bootloader with extra entries you may never use -- what would trigger
their removal and when? I just assume leave out the auto-rebuilding of the
initrd though. I think if you know you need/want new firmware for a device,
you should be able to figure out how to create a new initrd with it (and save
the old initrd as a fallback).
I didn't find that scenario interesting because you already have
your
rootfs mounted so you could do other tricks to recover from that.
Yeah, I sent a follow-up email saying the same, didn't take that into account
until after hitting send, and my unsend button never seems to work... :)
--
Jarod Wilson
jwilson(a)redhat.com
2:12 a.m.
On Mon, 2008-06-09 at 11:04 +0100, David Woodhouse wrote:
Been playing with how I'd make the kernel package deal with the
new
'make firmware_install' stuff. Currently looks something like this.
The patches have now hit Linus' tree, so I've committed the specfile
parts too. As soon as we update to 2.6.26-git1, we'll get a separate
kernel-firmware package which is required by the main kernel binary
package.
I suspect that (for now) we should make the kernel binary packages
depend on kernel-firmware?
Done. There are some firmwares which are under GPL, so even the "Free
Software or nothing!" folks can have _some_ form of kernel-firmware
package. I don't think there's a problem with requiring it.
I'll leave it to Alex to submit for review a kernel-firmware-libre
package which Provides: kernel-firmware and which actually builds the
various firmware files from source :)
Should the package own the /lib/firmware/ directory?
Not done.
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.
Done.
--
dwmw2
5772
days inactive
5808
days old
kernel@lists.fedoraproject.org
23 comments
5 participants
participants (5)
-
Bill Nottingham -
David Woodhouse -
Don Zickus -
Jarod Wilson -
Jon Masters