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

Bug#492205: installation-reports: firmware load testing

Jérémy Bobbio wrote:
>  * Firmware packages should not be installed for firmware that were not
>    explicitely required.
>    This would need further investigation as the code, as far as I can
>    see, should filter out the packages present on the media based on
>    needed firmware files.

The filtering worked in my testing. Before I go off on a wild goose
chase, are we sure that Dan didn't dump the debs into
/var/cache/firmware/ in d-i? Because it would pefectly explain it trying
to install all the debs from there.

Hmm, tested again, code still seems to work:

# files="foo bar"
# echo "$files" | sed -e 's/ /\n/g' >/tmp/grepfor
# cat /tmp/grepfor 
# list_deb_firmware () {
 # list_deb_firmware () {
>         ar p "$1" data.tar.gz | tar zt \
>                 | grep '^\./lib/firmware/' \
>                 | sed -e 's!^\./lib/firmware/!!'
> }
# list_deb_firmware zd1211-firmware_2.16.0.0-0.1_all.deb 

# list_deb_firmware zd1211-firmware_2.16.0.0-0.1_all.deb  | grep -qf /tmp/grepfor
# echo $?

It does, however, think that every deb contains a firmware file named "", so if
it somehow thinks it needs such a file, it will try to use every deb to provide

/ff # files="foo bar "
/ff # echo "$files" | sed -e 's/ /\n/g' >/tmp/grepfor
/ff # list_deb_firmware zd1211-firmware_2.16.0.0-0.1_all.deb  | grep -qf
/ff # echo $?

I don't see how $files could get an extra leading/trailing space to
tickle this problem, unless a module actually requests a firmware file
with a space in its name. But I've checked in a fix for it anyway..

>  * The post-base-installer hook uses "dpkg -i" to install the firmware
>    packages on the target system.  This will fail if the firmware
>    package dependencies are not fulfilled on the target at that time of
>    the installation process.
>    Possible fix: switch to a "dpkg --unpack", "apt-get -f install"
>                  construct

Maybe, however firmware debs really have no business depending on
packages not in base either. And getting the dpkg db into a broken state
and relying on apt fixing it, noninteractively, seems like it can be
asking for trouble.

In particular, atmel-firmware has no reason to depend on perl, since
atmel_fwl is not used in normal operation. And neither atmel-firmware
nor zd1211-firmware have any business depending on udev. Bugs filed on

Until those two can be fixed, we can simply drop their debs from the
firmware-nonfree images.

And for added robustness, I've made it dpkg --remove the package if dpkg
-i fails.

>  * If firmware packages for other architectures than all or the one
>    being installed are present on the firmware media, the
>    post-base-installer hook will try to install them nevertheless.  This
>    will obviously fails.
>    Possible fix: filter packages for wrong architectures in
>                  check-missing-firmware.sh

Added, but note that this is currently only really useful in the case
of choosing the right arch ixp4xx-microcode on arm/armel.

see shy jo

Attachment: signature.asc
Description: Digital signature

Reply to: