Is anyone able to use CC2531 stick after switching to SSD?
As I already wrote above, if you’re using USB3 this might cause heavy interference on the 2.4Ghz band, and Zigbee happens to be in that range 
How can USB create interferences - when using an USB extension cable to plug in the ZigBee stick not directly to the Pi‘s USB ports instead a bit away, this should be fine I think.
Just an update on this issue.
It seems updating to 5.8 also messes with the bootloader.
The Devs have since addressed this, as 5.9 onwards no longer updates the EEPROM firmware.
Applying the below fix, then burning 5.10 (latest stable) to my SSD has fixed this. After a snapshot restore I’m back up and running.
EDIT: Link added. here
1 Like
Linked the paper, didn’t know about that either.
Yes, moving the stick away from the SSD/adapter might help. As mentioned in my case it rendered my wireless keyboard/mouse and 2.4Ghz Wifi useless.
“Applying the below fix, then burning 5.10 (latest stable) to my SSD has fixed this.”?
What did you do to get it working?
I have it working using the recommended adapter and a 240GB Kingston SATA SSD but only on USB2 ports. When I connect to USB3 it seems to not be able to access the hassos-overlay and hassos-data partitions. For reference I’m using this adapter
along with a Raspberry Pi 4 with 8GB. It still works great but I’d like to get it working on USB3.
Thanks.
I have the same adapter with a Samsung 860 EVO 500GB and I had 5.2 booted from USB3. Tried to update and I think it changed my eeprom when I updated. Trying to get 5.10 booted now.
I’m running 5.10. Maybe that has something to do with it. Let me know if you have the same issue.
I’ve tried 4 times now on USB3 and USB3 and I get to this point and it never shows up on my network. What eeprom version do you have? Just curious.
I’m not sure how to get the version now without popping the Raspberry OS SD card back in, but it was from Dec 2020. I literally upgraded from an SD card this afternoon. I get to that point as well, but with a bunch of errors on boot. Then if I log in with root, I get an error about not being able to mount hassio-data and its loading emergency console or something like that.
Well, plugged my keyboard in and logged in as root and got this. I am on USB2. That’s more than I got the last time. Now I’ve got to figure out how to enter my network settings from here.
When I had 5.2 running on USB3 I had followed this guide https://www.jeffgeerling.com/blog/2020/im-booting-my-raspberry-pi-4-usb-ssd which had my bootloader version at the version below. I am now on the latest bootloader version which will only boot on USB2 for me.
pi@raspberrypi:~ $ vcgencmd bootloader_version
Jul 16 2020 16:15:46
version 45291ce619884192a6622bef8948fb5151c2b456 (release)
timestamp 1594912546
Back up and running. SSD is on USB2, will not boot on USB3. I was able to restore a snapshot to get back to where I was before trying to update from 5.2 to 5.9.
Although it is on USB2 it seems a lot snappier than my RPI running on an SDcard. Reboots average under 30 seconds.
With all the problems mentioned by several users here I want to quickly compile some facts here. Will include them in the guide later:
-
HA OS versions 5.0 to 5.5 did NOT change the boot EEPROM
-
HA OS versions 5.6 to 5.8 DO change the boot EEPROM to version 2020-10-28 - BETA. This was beta but considered the better solution for many users because it solves reboot hangs for many drives.
-
HA OS versions since 5.9 do NOT change the boot EEPROM any more to give back control to the user.
-
There is a new stable boot EEPROM version available (currently 2020-12-11) but even in the RPi GitHub repo there are plenty of issue reports. So I suggest that if you found an EEPROM version that is working for you, you do NOT upgrade at this time.
-
All in all it seems recommendable right now to manually try several stable boot EEPROM versions and avoid HA OS versions 5.6 to 5.8 because they will overwrite the EEPROM on their own.
-
There seem to be problems with some adapter chip sets when switching to UAS (USB Attached SCSI, UAS or UASP) during Linux system startup. But I still have to gather information about that.
-
RPi4 with 1, 2, 4 GB behave slightly different from 8 GB on a reboot. All do a USB power off but the 8 GB version does it much longer. If your Pi with up to 4GB hangs on reboot try to really power off/on the system.
-
Make sure your RPi power supply is sufficient to power both your Pi AND your SSD. Better use the original RPi4 power supply with 3 Ampere output.
-
USB3 signal frequencies may interfere heavily with WLAN, Zigbee, ZWave, Bluetooth, enOcean. Use a male-female USB adapter cable to get your radio sticks away from the Pi. Connect your sticks to USB2 not 3.
4 Likes
There is still something else for me. Mine had no issues when I changed from sd to ssd using the method above to upgraade the eeprom. When the os upgraded to not sure but I believe 5.8 (it could have been before) my issues started. If I down grade to 5.2 I have no issues. Did the eeprom get changed on the down grade? I don’t believe so. I tried to upgraade from 5.2 to 5.10. My Home Assistant froze after 5 hours. I believe something has changed in the os that is causing my issue.
FYI - after more then 2 weeks running OS 5.8 I have today upgraded to 5.9 via Supervisor and after that rebooted the server. All went well with no issues and all together took less then 15 minutes.
Sorry Dmoses, seems I didn’t include the link.
Here it is and hope it helps.
https://github.com/home-assistant/operating-system/issues/1045#issuecomment-754168551
1 Like
I had the exact same issue tfili. It seems there are some revised, perhaps counterfeit, Eluteng adapters in circulation. I moved over to a Kingspec SSD and the problem went away. See here.
Hope it helps you.
1 Like
I’m reading in some threads that Esphome is not compiling when using the 64 bit version, can someone confirm this ? I hope not because this will be a dealbreaker for me.