"Update Available" - No thank you very much!

A couple of days ago I saw that there’s an update available to ‘Home Assistant Core - 0.110.2’

I tried updating and the ‘wheel’ started revolving - and went on and on. I left it for the night and when I checked in the morning the ‘Pi’ was dead with no network or other activity. I couldn’t even ‘ping’ it. I ended up power cycling, but it didn’t boot and the network didn’t come up. I ended up reinstalling HA.

Last night I tried again with the new installation and the same thing happened, only this time the system came up after power cycling and appears to be working OK. The update hadn’t been installed - but I’m not going to risk it again!

Any idea what might be the problem, please?
Jim

no logs, no problem. You say HA Core on a RPi. I’m guessing this is a venv install? If I’m wrong, then you need to tell us how you installed HA. What version were you running before trying to update? it’s rare for a point release to fail an update. It’s more common for a major release to fail due to breaking changes.

Which is what makes me think that perhaps it wasn’t an upgrade from 0.110.1 to 0.110.2 but from something earlier.

This is information that would also have been helpful to include.

I installed HA onto a 32G microCF card on a Pi 3B, using the hassos_rpi3-3.13.img.gz image.
Developer Tools Info tells me that I’m running ‘Home Assistant 0.110.1’. The Supervisor Dashboard states:
“Update Available :tada:
Home Assistant Core 0.110.2
You are currently running version 0.110.1”
Which is what it showed when I attempted to upgrade - and it subsequently crashed.

Anything else you need to know?

If you want me to attempt the update again and it crashes irrecoverably - you’ve got to buy me a beer! :wink:

Thanks for the prompt replies.
Jim

Ok so it was a point release update. That is very unlucky. There were no extra breaking changes from .1 to .2 that I can see. All just fixes.

Double check the breaking changes for the 0.110.0 release and then have a read through this list and see if any of the fixes apply to your setup: https://github.com/home-assistant/core/releases/tag/0.110.2 they may have inadvertently introduced another issue. Or you may have just been unlucky :man_shrugging:

Thanks for the reply ‘tom_I’.

I looked through the list and nothing jumped out at me - but I may have missed somthing.

I think I’ll just stick with the version I have at the moment, until a major release comes along.
Jim

Did you check the supervisor logs? Somewhere you will find the reason the update failed.

The first time it crashed I couldn’t recover the system and had to reinstall HA. The second time I had to power cycle and the log restarted afresh.

(What is the system’s name for the ‘supervisor log’? The only log I can find by ssh’ing into the system and doing a <find / -name ‘*.log’> is the home-assistant.log)

Jim

From ssh
Docker logs hassio_supervisor

I have no ‘hassio_supervisor’ in my directory tree. The only docker directory in the system is:
./.oh-my-zsh/plugins/docker

Thanks for the reply, David.
Jim

It’s not a file or folder. It’s a docker command you run in a console. (Ssh)

“zsh: command not found: hassio_supervisor”

(Thanks for staying with me David!)
Jim

Start ssh session
Type in this whole command

docker logs hassio_supervisor

New update kills 0.110.3

alarm_control_panel:

  • platform: manual

Anyone have this issue also

“Error: No such container: hassio_supervisor”
Jim

Try docker ps

Me too. Ever get this figured out?

Yes all you need to do is rename some of your config

see below Manual Alarm Panel - When going from state disarmed to any other (armed) state such as armed_away , the state will be arming instead of pending during the transition time as set in the configuration. When going from an armed state (such as armed_away ) to the triggered state the state will still be pending during the transition time as set in the configuration (as it was before). - (@starkillerOG - #32950) (manual docs)

  • State attribute pre_pending_state changed to previous_state
  • State attribute post_pending_state changed to next_state
  • Configuration option pending_time is renamed to arming_time , functionality is the same.
  • The time the alarm stays at pending when triggered has changed from delay_time of the previous state + arming_time (previously known as pending_time ) of the triggered state to only the delay_time of the previous state.

No - I’ve given up!
Jim