For the people commenting here about how they want to install other applications on Home Assistant Supervised. What is your suggestion to make it work today and ensure it keeps working as both that application and Home Assistant + Supervisor evolve.
If you have access to a VM, I would encourage to use HassOS in a VM as it’s the easiest installation while still having a host system that you can do with whatever you wish.
One thing I don’t have the knowledge on, and therefore don’t understand is how something can interfere with the Supervisor. If you could clear this up, it would be appreciated.
As the Supervisor runs in it’s own container, how does installing something like SSH at an OS level affect the quarantined environment of the Supervisor container?
I understand the Supervisor needs OS dependencies to run, and that a change in those dependencies could mean breaking the Supervisor?
If the above is true, then can all the necessary dependencies be moved inside the container so OS level app changes do not affect it?
OK I get it. Other questions had been answered in that ADR, but never mind.
The question is still this: in any installation involving the supervisor, how do you ssh in, or otherwise fix things, if the supervisor is not working for some reason. I am not the only person who has had to docker pull homeassistant/amd64-hassio-supervisor:latest to fix a broken supervisor.
My understanding is that if the supervisor does not run, then no addons run, and you can’t access the system other than by hooking up a keyboard and monitor.
PS thanks for the ongoing work, we all do appreciate it. And you coming to the forums to answer questions.
It’s not a quarantined environment. The Supervisor manages a bunch of stuff on the host. See also this overview diagram in the docs https://developers.home-assistant.io/docs/supervisor and the list of required components that need to be in the host OS.
The solution is that the Supervisor needs to not die 
And if it does, it always needs to come back up. This is not always the case and we’re improving this.
In 4.10 Frenck just added some new self-healing capabilities https://github.com/home-assistant/operating-system/releases/tag/4.10
OK, that gives me a little more of an idea. Like I said, my knowledge on these things are not great, so I appreciate being educated on how it works.
If there any way that the buildroot OS used for the image based installs can be deployed as a container along side the Supervisor so it is less reliant on the underlying OS?
Just install Docker in Docker and you can isolate it 
It’s what we use for the Supervisor Development. Not everything works though.
The Supervisor will make USB devices that you plugin available. It will make sure your containers get all the right discovery traffic. All things that don’t work great with an out of the box Docker container.
So when I do an update on the host (standard debian updates) if docker gets updated the supervisor service dies and seems to need to be manually restarted. Then Supervisor, DNS and HA etc will start but other HA addons don’t automatically start up and need to be manually started again… Is this the kind of thing you are talking about improving? (Everything comes up properly if you restart the host but when you are running other stuff that isn’t always what you want to have to do)
Thanks for your work and engagement with this discussion too.
Since the Supervisor runs as a Docker container, updating Docker will stop all containers, including the Supervisor.
I don’t know the exact logic for the Supervisor, but I think it is expected that only when the Supervisor starts as part of booting your device will it start all add-ons marked as auto-start. Because you wouldn’t want all add-ons to start again if your Supervisor gets restarted because it is updated while your system is running.
Is there some reason those dependencies can’t be installed in a venv just like the HA Core installed in a venv does? And if any updates to the supervisor and/or HA dependencies are needed then just update those dependencies in the venv?
Probably because those dependencies are other operating system applications. You can’t install those in a Python venv 
I think you should do what you are doing and state that the system is designed to be the sole user of the instance and caveat emptor if that advice is not followed.
It is unreasonable for users to expect otherwise. If I buy a new car and fit unsuitable wheels, the manufacturer of the car will not support replacing the suspension under warranty. But equally, that is clear to the user at the start.
I’d accept that condition with the proviso (already made) that the devs will now be open to suggested changes that do not impact supervisor, but may make non-standard installs more stable (my example here is checking that apparmour is actually enabled not just installed - Apparmor fails to load · Issue #1679 · home-assistant/supervisor · GitHub, Include note re Raspbian and apparmour by borpin · Pull Request #13170 · home-assistant/home-assistant.io · GitHub - both of which I still think are reasonable requests but were unceremoniously dumped - not that I’m bitter and twisted 
).
One could equally say, what is your suggestion for making the home assistant + supervisor experience compatible with standard operating systems? (Just sayin’)
The ADR for “Home Assistant One” installation method has now been posted: https://github.com/home-assistant/architecture/pull/395
This is the proposed rename of “Home Assistant” (and formerly Hass.io). Name is not set in stone, so please feel free to weigh in with your thoughts.
Makes it far more efficient when there’s no resistance
But surely that means there’s no-one to assimilate (and no new technology to gain !!! )
Like the list of required components… makes sense. Good clarification.
So, it’s been 3 weeks since this blog post and about a month since it was announced that we’d still allow home assistant supervised on generic linux but there’s still no trace that it’s an option in the documentation… Is this deliberate or just a case of “haven’t gotten to it yet”?
