I finally gave in and did a full reinstall. I did the following:
Created a snapshot via the web interface
Copied the snapshot from the /backup directory to my local computer
Followed the instructions here and did a fresh installation (it had a few false starts but eventually worked)
Copied my backup back onto the Pi in the /backup folder
Went to the web interface and hit the refresh icon on the snapshots page (upper-right)
Selected my backup and chose restore
Waited, rebooted, etc.
After that I have a working Hassio again and was able to install Configurator and I’m pretty confident I’ll be able to upgrade next time around. I feel like ideally there should be an easier way to do a full backup/restore that can actually address disk corruption issues like this (maybe caused by unreliable SD cards?), but this got things working.
My Hassio is not accessible after update from 91.4 to 92.2, only vis SSH.
I get the same: Unknown Error, see logs
The logs looks like :core-ssh:~# hassio supervisor logs
19-05-05 09:36:41 INFO (MainThread) [hassio.api.proxy] Home Assistant WebSocket API request initialize
19-05-05 09:36:41 INFO (MainThread) [hassio.api.proxy] WebSocket access from a0d7b954_nodered
19-05-05 09:36:41 INFO (MainThread) [hassio.api.proxy] WebSocket access from a0d7b954_nodered
19-05-05 09:36:41 ERROR (MainThread) [hassio.api.proxy] Client error on WebSocket API Cannot connect to host 172.30.32.1:8123 ssl:False [Connection refused].
19-05-05 09:36:41 ERROR (MainThread) [hassio.api.proxy] Client error on WebSocket API Cannot connect to host 172.30.32.1:8123 ssl:False [Connection refused].
19-05-05 09:36:46 INFO (MainThread) [hassio.api.proxy] Home Assistant WebSocket API request initialize
19-05-05 09:36:46 INFO (MainThread) [hassio.api.proxy] Home Assistant WebSocket API request initialize
19-05-05 09:36:46 INFO (MainThread) [hassio.api.proxy] WebSocket access from a0d7b954_nodered
19-05-05 09:36:46 INFO (MainThread) [hassio.api.proxy] WebSocket access from a0d7b954_nodered
19-05-05 09:36:46 ERROR (MainThread) [hassio.api.proxy] Client error on WebSocket API Cannot connect to host 172.30.32.1:8123 ssl:False [Connection refused].
19-05-05 09:36:46 ERROR (MainThread) [hassio.api.proxy] Client error on WebSocket API Cannot connect to host 172.30.32.1:8123 ssl:False [Connection refused].
19-05-05 09:36:51 INFO (MainThread) [hassio.api.proxy] Home Assistant WebSocket API request initialize
19-05-05 09:36:51 INFO (MainThread) [hassio.api.proxy] Home Assistant WebSocket API request initialize
19-05-05 09:36:51 INFO (MainThread) [hassio.api.proxy] WebSocket access from a0d7b954_nodered
19-05-05 09:36:51 INFO (MainThread) [hassio.api.proxy] WebSocket access from a0d7b954_nodered
19-05-05 09:36:51 ERROR (MainThread) [hassio.api.proxy] Client error on WebSocket API Cannot connect to host 172.30.32.1:8123 ssl:False [Connection refused].
19-05-05 09:36:51 ERROR (MainThread) [hassio.api.proxy] Client error on WebSocket API Cannot connect to host 172.30.32.1:8123 ssl:False [Connection refused].
19-05-05 09:36:54 INFO (MainThread) [hassio.api.security] /supervisor/logs access from core_ssh
core-ssh:~#
The logs is a lot longer but repeating itself.
The “red” fails seems to do with “Client error on WebSocket API Cannot connect to host 172.30.32.1:8123 ssl:False [Connection refused].”
But I do not use the IP 172.xx.xx.xx in my setup?
I have tried to downgrade to 0.91.4 and a few in between, always with the same failure.
Are there any way I can rescue this with SSH terminal? Where did the 172.30.32.1 come from?
Whenever I get errors (occasionally) I use ssh to update:
hassio ha update – version=0.94.3
As an example. This always seems to work for my with no errors.
19-08-29 10:29:12 INFO (MainThread) [hassio.homeassistant] Update Home Assistant to version 0.98.0
19-08-29 10:29:12 INFO (SyncWorker_0) [hassio.docker.interface] Update image homeassistant/qemux86-64-homeassistant:0.97.2 to homeassistant/qemux86-64-homeassistant:0.98.0
19-08-29 10:29:12 INFO (SyncWorker_0) [hassio.docker.interface] Pull image homeassistant/qemux86-64-homeassistant tag 0.98.0.
19-08-29 10:31:00 ERROR (SyncWorker_0) [hassio.docker.interface] Can’t install homeassistant/qemux86-64-homeassistant:0.98.0 -> 404 Client Error: Not Found (“no such image: homeassistant/qemux86-64-homeassistant:0.98.0: No such image: homeassistant/qemux86-64-homeassistant:0.98.0”).
19-08-29 10:31:00 WARNING (MainThread) [hassio.homeassistant] Update Home Assistant image fails
After two previously working installations succumbed to this particular issue I went to wipe and rebuild a third time, but I have yet to have a successful install since then. In other words, I flash my SD card, add a CONFIG/network/my-network file, and plug it into my 3B+ Pi. I’m able to get it to respond to pings, so I have network, but Home Assistant never comes up.
I’ve done this now more than half dozen times, with three separate SD cards (two SanDisk 32GB Ultra Plus cards and one 64GB SanDisk Extreme Plus). About half the time I don’t get anything when I visit 192.168.1.34:8123 and the other half of the time the process hangs on “Processing Hass.io”. I waited for several hours before finally giving up and checking the logs.
Every time I plug it into a monitor and check logs it’s always readlink /mnt/data/docker/overlay2/l: invalid argument. Most of the time it’s the supervisor container, but other times it’s the actual home assistant container, which explains why sometimes I get nothing on port 8123, and sometimes I get the “Processing” page.
What could be causing this constant Docker filesystem corruption? Why is Linux able to run with no issues, but Docker is so incredibly flakey? I’m about to give up on Hass completely as I can’t even get a base install up and running.
There’s a new repair command for that particular issue, but I have no idea why you would hit it so soon on a fresh install. Are you using the HassOS based images for your board or are you installing some alternative way?
I have indeed been installing the HassOS based image. I believe the 32 bit version for the Raspberry Pi 3B+. I would use balenaEtcher to flash hassos_rpi3-2.12.img.gz onto my SD card, remove and reinsert it in order to save a CONFIG/network/my-network on there, and then took the SD card and put it into the Pi and plugged it in. I was always able to ping the device, and sometimes I got the “Processing” screen, but never a successful install.
Anyway, the good news is that I was finally able to make progress! After having tried pretty much every else before going back to Hassbian, I decided to make one last attempt by swapping out power supplies again. Although I’d tried multiple USB chargers (and successfully run on one of them for months), I went ahead and got a fast charger and plugged into that. Sure enough, my install was successful and I’m finally able to turn on/off my bathroom lights again!
I was completely stable when running Linux, no restarts or reboots like when I’ve run off an inadequate charger in the past; given this experience though, I suspect that Docker is extra sensitive to any power delivery issues. It could have just been a fluke, but if anyone else is experiencing issues with readlink /mnt/data/docker/overlay2/l: invalid argument, make sure you are using a quality 2.5A USB charger. I’ve also plugged my device into a UPS so hopefully I won’t get corrupted by a brief power outage either.
This happened to me again (3rd or 4th time?) and I limped along with sporadic freezes and reboots and no updates for several months. I broke down and ordered a fancy new “high endurance” card. The day it was to be delivered, I was tinkering and tried the update a few times and it worked. It’s been running fine ever since. I still haven’t set up the new card, but I do take regular backups when I’m making changes.
I just got caught up with this thread and will be saving this one for next time…
So, you could procrastinate and then order a new card and see what happens