Thanks, that’s the answer I was after
The image itself are supported, support for your Hypervisor itself, is of course with the vendor.
Have you enabled EFI boot?
Perhaps looking at how the addon does it?
Or just running it your OS ? Why do you need Docker to run nut?
Statements like this make me reluctant to add a reply, but you are missing a step.
Load the appliance image into your virtual machine software. Choose 64-bit Linux and UEFI boot.
Comment Removed.
So, then my installs are ‘unsupported’ from yesterday. Great communcation
The new alternative installation methods, he helper in installer page should be highly extended. Like, I want to run the installer on an Intel NUC, but examples are only for RPi and SD.
I can manage not having control of the OS, but the different ways of installation should be proper documented, ref “we want to be more professional”.
Could anybody give a good description on how to proper install HA on an Intel NUC?
I’ve tried that and trying to figure out all of the dependencies and stuff that’s included in the dockerfile is way over my head at the moment. Installing from the add-on was way easier.
As for having it in Docker…well…I guess I don’t need to. It’s just better to run it in Docker so If I ever decide I screwed something up or no longer need it I can just wipe it away with a click. It’s the beauty of Docker isn’t it?
Will the Virtual Appliance images be released for ARM, I.E Raspberry Pi’s ?
Those are common, and not really related to HA, you get a lot of answers for both those on VMWare forums.
You may want to try:
- Stopping the VM
- Removing the current disk.
- Checking that the EFI is enabled.
- Attach the VMDK file as a new disk.
- Save the dialog, open it again.
- Change the storage capacity (see that it say IDE as controller).
- When the task (see bottom of the screen) are complete, start it.
Perhaps Pascal could explain what makes the deprecated method so hard to maintain. I’ve ran this way for years with zero problems on a 2012 Apple Mini running Ubuntu and have little-to-no interest in switching to another platform or install method. I’d be happy to help contribute to maintaining this method if somebody can articulate what needs to be done.
As others have mentioned, just killing it with no real explanation other than “it’s difficult” really does little to show that you have the community’s best interest in mind.
Again, happy to help, just point me in a direction…
Terry
Via docker
docker run --init -d --name="home-assistant" -e "TZ=America/New_York" -v /PATH_TO_YOUR_CONFIG:/config --net=host homeassistant/home-assistant:stable
Or venv
EDIT. this post installs core only. Sorry for any confusion.
I just want to make sure I understand the change. I used these instructions to install HA on an Intel mini-PC (Udoo x86 Ultra). Since I’m running Core in a venv, I’m still supported right?
I haven’t bothered to get involved in VMs and containers only because I had no need. I may do greenfield do-over with HA, installing with a container or VM and re-adding all my devices and integrations/addons from scratch. Things have gotten a bit convoluted in my install and it seems like a good idea anyway.
My only comment on this change is that it seems awfully sudden, sort of like Wink’s sudden decision to charge a fee for their cloud service with a week’s notice. Significant HA changes in the past have always seemed to come with log warnings that a given feature would be gone 2 feature releases from now which always seemed reasonable. However I’m not volunteering to pick up the slack here so my opinion can be ignored.
Yes yiu are
That what I was thinking.
I’m not a dev but I willing to pay for someone to fork and maintain supervised installation.
Oh good grief.
First I installed it in a Python venv because that seemed like the right thing, but upgrading was tricky.
Then everyone seemed to be using Docker and that was great because Supervisor took care of everything.
Now I find out I’m still doing it wrong. Despite the fact I went to the docs each time to try and find the best way.
So, for now, the method is dedicated hardware or a VM. Except my NAS is getting on a bit and doesn’t have all the latest features that make VMs run well
And if you are truly running “core in a venv” then you don’t have “add-ons”.
Those are only available in hassio or a (now gone) supervised install.
A guide to migration from HA Supervised under Ubuntu on the NUC to HA Supervised under HassOS on the NUC. That’s my migration path I believe.
Right, I couldn’t remember offhand the distinction between integrations, addons, plugins (HACS).
Via docker
docker run --init -d --name="home-assistant" -e "TZ=America/New_York" -v /PATH_TO_YOUR_CONFIG:/config --net=host homeassistant/home-assistant:stable
Hi @nickrout What am I missing? Isn’t the whole idea to not run on an unit where you cannot control the local OS? Like me, I’ve always installed HA on Ubuntu using the script installation.
Can I still install HA using your method on Ubuntu, without any virtual machines? ANd still have Supervisor available and do the same as previous?
I can almost do ‘magic’ with sensors, lovelace-building etc, but never quite sat down reading and unstastanding the different ‘versions’ of HA and how to install them.
I would be sincerely happy if you could elaborate on this matter?
Greetings from the North of Norway
migration from HA Supervised under Ubuntu on the NUC to HA Supervised under HassOS
But why would that be the best option?
The entire reason to not use HassOS was to allow the user to be in control of the underlying OS and not be locked in to only being allowed to run the things that HA said you could.
Running only HA on a NUC is way overkill.