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

Re: Use isenkram to get around the firmware problem?


Petter Reinholdtsen <pere@hungry.com> wrote (Sun, 07 Mar 2021 08:13:31 +0100):
> 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?

I fear, all the above is out of my skills.

And for the (graphics) firmware problem, isenkram is of no help as it seems, 
at least for Bullseye.


Holger Wansing <hwansing@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Reply to: