Boot method: USB stick
Image version: debian-bookworm-DI-alpha2-amd64-netinst.iso
                debian-bookworm-DI-alpha2-i386-netinst.iso
Date: 2023-03-05

Machine: various PC
Processor: various Intel from Pentium 4 to Core i7
Memory: 1.25 to 16 GiB

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:           [O]
Detect network card:    [E]
Configure network:      [O]
Detect media:           [O]
Load installer modules: [O]
Detect hard drives:     [O]
Partition hard drives:  [ ]
Install base system:    [ ]
Clock/timezone setup:   [ ]
User/password setup:    [ ]
Install tasks:          [ ]
Install boot loader:    [ ]
Overall install:        [ ]

Comments/Problems:

I tested firmware detection and loading with various (mostly old)
hardware I have. I did not complete all installations.


1) Things that went well:

GPU AMD/ATI (radeon+firmware-amd-graphics): OK
GPU Intel (i915+firmware-misc-nonfree): OK
PCI SCSI QLogic ISP1020 (qla1280+firmware-qlogic): OK
PCI Ethernet Intel PRO/100 (e100+firmware-misc-nonfree): OK
PCI Ethernet Broadcom BCM5901 (tg3+firmware-misc-nonfree): OK
PCIe wifi Intel Centrino Advanced-N 6205 (iwlwifi+firmware-iwlwifi): OK


2) Things that did not go so well:

PCI SCSI Advansys ASC 1300/3300 (advansys+firmware-misc-nonfree): KO/OK
- i386: OK
- amd64: KO. This is a kernel driver bug, cf. bug #1032271.


* PCI wifi Intel PRO/Wireless 2200BG (ipw2200+firmware-ipw2x00): KO/OK
The firmware package was found, installed and used but not copied in
/var/cache/firmware. IIUC install_firmware_pkg() in
check-missing-firmware ,it is because its preinst script requires a
license acceptance (is that really needed ?). However the firmware files
are left because of a typo (".md5sum" should be ".md5sums"):

As a result, the interface works in the installer but IIUC the package
will not be installed in the target system.


* CardBus wifi Intersil Prism54 (p54pci+isl3886pci): KO/OK
The firmware is not included in any Debian package, so I provided it
either as loose file or hand-made .deb on a second USB stick.
But check-missing-firmware never runs mount-media. Looking at the code:

shouldn't the condition be "-gt" ? After changing it,
- loose file: KO (not found, known bug)
- .deb: OK


* USB wifi Intersil Prism54 (p54usb+isl3886usb): KO
The firmware is not included in any Debian package, so I provided it
either as loose file or hand-made .deb on a second USB stick.
It seems that check-missing-firmware failed to find the real module name
despite hw-detect commit ab087adedd738d8b6bfb7e785c591a1aa982b7f2.

Messages recorded in /var/log/syslog:

Pascal Hambourg <pascal@plouf.fr.eu.org> (2023-03-05):

Thanks for that.

Great.

OK.

Fixed the typo for now. I don't have enough bandwidth to actually think
about the license acceptance part. Might be worth filing separately
against hw-detect for later consideration.

Definitely a typo/thinko, fixed.

Please share the contents of that device's directory, so that the lookup
can be adjusted. I could only test with one single device, so I haven't
tried to be clever and think about all possible cases. Feel free to
spawn a specific hw-detect bug report for that.


Cheers,

See attached files with and without firmware. The following links and
directories exist only with firmware:

lrwxrwxrwx    1 root     root             0 Mar  5 13:29 driver ->
../../../../../../bus/usb/drivers/p54usb
drwxr-xr-x    3 root     root             0 Mar  5 13:29 ieee80211
drwxr-xr-x    6 root     root             0 Mar  5 13:29 leds
drwxr-xr-x    3 root     root             0 Mar  5 13:29 net

I am afraid that when the firmware is missing the driver is not attached
to the device so there is no direct way to retrieve it through /sys.

An indirect way may be to list loaded USB driver modules in
/sys/bus/usb/drivers or /proc/modules and search in their firmware
fields with modinfo ? Heavy and not 100% reliable though...

Pascal Hambourg <pascal@plouf.fr.eu.org> (2023-03-05):

Alright, nice to know which part of the lookup was failing anyway
(single 2-4:1.0 below 2-4, but missing driver symlink).

Since the existing code seems to work in at least some cases, it
wouldn't seem crazy to me to implement a fallback plan in case it
doesn't (as opposed to replacing the existing lookup entirely). After
all, we're quite certain that reloading usb* isn't going to work anyway,
so anything else we can try can't really be worse.

And I suppose iterating over a (uniquified) list of basename for
/sys/bus/<bus>/drivers/*/module might work on more buses than just usb
(see mhi for the qrtr-mhi thing in #1032140), so it should even be
possible to reuse this outside this specific usb usecase.


Cheers,

Hello,

What is wrong if there are multiple /sys/bus/devices/$address/$address:*
subdirectories ?

OK, I am working on fallback module detection based on matching modalias
and firmware fields when they exist. Also check module holders when needed.

Yes, although #1032140 seems to be a very special case because
ath11k_pci fields do not advertise the requested firmware file
ath11k/WCN6855/hw2.1/amss.bin, and only advertise pci aliases, not mhi.