Control: block -1 by 513974 On Tue, 2021-10-26 at 22:03 +0200, Cyril Brulebois wrote: > Holger Wansing <[email protected]> (2021-10-26): > > The bullseye amd64 netinst iso does not include this particular package. > > (Don't know why. I did not manage to understand the logic behind the > > selection, which packages get included in the firmware-containing isos.) > > So, installing it 'offline' from the netinst iso is not possible. > b43 is indeed quite specific…
The reason for this weird state of affairs is that Broadcom's official b43 firmware is effectively non-redistributable, thus we can't even have it in non-free-firmware: https://fedoraproject.org/wiki/Firmware#List_of_firmware_which_we_can_NOT_package It is not in the linux-firmware upstream repository either. This chipset in particular is notorious for this limitation: https://lists.debian.org/msgid-search/[email protected] The workaround that most distros have adopted is to use a package like our firmware-b43-installer, in contrib, which downloads a version of Broadcom's proprietary driver from a permissible source and the firmware (only part we need) is extracted from it. This approach cannot be useful to provide connectivity within the Debian Installer. Now, there is a plot twist: a clean-room reverse-engineering effort brings us OpenFWWF, a free and functional (even if experimental) libre replacement! However, it's not packaged in Debian (WNPP #513974) and concerns have been raised there about whether packaging it is worthwhile at this point. Even if it weren't included in Debian otherwise, having OpenFWWF available while running the Debian Installer could, hypothetically, provide connectivity good enough to utilize firmware-b43-installer and ensure that's installed on the final system. Thus the subject line ("b43 firmware not found or installed") really describes two different issues: • if network connectivity is available in any fashion whatsoever during the installation run, even if using a different NIC, Debian Installer could cause firmware-b43-installer to be installed into the final system. When its postinst is run inside d-i, it'll unpack the firmware and put it in the right place for the first boot. • as for having b43 firmware *during* the installation when one wouldn't otherwise have any internet access, OpenFWWF is the only conceivable solution. It need not be used in the final system if Broadcom's proprietary bits remain the go-to solution; merely having it in the installer itself for the installation run (or even if just to bootstrap a connection long enough for b43-installer to work), could break this circular problem I'm setting OpenFWWF's RFP bug as blocking this one because it would make solving this issue a lot easier.
signature.asc
Description: This is a digitally signed message part
