SD card won't boot all of a sudden

I’ve had HA running awhile and a few days ago it crashed. I can’t boot anymore. I hooked the Pi to a monitor and watched it boot and saw a bunch of Squashfs errors.

When I mount the SD on another RPi I see the partitions and I’m guessing the hassos-kernel has a bad zImage.

My question - can I get another SD card and load it with a standard vanilla HA release, then copy in the contents of hassos-data and hassos-overlay, hopefully resulting in a bootable HA with all my old data?



I don’t have an answer to your question, but I did want to recommend something for when you set up HA again:
HA is not very friendly to SD cards. The problem is that it does a lot of writing to the database and will eventually overrun an SD card’s write limitations. Many of us have switched to SSDs with much better reliability and a faster boot time as well.

Also in future set one of these up to automate your backups off the system:

If you don’t have access to a recent backup on your SD card you can copy the entire /config folder (including hidden folders) to a new installation. This will restore everything including third party integrations but not addons. You will have to reinstall any addons used.

Thanks! Great advice. I’ve had several issues over the past few years with the SD cards.


Thanks, Tom! That’s what I was hoping for! :slight_smile:

Now, I hope I can get this fixed before my son knows the liquor cabinet isn’t protected…! :wink:


I’m probably going to jinx it, but I want to add that I’ve been running HA on the same SD card since early 2019, and no failures…yet.

As Russel points out, it’s writing to the database which will really tax your SD card. In the past few releases, the HA development team has made some dramatic improvements in the database design, and I think there are more to come. That should help.

But there’s a lot you can do right now to mitigate the problem. In configuration.yaml, manage your recorder: section closely. I have mine set to:

  purge_keep_days: 4
  commit_interval: 15

I also ruthless exclude entities from ever being recorded in the database. Others have gone farther and used the include to only allow the few they want recorded, automatically excluding the rest.

Finally, I do no automatic backups. When I change something, I’ll copy the file I changed to another system. I regularly copy the entire config folder to my NAS. I only use the HA backup function just before I do a version update, which I do about once a month. Even that is probably unnecessary, but it would make the restore a bit easier.

The reason for this is that the HA backup writes everything to the local drive, in my case the SD card. As you found out, the SD card probably won’t be available when restoring, so you need to copy it somewhere else anyway. I do have a Feature Request recommending the ability to back up directly to external storage, but I haven’t heard that it’s been considered yet. Feel free to up-vote if you think it’ll help you.

OK, really stupid question… I see 3 volumes: hassos-kernel, hassos-data, and hassos-overlay. I find a couple of mostly empty files in 2 “config” directories (and none of those files mention any of my setup). Where is the /config directory you mentioned? Is it buried in a docker instance and I can’t see it? How do I get to it?



A little off-topic, but I started to use one of these instead of an SD card with USB mode on the rpi enabled and I haven’t had an issue since. The memory/ssd controller in them are closer to a regular ssd.

Looks nice. Is an RPI4 capable of powering this one, or should it be used with a powered USB hub like must external drives? Usually, the faster the more power hungry too.

I’ve been using it for over 6 months with no hub and no issues. I use an official rpi4 power supply btw.

1 Like

OK, digging deeper it looks like I need to

  • either install Docker on my other RPI4, mount the docker image and extract /config
  • get the drive recognized on my Mac using ext4fuse and get access to the docker image, mount it and extract the /config file.

Sound about right?



Sounds about right. You may find those volumes are unreadable depending on how fried that sdcard is. Hopefully its just a corruption somewhere else. But usually when these things go bad, its down hill.

your data should be on the hassos-data partition.

Thanks, Rob. I got docker running on my other RPi4 and I found a bunch of GUID looking things in hassos-data/docker/containers. I tried to docker run , but none of them will load directly. Is there a bootstrap dockers image I should load and all the rest will just load automatically?

In the hassos-data there should just be the entire supervisor/homeassistant directory which really is your config directory. You just need to copy the entire contents to your new config on your new sd.

You should just be able to mount that partition without docker and copy the entire contents over. Then just re-add your addons.

findfs LABEL=“hassos-data”

mkdir sd
mount /dev/sdaX sd ← where the /dev/sda is what was found with findfs
ls -l sd

# findfs LABEL="hassos-data" 
# mkdir sd
# mount /dev/sda8 sd
# ls sd/supervisor/homeassistant/
cp -rp sd/supervisor/homeassistant/. <dest>

Make sure you copy the ENTIRE directory including hidden files/directories.

Thanks, but all I see in the hassos-data directory is 4 directories:

  • docker
  • logs
  • lost+found
  • supervisor

I really think the /config directory is embedded in the docker image somewhere.

Maybe we’re miscommunicating… you say “/config”, but the script you shared says /supervisor/homeassistant. Looking more carefully, I see /supervisor/homeassistant has important looking things like configuration.yaml, secrets.yaml, scenes.yaml, zigbee.db, etc. Is THAT what you mean even if it’s not called “/config”?


That is the config yes. You need to copy the contents of /supervisor/homeassistant to your new config directory. That is the config directory. Once you do that, you’ll have your old environment back minus the addons.

It isn’t. It is a mount essentially from /supervisor/homeassistant

Thanks very much, Rob! :slight_smile: :+1: