Bug#562594: More information
On Sat, Dec 26, 2009 at 05:03:03PM +0100, Frans Pop wrote:
> On Saturday 26 December 2009, Jurij Smakov wrote:
> > It turns out that the installer does offer an option to load firmware
> > from external drive, but only *after* I have loaded the firmware by
> > hand and re-ran 'Detect disks' option from installer menu.
>
> There are calls to a script 'check missing firmware.sh' during all three
> stages of hardware detection.
>
> Please do an install in expert mode, before any hardware detection is
> performed, add a 'set -x' in:
> - /bin/hw-detect
> - /bin/disk-detect
> - /bin/check-missing-firmware
>
It appears that logic in check-missing-firmware is flawed. It
checks the /dev/.udev/firmware-missing directory first to see if any
missing firmwares are listed there, and on my system the needed
firmware shows up there:
~ # ls -al /dev/.udev/firmware-missing/
drwxr-xr-x 2 root root 60 Dec 26 19:05 .
drwxr-xr-x 8 root root 180 Dec 26 19:08 ..
lrwxrwxrwx 1 root root 68 Dec 26 19:05 ql2200_fw.bin -> /devices/root/f006a214/pci0001:00/0001:00:04.0/firmware/0001:00:04.0
~ #
It then munges the link destination to come up with the device path of
/sys/devices/root/f006a214/pci0001:00/0001:00:04.0. That's the
correct device path for SCSI controller, confirmed by matching to
the lspci output. It then expects to find a symlink driver/module in
this directory, pointing to the driver module. It's not present in my
case:
~ # ls -la /sys/devices/root/f006a214/pci0001:00/0001:00:04.0
drwxr-xr-x 2 root root 0 Dec 26 19:05 .
drwxr-xr-x 4 root root 0 Dec 26 19:02 ..
-rw-r--r-- 1 root root 8192 Dec 26 19:11 broken_parity_status
-r--r--r-- 1 root root 8192 Dec 26 19:04 class
-rw-r--r-- 1 root root 256 Dec 26 19:11 config
-r--r--r-- 1 root root 8192 Dec 26 19:04 device
-rw------- 1 root root 8192 Dec 26 19:11 enable
-r--r--r-- 1 root root 8192 Dec 26 19:04 irq
-r--r--r-- 1 root root 8192 Dec 26 19:11 local_cpulist
-r--r--r-- 1 root root 8192 Dec 26 19:11 local_cpus
-r--r--r-- 1 root root 8192 Dec 26 19:11 modalias
-rw-r--r-- 1 root root 8192 Dec 26 19:11 msi_bus
-r--r--r-- 1 root root 8192 Dec 26 19:11 obppath
--w--w---- 1 root root 8192 Dec 26 19:11 remove
--w--w---- 1 root root 8192 Dec 26 19:11 rescan
-r--r--r-- 1 root root 8192 Dec 26 19:04 resource
-rw------- 1 root root 256 Dec 26 19:11 resource0
-rw------- 1 root root 8192 Dec 26 19:11 resource1
-r-------- 1 root root 131072 Dec 26 19:11 rom
lrwxrwxrwx 1 root root 0 Dec 26 19:11 subsystem -> ../../../../../bus/pci
-r--r--r-- 1 root root 8192 Dec 26 19:11 subsystem_device
-r--r--r-- 1 root root 8192 Dec 26 19:11 subsystem_vendor
-rw-r--r-- 1 root root 8192 Dec 26 19:02 uevent
-r--r--r-- 1 root root 8192 Dec 26 19:04 vendor
~ #
The logic in check_missing() function appends the missing firmware
file name to the $files list and the module to $modules list. However,
if such mapping fails (as in this case), nothing is appended to $files
or $modules, and the file is simply ignored as a result:
if [ -n "$modules" ]; then
log "missing firmware files ($files) for $modules"
return 0
else
log "no missing firmware in $MISSING"
return 1
fi
The problem here is that empty $modules does not mean that there are
no files in $MISSING which is set to /dev/.udev/firmware-missing (the
log message is wrong as well). Not sure whether this problem is caused
by changes to check-missing-firmware or kernel, I can try to boot a
lenny installer tomorrow to see how it worked there.
Best regards,
--
Jurij Smakov jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
Reply to: