When the deprecation news came out I was disappointed. Disappointed at the short notice mostly. I know I’ll be able to get something else worked out. I am currently running HA in an Ubuntu VM running in KVM on an Ubuntu hypervisor; it works just fine right now, and I could probably get by without any updates for some time.
I looked at the latest options for install, and it all looks kind of hardware-dependent, though there are some VM images available, and one in particular that caught my eye: qcow2. That wasn’t there when I first installed HA on my Ubuntu VM, otherwise I would probably have gone with that in the first place.
Anyhoo, I’ve tried installing that, and after a bit of trial-and-error (there’s no documentation on any of these VM images that I could find), I got a new VM running the qcow2 image (UEFI is the key).
So, now I can rest a little more easily knowing I personally have a way out.
But I do worry that the “official” way I choose next will be dropped suddenly too. After all, the way I did it before, installing HA in an Ubuntu host was official until yesterday. And then official again today, though I notice the instructions have not reappeared on the front-page of the HA website.
Personally I lean towards debian. Pretty darned stable.
I don’t disagree, but a supported distro for the RPi is needed and the options are Ubuntu (core or Server) or Raspbian. I had not realised there was an Unbuntu distro for the Pi until recently, but I suspect it may be a better base than Raspbian for this purpose.
This especially puts us PI 4 users in a bind. Maybe the developers can suggest a way forward? I don’t want to dedicate a PI 4, it’s overkill. Yet I don’t know of a good kvm.
Yeah, running generic Linux until it breaks is pretty much my only option.
None of the supported options will work with my Google Coral and HGI-80 (which don’t play nicely on VM) and allow me to keep my RAID disks (which are not allowed on any of the supported hardware platforms). Even if it did, it would be asking alot for me to go out and buy new hardware just for this.
I already moved from just running bare metal python to hassbian on a pi to vm to now what I thought was my final config on a dedicated mac mini running ubuntu, all in 18 months, but here I am having to reassess again.
Hopefully with the decision to put this action on hold there will be an outcome that is easier to swallow for all the users who use the generic linux supervised install.
Ok because of my TZ I woke up yesterday to the deprecation, and this morning to it being on hold. Thanks @balloob. To the rest of you ‘on hold’ is not ‘cancelled’. At least we should all be better prepared when this moves again, in whatever form that may take.
Hi, just got confused, I’m running Home Assistant, previously called Hassio, on docker in a nuc with Ubuntu, is that the installation that will get unsupported?I don’t understand, i know the announcement that for now is still usable I just want to know about my installation
I want to know this also, did you get a response?
Thank you for listening and putting this on hold and for the future discussions that I know your decision will ultimately inspire. I hope good things come from this and am confident that a good solution will be the outcome.
You are running the supervised mode that this post is dealing with.
Wow thanks, that’s not good
Glad that its on hold… all my HASS installations are on generic linux as they are on multipurpose PCs, its a must for me!
Again, I know no one owes us anything, so thanks again for your hard work either way.
Thank you for putting this on hold. I am so relieved as I really depend on HA in my home. I am running HA supervised on Ubuntu/NUC and was starting to panic on which way to move forward. Since I want the ease of use of add-ons then it appears that my options are to wipe out my Ubuntu/NUC system and install HassOS or Proxmox and then HassOS as a VM. Is this correct? I don’t like that HassOS limits my NUC to only HA and I have zero experience with Proxmox (or any other VN) which would dramatically increase the time I spend maintaining my installation. So, neither way was a good alternative.
So thanks to the devs for listening to the user community.
Yeah, use the qcow2 one - it’s not as straightforward as one would expect though, and there’s some other issues.
This one to get it installed…
This one to see why hoping you can just install it, copy in a snapshot and be up and running in no time is a misnomer…
What is the problem with devs knowing in what way their platform is being used? It can only give them an idea, about what is usefull to maintain(or not). The only metric now is # of downloads, which is untrustworthy.
How you or I ‘want’ it to be is irrelevant imho. Personally I like yaml over all that click and point stuff, but I don’t complain.
The devs decide the route, but that goes easier with reliable info.
Thank you for listening.
There have been a number of these sorts of threads over the past few months in which the attitude has been dismissive and at times arrogant to the thoughts and feedback from the community. This thread looked to be much of the same.
I was so pleased to have woken this morning to see that the dev team has listened. I genuinely mean that, thank you for listening.
The take away from this is that communication is key, clear and precise explanations are important and pathways for users post any sort of change need to be considered before making a change.
It’s not back in the install docs yet so excuse me if I delay popping the champagne corks just yet.
I wonder what percentage of users this actually affects. I would think it is fairly high maybe ~40% or so… but that is just a total guess…
Anyway good news and also surprised the devs cared to listen to the users…
I submitted PRs yesterday to reinstate the docs, Frank closed them down. I’ll try and reopen now.
Good luck with that. This is only a stay of execution until they devise an alternative solution.