Auto updates need to turned off. When you’re using HA as part of an alarm system the last thing you need is to walk out the door only to find out you’re alarm system has been dead for days because of some auto update. I left my house today and everything was fine. Came back two hour later and my system had crashed. On reboot none of the containers restarted. I had some docker error about overlay2 issue and failure to mount. Looking at syslog the last message that was stored prior to the system rebooting:
May 29 08:27:09 odroid hassio-supervisor[8681]: #033[32m20-05-29 12:27:09 INFO (SyncWorker_19) [supervisor.docker.interface] Pull image homeassistant/aarch64-hassio-supervisor tag 225.#033[0m
So an auto update killed things. The only way I could fine to fix things was to remove all the containers and re-install them, along with all the addons I’d installed. I’m running the supervisor version on Ubuntu 18.04 on an odriod N2. It’s great platform for HA. Please move this up on the feature list. I took rockyou’s suggestion and hopefully his suggestion will fix things. On my system the tasks.py was down another layer under the misc directory. Please do not force auto updates.
But, also please don’t forget the other side of the coin:
Homeassistant is still in active development. It isn’t at the “stable” 1.0 target version yet so you’d have to keep in mind that any nabucasa cloud backend could be updated and no longer work with local installs that are lower than 0.xx.
Saying that though, I do also think it’s should be an option where you can opt out (on by default), but with an “on your head be it” kind of warning.
My ‘supervised’ system also experienced issues (HA core wasn’t available) after yesterday’s auto-update. Fortunately, I was able to SSH to the OS and perform a reboot and then everything started up normally. I didn’t have time to investigate and troubleshoot, I just know that Supervisor is now on version 227 and believe that the auto-update was the root-cause of the downtime, since that was the only change.
I think I will be migrating to HA Core Docker because my apartment heavily relies on HA availability and I need to plan the downtime. The convenience of add-ons is great and a killer feature of the platform, but the trade-off of system stability due to the lack of control of Supervisor updates is a deal breaker for me at this time. I want a stable system and I want/need to schedule downtime on my own terms.
I think that auto-updating of Supervisor is in direct contradiction with the goals of most people who chose the generic Linux install method of HA (more local control)… This installation method is unfortunately the least stable option right now. With user-configurable updates of Supervisor, it wouldn’t be… Power-user / enthusiast crowd opinions, who are most passionate about the platform and spread the word of it’s excellence far and wide, are too easily being dismissed.
IMHO, generic Linux install should be left deprecated if Supervisor updates remain unconfigurable for the user.
–
Btw, this is my first post on this forum and I would like to use this opportunity to thank every single person who sacrified their free time to contribute to this wonderful project to make it the best homeautomation platform ever, I am extremely grateful. Thank you!
This would be a fabulous feature to have.
It’s tremendously frustrating to have a completely working system start (seemly randomly) having issues and not knowing why, only to find out that it’s because someone forced an update on your system.
I don’t see how Home Assistant could be trusted in any type of important situation until this is added.
That’s why I’m on this thread. I am spending the morning trying to track down issues with a system that was previously working fine. It led me to the supervisor, and to auto-updating and now to this. (The auto update happened sometime in the last few months, but I didn’t have physical access to trouble shoot the system until now)
The auto-update put my system in a situation where I couldn’t fix it as an end user without physically pulling the plug on my raspberry pi. (I was getting the error: Post http://supervisor/host/reboot: dial tcp 172.30.32.2:80: connect: connection refused)
I want to have an install of Home Assistant that I can use as an end user because I need it to be reliable. So I followed that path for my install and setup. I used one of the install images with Home Assistant OS and Home Assistant Core for Raspberry Pi. But now I understand that if I want to use it without having to worry that it might break on it’s own, I need to block version.home-assistant.io at my router. That seems weird to me.
Adding this feature would be a significant step toward making Home Assistant more end-user friendly, just like the GUI setup.
What is the issue in the development? Is it so hard to implement a switch to enable or disable auto update? It is not very funny, if I am not at home for a long time, Hass is not available because of restart issues after some supervisor issues. I should be able to control the smart home and not the smart home should control me.
In General I have no idea how to make the supervisor available again, because I am not a Linux or docker specialist.
To setup a very new Hass every time and to try to restore an old backup could work. But it is also time consuming and not the best way.
I think they care… considering the effort required to get HA to this point… they care
What I’ve not seen (and not searched for…maybe it’s written down somewhere) are the reasons why this feature can’t be implemented. Perhaps it’s on the roadmap, perhaps it has been considered, perhaps it’s waaaaay more complex than anyone can implement? Perhaps the HA devs just don’t want it. Perhaps they want it too, but it’s 1 of millions of other FRs?
Personally, I just want auto-updates to check for an update, but not to actually install it. Which seems ok, but what if I don’t check for [insert long period of time] - would the updater actually work any more? Maybe that’s the problem?
I also use pfSense at home and because it’s my gateway to the internet, I have not updated it recently because I cannot afford for the upgrade to fail whilst we’re all working & learning from home. However, I’m quite happy to plan for a weekend when I’m not working and the family aren’t glued to the internet. Then, after breakfast, I can backup my current system, check I have the old firmware to rollback (just in case) and then perform the backup at a relaxed time, during daylight hours…
Every single time I do that, I barely finish my coffee and we’re up & running again
If I could do that with HA, then I’d be happy
I’m not wanting to block URLs, or freeze my system “forever” and I’m quite open minded that HA is on a very fast development cycle at the moment, but, sometimes, I just need a day or two before I’m ready for the upgrade.
Don’t conflate Home Assistant Core (HA) with Supervisor. They are two different software projects, each with its own GitHub repo and development team. Currently, there are two active developers for Supervisor. Historically, it was the invention of one person who had little time to implement Feature Requests. If you look at the repo, they also have very little time to resolve Issues.
In contrast, Home Assistant Core has a large team of paid developers plus a small army of volunteer developers. New functionality is added regularly and Feature Requests are occasionally implemented. It’s much more open to user input, whereas the Supervisor project is comparatively insular.
As for a roadmap, if any of the projects (Core, Supervisor, Operating System, etc) have one, it’s never been shared publicly. In other words, it doesn’t exist.
If you’re interested, you may also wish to vote for the following Feature Request:
The suggested workaround is now impractical because it has negative consequences.
The workaround suggests modifying Supervisor’s source code. Since Supervisor version 2021.05.3 it detects changes to its source code and marks your instance as Unsupported and Unhealthy (and then you can’t add/update Add-Ons or update Home Assistant).
There is a command line option to disable checking for source code modifications. If disabled, it simply flags your instance as Unsupported. However, in version 2021.05.4 that option broke. Even if disabled, it still marks the instance as Unsupported and Unhealthy. I reported the bug as an issue a week ago (and there has been no reply yet).
+1 for this. I find it absurd that we’re resorting to blocking outgoing connections, this isn’t a chinese ip camera.
The pros have already been discussed thoroughly. If there are reasons to keep this feature that we don’t know about it would be great to hear them so we can understand why things work like they do.
Is this feature documented somewhere? Couldn’t find it.
My HomeAssistant install keeps breaking because Supervisor gets updated, but core does not. I end up with a broken system on reboot, which I inevitably find out about when I’m trying to go to bed and wondering why lights won’t turn off.
Having to implement blocks at DNS level to prevent a piece of open-source software from updating is beyond insane.
