Supervisor update

This is what happen to docker

[email protected]:/etc# docker ps
[email protected]:/etc# docker ps -a
CONTAINER ID   IMAGE                                     COMMAND        CREATED          STATUS                      PORTS                                                 NAMES
ca77c48b366e   homeassistant/aarch64-hassio-supervisor   "/init"        2 seconds ago    Created                                                                           hassio_supervisor
df241d978714   portainer/portainer-ce                    "/portainer"   52 minutes ago   Exited (2) 25 minutes ago   8000/tcp,>9000/tcp, :::9000->9000/tcp   portainer

When I do docker ps show nothing but if I put docker ps -a it show my container.

Portainer is now cant be called from port 9000 and suppose to be running, before reboot I can access it. So there are something being done by the supervisor scripts that break docker. The system keep on making machine-id directory.

This is not happening on VM only on RPI4

Take a look at the link I’ve send before on how to handle machine-id correctly.


docker run hassio_supervisor

Stop the bus,

Do you have the debian 11 (bullseye) version of docker. This exactly what happened to me.

1 Like

I run curl -fsSL | sh to install docker

So far I do not see any solution other than making an assumption that there are bugs on the current supervisor-install. I try to follow Kange-Who guide Installing Home Assistant Supervised on Debian 11 - Community Guides - Home Assistant Community ( and try my old Debian 10 script which has been modified to cater Debian 11. Tested in multiply attempts and it keeps making some problems.

The problem is clear that hassio-supervisor when it first runs creates /etc/machine-id and `/var/lib/dbus/machine-id’ as a directory instead of files. Removing both directories won’t delete it as long hassio-supervisor is up and running.

Temporary solutions (thanks to @Tamsy) for his guide by making these steps.

$ service hassio-supervisor stop
$ rm -f /etc/machine-id
$ rm /var/lib/dbus/machine-id
$ dbus-uuidgen --ensure=/etc/machine-id
$ dbus-uuidgen --ensure
$ systemctl reboot

and you will have a working Docker + HA

The problem only happen to Raspberry Pi 4, the same problem did not occur on my proxmox install running Debian 11 Cloud

I did a clean install on a Pi 4, 2 days ago to update my guide for Debian 11. Worked perfectly and no issues encountered.

I doubt that the issue with machine-id you encounter has anything to do with the install-script at @kanga_who’s instructions nor with bugs on the current supervisor-install.

From the Debian-Wiki:

The /etc/machine-id file contains the unique machine ID of the local system that is set during installation or boot. The machine ID is a single newline-terminated, hexadecimal, 32-character, lowercase ID. When decoded from hexadecimal, this corresponds to a 16-byte/128-bit value. This ID may not be all zeros.

What is it used for:

  • Creation of DHCP host identifier (probably causing multiple machines fighting over the same IP address on the DHCP server)
  • GNOME stores screen layout configuration keyed by machine ID
  • The systemd-boot EFI bootloader stores the OS installation’s kernel(s) in a directory named after the machine ID to prevent collisions.

More details here.

As you can see there is no correlation between machine-id and HA and/or supervisor-install.

1 Like

Can someone please help me with this? Where I should look on Debian Bullseye on a Intel based machine (not virtual, no Proxmox)

I can’t find, which file to edit. Modifying kernel is not on my experience list…

So I also now have RAM usage showing 0, everything else runs fine (latest Debian, latest HA + supervisor)

Versie van het besturingssysteem 5.10.0-8-amd64
CPU-architectuur x86_64

On the x86 architecture that file should be /proc/cmdline

You can easily check (the actual content) by typing:
$ cat /proc/cmdline

You cannot edit /proc/cmdline

That file is created by the kernel when it boots. It reflect what is running, not what will run on next boot.

That is correct. That is why I wrote

For configuring kernel parameters permanently you have to work with syctl but I am not really advise to do so unless you know exactly what you are doing :no_mouth:

The question was “what file do I edit” to which you replied “the file is /proc/cmdline”.

You can see why I misunderstood you :slight_smile:

1 Like

I didn’t read bebe’s message carefully enough. My apologize for that.

@BebeMischa: For Debian on x86_64 with GRUB installed as bootloader to add kernel parameters and make them persistent you have to edit:

$ sudo nano /etc/default/grub

Find the line starting with:

and add the new parameters:
GRUB_CMDLINE_LINUX_DEFAULT="[whatever-is-already-in-there] systemd.unified_cgroup_hierarchy=false systemd.legacy_systemd_cgroup_controller=false"

(all in one line, each command seperated with [space] and inbetween the quotation marks)

Save the file and close the editor.

Now run:
$ sudo update-grub

If no error message pops up, on the next reboot the kernel should be started with the new boot parameters.

To verify your changes after reboot execute:
$ sudo cat /proc/cmdline


And we have an error…

/usr/sbin/grub-mkconfig: 10: /etc/default/grub: systemd.unified_cgroup_hierarchy=false: not found

sure the syntax is correct like this?

Remove systemd.unified_cgroup_hierarchy=false from

and add it to
GRUB_CMDLINE_LINUX="" (inbetween the quotation marks and separated by [space] if there are other commands)

Then execute:
$ sudo update-grub

If the command is accepted by GRUB do a reboot and verify the changes thereafter:
$ sudo cat /proc/cmdline

1 Like

That did the trick. Thank you very much.
It works, I do see RAM usage again.

1 Like

Excellent :+1:t3:

1 Like

Where should we add systemd.unified_cgroup_hierarchy=false and systemd.legacy_systemd_cgroup_controller=false in a Pi4? I added them in /boot/cmdline.txt, rebooted but it doesn’t seem to make a difference (I still see no RAM usage).

Edit: Indeed the output of cat /proc/cmdline verifies that the above parameters have been set. But I see no difference (eg. RAM usage).

As for the RPI4 on Debian the file is located at:


Don’t forget to reboot the host after you have made changes to that file:
$ sudo systemctl reboot