Once you have this complete, you will manage Hass.io and native add-on updates from within HA itself and manage any external container you have manually installed outside the HA environment, using Portainer.
You will almost never need to update your base operating system, Ubuntu in this case.
No. That’s the docker ce script…but it’s only 4 commands if you just run them yourself. I don’t use those scripts.
No. Don’t rerun the hassio installer script.
Again, your system has everything from the first time you ran the script. It has the systemd scripts, and the paths.
Please go read the hassio script.
Yes! That’s all it does. You don’t need to run the script again because you already have the service in place, and apparmor…just stop the service and delete the docker containers. You don’t need to stop the docker daemon. Just delete the containers and restart the service.
Yeah for example there was a critical security update for docker recently everyone was getting very excited about.
I was referring to a normal upgrade of course not a dist-upgrade. Personally I do a dist-upgrade normally but I’m running Debian so there’s very little chance of that screwing something over unexpected.
God I wish I could find a rolling distro I really like. I was a gentoo user for years, but I prefer to do stuff with my computer as opposed to minding it like a toddler driving a tank. I may move to arch at some point.
Lol @ everyone confusing a dist-upgrade with a release upgrade…
sudo apt dist-upgrade is safe.
dist-upgrade
dist-upgrade in addition to performing the function of upgrade,
also intelligently handles changing dependencies with new versions
of packages; apt-get has a "smart" conflict resolution system, and
it will attempt to upgrade the most important packages at the
expense of less important ones if necessary. So, dist-upgrade
command may remove some packages. The /etc/apt/sources.list file
contains a list of locations from which to retrieve desired package
files. See also apt_preferences(5) for a mechanism for overriding
the general settings for individual packages.
Yep it is pretty slow with default settings as HA stores the database on the SD card. Once I moved it to a mySQL database running externally things were much much faster, it was like running HA on a different system, plus no more writing to the SD card for the database.
Things like restarting the HA container still takes a few minutes however, luckily I don’t have to do this very often.
HassOS does limit you with what can be done, this is by design, and allows for easy upgrades but at the expense of the ability to tinker and add and remove packages. If it allowed you to install extra packages, then it would have to keep them up to date also, and can break other things.
HassOS It has no package manager, everything is a HassIO addon instead.
If you are able to do everything you want with HassIO addons, great, however if there isn’t a hassIO addon for some piece of software you need to:
Made your own addon for the software you need.
Move whole system another OS with a package manager like debian/ubuntu/etc.
Use a other system to run that software
I went with option 3 but as you have a single NUC you should probably go with option 2 unless HassIO has the addons you need.
ran docker ps -a and stopped and removed all containers related to homeassistant (docker rm ...)
Restarted sudo service hassio-supervisor start (came up just fine)
As a test, installed the Visual Studio Code add-on. Started and got the following fatal error in the log “13: Permission denied”:
INFO Started (click the link below to open):
INFO http://localhost:8443/
INFO
[10:36:20] INFO: Starting NGinx...
nginx: [emerg] open() "/proc/1/fd/1" failed (13: Permission denied)
[cont-finish.d] executing container finish scripts...
[cont-finish.d] 99-message.sh: executing...
[cont-finish.d] 99-message.sh: exited 0.
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
I reran the hassio configuration script but patched as follows:
#detect if running on snapped docker
if false; then # snap list docker >/dev/null 2>&1; then
For some reason the script uses the “snapped docker” if available. It does not even check if /usr/bin/docker exists.
From what I conclude from the above discussion, this is backwards: it should first check for the “official” docker /usr/bin/docker, warn (or, better, just exit) if not, and, possibly give the option to use the “snapped docker” (giving endless headaches).
For good measure I removed the wrong docker from my system:
$ snap list docker
error: no matching snaps installed
@ttmetro Is there any reason you are persisting with the snap install you have?
In the time you have been trying to debug and get this working, you could have easily done a fresh install using the method I posted above 3 times over and be up and running.
I would start fresh using the guide I posted above earlier. That’s just my opinion.
I know those install instructions work as I made a recent edit to those instruction on the website, and have used them myself a number of times to install to a NUC and Pi3.
Completely up to you, you may be only 1 step away from sorting it all out, but honestly, start over. It will take 30mins to be back up and running.
