Cannot install homeassistant-supervised
vspek opened this issue · 6 comments
When running 04_setup.sh the scripts end with an error.
End of the script:
[info] Install supervisor Docker container
[info] Install supervisor startup scripts
[info] Install AppArmor scripts
[info] Start Home Assistant Supervised
[info] Installing the 'ha' cli
grep: /etc/default/grub: No such file or directory
[info] Switching to cgroup v1
cp: cannot stat '/etc/default/grub': No such file or directory
dpkg: error processing package homeassistant-supervised (--install):
installed homeassistant-supervised package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
homeassistant-supervised
Unable to install Home Assistant package /tmp/9y2Zy-DOWNLOADS/homeassistant-supervised.deb. Try running:
gdbus introspect --system --dest io.hass.os --object-path /io/hass/os
I got it working by adding what is written here (added manually the file and content /etc/default/grub)
https://community.home-assistant.io/t/installing-home-assistant-supervised-on-a-raspberry-pi-with-debian-11/247116/569
After the changes and reboot 04_setup runned without errors.
Thank you very much for your work
Thanks for drawing my attention to this. I don't actually use HA for anything so it would have been some time before I spotted this problem myself.
I read the material at the link you provided and started nosing around. To summarise:
- The problem seems to have been introduced around March 23 by Pull Request 201.
- It has been reported as Issue 207.
- A "fix" is in the works as Pull Request 206.
If you read through the comments on PR206 you'll see that I've just added my 2¢ worth.
I can confirm that executing:
$ echo "systemd.unified_cgroup_hierarchy=false" | sudo tee /etc/default/grub
before running the PiBuilder 04 script does indeed provide a workaround (changes to cmdline.txt are unnecessary) but I'm still thinking about the wisdom of patching the 04 script to do that. That's because, in all my nosing around, I keep running across comments about how HA is not supported on Raspbian / Raspberry Pi OS. I don't know whether Pull Request 201 should be viewed as a one-off - a problem that should have been caught in testing - or if it represents the start of a trend where there will be more and more failures coming our way?
The only reason I added HA to the 04 script in the first place was because it had been a convenience in IOTstack, a lot of people seemed to like it, and the original IOTstack implementation mechanism (a script between IOTstack and HA) stopped working and was no longer maintained.
But, bottom line, I'm not really interested in chasing HA's tail so I'm currently mulling over whether to:
- Do nothing until Pull Request 206 gets resolved and makes it into production, at which point the PiBuilder 04 script will work again.
- Patch PiBuilder as a workaround.
- Pull HA from PiBuilder entirely.
Do you have any thoughts or advice?
I decided to go with a patch for the time being. There are some more comments as part of HA PR206 which have to do with /boot/cmdline.txt but I still don't understand the relevance (almost certainly down to my own lack of knowledge).
You are quicker then I can reply. Great.
Option 1:
It could be that the pull request will be accepted, but in the comments the founder of HA is against it.
Option 3:
I became aware of your script because of this page
https://sensorsiot.github.io/IOTstack/Containers/Home-Assistant/
It is a very user friendly way to get Home Assistant running next to IOTstack, would be unfortunately if that was not possible anymore.
On option 3, the reason I pointed IOTstack to PiBuilder is because I didn't want to wind up maintaining code in two places. But, if IOTstack still offered the same functionality, it would face the same problem.
This response - and the link it points to - pretty much confirm my fears. It's their way (real Debian, not Raspbian calling itself Debian) or the highway. It looks to me like we will eventually reach a point where someone who wants both IOTstack and HA will have to run two RPis. Sad. And a waste of hardware.
Some more "discoveries". It looks like HA installs systemd-resolved.service. That takes port 53. And that, in turn, means containers like PiHole and AdGuardHome can't run. Clobbering that service, starting PiHole (so a resolver is present), and starting HA results in HA complaining:
WARNING (MainThread) [supervisor.resolution.evaluations.base] Systemd-Resolved is required for DNS in Home Assistant. (more-info: https://www.home-assistant.io/more-info/unsupported/systemd_resolved)
INFO (MainThread) [supervisor.jobs] 'ResolutionFixup.run_autofix' blocked from execution, system is not running - CoreState.SETUP
...
WARNING (MainThread) [supervisor.core] System running in a unsupported environment!
I take that to mean "no substitutes permitted" when it comes to DNS services.
The original idea was that Supervised HA could coexist with IOTstack. This new "my way or the highway" attitude is not my idea of coexistence. I think Option 3 is where PiBuilder is heading.
I have decided that it would be best to withdraw all support for Supervised Home Assistant from PiBuilder. I've given the reasons here. It's clear that the Home Assistant folks want to go down the standalone appliance route. Anyone trying to find workarounds to keep Supervised Home Assistant working alongside something like IOTstack will be pushing increasing amounts of frass uphill.
I have also updated IOTstack pending Pull Request 528 so that the IOTstack container documentation for Home Assistant no longer points to PiBuilder, and gives the same reasons for why it's no longer feasible to run IOTstack and Supervised Home Assistant on the same machine.
I know you'll be disappointed by this (so am I - it took ages to get the 04_script install working correctly) but there comes a time when the only sensible thing to do is to draw a line in the sand. The alterations made to Supervised Home Assistant over the past couple of weeks have convinced me that this is that time.