supervisor
supervisor copied to clipboard
pull #3421 not working on supervised installation wih RaspberryMatic snapshot plugin
Describe the issue you are experiencing
RaspberryMatric on HA Supervides install (x86/amd64) throws errors, process wanting to access dynamically created devnodes can not access them:
22-02-12 07:09:36 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD hardware /dev/mmd_hmip - None 22-02-12 07:09:36 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD hardware /dev/mmd_bidcos - None 22-02-12 07:09:36 ERROR (MainThread) [supervisor.docker.addon] Can't set cgroup permission on the host for addon_de838cd8_raspberrymatic-dev
See detailled description below for URL to full log
What is the used version of the Supervisor?
supervisor-2022-01.1
What type of installation are you running?
Home Assistant Supervised
Which operating system are you running on?
Debian
What is the version of your installed operating system?
Debian GNU/Linux 11 (bullseye)
What version of Home Assistant Core is installed?
core-2022.2.6
Steps to reproduce the issue
- Meet https://github.com/home-assistant/architecture/blob/master/adr/0014-home-assistant-supervised.md
- Install HA supervised https://github.com/home-assistant/supervised-installer Intel atom NUC Debian 11
- Buy HMIP-RFUSB https://www.amazon.de/gp/product/B07B4DP1KY/
- Solder HMIP-RFUSB
- Inset HMIP-RFUSB onto any USB port
- Install RaspberryMatic, latest snapshot for HA Supervised https://github.com/jens-maus/RaspberryMatic/wiki/Installation-HomeAssistant#using-homeassistant-supervised
- When RaspberryMatic starts, HA Supervisor throws error messages according to first supervisor log shown in: https://homematic-forum.de/forum/viewtopic.php?p=706012#p706047 (sorry, explanatory text in german, pls. use translate).
According to Jens Maus and others in the RasperryMatic Forum, this error does not occur on HAOS installations, e.g.: #3421 is making th dynamically created devnodes work. But in this supervised install it does not work.
Anything in the Supervisor logs that might be useful for us?
See above
Additional information
No response
please post the ha info
Not OP but I am seeing the same issue on my supervised setup.
22-03-01 08:32:45 INFO (MainThread) [supervisor.addons] Add-on 'de838cd8_raspberrymatic' successfully installed
22-03-01 08:32:52 INFO (MainThread) [supervisor.ingress] Update Ingress as panel for de838cd8_raspberrymatic
22-03-01 08:32:58 INFO (SyncWorker_1) [supervisor.docker.addon] Starting Docker add-on ghcr.io/jens-maus/raspberrymatic with version 3.61.7.20220226
22-03-01 08:33:04 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD hardware /dev/mmd_hmip - None
22-03-01 08:33:04 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD hardware /dev/mmd_bidcos - None
22-03-01 08:33:04 ERROR (MainThread) [supervisor.docker.addon] Can't set cgroup permission on the host for addon_de838cd8_raspberrymatic
22-03-01 08:33:04 ERROR (MainThread) [asyncio] Task exception was never retrieved
future: <Task finished name='Task-376' coro=<DockerAddon._hardware_events() done, defined at /usr/src/supervisor/supervisor/jobs/decorator.py:71> exception=DockerError("Can't set cgroup permission on the host for addon_de838cd8_raspberrymatic")>
Traceback (most recent call last):
File "/usr/src/supervisor/supervisor/docker/addon.py", line 700, in _hardware_events
await self.sys_dbus.agent.cgroup.add_devices_allowed(
File "/usr/src/supervisor/supervisor/dbus/agent/cgroup.py", line 19, in add_devices_allowed
await self.dbus.CGroup.AddDevicesAllowed(container_id, permission)
File "/usr/src/supervisor/supervisor/utils/dbus.py", line 172, in call_dbus
raise DBusFatalError(reply.body[0])
supervisor.exceptions.DBusFatalError: Can't find Container '028bbba77f90cdb27e93b8a1895c24c9c4c31e7a0ef85265b061ff6752d786f7' for adjust CGroup devices.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/supervisor/supervisor/jobs/decorator.py", line 108, in wrapper
raise err
File "/usr/src/supervisor/supervisor/jobs/decorator.py", line 106, in wrapper
return await self._method(*args, **kwargs)
File "/usr/src/supervisor/supervisor/docker/addon.py", line 707, in _hardware_events
raise DockerError(
supervisor.exceptions.DockerError: Can't set cgroup permission on the host for addon_de838cd8_raspberrymatic
22-03-01 08:33:04 ERROR (MainThread) [supervisor.docker.addon] Can't set cgroup permission on the host for addon_de838cd8_raspberrymatic
22-03-01 08:33:04 ERROR (MainThread) [asyncio] Task exception was never retrieved
future: <Task finished name='Task-379' coro=<DockerAddon._hardware_events() done, defined at /usr/src/supervisor/supervisor/jobs/decorator.py:71> exception=DockerError("Can't set cgroup permission on the host for addon_de838cd8_raspberrymatic")>
Traceback (most recent call last):
File "/usr/src/supervisor/supervisor/docker/addon.py", line 700, in _hardware_events
await self.sys_dbus.agent.cgroup.add_devices_allowed(
File "/usr/src/supervisor/supervisor/dbus/agent/cgroup.py", line 19, in add_devices_allowed
await self.dbus.CGroup.AddDevicesAllowed(container_id, permission)
File "/usr/src/supervisor/supervisor/utils/dbus.py", line 172, in call_dbus
raise DBusFatalError(reply.body[0])
supervisor.exceptions.DBusFatalError: Can't find Container '028bbba77f90cdb27e93b8a1895c24c9c4c31e7a0ef85265b061ff6752d786f7' for adjust CGroup devices.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/supervisor/supervisor/jobs/decorator.py", line 108, in wrapper
raise err
File "/usr/src/supervisor/supervisor/jobs/decorator.py", line 106, in wrapper
return await self._method(*args, **kwargs)
File "/usr/src/supervisor/supervisor/docker/addon.py", line 707, in _hardware_events
raise DockerError(
supervisor.exceptions.DockerError: Can't set cgroup permission on the host for addon_de838cd8_raspberrymatic
Here is ha info
arch: amd64
channel: stable
docker: 20.10.5+dfsg1
features:
- reboot
- shutdown
- services
- network
- hostname
- timedate
- os_agent
hassos: null
homeassistant: 2022.2.9
hostname: debian
logging: info
machine: qemux86-64
operating_system: Debian GNU/Linux 11 (bullseye)
state: running
supervisor: 2022.01.1
supported: true
supported_arch:
- amd64
- i386
timezone: Europe/Berlin
Do you run cgroup2?
debian@debian:~$ mount | grep cgroup
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
Looks like it. It is a new Debian installation from a couple weeks ago.
We only support cgroup1 - I will ask our debian maintainer if he will lock into and fix the packages to change the system for running cgroup1. Maybe you will look into our amazing OS to avoid issues in future
I did the following now:
In /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet systemd.unified_cgroup_hierarchy=false"
Afterwards an update-grub
followed by a reboot
which worked around the supervisor issue for now.
Thanks a lot. Also seeing cgroup2 on my bullseye debian installation. Will attempt workaround.
I'm also using a supervised setup on archlinux arm on my raspberry together with RaspberryMatic. If have created patched os-agent which uses the cgroup2 interface, but currently grants rights to all device files (and also has some features disable I do not use). The main implementation is in this commit if some is interested. The cgroup2 code is copied from opencontainers/runc. The proper way in the future would probably be to use an API provided by the docker daemon UpdateContainer which should handle cgroup1 & 2 transparently. For some reason using the UpdateContainer API did not work. Using the API is necessary as the cgroup2 interface no longer uses interface files in the sysfs but instead BPF programs. My current implementation simply deletes all attached BPF programs and creates a new one allowing access to all devices.
EDIT: I'm glad to see that agners is working on it. See Issue: https://github.com/opencontainers/runc/issues/3401 and PR: https://github.com/opencontainers/runc/pull/3402
See the following kernel documentation. Cgroup2 no longer allows for easy adding of rules and therefore only a single instance (docker or systemd) should handle it and manage the BPF programs for a specific cgroup.
I have the same problem since the last update from the container of jensmaus . I also see the cgroup2 on my debian installation.
The solution from @sbyx didn´t work for me because i have no file /etc/default/grub. What can i do?
My container log: Mounting /data as /usr/local (Home Assistant Add-On): OK Starting watchdog... Identifying host system: oci, OK Initializing RTC Clock: no hardware found Running sysctl: OK Checking for Factory Reset: not required Checking for Backup Restore: not required Initializing System: OK Starting logging: OK Init onboard LEDs: init, OK Starting irqbalance: OK Starting iptables: OK Starting network: eth0: link up, fixed, firewall, inet up, 172.30.33.0, OK Identifying Homematic RF-Hardware: ....HmRF: HMIP-RFUSB/eQ-3 [email protected], HmIP: HMIP-RFUSB/eQ-3 [email protected], OK Updating Homematic RF-Hardware: HMIP-RFUSB: 4.4.16, not necessary, OK Starting hs485dLoader: disabled Starting xinetd: OK Starting eq3configd: OK Starting lighttpd: OK Starting ser2net: disabled Starting ssdpd: OK Starting ha-proxy: OK Starting NUT services: disabled Initializing Third-Party Addons: OK Starting LGWFirmwareUpdate: ...OK Setting LAN Gateway keys: OK Starting hs485d: disabled Starting multimacd: .OK Starting rfd: ....................ERROR Starting HMIPServer: .....................................................................................................ERROR Starting ReGaHss: .OK Starting CloudMatic: OK Starting NeoServer: disabled Starting Third-Party Addons: OK Starting crond: OK Setup onboard LEDs: booted, OK Finished Boot: 3.61.7.20220226 (raspmatic_oci_arm)
Please try out the latest release of the Home Assistant Supervised installer https://github.com/home-assistant/supervised-installer/releases/tag/1.1.1
I have a clean debian bullseye system. I have the following items on my kernel boot line
systemd.unified_cgroup_hierarchy=false systemd.legacy_systemd_cgroup_controller=false cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory
When attempting to install the package I get
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:
I pulled the the 1.1.1 tagged version of the deb and I still get this same result.
I have a bunch of arm boards running various things on arm based distros and none are using GRUB. It's not clear why the code would be looking for a grub file. If you can get this issue fixed it would be greatly appreciated.
I guess if you can tell me what you would want in /etc/default/grub I could dump a dummy file there.
If it matters I'm running debian bullseye on Odroid N2+ kernel 5.16.16.
I guess one way to fix the problem is to do the following
touch /etc/default/grub
Then put a script named update-grub in /bin that doesn't do anything
#!/bin/bash
echo $@ > /tmp/update-grub.out
Not a good solution but the install will complete
Seems like a fix for the package would be to do a check for the grub file and if it doesn't exist don't do anything, or if the intent is to get the cgroup right you could display a message telling the user they need to update their boot line with whatever is correct.
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
the problem is still not solved for me. i am using debian 11, latest updates applied. i have modified the grub config, but the issue persists. is there any solution other than not updating/using plugins that requiere elevated rights?
@filewalker1 did you run the latest supervised installer? https://github.com/home-assistant/supervised-installer/releases/tag/1.2.0
@ikifar2012 is it possible to run the installer again without messing up my installation? I installed HA some time ago using the latest installer at this time. i manually changed my grub-config file, but this does not help.
@ikifar2012 is it possible to run the installer again without messing up my installation? I installed HA some time ago using the latest installer at this time. i manually changed my grub-config file, but this does not help.
@filewalker1 Yes but I would recommend a backup just in case
@ikifar2012 thank you very much! now it is working as expected. Do i have to update the supvervised installer package manually if there is a new release on github?
@ikifar2012是否可以再次运行安装程序而不会弄乱我的安装?我前段时间使用最新的安装程序安装了 HA。我手动更改了我的 grub-config 文件,但这没有帮助。
@filewalker1是的,但我建议备份以防万一
Thanks, It works!
@ikifar2012 thank you very much! now it is working as expected. Do i have to update the supvervised installer package manually if there is a new release on github?
As of right now it does not update through a package repository, so yes you do have to manually update it
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.