home-assistant / supervised-installer

Installer for a generic Linux system
Apache License 2.0
1.73k stars 588 forks source link

Bug Report: script will not fix cgroup v1 setting when u-boot bootloader is used #253

Closed Ventusfahrer closed 1 year ago

Ventusfahrer commented 2 years ago

OS Version

Debian GNU/Linux 11 (bullseye)

System Information

Linux 7vhas 6.0.8 #1 SMP PREEMPT Mon Nov 14 16:12:47 CET 2022 aarch64 GNU/Linux

What happened?

The operating system image was prepared and successfully installed using a Debian Bullseye kernel which I build with: https://github.com/pyavitz/debian-image-builder

After the successfull installation - without error message the system started and I got the:

Unsupported system - CGroup version

message.

Rerunning as advised:

dpkg -i homeassistant-supervised.deb

Machine Type

odroid-n2

Installer output

root@7vhas:~# dpkg -i homeassistant-supervised.deb
(Lese Datenbank ... 56046 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von 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.
»Umleitung von /etc/NetworkManager/NetworkManager.conf zu /etc/NetworkManager/NetworkManager.conf.real durch homeassistant-supervised« wird beibehalten
»Umleitung von /etc/NetworkManager/system-connections/default zu /etc/NetworkManager/system-connections/default.real durch homeassistant-supervised« wird beibehalten
»Umleitung von /etc/docker/daemon.json zu /etc/docker/daemon.json.real durch homeassistant-supervised« wird beibehalten
»Umleitung von /etc/network/interfaces zu /etc/network/interfaces.real durch homeassistant-supervised« wird beibehalten
Entpacken von homeassistant-supervised (1.3.1) über (1.3.1) ...
homeassistant-supervised (1.3.1) wird eingerichtet ...
[info] Restarting NetworkManager
[info] Restarting docker service
PING checkonline.home-assistant.io(2606:4700:20::681a:5ee (2606:4700:20::681a:5ee)) 56 data bytes
64 bytes from 2606:4700:20::681a:5ee (2606:4700:20::681a:5ee): icmp_seq=1 ttl=58 time=19.7 ms

--- checkonline.home-assistant.io ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 19.733/19.733/19.733/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/firmware/cmdline.txt failed to switch to cgroup v1
[info] Within a few minutes you will be able to reach Home Assistant at:
[info] http://homeassistant.local:8123 or using the IP address of your
[info] machine: http://192.168.221.201:8123
root@7vhas:~#

Relevant log output

[warn] Could not find /etc/default/grub or /boot/firmware/cmdline.txt failed to switch to cgroup v1

It looks like supervised installer only supports the usage of grub as boot manager. The above image is obviously using U-Boot as boot manager.
Coud you please advise me how to fix the situation?

Thanks and kind regards

Peter

ADR

Code of Conduct

Ventusfahrer commented 1 year ago

maybe it is worth to have also a look at:

https://github.com/pyavitz/debian-image-builder/issues/47

If the cgroup v1 needs to be fixed in /boot/config.ini, the .deb package is not fixing it.

adammohammed commented 1 year ago

I ran into this issue as well with the ubuntu image for the odroid M1. I resolved it by following the steps on hardkernel for updating kernel params.

So I just added the following to the /etc/default/flash-kernel:

LINUX_KERNEL_CMDLINE_DEFAULTS="apparmor=1 security=apparmor systemd.unified_cgroup_hierarchy=false"

Then following the docs again, I ran sudo /usr/sbin/update-bootscript which wrote a new boot.scr and rebooted.

To verify, you can check /proc/cmdline and check for your new settings:


cat /proc/cmdline 
apparmor=1 security=apparmor systemd.unified_cgroup_hierarchy=false  root=/dev/nvme0n1p2 rootwait ro quiet earlycon=uart8250,mmio32,0xfe660000 pci=nomsi fsck.mode=force fsck.repair=yes mtdparts=sfc_nor:0x20000@0xe0000(env),0x200000@0x100000(uboot),0x100000@0x300000(splash),0xc00000@0x400000(firmware) console=tty1

I don't have an N2, but it looks like something similar should be possible.

...

I did some more testing and I'm not sure with the hardkernel images if we even need to worry about disabling v2 cgroups. If I run a mount -l | grep cgroup I see the following:

tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)

The multple entries under /sys/fs/ indicate to me that this isn't just using v2. If I run the same on a x86_64 machine on a newer kernel version, I will only see the /sys/fs/cgroup with type cgroup2.

