I got back to the office and hooked things back up and lo and behold, the error is back! I fiddle with stuff and it turns out that if I replace the Apple keyboard with a Logitech keyboard, the SSD works again. Odd that a device on the USB 2.0 controller causes an issue on the the USB 3.0 controller. But I am not a Electrical Engineer, so who knows. And I have used this keyboard on this same RPi4 since I began working with them, very weird.
Edit: Then I remembered that I loaned out the USB extension cable that comes with the keyboard. I hunt down a replacement and hook it up… and now the RPI4 will boot with both the Apple keyboard and the SSD once again.
As I mentioned above I was holding back the latest 2 raspberrypi-bootloader packages as it broke bluetooth. I told them and they responded with a confusing answer which took me a couple of days to figure out what they meant and at the same time I was having to put out some other fires:
“The only change vaguely UART-related - at least on the firmware side - in the last week or so is the removal of the code that automatically converts an old cmdline.txt reference to ttyAMA0 to ttyS0 in the event that ttyS0 is the primary (console) UART. All new images for years have used “serial0” as an alias, and now all cmdline.txts have to either do the same or get it write and use ttyS0.”
Long story short I tried several combinations with cmdline.txt and the attach-bluetooth service. arch-arm uses ttyAMA0 in the /boot/cmdline.txt file and this has to be changed in 2 places in the file to have bluetooth:
The latest 2 raspberry-pi bootloader files has been pushed to the unstable branch when the mirrors sync. Be sure to make the 2 adjustments above in /boot/cmdline.txt to have bluetooth.
Oh, so not making the edits causes a similar looking issue. Good to know, because you know I will forget to edit also. And I would have tried to “fix it”, convinced I had the same issue again.
I got home and booted my unstable image, and it was minus the wifi device. I rolled back the linux-firmware and wifi was restored. Then reinstaleld the new linux-firmware, rebooted and wifi device was gone again. Rolled back again and the wifi device was back. So currently I am running on the previous version as I need wifi.
Not sure why I just now noticed this. Maybe I forgot to reboot after the update last night? Sorry I did not find this sooner.
That is my exact roll-back command. There is no reference to wlan0 in dmesg or journalctl -b with the new linux-firmware installed.
I just found that dracut is indeed passing a kernel command line, and it is my old one. So I am investigating that. But I don’t think the cmdline.txt changes has any effect on the wifi.
The new firmware-raspberrypi is supposed to fix a dis-connect issue with the pi4 wifi but the problem is it’s new files are in usr/lib/firmware/updates/brcm compounded by linux-firmware packages puts it’s files in /usr/lib/firmware/brcm which also has firmware for the pi4 wifi which would normally not be an issue because linux is supposed to look first in /usr/lib/firmware/updates first.
The kicker is it is hard coded to the /usr/lib/firmware/brcm directory for it to look for the firmware to load so it will never see the latest firmware and lately the linux-firmware package is providing outdated and in this case now looking like bad firmware for the pi wifi.
I can not dump the firmware-raspberrypi package in /usr/lib/firmware/brcm as it will refuse saying the files exist belonging to linux-firmware.
