Ok… as expected, I see this now:
and I can select and install ssh server, second option from the bottom.
I use these options only
Maybe the ISO you are using does not contain any of those options… I dunno… I always use that non-free image otherwise my WLAN etc on the NUC and some other stuff errors…
It must be something missing in the image I downloaded,
I’ll try the ISO from the link you provided.
Thanks for your help
It’s not that critical anyway… you can just install that package… but I’m OCD like this as well… I hate it when stuff doesn’t work like this simply…
The image you linked installed OK and I was able to install the SSH server.
Thanks again for your help. I am going to work on migrating my HA over to a Debian based install this weekend.
It’s not about downgrading docker, I can’t get docker installed at all on Debian. Not by using the script and not by using the official docker way.
Can you share some screenshots showing what you are doing and the response so that we can see what’s going on?
I can’t make sceenshots right now, but it’s pretty simple.
After installing Debian, I run the following command:
sudo add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/debian \
$(lsb_release -cs) \
Then i run
sudo apt-get update
And it ends with:
rvoosterhout@hp-srv:~$ sudo apt-get update
Hit:1 http://deb.debian.org/debian buster-updates InRelease
Hit:2 http://security.debian.org/debian-security buster/updates InRelease
Reading package lists... Done
E: Method https has died unexpectedly!
E: Sub-process https received a segmentation fault.
When I remove the docker sources from my sources list, which looks like this:
deb http://security.debian.org/debian-security buster/updates main
deb-src http://security.debian.org/debian-security buster/updates main
deb http://ftp.us.debian.org/debian/ buster main contrib non-free
deb http://deb.debian.org/debian/ buster-updates main
deb [arch=amd64] https://download.docker.com/linux/debian buster stable
# deb-src [arch=amd64] https://download.docker.com/linux/debian buster stable
deb-src http://deb.debian.org/debian/ buster-updates main
I can then do an apt-get update again. So the repositories from docker are somehow not working on the latest version of debian. ?
Well I have to say that was one of the most simple upgrades I have done on any system lol
Made a current snapshot and backed up everything in my HA Config folder just in case, installed Debian 10 following the OP instructions then Home Assistant. Restored my backup cleaned the dust out of my PC and connected my HUSBZB-1 and fired her up. Everything works just perfectly.
I was quietly dreading moving over from my Ubuntu based install to Debian but it really was a breeze.
I guess you are trying to install it on an Intel/AMD PC which I have not tried myself. There are plenty of guides out there how to do it including this one
Can anyone point me to what controls the container of an add-on installed via the supervisor (using this config on Debian 10). The add-on (Frigate) needs a environment variable added but I can’t seem to find what controls this on a supervised Debian install. I know this is why there is a disclaimer about don’t go this route unless you are comfortable using docker… but I think this is the only thing I need to tweak to have a working system. I found one of the config files but it seems to be dynamically generated so the update didn’t stick…
Normally you do that is the addon configuration (which writes that dynamically created file)
Unfortunately the developer hasn’t exposed that as an option and their docs indicate to do it at the container level…on a pi you don’t need to add this it’s only for amd devices so I guess most supervised installs don’t hit this… so any pointers
I used this script to setup my hassio. However, watchtower is apparently interfering with the hassio container saying that it’s in an unsupported state.
I want to exclude this container, but I don’t have a docker-compose for it? What would be a good docker-compose.yaml without losing my data in /user/share/hassio (I think) ?
Or is there another way to add the label to the homeassistant container?
Supervisor will detect watchtower if it is even there and you will be in an unsupported state. so if compose file includes watchtower you will still get the message.
No it’s basically my nginx rev proxy running in another container that’s causing it. I simply want to exclude this container. But I think I’ll do the opposite and mention explicitly which containers need to he watchtowered ^^
Yeah that is what I did/tried but it didn’t work. If watchtower is on same host HA will see it…
Ok, that’s goddamn annoying
I’m starting to dislike the supervised install It’s locking up my hosts audio, and now this thing. Meh.
I just switched to using docker-compose with a cronjob running every 12 hours to keep non HA stuff up-to-date. Works just the same…
The term Hass.io was deprecated well over 6 months ago, please stop using it.
I would suggest you look into Proxmox then. You can run HA OS as a VM, and any number of other VMs to run any other software you wish without it interfering HA or getting unsupported messages.
Thank you for your condescending messages. If I wanted to run HA into Proxmox, I would have indeed done so. It’s totally overkill for the situation as it introduces an overhead that’s totally unnecessary. Docker serves it’s purpose very well, it’s HA that behaves out of scope as it’s exceeding it’s container boundaries
I started with Home Assistation a week ago, the notions of hassio are still everywhere. Even in the paths. So the correct term is HA Supervised then? Anyhow if it ain’t even clear for new users like me (my main system still runs on openHAB so I’m not a total noob in home automation) … then I advise the devs to look into POKA YOKE =)