mokkin commented 1 year ago

I'm getting the same on a fresh install on RaspberryPi4-64:

[warn] Could not find /etc/default/grub or /boot/firmware/cmdline.txt failed to switch to cgroup v1
Ventusfahrer commented 1 year ago

I ran into this issue as well with the ubuntu image for the odroid M1. I resolved it by following the steps on hardkernel for updating kernel params.

So I just added the following to the /etc/default/flash-kernel:

LINUX_KERNEL_CMDLINE_DEFAULTS="apparmor=1 security=apparmor systemd.unified_cgroup_hierarchy=false"

Then following the docs again, I ran sudo /usr/sbin/update-bootscript which wrote a new boot.scr and rebooted.

To verify, you can check /proc/cmdline and check for your new settings:

cat /proc/cmdline 
apparmor=1 security=apparmor systemd.unified_cgroup_hierarchy=false  root=/dev/nvme0n1p2 rootwait ro quiet earlycon=uart8250,mmio32,0xfe660000 pci=nomsi fsck.mode=force fsck.repair=yes mtdparts=sfc_nor:0x20000@0xe0000(env),0x200000@0x100000(uboot),0x100000@0x300000(splash),0xc00000@0x400000(firmware) console=tty1

I don't have an N2, but it looks like something similar should be possible.

...

I did some more testing and I'm not sure with the hardkernel images if we even need to worry about disabling v2 cgroups. If I run a mount -l | grep cgroup I see the following:

tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)

The multple entries under /sys/fs/ indicate to me that this isn't just using v2. If I run the same on a x86_64 machine on a newer kernel version, I will only see the /sys/fs/cgroup with type cgroup2.

this is not working. The operating system was installed using petitboot and the USB-OTG option.

When installed with petitboot /boot/cmdline.ini is the right place to put the parameters to.

This file will only exist, when installing HA-Supervised using the 3rd-Party Software Installers in the menu-config script of https://github.com/pyavitz/debian-image-builder installed image.

When just performing the OS-Image installation and installing the Supervised-HA manually th config.ini is missing.

For more information see above referenced issue of the debian-image-builder

hellresistor commented 1 year ago

I'm getting the same on a fresh install on RaspberryPi4-64:

[warn] Could not find /etc/default/grub or /boot/firmware/cmdline.txt failed to switch to cgroup v1

i have got this warning now (10minutes ago, last version ~3hours ago). tomorrow will try it again with a new clean system, will use both os debian11 and rapiOS. @mokkin where you getting your os image?

Debian 11 arm 64bits -> /boot/firmware/cmdline.txt RaspberryPi OS (debian11) arm 64bits lite -> /boot/cmdline.txt

depend on 32bits/arm64 will be a different location to store systemd.unified_cgroup_hierarchy=0 in end of line cmdline.txt file

thats what i noticed , hope help

lazy lines sed -i 's/.*/& systemd.unified_cgroup_hierarchy=0/' /boot/firmware/cmdline.txt

purcell-lab commented 1 year ago

I just added the following to the /etc/default/flash-kernel:

LINUX_KERNEL_CMDLINE_DEFAULTS="apparmor=1 security=apparmor systemd.unified_cgroup_hierarchy=false"

Then following the docs again, I ran sudo /usr/sbin/update-bootscript which wrote a new boot.scr and rebooted.

Thanks, I had the same issue on an N2+, and your hints got me back into cgroup v1.

github-actions[bot] commented 1 year ago

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.

vst-name commented 10 months ago

I've had the similar issues with orange pi zero 3 Debian arch image. GRUB wasn't on the provided system, so i've installed it with sudo apt-get install grub2-common sudo nano /etc/default/grub sudo touch /etc/default/grub echo GRUB_CMDLINE_LINUX_DEFAULT="quiet splash apparmor=1 security=apparmor systemd.unified_cgroup_hierarchy=false" >> /etc/default/grub cd /boot mkdir grub sudo update-grub reboot

And then reinstall dpkg -i homeassistant-supervised.deb That seemed to have resolved the issue for me

Hope that would help to someone coming from SEO.

btw, home assistant container was refusing connections without active firewall on host i've setup ufw with ufw allow 8123 image

hellresistor commented 10 months ago

this will happen everytime you run 'sudo apt upgrade' , /boot/firmware/cmdline.txt will change.. after change. make a backup. this was my workaround or just create a basic script add aliases to replace backedup file after sun upgrade cmd.

on next upgrade i wil try your method @vst-name