Then there’s the mainline kernel drivers to consider.
Any one of those might have been the working driver. I’d suggest starting with a clean slate and intentionally installing only one at a time until you get some success. The issue there is, without internet access, doing that is not going to be easy.
I backed up my files, gonna install some other distro, thanks for the help. I wanted to use EOS but l can’t spend hours fixing it, I already have a working job for problems. And probably no more Arch based anything, too difficult and the often mentioned arch wiki is for technical linux users.
Thanks a ton Bink, I learned a few things today.
Arch / Endeavour do require quite a bit more hands on management, as you’ve noted. A greater onus is on the user to have a decent understanding of the workings of their system.
It’s not the option I would recommend to those who aren’t prepared or able to get their hands dirty, but that said, we can approach these things in steps. Maybe one day, after easing into Linux a bit more gradually, you might find yourself ready for something like EndeavourOS or Arch.
Best of luck with your distro hunting. You’re of course, always welcome!
Gonna give it another go, not gonna install anything else yet, it’s been a few hours only.
One question I have, is there something else I need to do other than install the package? Like do some other modprobe or some other command to start it?
I’m not really clear if Arch works just by having a package installed or if something else needs to happen.
Generally speaking, installing the package is sufficient, but in the cases of kernel module, it might then only become active after a reboot.
Where some manual intervention might be needed, is when kernel mainline drivers (drivers built into the kernel) override a driver you’ve installed, or there are multiple possible mainline drivers and its defaulting to a problem one. In these cases, one might need to blacklist the driver you don’t want loaded, and this is a possibility in your scenario too.
I ran across that cause the offline method in the arch wiki mentions it, but not the command, just a reference that sounded like they were needed for offline installations.
Spot on. Then, the broadcom-wl-dkms driver should get properly integrated. It would have never worked without those headers.
The dkms version of a driver is able to be integrated with any kernel, including more obscure ones, provided you have the headers for that kernel installed. This gives you kernel flexibility (eg: linux, linux-zen, linux-lts and the respective headers, linux-headers, linux-zen-headers, linux-lts-headers).
The non-dkms version of a driver is built only for a specific kernel, and no headers are necesarry to use it.
That looks healthier. It should have spent a bit of time there integrating that broadcom-wl-dkms driver, as part of the installation. Any joy if you reboot now?
Just rebooted, but no dice. I have to connect the wireless usb stick that does work with supplicant, cause if I systemctl stop wpa_supplicant, it doesn’t detect any wireless.
So that update removed something, but I don’t know what. the headers are there like you instructed, and the correct driver, dkms.
What else am I missing?
I also don’t have the b43 module so I don’t need to black list any module, do I? Or should the wpa_supplicant be blacklisted. (As a note, the external usb wireless card seems to need that one).