(Raspberri Pi 4) 9 steps howto get both HASSIO boot & data run over an SSD

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] IMPORTANT A lot of 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)

  • [STEP 9] 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 don’t know if this method will be resisting OS upgrade though. So you may have to patch the cmdline.txt again after an OS upgrade. But after a full backup restores and a HA core upgrade, my cmdline.txt still shows the patched version, so I faced no issue so far. 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.

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)

2 Likes

Do you feel any speed performance increase with the ssd setup? Ex. Lights turn on quicker when motion sensor is trigger?

2 Likes

overall the system is more reactive yes. I haven’t tested the specific scenario you describe, but yes, the OS is faster across the board.

1 Like

Thanks for your elaborate explanation and suggestions. let me add some more.
I had a good running HA installation on my SD card, and what I did in step 7 was to use Balena Etcher and make a clone of the SD to the SSD. imho you avoid the Zwave namespace issues because your new environment is really a clone from the old one.
Unfortunately I ran into the same under voltage problem with the Intenso 128G SSD. Only running it via a powered USB (2.0) hub which I had lying around made the Pi boot from the SSD.
Last but not least the system is much more responsive. maybe not the automations but the UI is.

there is however one drawback to the cloning of SD to SSD image.
HA starts complaining (configuration >> Add-Ons >> System) that I am running an unsupported installation and that my installation is unhealthy.

I tried to upgrade the host. well that was bad luck. I get a ping reply from the Pi so there is something running but not HA.
so back again to cloning the SD card to the SSD. and now I updated HA core to 2022.3.3
that went well. so I don’t know what is blocking the HAos from 7.3 to 7.4 and what I am missing if I keep on running on 7.3.
I have not seen the supervisor warnings since the core upgrade.

2 Likes

Besides my other contribution in this thread about copying a image from an SD card to an SSD I made a interesting observation.
I wrote a standard raspbian os (bulleye) to my Intenso SSD and hooked it up to one of the USB3 ports of my RPi 4b (brand new). Yes I ran the bootloader program first.
Normally I run Pi’s headless but this time I chose to hook it up to a monitor and keyboard. I wanted to see what was happening and what I could change on @kameo4242’s plan. well I saw a lot of things coming by on my screen but in the end I did not get a running system which was to be expected…
Then I changed the SSD to one of the USB2 ports and rebooted the Pi.
I got all kind of sensible data on my screen of subprocesses running and ending OK. And I got a running and responsive bulleye at my disposal.
So although I will not get my optimal speed on the USB2 port I prefer that over conecting the SSD via a powered USB3 hub (more cabling, more power converters etc). Besides that I am not running into the UAS problem that @kameo4242 descibed above.
Next I changed the SSD on my Pi which is running HA also to the USB2 port and rebooted it connected to KVM. it booted without problems and 1 undervoltage warning.
I tweaked the powersupply to the Pi a little to 5.08V and after that no more undervoltage warning.

My Pi’s are mounted on a DinRplate and I piggy backed the SSD on the backside of the DinRplate (they have exactly the same size) and put it back on the DinRail. looks neat.

So my observation, if you want to run you HA system on an SSD do the following:

  1. buy an SSD (I used the Intenso 128G)
  2. copy your running HA setup from your SD card to the SSD with Balena Etcher
  3. run the bootloader program from the Rasberry Pi Imager on you Pi (step 2 and 3 form @kameo4242 's description)
  4. Connect the SSD to one of the USB2 ports and power it up.
  5. wait long enough to let the system do all kind of chores e.g. resizing the sda2 partition.

you have a good chance to get a fully functional HA system running from the SSD and being much more responsive than it was running from the SDcard.

Hey, thanks a lot for your writing here, helped me a lot to gain some confidence for my impending move from SD to SSD on my Pi3. One question about the Balena Etcher line in your how2: I understand it as “shutdown the PI, take out the SD card, put it into an SD reader on my PC/laptop, also connect SSD to PC/laptop, use Balena to clone SD to SSD”. Did I get that right?

A bit nervous to be honest, I don’t have a spare Pi laying around, so I don’t want to “burn” the one I have, and I was hoping to do the cloning completely separate from the Pi.

1 Like

If you have a supported SSD adapter there is nothing to worry about. Why not just upload HaOS to the SSD and then use the HA backup from the SD card?
Don’t forget to update Rpi4 bootloader

I’ve got one specifically for the Pi (%product-title% kaufen), so I’m optimistic about that one. It explicitely mentiones the Pi3, so I should be okay. I do need to update to USB boot thought still on the Pi.

About the backup: I did read various threads were people were having issues with a broken sqlite db file from the backup, and I definitely want to keep the stats, especially around energy usage and environment data. Therefore I was hoping to go with a cloned approach.

I thought you had an Rpi4. Rpi3 does not have a boothloader (separate eprom). If you do a clean HaOS system on the SSD and use a backup you can always go back to the SD card if something goes wrong.
You never know if something will go wrong even with cloning.

Fair point about the clean install, maybe I’ll just give it a try indeed.

About booting: was planning to “upgrade” the OTP via the method described in https://www.instructables.com/Booting-Raspberry-Pi-3-B-With-a-USB-Drive/

In the end the result should be the same.

I went in the end for the ‘standard’ data migration, just moving the datadisk to SSD, and keeping the SD card for the OS, as that is written to way less often anyway. I ran into an SSD issue so far not mentioned.
I initially connected my SSD to the USB 3.0 ports, as that seemed to work well. The migration went all smooth by itself (so HASSIO can mount it properly and transfer all data). But when finished, it rebooted and then it could not load the HA Core and other elements and data. So mounting via an USB 3.0 port works, writing to it as well, but after that, the migration processes was frozen.
The ‘solution’ was to unplug the SSD and connect it to an USB 2.0 port. After that, everything worked as before, except that the interface is a lot faster, and the automations seem to respond faster too.

I have a question about your comment to “use your backup” from your SD Card, I assume you are talking about the link at the bottom of the onboarding screen that lets you restore from a previous backup? The question then is, how to you access that backup, or how do you copy it to the new drive to access it there. These directories are not easily accessed from outside HA.

I would probably just download it from the old system after you make it, which is generally what I do with my full backups anyway.

That would require you to have at least SAMBA installed on the new system (which means you’re into onboarding) or use SSH to copy the files, assuming you have access to those directories. I’m just trying to determine if anybody has done it and what the process was. The “how” to get the backup files on the new disk to restore it is the missing part for me. Still trying to sort that out. This is on HAOS btw.

Hi GrizzlyAK, I actually use the google drive backup plugin.
So 1st thing I did is to reinstall the plugin and restore my HA using it if I recall properly.

You can just upload it from your browser in the dialog after clicking on “restore” on the new instal, assuming you downloadeed the file from your old system to your laptop before.

1 Like

Now that’s the kind of response I was looking for! Thanks Lakini! :grin:

Technically @daywalker03 's answer already gave the clue before mine, so the credit goes to him as well :slight_smile:

1 Like