Building for 5.2.0-0.bpo.2-amd64
Building initial module for 5.2.0-0.bpo.2-amd64
Error! Bad return status for module build on kernel: 5.2.0-0.bpo.2-amd64 (x86_64)
Consult /var/lib/dkms/broadcom-sta/6.30.223.271/build/make.log for more information.
dpkg: error processing package broadcom-sta-dkms (--configure):
installed broadcom-sta-dkms package post-installation script subprocess returned error exit status 10
Errors were encountered while processing:
broadcom-sta-dkms
E: Sub-process /usr/bin/dpkg returned an error code (1)
~ ❯❯❯ 100
I noticed the same and tried out a lot of things to no avail.
This included reconfiguring the firmware with: "dpkg-reconfigure firmware-b43-installer"
In the end I left it for what it was ...... and my broadcom simply works, despite those kernel errors. Actually it looks to be more stable/better than before albeit a tad slower..
those drivers are sometimes updated, the question is: does it makes your system broken? (like broken-status of the packages)?
if yes, we will need a way to fix this (holding those -dkms package to never update maybe)
Since all those packages are related to only the broadcom B43* drivers, I wonder if should be wiser to just remove them from the installations for those who don't need them (but in case that they plugs a B43 wifi usb stick, will not work on the fly)
I think it has to do with backwards compatibility using legacy kernels....but I'm not sure.
You could try ....... but apparently no one is having real problems excepting the error messages from dpkg.
but not with 5.4 kernel (which i think is going to be used for the next build)
the thing is that some people -may- require this "wl" driver for some broadcom 43xx devices to work
and the question is: is better to use an updated kernel without it (so that it supports more hardware) or to have a little older kenrel with including this driver for those broadcom cards?
Actually there are, and always has been, some issues with Debian/Ubuntu and certain Broadcom wlan models. If you can not get yours - after a regular installation - to run, you are probably effected. Alas.
There are several ways to solve it, but after many investigations from my side (because I was many times effected... [brmsmac]...) I found that the most reliable way is = check your hardware installed by yourself - from the terminal: $ lspci -nn -d 14e4:
Read the output well and find your model; eg: 03:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM43224 802.11a/b/g/n [14e4:4353] (rev 01)
or similar. In this example it is: BCM43224
With this knowledge you can find out now, which one is the right driver - here:
After you did identify your card with the correct driver in this list -
use synaptic to search and install the driver.
.
.
In the example above it is a bit more delicious, because
(reading the list reverse:)
BCM43224 = Driver: brcmfmac ; = Driver family: brcm80211 and ... "Non free firmware required": Yes
Means: Probably you will not find this particular driver with synaptic.
In this case the brcm80211 package needs to be installed (into the kernel):
$ apt install initramfs-tools
then jump to (here in this example I do need the driver for Debian Buster) Debian -- Package Download Selection -- firmware-brcm80211_20190114-2_all.deb
choose a mirror from the list and download the file
firmware-brcm80211_20190114-2_all.deb
install it (usually a double-click on the file is doing the job)
making sure all is well placed and working ; restart your machine.
Well, Elive includes actually a smart "loader of b43 driver" (please try it if you have this hardware ), which basically does:
if a b43xx device is detected, load all the available drivers one to one, check if it mades the wireless device to work (show), if not, try the next one, loop... if the full loop fails, try the same loading extra firmwares, if the loop fails, try again with some special "hacks" by loading them... etc, basically it stops when the wireless device appears working, a pretty smart tool that makes a good % of b43 devices to work
But specifically talking, the "wl" driver (broadcom-sta* packages) is only one of them (around 5 actually), and a pretty good candidate in fact, so the problem is that by building the iso with the 5.4 kernel, the wl driver cannot be included (doesn't compile)
Well I know macbooks (and they could be recognized as such during an install) are notorious B43 machines but actually wondering if there are stil that many USB versions around.
How often would that be a problem, for it to have this non-free binary blob contaminating the kernel? Maybe just leave it out until it gets fixed for 5.4 (and later) ?
Never mind .... I just discovered that the source of said broadcom-sta-dkms package was added which allows for succesful compilation.
as said before, the updated pacakges compiles correctly in our actual kernel
but i wanted to release with a 5.4 kernel, and this driver doesn't compile with this one (so it needs to be removed or downgrade kernel, which also means less hardware support )
just as "By the way"...
actually it is kinda tricky with specific MacBooks and therefore iMacs (!), too (those got identified as "NoteBook", which is also not wrong, because an iMac is in fact a MacBook just transformed into a Desktop computer)
The issue is here - that 2 different b43 drivers are loaded during startup,
and so many times 1 of them needs to be blacklisted in the conf file(s)...
But which one is the right one ....
This phenomena occurs especially, if the effected machine is used as dual- boot (macOS & Linux). Funny thing is:
When you are close to pull off your hair - just shut down (!) the machine from the Linux environment and boot into macOS, reboot (!) into the Linux environment - and everything works out of the box - like as it would never ever had any issues...
Am still at this point with certain models from before 2012...
(and so what!)
.
Indeed, most of it.
Still Debian is not the best friend of contrib-non-free .....
yeah, that's exactly what the (auto) tool provided in elive works , unless its bugged or very specific cases (if someone has a b43 not working, please report)
where if im not wrong, in each "attempt loop", it unloads all the b43 modules and try just a single one, if works, it adds all the other ones in the blacklist, this makes the wifi work on that moment and also in each reboot (unless as I said, its not working on the expected way, so i don't even have a single b43 hardware to test with lol, and like you said, there's many different ones that requires a different conf)
In the example above it is a bit more delicious, because
), which basically does:
work this 
distro 
