I am getting the same error as well. I also removed the older version of Terminal/SSH add-on (9.4 that was working fine) and tried to install 9.5 and received the same error. I had to restore 9.4 after that from backup. But unable to update to 9.5.
Noticed the same here, saw that the Docker Configuration - Home Assistant page suggested the GRUB_CMDLINE_LINUX_DEFAULT modification so I did that rebooted the host and the problem persists. I also verified that I have my daemon.json configured as recommended:
I just added a step to the solution at the “learn more” link based this comment. After updating /etc/default/grub run sudo update-grub and then reboot. Can you give that a shot and see if it fixes it?
Step 4 is the one that I believe should fix it so could try just doing that and skipping the others. That being said you might want to do them anyway:
Step 1 should be very quick if you’re up to date and if not then it’ll get you up to date.
Step 2 isn’t as quick but I can tell you there’s a ton of threads around supervised installs today where the solution was “update docker”. So if you haven’t done that in a bit I would run that step just in case.
Step 3 you can probably skip unless you haven’t done any updates on the host OS since before october 2021 (last release of OS agent). If you think it might’ve been that long then definitely do all these steps.
I executed step 1 and 2 not knowing an update might be necessary, but in the end update-grub was my path to remove the message about the system being unsupported . Thanks Mike!
Ah! I knew something was amiss when I edited the grub file without running something after… I couldn’t remember the update-grub was required to regenerate the init files. Thanks for posting this. I’m no longer unsupported!
I have four HASS installations, all on Debian supervised. The two on Intel processors were fixed as in the directions (including update-grub). They are again “supported.”
However the two pi4B Debian installations do not boot using Grub. These were installed using the “tested” image distributed by "raspi.debian.net/tested-images." Previously, these installations showed as supported. I suspect that the check for “cgroup version 1” is new and does not take into account the piB4. It is possible to use Grub with the Pi. OpenSUSE does so, but not the standard Debian image.
So, another version of the Supervisor is needed, or a version of Debian with Grub. I’ll look further into the latter.
I have tried the suggested solution but it still does not work for me so I have reverted my /etc/default/grub file to what it was prior to the problem I have listed the grub file below
I am running 2022.6.7 on a NUC-i3 with Ubuntu as an OS
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'
GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
Please see my post above. Since tested images for Debian on Pi4B do not use Grub and the test for “Supported” requires Grub, your installation cannot be supported. You may note that Supervised is listed as an installation option for Linux, but not Raspberry Pi.
However, I have recently completed installing Debian Bullseye on pi4B with Grub and have completed the supervised installation of HA. In a short time I will confirm that this installation reports as supported. OK, confirmed.
Facing the same issue on a totally out of support Nanopi Neo 3 running Armbian Bullseye, I could find back the way of support by adding the right configuration at the the right place.
What’s required is to launch the kernel with this specific Systemd parameter:
systemd.unified_cgroup_hierarchy=false
So basically in grub as it’s the system loader for many PCs, but which is not for many SBC (all ?).
But to achieve this, there are other ways, like in my Nanopi, I just had to edit /boot/armbianEnv.txt file and append to following in a new line:
extraargs=systemd.unified_cgroup_hierarchy=false
I believe there is a similar possibility using /boot/cmdline.txt with Raspberry PI…
Finally I found how to get rid of “Unsupported System - Docker CGroup Version” on a Raspberry PI 4: add systemd.unified_cgroup_hierarchy=false to the file /boot/cmdline.txt
This solution also solved my issue, i searched a lot of website and forums, never one solved this problem off my Armbian Bookworm os on installed Orange Pi 3 Lts.
Thanks mmz06
