No GUI after reboot and update

[dampsquid (Bob P)]

I have a problem, I can’t reach the HA GUI. This is after a power outage. A recent update may be a factor too.

HA has been up and running for a long time, lots of config done. A couple of days ago I attempted updates. Of the two components (core and ?) one worked, the other did not. No message on that. Everything was working so I left it for another day.

In the meantime the host computer had a power outage. Everything seems to start, the VM comes up, docker seems to (not an expert there), the cli comes up etc. The only message reported is a Udev failed to bind, address in use message, which I understand may be a red herring in any case. I can access the cli through the ‘console’ but the Home Assistant GUI does not come up. Wireshark reveals the host is sending a TCP RST immediately after receiving a TCP SYN. The Observer does render a page though it just says basically ‘running’. I can ping HA’s IP address. It refuses a ssh connection.

core info says I am on : 0.115.3
host info says I am on: Home Assistant OS 6.0; kernel 5.10.42
info says supervisor version is 2021.06.03

I have no idea where to look next, what to try. There was a log earlier that was something along the lines of ‘waiting for recorder’. I can’t find that now (multiple reboots later) but a Google search suggested the db file may be corrupt. I don’t know how to reach that to even delete it…

Any pointers would be much appreciated… what would be perfect is a workflow to follow where I can google each step and figure it out from there. Right now, I am sitting here three hours after the power problem totally lost in space.
thanks!

[tomdudu38]

Hello.
i suppose you used the install script to install hassio supervised .
I suppose you updated it with something else than hassio or the script.
Just use the install script again.

home-assistant/supervised-installer

[dampsquid (Bob P)]

Hello, thanks for the reply. For the original install I took the Linux vmdk option from home-assistant.io. This is running under VMWare ESX. One thing I just noticed is the VM under ESX has powered off without me asking… that’s twice now.

Your suggestion to re-run the install script… how do I get to a Linux cli to do that? The image boots into the HA ‘shell’ (?)… that is all I get is a command prompt that looks like:
ha>

To add: the update I did was via the GUI, following the notification icon that updates were available…
Thanks!

[dampsquid (Bob P)]

Update: I can connect via SMB. So I have my config at least. I tried deleting home-assistant_v2.db using SMB, but it was still there after a restart.

So I’m still stuck. Really hoping this isn’t going to be 3/3 upgrade failures… If anyone can sketch out some troubleshooting steps, that would be great.

[dampsquid (Bob P)]

Further update:
Adding this in the hope it may help someone experiencing the same problem:
I succeeded in deleting home-assistant_v2.db via SMB connection. After that and a restart I can now use the GUI again.
But, after a while the VM shuts down. I have no idea why. ESX isn’t shedding any light on that.
Feeling pretty disillusioned with Home Assistant at the moment. Looks like I’m going to have to recreate my installation from scratch again (fourth time) to get stability. And then avoid upgrading anything at all costs. While I commend the open source community for all the positive work - in my case I can’t find the answers, not even an outline of steps to resolve the issue that I can then research myself, and with the exception of Tomdudu38 (big thank you) there’s been no help…

[Mikefila]

@dampsquid

HA has been up and running for a long time

Are we talking months without updating?

@dampsquid

There was a log earlier that was something along the lines of ‘waiting for recorder’. I can’t find that now

Depending on how long it was since the last update, there was an update that took a long time because I believe the format of the db changed. This may explain why you received the message and it disappeared after.

@dampsquid

And then avoid upgrading anything at all costs.

You can’t use a supervised version if this is your game plan. Right now as it stands supervisor updates automatically, there really isn’t many ways from stopping.

It’s been under discussion to be able to disable it. The team that runs supervisor is not interested in implementing it. There are feature requests, please vote for them if you agree.

Allow some degree of control over Supervisor

Currently, Supervisor performs varies activities over which the user has no control. For example, it performs an Internet connectivity check every 5 minutes (and makes several DNS lookups each time). It also performs version checks many times a day. This activity makes it one of the most chatty clients on my local network (more than commercial devices I have that rely on the cloud). It would be useful to have a supervisor.yaml file where one could control some of Supervisor’s activities. For e…

Feature request: block supervisor auto-updates

Could it be possible to have a switch to block supervisor auto-updates? This way we could stay in an stable version without the need to have to update HA or the addons because they aren’t compatible with supervisor anymore.

Back to your situation what is the most recent working backup do you have? Is the entire VM backing up on a regular schedule? What about HA back ups? Anything recent?

I’d restore to a prior point rather than start from scratch. If your db is large consider deleting, then do the pending updates.

[dampsquid (Bob P)]

Thanks, Mikefella, for your reply.

Some time = months without interruption. I’ve used HA for a couple of years total now.
I have a snapshot saved off of the HA system from February. I have copied the current configuration via SMB. And, taken another snapshot - though I wouldn’t trust that one at the moment. What I wish I had done (but didn’t) is use ESX snapshots periodically.

At the moment HA is running… but I still don’t know why it’s shutting itself down. The last time was earlier today after running all night, so 12+ hours apparently fine. I realise there may be an issue with the underlying hypervisor (ESX) or even the physical host, I can’t rule that out, other than noting ESX isn’t reporting any issues and other VMs on that system are behaving just fine.

I will be voting for the ability to block updates! The chattiness issue isn’t something I’m too worried about, though it’s a nice to have to control that.