The generic Linux (Home Assistant Supervised) install, which this topic is about, is being (on hold) deprecated.
As noted above;
Just read this thread and wow sure took me a long time!
Just wanted to thank those who helped me transfer from my pi to generic Linux install. It has worked flawless and I am sure glad i did this. It’s helped me learn Linux and now even a bit of python too.
Which brings me to my next point: I see people fretting about Proxmox including some of the people who helped me (I think).
If generic Linux goes away do not fret about Proxmox. For me it was easier to get going than HA itself. I barely knew what I was doing and had it installed in about 15 min. Took much longer to get it where I liked, but I did it slowly when I had the time to fool with it.
Get something with an I5 or I7 (Used Dells are cheap ((`$120-150) on Amazon and Ebay)
Proxmox is great because you are not dedicating the whole machine to HA. I have windows and other versions of linux on mine and it works great. You guys helped me and I don’t mind returning the favor. No expert but I can probably help enough to get it working…
1 Like
The supervised setup has been a brilliant piece of work. In fact two weeks ago when my rPi died, I tried installing HA on my Mac mini. In the end the only working install was the supervised one. Mac + zwave stick don’t work native on docker, VMware image issues (forgot what the issue was), supervised worked out of the box. So I was really happy until an hour ago when I started to read this thread. Will now have to try a fresh install again and hopefully this time I will get the vm working or else I’ll be in trouble.
Just found this blog post and it’s glad to see that it is put on hold but I am hope that it’s not just put on hold but the generic Linux installation is seen as a permanent option because I’m using without having any problems with the supervisor ever (on a raspberry pi and x86 machine both with ArchLinux).
The problem seems to be that you did not know which option for user is using the data being collected from the updater component which is not enabled by default could be used but is missing the host os and also not transparently shared with the community. For that reason I also disabled the reporting.
Why not add a general data collection option and ask the user on the first installation if he wants to disable it. The important part is from my point to be 100% transparent about the which data Is being collected. Additionally it’s also very important from my point to share this data with the community continuously not just in a blog post every few weeks. This motivates my and maybe others to share their data, and also help the community to make transparent decisions.
I see the file sharing (open source Dropbox replacement) syncthing as a very good example. On first visit of the Management UI the user is told that data collection is enabled an can be disabled with a single click.
Also you can view the data online: https://data.syncthing.net/
I think nobody is disagreeing that the data is valuable, so there’s a fine line to walk on between privacy, data collection, improving homeassistant and showing it transparently. In my opinion this would avoid such problems in the future.
@Underknowledge and @remcomeer1989 this might be for you and of other folks having issues with the script Supervised installation script:
Try taking the the pipe and BASH off of the tail end of the CURL command and instead do output to file like so curl blahbla > installhassio.sh — then chmod +x installhassio.sh — then ./installhassio.sh
I had this issue and it’s likely because the shell “read” command is now used for you to acknowledge the “not supported” confirmation.
This was the next step… already tried this yesterday… also worked. Just removed the “On Hold” part.
But using these steps it works like a charm. Tried this moring again from inserting the usb drive with ubuntu ( Ubuntu Server 20.04 LTS) setup to running home assistant with supervisor within 20 minutes.
sudo -i
apt-get update
apt-get upgrade
apt-get install -y apparmor-utils apt-transport-https avahi-daemon ca-certificates curl dbus jq network-manager socat software-properties-common
sudo apt install docker.io
systemctl disable ModemManager
apt-get purge modemmanager
curl -sL https://raw.githubusercontent.com/home-assistant/supervised-installer/c674830d8ddc6af9d618755a7995af939dd73fde/installer.sh | bash -s
Hope i can help someone else with these instructions.
4 Likes
Thanks for re-concidering deprecating Supervisor - I am a very happy user and would appreciate if it could be maintained 
Terminology aside I think you are mostly correct. As I said in an earlier post, the problem seems to be that “supervisor” covers too much territory. It both handles automating updates and OS management AND configuring HA function (e.g., access to add-ons). The latter should not be architecturally combined with managing the OS. There should be clear separation between OS management which makes sense for a plug and play user and configuring HA function which should be doable in the same way for all users, even those that want to run under Docker on their own OS. Currently it seems that Supervisor is doing both these functions and this creates multiple problems for the developers. It makes them force users who can manage their own OS into reduced HA function (no add-ons and who knows what else in the future) and it seems to force them into doing difficult internal OS management. Yes - folks will tell you that you can install the add ons as your own Docker containers but nowhere that I can find is there a comprehensive list/documentation of how to do that for each such container (that configuration part you allude to). Much as I admire the overall architecture of HA, I think in this one case it is flawed and I say that as a person with nearly 50 years in very complex system architecture roles.
4 Likes
Perhaps an issue is trying to accommodate too many variants of Linux.
If we look at the bigger picture, a major goal is to appeal to folks who aren’t technocrats. The bigger the installed base, the more manufacturers of connected gadgets will be willing to open their APIs to Home Assistant. So, I can understand why HassOS and add-ons are desired. That said, for folks who are using HA as a part of a home security solution, more capable SBCs need to be supported. That’s what drew me to a supervised installation with a reliable SSD (i.e. one with power-loss protection and reasonable write performance).
Managing addons is part of managing the OS.
Not if you treat them a real docker containers and compartmentalize the connection/configuration stuff. That is the entire point of systems like Docker - they operate without real dependencies on the underlying OS. There may well be things that Superviisor should do to make a naive user not have to be at all concerned with the details of the OS but, e.g., accessing an editor that knows about HA config files (VSCode) certainly is not an OS dependent issue. I’m not saying that there aren’t things that can benefit from a fixed OS for the simple user - there clearly are. What I am saying is that there are other things that are currently lumped into Supervisor that don’t fit that pattern. Splitting these apart would make live simpler. If you want HA++ to manage your system network and such other OS centric stuff - fine. But don’t make access to a Dockerized database dependent on the same tool because that isn’t necessary and has led to this problem.
4 Likes
There an error on its current state but many solutions out there… or you can also try my fork
curl -sL "https://raw.githubusercontent.com/krdesigns-com/supervised-installer/master/installer.sh" | bash -s
One year ago everyone and devs on discord, forum,… said install linux and then docker and HA.
And now it will be gone. I have also paid 60$ a year to HA, because of this installation. Also bought nuc because of this. Now it is a overkill for hassos, or to slow to run virtualboxes
This is a joke!
No, you pay for the use of, and access to Nabu Casa, not for HA.
If it is too slow to run VMs, then how did it run everything properly before? Using something like Proxmox is extremely lightweight and does not use many extra resources.
Not using nabu casa! It runs fine without virtualboxes. Proxmox needs fresh install, do not want to reinstall everything, have other things running on linux
The $5 a month is for Nabu Casa, not HA.
So run 2 VMs, one for HA and an Ubuntu VM for everything else.
1 Like
That’s the entire issue that we’re trying to avoid and hence this thread with over 700 comments in a short period of time. Setting up and administering 2 Linux boxes for home automation seems like ridiculous overkill. Then having to configure inter-connectivity between the machines, etc. I’m sure most of the folks here already have a bunch of watts being eaten up by computers and other fun gadgets. It’d be nice to go a bit leaner and greener here and leverage Docker for what it was meant to do and easily does today.
7 Likes
I don’t disagree with you. I have written an install guide that many people have used that uses the generic install method. I’m all for it.
You have misread my comment - I was questioning the ability to run VMs on a NUC as suggested. I’m not advocating for the use of VMs. Yet.
I am one of those who followed your guide (NUC) and I am super happy with this setup, because I am getting the best from HA and from my NUC.
What the devs should understand is that non-power users are here for the “HA software” and not to learn about VMs prxomox docker etc.
HA itself have a learning curve and in the begging it takes time and effort to make things happen.
Nobody will spend minimum a week in order to understand and make the right environment in order to install HA.
Imagine the average “windows user” (we like it or not are the majority uses windows) what will do if the best way to use HA is to install proxmox,virual machines etc. They will just no bother and move on
Ideally, in the end of the day, HA should be easy to install as an exe file fo windows and users start immediately play with HA, which is after all what they need. I don’t know if ever this could happen but I believe that this should be the ultimate goal.
Diversity is good, but I would prefer 1 main EASY install method and more capabilities in the program itself.
3 Likes
There are lots of land mines and stuff with setting up Proxmox as well that are less than straightforward. Particularly for someone just getting started.
1 Like