Updated to latest supervisor and despite mentioned changes still get "unsupported installation"

Configuration
1

I updated the supervisor to supervisor-2022.06.2 on my otherwise up to date HA supervised setup on Debian bullseye (which is btw up to date) and got the “unsupported installation” info.

The “LEARN MORE” button led to Docker Configuration - Home Assistant which listed changes I had to do. The changes to docker were already in the system so I changed the grub setting of GRUB_CMDLINE_LINUX_DEFAULT to “systemd.unified_cgroup_hierarchy=false”

An update showed up and on trying to update the Terminal & SSH add-on I got the error message “Can’t install homeassistant/amd64-addon-ssh:9.5.0: 404 Client Error for http+docker://localhost/v1.41/images/create?tag=9.5.0&fromImage=homeassistant%2Famd64-addon-ssh&platform=linux%2Famd64: Not Found (“manifest for homeassistant/amd64-addon-ssh:9.5.0 not found: manifest unknown: manifest unknown”)”. This means likely that I have to solve the issue with the supervisor to be able to update the add-ons, right?

I did a restart of HA and a reboot but nothing changed. The message "You are running an unsupported installation " is still showing up.

Anyone out the able to help? TIA!!!

Here the system info:

System Health

version: core-2022.6.7
installation_type: Home Assistant Supervised
dev: false
hassio: true
docker: true
user: root
virtualenv: false
python_version: 3.9.12
os_name: Linux
os_version: 5.10.0-15-amd64
arch: x86_64
timezone: Europe/Berlin

GitHub API: ok
GitHub Content: ok
GitHub Web: ok
GitHub API Calls Remaining: 3326
Installed Version: 1.25.5
Stage: running
Available Repositories: 1070
Downloaded Repositories: 90

can_reach_server: ok
remaining_requests: 15

logged_in: false
can_reach_cert_server: ok
can_reach_cloud_auth: ok
can_reach_cloud: ok

host_os: 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: 115.9 GB
disk_used: 24.1 GB
healthy: true
supported: failed to load: Unsupported
supervisor_api: ok
version_api: ok
installed_addons: ESPHome (2022.6.2), Home Assistant Google Drive Backup (0.108.2), Studio Code Server (5.1.2), MariaDB (2.4.0), Terminal & SSH (9.4.0), Mosquitto broker (6.1.2), Tor (4.0.0), Uptime Kuma (0.1.0), InfluxDB (4.5.0), Grafana (7.6.0)

dashboards: 5
resources: 10
views: 29
mode: yaml

oldest_recorder_run: June 6, 2022 at 10:02
current_recorder_run: July 6, 2022 at 12:31
estimated_db_size: 1663.42 MiB
database_engine: mysql
database_version: 10.4.19

2

Similar problem. Docker config was as required. Created new /etc/default/grub with single line:
GRUB_CMDLINE_LINUX_DEFAULT=“systemd.unified_cgroup_hierarchy=false”
Rebooted. No change, still unsupported. Was not unsupported before upgraded supervisor.

1 Like
3

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.

Version core-2022.6.7
Installation Type Home Assistant OS
Development false
Supervisor true
Docker true
User root
Virtual Environment false
Python Version 3.9.12
Operating System Family Linux
Operating System Version 5.15.45
CPU Architecture x86_64
Timezone America/Chicago
4

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:

$ cat /etc/docker/daemon.json
{
    "log-driver": "journald",
    "storage-driver": "overlay2"
}
$
5

Experiencing the same error message. Any resolution?

6

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?

2 Likes
7

I have Home Assistant Supervised on a Raspberry Pi with Debian 11 installed.
So, I do not have /etc/default/grub file

8

Ok in that case did you try re-running the installation script as per the alternative suggestion?

9

Do I have to perform all these steps and thank you for your time and assistance…

image
image876×635 6.6 KB

10

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.
11

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!

12

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! :smiley:

1 Like
13

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.

Well, not too hard. See Guide: Installation of *VANILLA* Debian 11 (or later) on a Raspberry Pi 4 - Raspberry Pi Forums and FLOSSLinux: Vanilla Debian on a Raspberry Pi 4 with UEFI.

I’ll try it and report back (unless someone has already done so)?

2 Likes
14

UPDATE: so to make sure this is correct.… THis works… Verified with screenshot below…just update /etc/default/grub
Then make this line:

GRUB_CMDLINE_LINUX_DEFAULT="quiet"

look like this…

GRUB_CMDLINE_LINUX_DEFAULT="quiet systemd.unified_cgroup_hierarchy=false"
and then run the grub update command.

image

2 Likes
15

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"

I am lost. Can anyone help?

16

You have HA Supervised running on Ubuntu, that’s not supported. It’s supposed to say unsupported for you, that’s not a bug.

Or are you not able to get supervisor to start? If so there’s a thread here with a lot of other users on Ubuntu with some suggestions to try:

17

I just updated to a Debian Bullseye on my RPi4 and I’m having the same issue. Have managed to fix all the other unsupported messages, except this one.

The config file already had the correct lines in it. I remade it just Incase, no change.

I don’t use grub, so that part makes no sense.

I’m not sure what to try next.

1 Like
18

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.

2 Likes
19

Worked for me - Many Thanks

20

Hi There,

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…

Hope this can help someone

1 Like