do
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 get.docker.com | 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 (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
1 Like
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 
The question was “what file do I edit” to which you replied “the file is /proc/cmdline”.
You can see why I misunderstood you 
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:
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
3 Likes
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
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
1 Like
That did the trick. Thank you very much.
It works, I do see RAM usage again.
1 Like
Excellent 
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:
/boot/firmware/cmdline.txt
Don’t forget to reboot the host after you have made changes to that file:
$ sudo systemctl reboot
Thanks, but there is no ‘firmware’ folder in /boot for me (pi 4 Debian 11 64).Cmdline.txt is in the root of /boot . As I said before, I added the lines there but nothing changed.
Have you mounted the boot partition?