Wish I had read this before. I installed 12.4 fresh and tried to restore my backup from 2 days ago.
When restoring my influxdb setup, which the main thing I want, the restore process is crashing with
“Not a gzipped file (b’\xa7d’)”
But there is no problem with the tar.gz file, so just another bug or smth
Jeez why did I tried the upgrade to 13.1 
Oh no. I feel your pain. 
Do them once a year or something, not worth the hassle most of the time. backups are only good for the config. Dont hope it will actually save data like temps, humidity, etc
I do use influxdb to save metrics from my solar PV system which I really want to restore. I need to figure out if there is a way to manually restore the influxdb database. Files are good in the tar.gz not sure why supervisor is not restoring correctly.
Does anyone know if it’s possible to restore manually?
Well opened a bug in the supervisor repo Can't restore influxdb partial backup due to "Not a gzipped file (b'\xa7d')" error · Issue #5266 · home-assistant/supervisor · GitHub
Hopefully anyone addresses it.
Thought it could be due to the amount of ram the rpi3B has, that was having issues decompressing the 2GB file with Python’s tarfile code, but I was able to run a python script using tarfile in the rpi3 and it successfully extracted the contents
I am going to say this but I doubt I am right? I do update to every new release but both in terms of Rpi hardware and HA software.
This is mostly because development moves forward. Now having said that my HA is running well on a 4GB Pi4 until my Pi5 arrives later this week. Then I will migrate.
Please understand that I just see the two working hand in hand!
My Pi3 also went into reboot mode! Your tip (ha os boot-slot other) saved me many hours! Thank you very much!
I simply don’t understand why HAOS 13.1 hasn’t been taken down; the update ruins many installations!
I think the culprit might just be the lack of resources the pi3 has. I even had the thermal warning show up when booting the cli on 13.1
Upgraded fine on my NUC that is running ESXi 7.0. I always make sure to uncouple the PCI passthrough of the iGPU to Frigate and disable start at boot for frigate before updates so I can do a vmware snapshot. Makes botched OS updates that much easier to revert 
I am on the beta channel, I had this same type of bug upgrading to the 13.1 release candidate, and reported it. Went back and forth a bit with the developer but didn’t find the cause. Before I had a chance to find it, 13.1 proper was released, which did not show the same behavior. I saw this in a VM installation, if you are seeing it in a bare metal PI installation it’s probably something deeper. 13.1 rc1 will not load · Issue #3545 · home-assistant/operating-system · GitHub is my issue. You might want to open another one and reference this.
[quote=“weehuddy, post:10, topic:762530, full:true”] backups are only good for the config. Dont hope it will actually save data like temps, humidity, etc
[/quote]
I wonder what makes you say that? My backups contain all the data for as far as it was available at the time of backup.
I do not think the update is at fault here, but rather the lacking hardware resources of the RPi3.
Nearly all the posts are from RPi3 users and RPi3 is mentioned with a warning in the installation docs, about it being at limits.
From now on RPi3 users might have to reduce their resource usage before each update, because each update can include more services and check running.
It is just a fact evolution in the IT world that things grow over time.
I’m on a 2gb pi4 and I’m hitting this - people with 4gb pi4’s also report it. And yet many others work. It’s a strange one.
I don’t think that’s correct, as several Pi4 users also have the problem.
Moreover, it’s not acceptable that supported hardware can simply become unusable after an update, without any prior warning. I’m just a user of HA and have no idea what could cause it to fail in this way. I think many people might be discouraged from using this fantastic system when something like this happens.
After updating to HA OS 3.1 yesterday, my Pi3 started rebooting constantly. I used your tip about using the old boot slot with the command “ha os boot-slot other”
This worked fine, and I was able to use my HA again, and the version number was back to 3.0.
Today, I restarted HA OS, and now it has started rebooting again, and this time it’s running 3.0. Have you tried restarting, and do you have any idea what I can do to get my installation working again?
Yeah, if a Pi4 with 2gb of ram is hitting this, there’s more to it than just the lack of resources
The RPi4 with low memory might also see this issue.
And it happens all the time in the world of IT.
You might get a RPi3 to run, but the after the update the OS require more resources, so you need to discard some of your integrations/addons to free some up.
This happens for Windows, MacOS, Linux and any other software that are kept up-to-date or evolve to new versions.
Just an update from my end, I tried removing my ‘Zigbee CC2531’ from the USB port and then started HA OS 13.0. HA OS started up without any issues, and everything except my ZigBee devices worked as it should. I then tried plugging the ‘Zigbee CC2531’ dongle back in while the system was on, and shortly after, all my devices came ‘Online’ and everything seems to be working again! It seems like HA OS 3.x can’t fully boot up and starts rebooting when the dongle is plugged in. This has never been a problem in the last 2-3 years. There must be a bug somewhere in 3.x…
I don’t think this is due to a lack of resources from the Pi3.
