Just want to mention here until Raspbian natively supports boot to usb for Raspberry Pi 4’s, I believe the only way to run a full Home Assistant (previously referred to as Hassio) install with the /root partition on an attached usb drive is to manually configure this set up in a Raspbian install, then install docker, and then install HA Supervised Install…
Otherwise RPi4 users are forced to do everything with an sd card.
So if the HA Supervised Install must be deprecated because of a lack of resources perhaps it may be worth considering offering an option within the native installer for RPi4 to minimize the usage of the sd card to initializing boot only and switch to usb attached drive?
(Unless the HassOS RPi4 installer already allows this moving of /root while keeping /boot on the sd card)
(I do hear that Ubuntu for RPi4 supports native usb boot in release 20.04, if that’s of any help)
That’s exactly what you get when you install HassOS. Add-ons are just docker containers, that have been modified to integrate smoothly into Home Assistant.
So why don’t they automate this for a none HassOS but docker based setup to make it fully equivalent?
@123 They still plan to discontinue the Core+Supervisor approach so I feel my suggestion on making the docker approach a proper fully automated addon approach like HassOS is relevant and needed.
I didn’t comment on that aspect of your post. I only commented on the fact your post misused terminology which resulted in describing unusual or non-existent things like:
Hassio aka HA OS - whether running in a VM or not
The term hassio was replaced months ago by the term Home Assistant and it has never been “also known as” HA OS.
HA in a Docker with addons as additional docker images
Home Assistant Core is available as a docker container. Add-Ons are customized docker containers designed to work with the Supervisor docker container. Home Assistant is the combination of Home Assistant Core, Supervisor, and Add-Ons (all docker containers) running on HassOS. The variation that runs on generic linux, as opposed to HassOS, is called Home Assistant Supervised (and is slated for deprecation).
But unfortunately the installer script no longer works.
Should give a warning but even in this script there is an error …
Even the script has been adjusted (incorrect piece with warning omitted) but even then you will not get there anymore …
It may still work on a pi, but unfortunately it is no longer possible on a mini pc or a desktop … I no longer succeed …
the last 5 installations were without problems, but unfortunately no longer. Cloning a hard disk and then restoring a backup from another location does work. but seems unnecessarily complicated to me.
That’s what you get currently when you use Home Assistant supervised install on a generic linux system, the method this topic is talking about, that is currently on hold to be deprecated.
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…
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.
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.
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).
