Supervisor update

KingRichard · September 9, 2021, 5:16am

This is what happen to docker

root@kedoyaha:/etc# docker ps
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES
root@kedoyaha:/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, 0.0.0.0:9000->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

Tamsy · September 9, 2021, 5:21am

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

nickrout · September 9, 2021, 5:23am

do

docker run hassio_supervisor

nickrout · September 9, 2021, 5:25am

Stop the bus,

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

KingRichard · September 9, 2021, 6:33am

I run curl -fsSL get.docker.com | sh to install docker

KingRichard · September 9, 2021, 9:10am

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 (home-assistant.io) 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

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

kanga_who · September 9, 2021, 10:18am

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.

Tamsy · September 9, 2021, 11:19am

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.

BebeMischa · September 9, 2021, 7:52pm

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

Tamsy · September 10, 2021, 12:16am

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

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

nickrout · September 10, 2021, 12:20am

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.

Tamsy · September 10, 2021, 12:46am

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

nickrout · September 10, 2021, 1:44am

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

You can see why I misunderstood you

Tamsy · September 10, 2021, 2:20am

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:
GRUB_CMDLINE_LINUX_DEFAULT="[whatever-is-already-in-there]"

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

BebeMischa · September 10, 2021, 2:56pm

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?

Tamsy · September 11, 2021, 2:05am

Remove systemd.unified_cgroup_hierarchy=false from
GRUB_CMDLINE_LINUX_DEFAULT=

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

Then execute:
$ sudo update-grub

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

BebeMischa · September 11, 2021, 7:03am

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

Tamsy · September 11, 2021, 7:20am

Excellent

Tryfos · September 16, 2021, 7:10pm

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

Tamsy · September 17, 2021, 12:42am

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

/boot/firmware/cmdline.txt

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