Hi everyone,
I decided to switch to a full SSD setup, not only for data (like HA offers now) but for the OS too.
I grew tired (and worried) of my SDcard frying one more time. Restoring a backup is really easy, but the problem is the names of Z-Wave devices are all messed up after, leading to a painful walk of shame in the house to identify what is where.
People facing issues with the migration of their data partition usually have either an issue of undervoltage or a problem of UAS/quirks, or like me, both. In my case, the console clearly showed undervoltage (step 7 below) and issues with writing to the disk when I don’t have an external power source for the drive (In this case, a powered USB hub). I also had a UAS mode issue (see step 9 below), which took me a while to figure out, but now, all works fine and my setup runs fully on SSD, Boot & data.
Since it’s not as straightforward as it can seem, here is a quick recap on how I did it:
- [STEP 1] Backup your existing setup. Careful here, the Zwave namespace might not survive the backup/restore, I highly encourage you to note down the node number and the name you gave them to be able to restore them by hand at the end of the process.
- [STEP 2] Use the Raspberry Pi imager to burn a basic SDcard to switch to USB boot (instead of Sdcard by default in the bios) and burn the SDcard using the image located in “misc utility image” → “boot loader” → “USB boot”
- [STEP 3] Boot your Pi using this SDcard, wait for a minute (there is a green screen if you have any plugged in) and power off. (just need to be done once)
- [STEP 4] To avoid your Pi getting itself into the infamous “low voltage” inferno, the trick is to use a power bloc with a fast charger port and plug your Pi on it. I use this one and plugged the pi on the orange port.
- [STEP 5] Add an M2 based drive (less consumption?) in a form factor that has a single USB 3 plug (here an intenso 512 Go but a 128 should do)
- [STEP 6] IMPORTANT To avoid voltage dropping due to the SSD drive consumption, add a basic, yet externally powered, USB3 hub, plug the drive on it, and the hub to the Pi. Something like this should do, probably any as long as they are self-powered and not drawing current from the Pi.
- [STEP 7] Flash your SSD drive with a recent image of HA (I used the one from HA directly, but the raspberry pi imager is providing one as well)
- [STEP 8] Boot on your new disk & restore your backup by going to the classical 1st boot interface, fill in whatever, go to the supervisor (now migrated in the configuration section), click the three dots in the upper right corner and upload your backup. This method seems more reliable than the one consisting to restore from the onboarding screen directly. Up to you.
Enjoy a home assistant running without any sdcard, with both boot & data on an SSD drive. I only tested this method on a Rpi4, my blind guess is that the steps and roadblocks for a Rpi3 or 2 may vary, but the UAS problem could be consistent across different versions of the Pi.
Big up to the amazing team behind Home assistant, colossal work!
PS: I don’t know if there is a way to totally deactivate the UAS mode during kernel boot, but that could be a good thing to do in the raspi HA image by default, because it doesn’t bring much in the context, but headache.
PPS: I finally got rid of the USB hub, plugged the SSD directly to one of the USB3 ports (the other one being used by the Aeotec Z-wave stick), and all works perfectly well since the power supply does provide ample enough power.
Caveheat: OPTIONAL [EDIT 15/03/24, this is far less likely to happen since @sairon maintains a list of disk posing this problem directly in the OS image.] Yet if you still are facing an issue with your SSD, here is a walkthrough:
Some USB SSD / Hub combinations will run in the problem of the “UAS mode”. Long story short, your USB SSD drive is detected as capable of using UAS mode but cannot due to certain combinations of hardware (hub model, disk model/type, Rpi model, etc.). So it just cannot use UAS mode over USB, leading to errors. Typically, on the console, you will see messages like this:
. . . [sda] tag#27 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
. . . [sda] tag#27 CDB: opcode=0x28 28 00 00 03 b0 3a 00 00 b0 00
or similar or your squashfs complaining, errors writing to disk, etc.
If you are in this case, you then need to mount your drive on another Linux machine, run a lsusb and note down your SSD drive USB bus address.
Bus 001 Device 002: ID 8087:8000 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 152d:0579 JMicron [...] Portable SSD
Bus 002 Device 005: ID 0525:a4a7 Netchip Technology, Inc. Linux-USB Serial Gadget
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Here the SSD drive is the “152d:0579” device. Mount the 1st partition of your USB drive somewhere on your Linux machine using something like:
(adapt where need be)
mount /dev/sdb1 /mnt/usb
Edit your cmdline.txt file, adding the specific USB storage quirks parameter to the existing ones:
usb-storage.quirks="152d:0579:u" dwc_otg.lpm_enable=0 console=tty1
(replace “152d:0579” by your SSD address on your USB bus as seen with the lsusb command line)
Hope this helps.
(My other posts: Integrate any remote to HA, Run HA boot+data on SSD with a PI, False positive proof security system, Advanced solar panel monitoring)
