Warning: Long report. The following report documents the Devuan netinst process on a Compaq C700 laptop with missing Broadcom wireless adapter firmware. As it turns out, and as I have surmised and suggested in an earlier post, Devuan has inherited a old bug from Debian[1]; One that was never fixed; only a work around was provided, but if you are persistent enough you can find it (stumble upon it?) in the haystack that is the internet concerning this issue for this particular setup. At least it is there! This took considerable persistent effort and some help from the dng list for which I'm very grateful. (Thank you fsr). For the Initiated/Veterans, the Debian Bug can be found here: (A listing is provided at the end of this report).
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740503 The logical play-by-play account of these frustrating efforts follows (with embedded Mutterings). For those who might be annoyed by such details, you have been warned. The mutterings are directed at the software, not to any individual. I don't believe Devuan is responsible for what I believe are shortcomings. The Experience. After running the "Detect network hardware" step of the Devuan netinst, it states: "Some of your hardware needs non-free firmware files to operate. The firmware can be loaded from removable media, such as a USB stick or floppy." Muttering: Based the following experience, is it *really* the case that the firmware files are "non-free", OR, is it the case that they are simply missing? "The missing firmware files are: b43/ucode13.fw b43ucode13.fw b43-open/ucode13.fw b43-open/ucode13.fw" (sic. The names are repeated.) Does this reflect a weakness in the code? Muttering: (Speaking to the software) What's that fullpath again?? Do you not know? After all, you are the program(mer). I'm sure you know. Why not tell us. Why not now? "If you have such media available now, insert it, and continue." "Load missing firmware from removable media?" (select Yes after inserting the appropriate removable media containing the firmware file). Comment: Without going any further, at this point, from tty2, one can see that the /lib/firmware directory on the target system has not yet been created. Comment: At this point, from tty4, one can also see: "Broadcom 4311 WLAN found (core revision 13)" And: "b43-phy0 ERROR: You must go to http://wireless.kernel.org/en/users/Drivers/b43#devicefirmware and download the correct firmware for this driver version. Please read [...everything there]." And: "Broadcom 43xx driver loaded [ Features: PNLS ]" Comment: From this we know that the Broadcom B43 driver module is already loaded into the kernel. Comment: If we execute the following cmd in the tty2 terminal, we have visibility to the [pci-id/chip-id] information for the wireless adapter. (This requires esoteric knowledge on the part of the un-initiated trying to install Devuan on their (only?, not so network-connected) computer for the first time.) lspci -vnn | grep Network Which returns: (On the Compaq C700) "Broadcom Limited BCM4311 802.11b/g WLAN [14e4:4311] (rev 02)" Comment: For additional description of the wireless adapter, execute the following: lspci -vnn -d 14e4: (the colon is req'd) (more esoteric knowledge required here.) Comment: BTW, from your OTHER NETWORK-CONNECTED COMPUTER, you will find that there is no firmware to download from the URL Specified. But, after some study of that page to determine what the page is all about (Muttering: Since there is no Clear Explanation at the top as to what one might expect to gain from having read it), and with the information from the previous commands, one can use the table on that page to confirm that the B43 driver supports the 14e4:4311 chip set. (Muttering: Hooray! That's very nice to know! BTW, Getting back to the issue at hand, where did you say that firmware file is? You remember? Your know, the ucode13.fw one that you asked for?). Finding the ucode13.fw file: >From searching the web, there are so many "ways" of obtaining the file in >question that it leaves the un-initiated's head spinning: (different distros >(mostly Ubuntu), multiple releases, different platforms, etc., and over a >number of years, has created a confusing haystack on the internet. I've obtained it from several places but they are not the same length. >From much study and searching, the most common and cleanest way to get at this >file is as follows: Background: It seems that Broadcom wrote their own device driver for their chip set. Instead of releasing their device driver software and its associated firmware as open-source, they made it proprietary. Its called "wl" or "sta". Their driver is (apparently) distributable. (This must also be true of its .o components.???) That driver has been reverse engineered to produce two device drivers: B43 and B43-legacy. (Broadcom's wl driver is missing some desireable functionality). Since the firmware is embedded in their driver, a slice-and-dice program was written to "extract" the firmware files from the compiled distributable device driver, or from its .o components. That program is called b43-cutter. (It has been packaged into a .deb package.) When executed against Broadcom's files, it creates the /lib/firmware/b43 directory on the (already installed?) target machine and copies the .fw files there. (Or wherever you want to put them using the -w option.) Here is a composite procedure (Modeled somewhat after [3], and others) that I've come up with and find useful without contaminating my Refractor machine too much. This requires a second NETWORK-CONNECTED FUNCTIONAL COMPUTER. On your OTHER NETWORK-CONNECTED COMPUTER: mkdir ~./Desktop/b43offline cd ~./Desktop/b43offline mkdir ./firmware1 mkdir ./firmware2 (for experimentation) mkdir ./firmware3 (for experimentation) Download the b43-fwcutter_xxx-x_xxxx.deb package for your platform to the ~./Desktop/b43offline directory from the following page: https://packages.debian.org/jessie/b43-fwcutter Install the b43-fwcutter package: sudo dpkg -i b43-fwcutter_xxx-x_xxxx.deb EXERCISE1: (This retrieves the file used in the C700) All the .fw files are contained in Broadcom's device driver. Download the Broadcom device driver wl: http://www.lwfinger.com/b43-firmware/broadcom-wl-5.100.138.tar.bz2 Extract the Driver: tar -xjvf broadcom-wl-5.100.138.tar.bz2 The following file is now available to be sliced and diced: ./broadcom-wl-5.100.138/linux/wl_apsta.o The following cmd will now slice and dice this file and place the .fw files in the ./firmware2/b43 directory. sudo b43-fwcutter -w ./firmware1 ./broadcom-wl-5.100.138/linux/wl_apsta.o EXERCISE2: (This also retrieves the file(s) by name but they have a different length from those in EXERCISE1) All the .fw files are contained in Broadcom's device driver. Download the Broadcom device driver wl: http://mirror2.openwrt.org/sources/broadcom-wl-4.150.10.5.tar.bz2 Extract the Driver file: tar -xjvf broadcom-wl-4.150.10.5.tar.bz2 The following file is now available to be sliced and diced: broadcom-wl-4.150.10.5/driver/wl_apsta_mimo.o The following cmd will now slice and dice this file and place the .fw files in the ./firmware3/b43 directory. sudo b43-fwcutter -w ./firmware2 broadcom-wl-4.150.10.5/driver/wl_apsta_mimo.o EXERCISE3: This exercise creates the ./firmware3/b43legacy directory and its associated .fw files. (It does not obtain the necessary file(s) for the C700.) Download the following firmware-containing file to the ~./Desktop/b43offline directory: http://downloads.openwrt.org/sources/wl_apsta-3.130.20.0.o (direct download of .o) The following cmd will now slice and dice this file and place the .fw files in the ./firmware3/b43legacy directory sudo b43-fwcutter -w ./firmware3 ./wl_apsta-3.130.20.0.o Make everything universally readable: sudo chmod 755 ./firmware?/b43, etc. Comment: BTW, ucode13.fw can also be found on the Devuan Live CD. It has no problem getting to the internet when doing the install from there. After boot, it can be found in the /lib/firmware/b43 directory. I have to conclude that ucode13.fw is not a "non-free" file as stated by netinst at the point it finds it missing. I could be confused. Comment: There is even a stand-alone copy of ucode13.fw that has been uploaded to github: search for "ucode13.fw github". Muttering: All of the above is well and good. However, even though you have the file in you hot little hands, you are not home free yet. You must now go through the discover process of finding out how to feed this file to the “missing firmware module” in netinst during the install process. This has proven to be a non-trivial exercise. First of all, in a normal Linux working environment, to create the necessary "removable media", one would insert a usb drive into YOUR OTHER WORKING SYSTEM and launch gparted. You clean up the usb drive and create a filesystem to hold the firmware files. I chose file type ext4 to make sure it was Linux readable. (In retrospect, while this is normal expected behavior this is actually a mistake because of the inherited Debian bug. :( By checking its properties one can see that the USB stick is sdb1 (On my OTHER WORKING SYSTEM). You can now copy and paste the ucode13.fw to that usb drive using filemanager. You now move the usb drive over to the target system. By checking tty4 you can see that it is known as sdc1 (On the target system.). Then on tty1 press enter. After several seconds, the system comes back with the exact same missing firmware message. It did not find the file. So, what is netinst looking for, and where? Is it looking in the ?b43/ or the ?b43-open/ directories as presented by the message on tty1, (the two most likely candidates based on what is presented to the user). Does that mean that it is in the /firmware/b43 directory, or, the /firmware/b43-open, or, perhaps, the /lib/firmware/b43 or /lib/firmware/b43-open directories, or the '/' directory, or the /firmware directory of the usb drive? Nope. I tried them all. (At the same time.) It does not find the file on the USB stick. Why? Note: There is also a /firmware directory on the netinst.iso usb drive but the files in that directory are all .deb files. No .fw files there. Conclusion: Logically, either 1) netinst is looking in the wrong place, or 2) its looking for the wrong file name. So what is netinst looking for and where is it looking? [In retrospect, the filename *is* correct.] So its looking in the wrong place. Or is it? As it turns out, and as I have surmised and reported in an earlier post, netinst has inherited a old bug from Debian[1]. One that was never fixed; only a work around was provided. And if you are persistent enough, you can, in fact, stumble upon it. At the point of failure, it seems that netinst must not be looking in the right place.[2] Well..., not exactly. (See the referenced Debian Bug below.) In the case in point, as it turns out, it cannot find the file on this *Partitioned USB Device* because the file must be on, (Drum roll please!), what gparted calls a "plain floppy" device. Muttering: Who'd a Thunk That!! How Clever! How Irrestibly Clever! Ok, so how do you make a "plain floppy" device out of a USB stick? Don't look to gparted. gparted cannot create such a filesystem. When ask to create a FAT32 file system on the device, it creates a partition that starts at sector 2048, size 32MB, and calls it sdX1. But, wait, there is a command line command that will get you there: (Another bit of esoteric Knowledge.) mkfs.vfat -I /dev/sdX This will create a FAT32 file system the size of the device starting at sector 0. Muttering: Have we just now done a time warp? Are we back in the days of DOS? I suspect that what we have here is an artifact from the days of the floppy which few of us still have the hardware to read, (but I still have a couple of eight inchers should they ever make a comeback.) After having created the USB stick in this fashion, it then becomes visible to gparted. However, gparted flags such a device with the following Warning: "plain floppy: device "/dev/sdX" busy (Resource temporarily unavailable): Cannot initialize '::' mlabel: Cannot initialize drive" BTW: pmount cannot mount such a "plain floppy" device. AND: filemanager cannot paste a file to such a "plain floppy" device even though its mounted r/w. You have to use the command line 'cp' cmd to copy a file to this device. When inserted into the target system, this “plain floppy” device is seen on tty4 as sdc. (on the C700). Note: Prior to executing the "Detect network hardware" step, the mount command (from tty2) cannot mount a usb drive whether created by the mkfs.vfat command or via gparted: ~# mount /dev/sdc(or sdc1) /media/mnt mount: mounting /dev/sdc(or sdc1) on /media/mnt failed: Invalid argument. Comment: Only after the first missing file message is presented to the user, the mount command does work on a mkfs.vfat usb drive (sdc), or, on a gparted partitioned usb drive. (sdc1). If at that point the needed file is cp-ed to /lib/firmware/b43 directory on the target system and the 'Detect network hardware' step is re-executed, no manual intervention is required, (as expected). But wait. There's more: After having created such a file system on a usb stick (on the OTHER WORKING SYSTEM) and cp'ing the file (ucode13.fw) to it, then moving the USB stick over to the target system, and pressing Enter, after a few seconds it presents the user with the Same Screen as before; except that the File Name has now changed. It now says that "b0g0initvals13.fw" is missing. (This was a bit of a surprise since, at first, only one missing file was mentioned on tty1.) Success: At this point, from tty2, it can be noted that the path /lib/firmware/b43 has been created and ucode13.fw has been safely stored there. After cp-ing b0g0initvals13.fw to the "plain floppy" usb drive using the OTHER WORKING SYSTEM, moving the usb drive back to the target system, and pressing Enter again, after a few seconds it presented the Same Screen to the user as before except that it now says that "b0g0bsinitvals13.fw" is missing. Re-doing the drill to add b0g0bsinitvals13.fw to the "plain floppy" usb, and pressing Enter, The Install Process Continued Nomally. Hip Hip Hooray!!! TIME-OUT: Documenting the netinst behavior when it cannot find the required firmware: Prior to executing the 'Detect network hardware' step, mount (from tty2) cannot mount /dev/sdc1 or /dev/sdc, (my guess is that the usb adapter has not yet been initialized). After the first missing-firmware failure, mount can mount either. While netinst does not handle sdc1, if sdc, containing ALL the correct files, is inserted as requested after the FIRST 'missing firmware' message, the software is not smart enough to attempt to read any additional missing files from the same source but forces the user to cycle through the same one-at-a-time missing-file menu. TIME-OUT: Is over. Continuing... Anomoly/Concern: If the "plain floppy” sdc usb drive is 'accidentally' left plugged in when starting or restarting the netinst process, the 'Detect and mount CD-ROM' step fails with “No common CD-ROM drive was detected. You need to load additional CD-ROM drivers from removable media, such as a driver floppy. If you have such media”..., etc,etc. Muttering: Is this a feature? ;) Comment: In some circles, I suspect that all this might be called Alpha Code. Comment: I could have “solved” this problem earlier just to get the C700 “up and running” without using the work-around, but I wanted to know what was wrong with the code. And still do. So, let me see, where did I put that source code? Oh. That's right. I have to learn how to find it first. If its not written in C, I might have to learn a new language. :) The Exercise: Frustrating and Annoying. The Education: Priceless. Love the chase. Thanks to fsr and others for your help. Also, my hat is also off to: >chris.bainbri...@gmail.com -- Debian Bug report logs [1] >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740503 > >Debian Bug report logs - #740503 >Installing from debian-7.4.0-amd64-netinst.iso> > >check-missing-firmware does not work with a USB drive that >contains a partition table. >When a USB drive with a single partition >containing the firmware is inserted, it reports that the firmware was >not found. >The firmware is on partition /dev/sdc1. From the log I can >see that the function is attempting to scan drives and partitions >detected on the system, and mount them as FAT file systems. [2] (THIS LINE INSERTED.) >The problem is that it does not try the USB drive partition 1 at >/dev/sdc1. >It does try /dev/{sda sda sdc sdc sda1 sda1 sda sda sdc sdc >sda1 sda1 sda2 sda2 sda3 sda3} in that order. So it is trying to mount >/dev/sdc (the USB drive) but not /dev/sdc1 (the actual partition). > > - Workaround is to format the USB drive without a partition table, > e.g. "mkfs.vfat -I /dev/sdc" (mkfs.vfat actually expects a > partition table, -I override forces it to use the entire device) >________________________________________________________________ > >[3]https://linuxforums.org.uk/index.php?>topic=5842.msg99312;PHPSESSID=9dvkad6b107rt8io16v2m3obh3#msg99312 End of report. ___________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
