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 ---
- To: submit@bugs.debian.org
- Subject: various firmware and initrd.img woes
- From: Sam Vilain <sam.vilain@catalyst.net.nz>
- Date: Thu, 30 Sep 2010 11:05:43 +1300
- Message-id: <[🔎] 1285797943.28046.390.camel@wilber>
- In-reply-to: <[🔎] 1285797378.28046.381.camel@wilber>
- References: <[🔎] 1285797378.28046.381.camel@wilber>
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 ---
- To: 598543-done@bugs.debian.org
- Subject: Re: Bug#598543: various firmware and initrd.img woes
- From: maximilian attems <max@stro.at>
- Date: Thu, 30 Sep 2010 10:27:10 +0000
- Message-id: <20100930102710.GS5947@vostochny.stro.at>
- In-reply-to: <[🔎] 1285797943.28046.390.camel@wilber>
- References: <[🔎] 1285797378.28046.381.camel@wilber> <[🔎] 1285797943.28046.390.camel@wilber>
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 ---