[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#598543: marked as done (various firmware and initrd.img woes)

Your message dated Thu, 30 Sep 2010 10:27:10 +0000
with message-id <20100930102710.GS5947@vostochny.stro.at>
and subject line Re: Bug#598543: various firmware and initrd.img woes
has caused the Debian Bug report #598543,
regarding various firmware and initrd.img woes
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
598543: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598543
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: initramfs-tools
Version: 0.98.4

Hi there, I noticed these problems on the lenny version but the current
unstable version seems to have the same problem, too.

There are various complications with using firmware with initrd.img.

First, the /lib/udev/firmware.agent file should probably be included in
the default initrd.img; it should also probably include "/" as a
firmware location (in addition to /lib/firmware and other places). 

This would allow people to merely tack cpio.gz files to the end of the
initrd.img (or list multiple files on the kernel command line) to supply
firmware files that might be necessary for boot.  Currently when it
fails because this agent file is not there, the situation is very
cryptic to figure out.

Finally, that firmware.agent file really should log what it's doing -
especially in the case of errors.  The kernel code which services the
request_firmware() functions log virtually nothing, which means that all
you get will be a pause of a minute, then a general error.  Booting with
'debug' and 'break' helps debug the situation, but printing out the
firmware file that was requested and the paths it tried to load from but
failed would make resolving the problem much easier.

Cheers,
Sam.

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
--- Begin Message --- 
On Thu, Sep 30, 2010 at 11:05:43AM +1300, Sam Vilain wrote:
> 
> Hi there, I noticed these problems on the lenny version but the current
> unstable version seems to have the same problem, too.
> 
> There are various complications with using firmware with initrd.img.
> 
> First, the /lib/udev/firmware.agent file should probably be included in
> the default initrd.img; it should also probably include "/" as a
> firmware location (in addition to /lib/firmware and other places). 

no / is not the place for firmware.
 
> This would allow people to merely tack cpio.gz files to the end of the
> initrd.img (or list multiple files on the kernel command line) to supply
> firmware files that might be necessary for boot.  Currently when it
> fails because this agent file is not there, the situation is very
> cryptic to figure out.
> 
> Finally, that firmware.agent file really should log what it's doing -
> especially in the case of errors.  The kernel code which services the
> request_firmware() functions log virtually nothing, which means that all
> you get will be a pause of a minute, then a general error.  Booting with
> 'debug' and 'break' helps debug the situation, but printing out the
> firmware file that was requested and the paths it tried to load from but
> failed would make resolving the problem much easier.

firmware.agent is part of udev, if you want enhancements there
report against udev.

closing as not an initramfs-toosl bug.
thanks

--- End Message ---
Reply to: