After updating to Debian Bullseye: Docker doesn't work

I’ve got some problems after Upating from Debian Stretch to Debian Buster, and from Debian Buster to Debian Bullseye, since than my Docker containers are not running anymore.
I tried to reinstall Docker, but I get errors something with “Lua”, have no clue what this is.

It says I have to configure it, so I’ve tried “sudo dpkg --configure -a”, after this I get:

lua5.2 (5.2.4-1.1+b3) wird eingerichtet ...
update-alternatives: Fehler: Alternativen-Link /usr/bin/lua wird bereits von lua verwaltet
dpkg: Fehler beim Bearbeiten des Paketes lua5.2 (--configure):
 »installiertes lua5.2-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 2 zurü
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von luarocks:
 luarocks hängt ab von lua-any; aber:
  Paket lua-any ist noch nicht konfiguriert.

dpkg: Fehler beim Bearbeiten des Paketes luarocks (--configure):
 Abhängigkeitsprobleme - verbleibt unkonfiguriert
lua5.3 (5.3.3-1.1+b1) wird eingerichtet ...
update-alternatives: Fehler: Alternativen-Link /usr/bin/lua wird bereits von lua verwaltet
dpkg: Fehler beim Bearbeiten des Paketes lua5.3 (--configure):
 »installiertes lua5.3-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 2 zurü
Fehler traten auf beim Bearbeiten von:

I get the same errors when trying to “–force-remove” Lua.
I’ve also installed the previous version 5.2 and 5.1.
As you probably can see, I have no clue what the heck is going on, I just want my Docker containers back running :cry:

I should have stayed on Debian Stretch, everything was working with this release :frowning:
Can somebody please help? Which logs do you need, to point me in the right direction?

hope you have done a backup before, that could be used to restore your system. Did the issue happen on the update to Buster already? Was everything working on Buster?

If you don’t need the lua package, you could try to purge it

apt purge lua*

I’ve done a backup, nevertheless I am not sure if it’s complete, but I guess it it is. It just took very long, I let it run over night.
I have updated right away from Buster to Bullseye, as I’ve read the recommendation from DietPi to update to Bullseye because of the newest security updates.

With “apt purge lua”
I get the same error, like I’ve copied in my post.

with “apt purge lua*”
I get the error luarocks-3.8.0 can’t be found

From the first error message, what does Lua want if it says lua5.3 and lua 5.2 needs to be configured?
What exactly I have to configure, with which command?

I have realized now the backup didn’t work “backup not found”, but I am 100% sure that I run the backup command.

I get rid of this lua “virus” by typing the apt purge command with any lua package one after another, like apt purge lua-any, apt-purge lua5.3, apt purge luarocks and so on. Nevertheless this doesn’t fix the problem, that docker doesn’t work anymore since the Bullseye update. Tried also reboot and reinstall of Docker with dietpi-software reinstall

I found out that Docker buster release was installed, I’ve updated it to the newest Docker bullsye version. But this also doesn’t help, when running “sudo docker run hello-world” I get the error message
docker: Error response from daemon: OCI runtime create failed: cgroup namespaces aren’t enabled in the kernel: unknown.
ERRO[0001] error waiting for container: context canceled

what kind of device you are running? Can you share some system details?

Required Information

  • DietPi version | cat /boot/dietpi/.version
  • Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
  • Kernel version | uname -a
  • SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)



Linux dietpi 4.4.192-rockchip64 #1 SMP Tue Oct 8 18:39:24 CEST 2019 aarch64 GNU/Linux

ROCK64 (aarch64)

I’ve updated to DietPi Beta yesterday, but the error was also in the stable version.
I am also not sure, how I can update the kernel and which might work with arm64 device.

Basically it’s not an issue of DietPi. Your kernel is not supporting cgroup V2. Similar issues to this one

But I’m not sure if we have a solution for Rock64

Do you know?

With the command dpkg -l | grep linux-image I get:

ii  linux-image-4.4.126-rockchip-ayufan-239         0.6.44                                    arm64        Linux kernel, ver                                                sion 4.4.126-rockchip-ayufan-239
ii  linux-image-5.1.0-1114-ayufan-g097e5be61be4-dbg 5.1.0-1114-ayufan                         arm64        Linux kernel debu                                                gging symbols for 5.1.0-1114-ayufan-g097e5be61be4
ii  linux-image-5.9.0-1146-ayufan-gab09e252a729     5.9.0-1146-ayufan                         arm64        Linux kernel, ver                                                sion 5.9.0-1146-ayufan-gab09e252a729
ii  linux-image-rockchip64                          5.98                                      arm64        Linux kernel, ver                                                sion 4.4.192-rockchip64

How can I switch from 4.4.192 to 5.9.0-1146?
Maybe this topic is similiar not be able to upgrade to higher Kernel:

Or would it help (if this is possible) to downgrade from Bullseye to Buster?

Uii, this is an old Ayufan based image and related old kernel. Though they are still maintained as can be seen by the newer kernel packages installed already, and even Linux 5.13 builds are available in theory:

If you find some time to transfer you data and configs, then I’d still recommend to flash our new ROCK64 Bullseye image, based on current Armbian kernel, where we better know the setup, repository, what/how things work etc.

If you want/need to stay with this image, looks like we can also upgrade the kernel, but let’s see how it is setup currently:

uname -a
ls -al /boot
apt show linux-image-rockchip64
cat /etc/apt/sources.list.d/*.list

Thanks for looking into this. Great support here!

Actually I would prefer just to update the kernel (to 5.13), but don’t know how.
But if it’'s easy to backup and migrate Docker and my containers to the new ROCK64 Bullseye image you’ve mentioned I would also consider this.
Basically I have not really changed anything in Dietpi and software I have only installed samba server, docker, dropbear and webmin. That’s it.

root@dietpi:~# uname -a
Linux dietpi 4.4.192-rockchip64 #1 SMP Tue Oct 8 18:39:24 CEST 2019 aarch64 GNU/Linux
root@dietpi:~# ls -al /boot
insgesamt 128348
drwxr-xr-x  4 root root     4096  6. Dez 02:11 .
drwxr-xr-x 23 root root     4096  5. Dez 21:26 ..
-rw-r--r--  1 root root      180  1. Jan 2020  armbianEnv.txt
-rw-r--r--  1 root root   307322  2. Feb 2019  boot.bmp
-rw-r--r--  1 root root     2886 10. Jan 2019  boot.cmd
-rw-r--r--  1 root root     4882 10. Jan 2019  boot-desktop.png
-rw-rw-r--  1 root root     2958 17. Nov 2019  boot.scr
-rw-r--r--  1 root root   148020 27. Mai 2018  config-4.4.126-rockchip-ayufan-239
-rw-r--r--  1 root root   160164  8. Okt 2019  config-4.4.192-rockchip64
-rw-r--r--  1 root root   217239 19. Jan 2021  config-5.9.0-1146-ayufan-gab09e252a729
drwxr-xr-x  4 root root     4096  5. Dez 16:46 dietpi
-rw-r--r--  1 root root     7588 12. Apr 2020  DietPi_OpenVPN_Client.ovpn
-rw-r--r--  1 root root     8196 29. Jan 2019
-rw-r--r--  1 root root    11599  5. Dez 16:29 dietpi.txt
lrwxrwxrwx  1 root root       22 17. Nov 2019  dtb -> dtb-4.4.192-rockchip64
drwxr-xr-x  3 root root     4096 17. Nov 2019  dtb-4.4.192-rockchip64
lrwxrwxrwx  1 root root       22  2. Feb 2019  dtb.old -> dtb-4.4.172-rockchip64
lrwxrwxrwx  1 root root       26 17. Nov 2019  Image -> vmlinuz-4.4.192-rockchip64
-rw-r--r--  1 root root  5410224  5. Dez 21:16 initrd.img-4.4.126-rockchip-ayufan-239
-rw-r--r--  1 root root  6017583  4. Dez 19:22 initrd.img-4.4.192-rockchip64
-rw-r--r--  1 root root 14582559  6. Dez 02:11 initrd.img-5.9.0-1146-ayufan-gab09e252a729
-rw-r--r--  1 root root        0 17. Nov 2019  .next
-rw-r--r--  1 root root  4660138 27. Mai 2018
-rw-r--r--  1 root root  4391578  8. Okt 2019
-rw-r--r--  1 root root  5208490 19. Jan 2021
lrwxrwxrwx  1 root root       39  6. Dez 02:11 uInitrd -> uInitrd-5.9.0-1146-ayufan-gab09e252a729
-rw-r--r--  1 root root  5410288  5. Dez 21:17 uInitrd-4.4.126-rockchip-ayufan-239
-rw-r--r--  1 root root  6017647  4. Dez 19:22 uInitrd-4.4.192-rockchip64
-rw-r--r--  1 root root 14582623  6. Dez 02:11 uInitrd-5.9.0-1146-ayufan-gab09e252a729
-rwxr-xr-x  1 root root 19726344 27. Mai 2018  vmlinuz-4.4.126-rockchip-ayufan-239
-rwxr-xr-x  1 root root 18890760  8. Okt 2019  vmlinuz-4.4.192-rockchip64
-rw-r--r--  1 root root 25582080 19. Jan 2021  vmlinuz-5.9.0-1146-ayufan-gab09e252a729
root@dietpi:~# apt show linux-image-rockchip64
Package: linux-image-rockchip64
Version: 5.98
Status: install ok installed
Priority: optional
Section: kernel
Source: linux-4.4.192-rockchip64
Maintainer: Igor Pecovnik <igor.pecovnik@****>
Installed-Size: 87,2 MB
Provides: linux-image, linux-image-2.6, linux-modules-4.4.192-rockchip64
Suggests: linux-firmware-image-rockchip64
Download-Size: unbekannt
APT-Manual-Installed: yes
APT-Sources: /var/lib/dpkg/status
Description: Linux kernel, version 4.4.192-rockchip64
 This package contains the Linux kernel, modules and corresponding other
 files, version: 4.4.192-rockchip64.

root@dietpi:~# cat /etc/apt/sources.list.d/*.list
# deb bullseye main
deb /
deb [arch=arm64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg]   bullseye stable
deb sarge contrib

Okay this is pretty confusing. It seems there are Armbian kernel + boot config and Ayufan kernel mixed on your system. Did you manually added kernel packages or other repositories in attempt to get a newer version? I see the disabled but present Armbian repository entry. I worry about e.g. the Linux image and device trees being linked to the Armbian 4.4.192 kernel, which also is the one loaded, but the initramfs is linked to Ayufan’s Linux 5.9 based uInitrd. When cleaning this up, we need to be careful to not render the system unbootable since e.g. I have no idea which bootloader is really in use. But actually it looks like it is originally an old Armbian image, while the Ayufan repository has been added later for unknown reasons, probably by you in attempt to get a newer kernel?

The post you deleted btw contained some helpful information. Why did you delete it?

However, let’s start with some safe cleanup of those kernel images which are definitely not in use:

apt purge linux-image-4.4.126-rockchip-ayufan-239 linux-image-5.1.0-1114-ayufan-g097e5be61be4-dbg
rm /boot/{,DietPi_OpenVPN_Client.ovpn,dtb.old}

Then we need some more information about the partition table and installed U-Boot packages, and the boot configuration:

fdisk -l "$(lsblk -npo PKNAME "$G_ROOTFS_DEV")"
dpkg -l | grep 'u-boot'
cat /boot/boot.scr

And from your deleted post, I saw that you have added the experimental Debian repository, which I would remove as long as you do not know exactly what the impact of this is. So let’s assure the standard Debian Bullseye repo parts are added only:

cat << '_EOF_' > /etc/apt/sources.list
deb bullseye main contrib non-free
deb bullseye-updates main contrib non-free
deb bullseye-security main contrib non-free
deb bullseye-backports main contrib non-free
apt update

If it indeed turns out to be an Armbian image, or at least with a compatible partition table, then we can simply install the newest Armbian kernel (5.10) and U-Boot.

I’ve added some newer kernel packages from ayufan, but I was not able to upgrade the kernel. At least I wanted a kernel with version 5.x, which could handle cgroup namespaces. Also tried a workaround with a namespace command loaded at boot, but this also didn’t work.

Sorry for deleting the post, was kinda frustated and thought what I did there had made not much sense anyway and didn’t want to spam the forum too much :smiley:

In the meantime I thought about the second option again, to start with a new Dietpi bullseye image. Maybe there’s to much mixed up with the kernel/system now. And probably I’ve already wasted to much time trying to upgrade the kernel or to workaround this cgroup namespace errorr. In this time I might had already a running system, if I had started with a fresh install.
Backing up the docker containers was quite easy, but from my linux eperience so far, I’m afraid, there will be still something which will prevent to restore them properly… let’s see.

Okay so then I’m pretty sure it’s an Armbian image which makes the kernel upgrade very easy. But please run the commands provided above for initial cleanup and to get some more info assuring that what I think is true :slight_smile:.

Sorry, saw your post to late. Flashed the newest Dietpi Bullseye image and everything is back to normal now, I should have done it this way in the first place.
The last kernel which was active was 4.192 from ayufan, don’t know about Armbian.
Thanks for your help.

Okay great, this was certainly the cleanest way :slight_smile:.