- Package:
- debian-installer
- Source:
- debian-installer
- Description:
- Debian Installer documentation
- Submitter:
- Jolly Roger
- Date:
- 2026-04-23 19:35:02 UTC
- Severity:
- normal
- Tags:
The following notes a number of installer problems. I attempted to install Buster on Dell Studio XPS with debian- live-10.1.0-amd64-xfce+non-free. During install there is a notice of a need for B43 firmware. But while the firmware is supposed to be included, the installer cannot find it. Worse, when swapping out the flash drive for another with the firmware directory on it, it still cannot see it and cannot come back from the original installer drive is reinserted. Currently, the connection to the network is slow to connect. It is assumed that it is because of this reason.
06:00.0 Network controller: Broadcom Limited BCM4322 802.11a/b/g/n Wireless LAN Controller (rev 01)
[1]
Over here is this
02:00.0 Network controller: Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter (rev 01)
When I asked for the ID of the device I was aiming for
$ lspci | grep Wireless
02:00.0 Network controller: Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter (rev 01)
$ lspci -n -s 02:00.0
02:00.0 0280: 168c:0036 (rev 01)
The idea was that original poster did buy B43 hardware[2]
and found that no firmware was loaded.
A reason for not loading FW is that kernel driver has no information
that the firmware also has to be loaded for the particular ID.
Now there is
and no identification (ID) information.
Things we known
* lspci is seeing a BCM4322 network controller
Things we don't known yet
* The effect of https://packages.debian.org/stretch/firmware-b43-installer
Groeten
Geert Stappers
[1] Be aware that fellow community members are reading this.
And "this" includes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940528
Please reply below the text and remove redundant lines.
[2] Hardware that is some how supported by Linux.
Hello I recently installed Debian 11 bullseye on a laptop with BCM4312 with a non-free firmware image, and could reproduce this issue. Below you can find my installation report. TL;DR: The installer reported: failed to load B43/ucode15.fw for my wireless card. I continued the installation with the Ethernet adapter. After finishing installing Debian and rebooting I had wired network but no wireless network. Manually installing firmware-b43-installer package solved the problem. I'm not sure if debian-installer is able to automatically install firmware-b43-installer or the mechanics is designed for simpler firmware packages (the ones that include the firmware in the proper package, not downloading it on the fly as firmware-b43-installer does). Kind regards,
Hi Laura, Laura Arjona Reina <larjona@debian.org> wrote (Tue, 26 Oct 2021 10:09:17 +0200): (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. However, the new mechanism for firmware installation basically should have detected the need for that firmware, and install it via your wired connection. If you sent us the installation logs (compressed), we can try to find out, why that did not work. Another way for you to deal with this situation: if you have the required ucode15.fw firmware file handy at installation time (for example from another system), you can copy it to a removable storage (like a USB stick), and plug it in, when asked for firmware. (I assume, you got a dialog saying that such firmware file is missing, and if you have it available on a storage, right? That's right at the beginning of the installation process.) Of course, this is not the perfect solution for all users, but I have prepared a stick here, where I have firmware for my wireless-LAN module stored onto. For installation tests or the like... Holger
Hi Holger, Holger Wansing <hwansing@mailbox.org> (2021-10-26): This reply went to the list only instead of being cc'd to the bug report, submitter, etc.: https://lists.debian.org/debian-boot/2021/10/msg00095.html b43 is indeed quite specific… Cheers,
Control: block -1 by 513974
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/20210414101750.GA8414@einval.com
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.