#1035356 hw-detect: rework looping over filenames

Package:
hw-detect
Source:
hw-detect
Submitter:
Charles Curley
Date:
2025-01-05 17:51:03 UTC
Severity:
normal
Tags:
#1035356#5
Date:
2023-04-03 22:53:48 UTC
From:
To:
Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Once again I pulled in the weekly d-i netinst ISO and tried it on my IBM R51. This i386 machine uses the Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection (rev 05), which requires the ipw 2200 firmware.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

I ran my usual preseed file, which is set up to use the wifi network for Internet access.

   * What was the outcome of this action?

I only saw the Ethernet interface as an option. That works.

Grepping in the syslog indicates that the installer is looking in the wrong place on the CD-ROM.

At approximately 21:50:11 syslog reports that

check-missing-firmware: installing firmware package /cdrom/firmware/firmware-ipw2x00_20230210-4_all.deb

However, searching the CD-ROM indicates that the firmware package is elsewhere:

root@hawk:/crc/isos/debian/12.x/weekly# mkdir loop
root@hawk:/crc/isos/debian/12.x/weekly# mount debian-testing-i386-netinst.iso loop
mount: /crc/isos/debian/12.x/weekly/loop: WARNING: source write-protected, mounted read-only.
root@hawk:/crc/isos/debian/12.x/weekly# grep ipw loop/md5sum.txt
7e6f43f1dd1ec551f5eed63652f35ff0  ./firmware/dep11/firmware-ipw2x00.component
e6eb2bebabf6d793ebd5ebe958461cde  ./firmware/dep11/firmware-ipw2x00.patterns
8ff7cc60a37ed026c84613021cd4eb05  ./pool/non-free-firmware/f/firmware-nonfree/firmware-ipw2x00_20230210-4_all.deb
root@hawk:/crc/isos/debian/12.x/weekly# ll loop/pool/non-free-firmware/f/firmware-nonfree/firmware-ipw2x00_20230210-4_all.deb
-r--r--r-- 2 root root 279224 Mar 11 14:40 loop/pool/non-free-firmware/f/firmware-nonfree/firmware-ipw2x00_20230210-4_all.deb
root@hawk:/crc/isos/debian/12.x/weekly#


   * What outcome did you expect instead?

Successful log in to the wifi network.
#1035356#10
Date:
2023-04-03 23:46:09 UTC
From:
To:
Charles Curley <charlescurley@charlescurley.com> (2023-04-03):

No, it isn't.

That search is incomplete, you didn't even try to list the contents of
the /firmware directory, where firmware-ipw2x00_20230210-4_all.deb is
found…

    kibi@tokyo:/tmp$ sudo mount debian-testing-i386-netinst.iso /mnt
    mount: /mnt: WARNING: source write-protected, mounted read-only.

    kibi@tokyo:/tmp$ ls -l /mnt/firmware/firmware-ipw2x00_20230210-4_all.deb
    -r--r--r-- 2 root root 279224 Mar 11 22:40 /mnt/firmware/firmware-ipw2x00_20230210-4_all.deb

Everything seems to be working as intended…

It'd be helpful to have the contents of /lib/firmware (in the installer
context) at this point.

    kibi@tokyo:/tmp$ dpkg --contents /mnt/firmware/firmware-ipw2x00_20230210-4_all.deb|grep ipw2200-bss.fw
    -rw-r--r-- root/root    191154 2023-03-11 15:15 ./lib/firmware/ipw2200-bss.fw

Arguably check-missing-firmware could be more verbose about what happens
around license accepting. What do debconf exchanges look like? You can
use DEBCONF_DEBUG=developer to see them all.


Cheers,
#1035356#15
Date:
2023-04-04 05:57:34 UTC
From:
To:
Yes. The package is found but rejected because of licence issue. This is
the expected effect of "Fix files removal for non-accepted firmware
packages (#1032377)", although it might be seen by users as a regression.

Yes, at the least.
#1035356#20
Date:
2023-04-04 14:55:02 UTC
From:
To:
On Tue, 4 Apr 2023 07:57:34 +0200 Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:

I agree, it is a regression, and silently eliding over the problem is
an unacceptable way to handle it. I believe that this approach
contravenes the spirit if not the letter of the vote to include
proprietary blobs in the Debian Installer.

It used to be possible to accept the license, use the firmware, and
continue. That should now be the approach.

Agreed.
#1035356#25
Date:
2023-04-04 17:39:58 UTC
From:
To:
(Please use reply-all.)

Charles Curley <charlescurley@charlescurley.com> (2023-04-04):

Because some people fought to death for their corner case to be
supported, see debian-cd changes.

We don't present a screen for each separate component that the installer
finds.

Thanks for that confirmation.

Sigh.

I'm attaching syslog again, so that it reaches the BTS and interested
people can look at those debconf exchanges.


Cheers,
#1035356#30
Date:
2023-04-04 17:48:07 UTC
From:
To:
Charles Curley <charlescurley@charlescurley.com> (2023-04-04):

I'm not sure whether you're purposefully trying to demotivate people who
have worked a lot to make that happen; if that's the case, good job.
You're entitled to being upset because your particular use case doesn't
work or no longer works. But you're not the only Debian user. And no,
the GR doesn't say or imply we have to support each and every bit of
hardware out there.

Now, if we could concentrate on understanding and fixing the bug, that
would be nice.


Cheers,
#1035356#35
Date:
2023-04-06 17:35:03 UTC
From:
To:
Hello,

I tested too, not with firmware-ipw2x00 which was not convenient for me,
but with a custom firmware-prism54 package based on the same model.

With Contents-firmware, the license text is not shown and cannot be
accepted. syslog extract:

Without Contents-firmware, the license text is shown and can be
accepted. syslog extract:

A difference between the two relevant sections in check-missing-firmware
is that install_firmware_pkg() is executed in a pipeline when a
Contents-firmware file is present, and not when it is not present. I do
not know enough about debconf to figure out how the pipeline may
interfere with it. Maybe something to do with standard input and output ?

Full syslogs attached.
#1035356#40
Date:
2023-04-06 18:56:47 UTC
From:
To:
Pascal Hambourg <pascal@plouf.fr.eu.org> (2023-04-06):

Very useful information, thanks.

And yes, something related to pipes and possibly some missing passthrough
setting was my wild guess (as rubberducked on IRC), so that seems plausible.


Cheers,
#1035356#45
Date:
2023-04-06 23:05:37 UTC
From:
To:
Ugly attached patch works for me as PoC.
Copy fd 0 into fd 9 (because it looked unused) before entering the
pipeline, and restore it when running install_firmware_pkg.
#1035356#50
Date:
2023-04-17 14:12:53 UTC
From:
To:
Control: tags -1 patch
call outside the pipeline instead of playing with file descriptors.

PS: shouldn't this bug report be reassigned to hw-detect ?
#1035356#57
Date:
2023-04-17 15:52:54 UTC
From:
To:
Hi,

Sorry it took some time to reply to that particular bug…

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

I think I'd be happy to take this patch for bookworm, as a workaround…

… before considering a real/better fix after bookworm.

Where the bug comes from seems pretty clear by now, so feel free to
reassign, and maybe clone it so that we can track the workaround
(bookworm) and the fix (post-bookworm).


Cheers,
#1035356#62
Date:
2023-04-17 21:40:14 UTC
From:
To:
Control: reassign -1 hw-detect

Feel free to pick either patch you like. Both work for me.

To be fair, I searched if other firmware packages than firmware-ipw2x00
had a preinst script using debconf dialog which required this fix, and
the only other one I found is firmware-ivtv which is not related with
networking or storage.

I've never cloned a bug report, so I'd rather leave it to a more
experienced user.
#1035356#69
Date:
2023-05-01 18:21:22 UTC
From:
To:
Hi,

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

Let's keep -1 = #1033921 for Bookworm.

Let's use -2 post-Bookworm. Relatedly, some firmware filenames might
include spaces (why oh why), see #1029843. So we might benefit from
reworking the whole thing at some later point.

It's been a long time for me, let's see if that works. :)


Cheers,
#1035356#80
Date:
2025-01-05 17:49:41 UTC
From:
To:
Hi,

Do you want to follow up on this or was the workaround for bookworm
eventually good enough ?