I would try RVitals workaround first.
If that works for your Pi2 I really would do this approach.
BTW, if you have strictly followed this guide you did install avahi-daemon. Check by doing:
sudo systemctl is-active avahi-daemon.service
I would try RVitals workaround first.
If that works for your Pi2 I really would do this approach.
BTW, if you have strictly followed this guide you did install avahi-daemon. Check by doing:
sudo systemctl is-active avahi-daemon.service
TW, if you have strictly followed this guide you did install avahi-daemon. Check by doing:
Nope, itās not active and not installed. I did strictly follow this guide, but it does not ask to install avahi-daemon
and it doesnāt get pulled by any other dependency.
Iāve also noticed that a systemctl restart hassio-supervisor
does indeed fix my issue, meaning that there is definitely a networking issue during the boot process that gets resolved later.
Manually restarting the daemon is not a proper solution, so I will try the one you suggested (nmcli connection modify "Supervisor eth0" ipv4.dns "local-dns-servers-ip-address"
).
Unfortunately I still get No version found for ghcr.io/home-assistant/armv7-hassio-cli
despite the nmcli connection modify "Supervisor eth0" ipv4.dns "8.8.8.8 8.8.4.4"
Thanks dude!
I have an RPI4 and did this and it worked out with some slight changes.
you need to add āchmod +x /bin/update-grubā to give it execute permissions.
Anyone notice docker_configuration causing unsupported installations in the latest supervisor (dev build)?
Been trying to install HAS following the instructions, but dpkg -i homeassistant-supervised.deb gives a warning:
Selecting previously unselected package homeassistant-supervised.
(Reading database ā¦ 25491 files and directories currently installed.)
Preparing to unpack homeassistant-supervised.deb ā¦
[warn]
[warn] If you want more control over your own system, run
[warn] Home Assistant as a VM or run Home Assistant Core
[warn] via a Docker container.
[warn]
[warn] ModemManager service is enabled. This might cause issue when using serial devices.
[info] Fix kernel dmesg restriction
Adding ādiversion of /etc/NetworkManager/NetworkManager.conf to /etc/NetworkManager/NetworkManager.conf.real by homeassistant-supervisedā
Adding ādiversion of /etc/NetworkManager/system-connections/default to /etc/NetworkManager/system-connections/default.real by homeassistant-supervisedā
Adding ādiversion of /etc/docker/daemon.json to /etc/docker/daemon.json.real by homeassistant-supervisedā
Adding ādiversion of /etc/network/interfaces to /etc/network/interfaces.real by homeassistant-supervisedā
Unpacking homeassistant-supervised (1.2.1) ā¦
Setting up homeassistant-supervised (1.2.1) ā¦
[info] Restarting NetworkManager
[info] Enable systemd-resolved
[info] Restarting docker service
PING version.home-assistant.io (104.26.4.238) 56(84) bytes of data.
64 bytes from 104.26.4.238: icmp_seq=1 ttl=59 time=7.61 ms
ā version.home-assistant.io ping statistics ā
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.611/7.611/7.611/0.000 ms
[info] Install supervisor startup scripts
[info] Install AppArmor scripts
[info] Start Home Assistant Supervised
[info] Installing the āhaā cli
[warn] Could not find /etc/default/grub or /boot/cmdline.txt failed to switch to cgroup v1
Iāve checked, and indeed, there is no /etc/default/grub or /boot/cmdline.txt, so its impossible to make changes to those files.
Iām using 20220121_raspi_4_bullseye.img.xz as base image and have selected raspberrypi4-64 as machine type.
Anyone any idea what goes wrong?
āUPDATE:
Did some digging and reading up on this thread. Didnt read everying because, well, 587 comments
Anyhow, as pointed out by some other members, arm doesnt use grub, so no use looking for it. Making dummy entries shouldnt be a solution either.
I found commandline.txt in /boot/firmware, not in /boot. Dont know if this is the right place, but I did use the suggested image from rasp. debian. net, so I guess it is.
Maybe a symlink does the job? I prefer the installer to be fixed though
Any suggestions on how to proceed??
Yep, followed this howto and found to be unsupported anyhow:
Host Operating System | Debian GNU/Linux 11 (bullseye) |
---|---|
Update Channel | stable |
Supervisor Version | supervisor-2022.06.2 |
Agent Version | 1.2.2 |
Docker Version | 20.10.17 |
Disk Total | 219.8 GB |
Disk Used | 3.8 GB |
Healthy | true |
Supported | Unsupported |
Supervisor API | ok |
Version API | ok |
Installed Add-ons |
Did you install apparmor?
No, its already in the kernel. I once tried installing it on top of Raspbian PI OS, which resulted in a dependency warning about apparmor being missing.
Try to enable AppArmor by adding lsm=apparmor
to the end of cmdline.txt file
Thanks, that solved it, its now supported
@kanga_who
I also have the same problem, like the above,
Iām getting an error
[warn] Could not find / etc / default / grub or / boot / cmdline. txt failed to switch to
cgroup vl
Is there a solution to this?
Try /boot/firmware, I found my cmdline.txt there
@Patrick010
I did not understand what I should do,
I would be happy if you could elaborate
How to install Home Assistant Supervised on Debian
As itās coming up Iām getting an unsupported version,
Thank youstrong text
@kanga_who
Is there a solution for this installation
Or does this installation no longer work??
What do you think about it?
Well, that supported quickly changed back in to unsupported
Adding lsm=apparmor to the end of cmdline.txt file didnt help after all.
ā UPDATE: lsm=apparmor disappeared from cmdline.txt. After adding it again the system is supported again. Very strangeā¦
Canāt answer your question. RPI OS is also based on Debian. The 64-bit version works flawlessly