Trying to install Hass.IO - need to install jq, network-manager, apparmor, etc

“sudo curl -sL “” | bash -s”

I do not wish to ‘destroy’ or damage my dietpi install.
What are the risks of installing the dependencies into my DietPi VM?

It needs
docker (supported menu based install)
jq (manual install)
apparmor (manual install)
avahi-daemon (supported menu based install)
network-manager (manual, and this concerns me, isn’t this some big fundamental thing to install?)

I would prefer over homeassistant, for the flexibility of backups etc.
Anyone else? I found a guide claiming was dead easy but it looks like it needs several non core things?

Ok so here’s an update.

I installed NeworkManager using sudo apt-get etc etc
It installed fine and Hassio worked.

However you guys make DietPi and it wouldn’t be included for a reason, what are the implications of installing NetworkManager into DietPi?

MichaIng I’d be interested as well.

I’m wondering if the ability to install via dietpi-software could be added. is so much more than vanilla home-assistant, it would be great if that was possible.

I checked the installer:

NetworkManager is just optional, not required. If you install it, dietpi-comfig network adapter options at least will not work anymore, but AFAIK NetMan configures the network on a different layer, hence it it should generally work. However to avoid any interferences between ifupdown and NetMan I suggest to comment/remove all /etc/network/interfaces entries then.

AppArmor is as well optional. We need to check our install options for compatibility with it, which is planned, probably even making AppArmor a default install on DietPi. AFAIK it can cause issues with our current MariaDB implementation, since it does not allow symlinks for /var/lib/mysql database dir, which we add by default to have database files easier on external drives. But some rule edit should be able to solve this as well.

Docker and Avahi daemon can be installed manually (via apt) or via dietpi-software, systemctl (systemd) and curl are present by default. jp and dbus need to be instaled manually (via apt). “apt-transport-https” package btw is obsolete since Buster, since it is integrated into base APT and the package is only a transitional meta package that depends on “apt” :wink:.

Otherwise is a docker image, hence it should install fine and work well regardless of other installs, besides the two mentioned above system-wide ones.

We could theoretically add to our install options, when ruled out above issues. NetMan should not be an issue after the planned network config rework has been finished, which will allow much more flexibility and 3rd party config tools, so that dietpi-config network adapter options are more an “option” than a need on DietPi (regarding what e.g. boot scripts expect to be present in /etc/network/interfaces etc). However, especially since it doubles obviously many of our config options (network management and others), I am not sure if it fits that well, and with the above linked install script it seems pretty easy anyway. Since DietPi allows the most important system configs with its scripts, I don’t think that additional software, which allows to do the same, and relies on certain related system environment, should be added with high priority to dietpi-software. The same is true for e.g. OpenMediaVault and such. As long as some software breaks any of our scripts, I am not keen to add it as “official” install option, but I aim to make most parts of DietPi scripts more flexible and optional, in long term :slight_smile:. Until then, manual install of course works in every case (DietPi is Debian, basically), as long as one can live with possible errors with our scripts.

Thanks for the reply. Could you reach out to the HassIO guys and see if there was a way to accommodate an optional install of NetMan as that seems the main stumbling block?

Looking at the forum, this post has generated a large number of views so I’d suggest there is quite a bit of interest.

The installation of HassIO (this would be regarded as a generic install) and the use of HassOS generates quite a bit of heat over there, but having a base OS that offers a non HassOS install of HassIO OOB may be positively received. I am not alone in thinking HassOS is just too restrictive.