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

Re: Use isenkram to get around the firmware problem?



Hi Holger,

[Holger Wansing]
> OK, so there might still be some hope :-)

Perhaps. :)

I unsuccessfuly tried to be breafer.  There seem to be two issues here.
One seem to be a bug or misfeature either in isenkram or appstream,
leading to long run times.  The other is lack of appstream mapping
information for the firmware-amd-graphics package, one I do not know
much about.

I do not know the solution to the former, and currently lack the time to
dive into it.  Did a quick look at the code, though, see below.

As for the latter, the easiest way I know to check the current appstream
content is to run appstream2modaliases from the isenkram source, and
look for firmware-amd-graphics.  It is not mentioned in the output, nor
in the modaliases file included in isenkram, so there is no knowledge
available for isenkram about what kind of hardware that package would be
useful for.

The generic solution is to get the firmware-amd-graphics maintainer to
add appstream metadata mapping to the PCI IDs supported by the package,
<URL: http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html >
and <URL: https://wiki.debian.org/AppStream/Guidelines >
provide some clues on how to do this.

If the maintainer is unwilling or while we wait for an updated package
there is a short term solution.  We can add the same mapping to the
modaliases file provided by isenkram, and upload isenkram instead.

As you can imagine, without hardware-package mapping information,
isenkram can not do much, and in this case the mapping is missing.  I
suspect Debian will need to use such mapping in the default installation
for a few releases before most relevant developers become aware of the
need and give priority to adding it to their packages.  Luckily there
are not that many maintainers with hardware specific packages, so it is
not an enormous job to convince them.

Unfortunately I have lacked the capacity the last few years to attack
the issue myself, and this is likely to continue, so someone else will
have to convince them.  I did submit quite a few BTS requests over the
years for the mappings I am aware of (see the
/usr/share/isenkram/modaliases in isenkram-cli for those I am aware of),
but ran out of steam and time.

Perhaps it is also possible to merge the modalias information in kernel
modules with their requested frimware files and the packages that
provide them, to extract these mappins automatically from the archive?
I suspect so, but have not tried so myself.  In any case, the
information must show up in appstream (or isenkram) to be useful.

> Next, I executed 'isenkram-pkginstall'.  A long list of
> binary/firmware files came up, with the informal line "info: locating
> packages with the requested firmware files" Then, the machine seemed
> to hang for about 25 minutes!  top showed, that there were many
> appstreamcli processes running (like 'appstreamcli what-provides
> firmware:runtime radeon/CAYMAN_me.bin').

It sound a bit like this code in isenkram-autoinstall-firmware might
take a long lime, specificly the appstreamlookup call:

loginfo "locating packages with the requested firmware files"
binpkginfos=""
binpkgs=""
for fwfile in $fwfiles ; do
    # First check appstream, next look in our local files if they exist
    binpkginfo=$(appstreamlookup $fwfile)
    if [ "$binpkginfo" ] && [ "$datafiles" ]; then
        fwfilere=$(echo $fwfile | sed -e 's%/%\\/%g' -e 's/\./\\./g')
        binpkginfo="$(awk "/^lib\/firmware\/$fwfilere/ {print \$2}" $datafiles)"
    fi
    if [ -z "$binpkginfo" ] ; then
        # Special case for b43 where the firmware is
        # undistributable by Debian.
        case "$fwfile" in
            b43/*)
                add_contrib_nonfree
                binpkgs="${binpkgs:+$binpkgs }firmware-b43-installer"
                ;;
        esac
    else
        binpkginfos="$binpkginfos $binpkginfo"
    fi
done

> Then I called tasksel and selected the new entries generated by
> isenkram (Hardware specific packages (autodetected by isenkram and
> Hardware specific firmware packages (autodetected by isenkram).  That
> lead to the same hanging machine again, as above, again for ~25
> minutes.

If my suggestion is right, the delay is because of the second tasksel
option, not the first.  I have no idea how to make the appstream lookup
quicker in shell script.  Perhaps it need to be rewritten to python to
avoid loading the appstream database on every lookup?

-- 
Happy hacking
Petter Reinholdtsen


Reply to: