Hi, Diederik de Haas <didi.deb...@cknow.org> (2023-05-04): > On Thursday, 4 May 2023 00:21:25 CEST James Addison wrote: > > I added a note[1] on the rpi4-uefi.dev GitHub repository, and from > > one of your fellow contributors' responses, it seems that in fact > > the filename-with-spaces format _is_ referenced from > > linux-firmware.git, in a 'WHENCE' file that is used to create > > symlinks (I hadn't been aware of that previously). > > And that makes it a firmware-brcm80211 issue and now it all does make > sense as it now all does tie together :-)
Great, that's what it looked like to me but I was afraid I could have misunderstood the situation and I didn't want to digress in a wrong direction… > So while upstream does define the link from what I earlier called > 'weird' name to brcmfmac43455-sdio.raspberrypi,4-model-b.txt, the Debian > firmware-brcm80211 package does not define that link and is therefor > missing. Adding the links will at least make those paths shows up in the Contents-firmware indices generated by debian-cd. Those contain 3 “columns”: path, package, component (the current format string is "%-55s %s %s\n"). Even if hw-detect didn't misbehave because of spaces in filenames (i.e. the way the list of missing files is constructed, which I've been assuming is one of the main issue here, but I didn't dive into it because that's not getting rewritten for Bookworm anyway)… it wouldn't be able to perform the required lookup, given how it extracts those “columns” from those indices. (Looking at regular Contents file again, I see there's nothing done specifically — like some kind of escaping — for paths like “/etc/testssl/DST Root CA X3.txt” in the testssl.sh package; so I guess it wouldn't be crazy to just change nothing in debian-cd, and have hw-detect deal with spotting package and component at the end of the line, reading the whole beginning as a path; of course, if someone goes as far as including spaces at the end of some firmware filename, we'll have to just change the format… Cc-ing debian-cd@ for information.) Anyway, you know how stupidly pragmatic I can be… For Bookworm, given we expect the firmware package to be adjusted to include those symlinks, what if hw-detect had some little cheatsheet, turning the space-powered filenames into their normal counterparts right off the bat (while going through the dmesg lines), so that hw-detect would: - not split those into smaller parts, therefore building a list of paths correctly; - additionally succeed in performing the firmware file to firmware package (and component) lookup; - deploy the relevant firmware package; … while the linux kernel would ultimately request the space-powered filenames again, this time finding the symlinks that the updated package would ship, being happy, no longer complaining, and hw-detect would give a green light and carry on. Embedding a little symlinks → files mapping for one single package, that's really not expected to change too much this close to the release… looks like (1) a very ugly kludge, granted; but also (2) a very small price to pay to get immediate support for that particular way of booting Pi devices, without waiting on any major, post-release rewrite. If that looks fine to you, feel free to clone this against hw-detect with the symlinks → files mapping. Cc-ing debian-boot@ for information as well. Cheers, -- Cyril Brulebois (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
