Re: Use isenkram to get around the firmware problem?
Hi,
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
--
Holger Wansing <hwansing@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Reply to: