Docker lässt sich nicht starten

Hallo,

UCS 5.0-6 errata916, Apps: Nextcloud, RocketChat

Der betroffene Server läuft seit ca. 2 Jahren. Letzte Woche war Nextcloud plötzlich nicht mehr zu erreichen, da docker nicht gestartet war. Der Versuch docker manuell zu starten, lieferte folgende Fehlermeldung.

Der Dienst docker konnte nicht neugestartet werden:
● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/docker.service.d
└─http-proxy.conf
Active: activating (auto-restart) (Result: exit-code) since Sat 2024-01-20 14:52:48 CET; 11ms ago
Docs: https://docs.docker.com
Process: 1951 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock (code=exited, status=1/FAILURE)
Main PID: 1951 (code=exited, status=1/FAILURE)

Jan 20 14:52:51 ucs-1753 systemd[1]: docker.service: Service RestartSec=2s expired, scheduling restart.
Jan 20 14:52:51 ucs-1753 systemd[1]: docker.service: Scheduled restart job, restart counter is at 1.
Jan 20 14:52:51 ucs-1753 systemd[1]: Stopped Docker Application Container Engine.
Jan 20 14:52:51 ucs-1753 systemd[1]: Starting Docker Application Container Engine...
Jan 20 14:52:51 ucs-1753 dockerd[1970]: time="2024-01-20T14:52:51.240329370+01:00" level=info msg="Starting up"
Jan 20 14:52:51 ucs-1753 dockerd[1970]: time="2024-01-20T14:52:51.310334246+01:00" level=info msg="parsed scheme: \"unix\"" module=grpc
Jan 20 14:52:51 ucs-1753 dockerd[1970]: time="2024-01-20T14:52:51.310358177+01:00" level=info msg="scheme \"unix\" not registered, fallback to default scheme" module=grpc
Jan 20 14:52:51 ucs-1753 dockerd[1970]: time="2024-01-20T14:52:51.310385223+01:00" level=info msg="ccResolverWrapper: sending update to cc: {[{unix:///run/containerd/containerd.sock 0 <nil>}] <nil>}" module=grpc
Jan 20 14:52:51 ucs-1753 dockerd[1970]: time="2024-01-20T14:52:51.310404476+01:00" level=info msg="ClientConn switching balancer to \"pick_first\"" module=grpc
Jan 20 14:52:51 ucs-1753 dockerd[1970]: time="2024-01-20T14:52:51.311523398+01:00" level=info msg="parsed scheme: \"unix\"" module=grpc
Jan 20 14:52:51 ucs-1753 dockerd[1970]: time="2024-01-20T14:52:51.311541389+01:00" level=info msg="scheme \"unix\" not registered, fallback to default scheme" module=grpc
Jan 20 14:52:51 ucs-1753 dockerd[1970]: time="2024-01-20T14:52:51.311559715+01:00" level=info msg="ccResolverWrapper: sending update to cc: {[{unix:///run/containerd/containerd.sock 0 <nil>}] <nil>}" module=grpc
Jan 20 14:52:51 ucs-1753 dockerd[1970]: time="2024-01-20T14:52:51.311574851+01:00" level=info msg="ClientConn switching balancer to \"pick_first\"" module=grpc
Jan 20 14:52:51 ucs-1753 dockerd[1970]: time="2024-01-20T14:52:51.316621054+01:00" level=error msg="failed to mount overlay: no such device" storage-driver=overlay2
Jan 20 14:52:51 ucs-1753 dockerd[1970]: time="2024-01-20T14:52:51.316654214+01:00" level=error msg="[graphdriver] prior storage driver overlay2 failed: driver not supported"
Jan 20 14:52:51 ucs-1753 dockerd[1970]: failed to start daemon: error initializing graphdriver: driver not supported
Jan 20 14:52:51 ucs-1753 systemd[1]: docker.service: Main process exited, code=exited, status=1/FAILURE
Jan 20 14:52:51 ucs-1753 systemd[1]: docker.service: Failed with result 'exit-code'.
Jan 20 14:52:51 ucs-1753 systemd[1]: Failed to start Docker Application Container Engine.

lsmod | grep overlay liefert kein Ergebnis.
uname -r liefert 4.9.0-12-amd64.

Es wird also ein veralteter Kernel geladen. Wo der herstammt, ist mir nicht klar, da er auf der Platte nirgends zu finden ist.
initrd.img und vmlinux verweisen auf boot/initrd.img-4.19.0-25-amd64.

Hat jemand eine Idee, wie ich grub repariere, damit der Kernel 4.19.0-25-amd64 geladen wird.

Gruß
George

Schaue mal nach, wie voll die Partition /boot ist.
Es steht zu vermuten, dass wegen fehlenden Speicherplatzes die Kernel-Updates nicht erfolgt sind. Sie hierzu auch /var/log/univention/updater.log und die alten komprimierten Protokolldateien.
(ich hoffe, dass ich die richtige Log-Datei erwähnt habe).

In der Log-Datei sollte auch aufgeführt sein, wie man nach einem Update Platz schafft.

Hallo Mornsgrans,
Danke für den Tip.

df auf dem fileserver

df /boot
Dateisystem    1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/sdb1         480618  353226    102458   78% /boot

df auf dem DC

df /boot
Dateisystem    1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/sda1         480618  353211    102473   78% /boot

Mit der letzten Paketaktualisierung wurde ein neuer Kernel installiert. Auf dem DC wird er geladen, auf dem Fileserver nicht.

uname auf dem DC

 uname -r
4.19.0-26-amd64

uname auf dem Fileserver

 uname -r
4.9.0-12-amd64

Inhalt von /boot auf dem Fileserver

/boot# ls
boot.msg                    initrd.img-4.19.0-24-amd64  System.map-4.19.0-25-amd64
config-4.19.0-20-amd64      initrd.img-4.19.0-25-amd64  System.map-4.19.0-26-amd64
config-4.19.0-22-amd64      initrd.img-4.19.0-26-amd64  vmlinuz-4.19.0-20-amd64
config-4.19.0-24-amd64      lost+found                  vmlinuz-4.19.0-20-amd64.efi.signed
config-4.19.0-25-amd64      memtest86+.bin              vmlinuz-4.19.0-22-amd64
config-4.19.0-26-amd64      memtest86+_multiboot.bin    vmlinuz-4.19.0-22-amd64.efi.signed
grub                        System.map-4.19.0-20-amd64  vmlinuz-4.19.0-24-amd64
initrd.img-4.19.0-20-amd64  System.map-4.19.0-22-amd64  vmlinuz-4.19.0-25-amd64
initrd.img-4.19.0-22-amd64  System.map-4.19.0-24-amd64  vmlinuz-4.19.0-26-amd64

Wo kommt der Kernel 4.9.0-12-amd64 her? In /boot ist er jedenfalls nicht. Release des Kernel 4.9 war Dezember 2016. Zu dem Zeitpunkt war der Fileserver noch nicht in Betrieb.

Ich verstehe einfach nicht, wo der uralt Kernel herkommt und wie er überhaupt geladen werden kann.

Gruß
George

Ich habe jetzt mal einen Monitor an den Server angeschlossen, neu gebootet und ein Foto des Grub Menues gemacht.

IMG_0282

Eigenlich sollten dort die Kernel 4.19.0.20 - 26 zur Auswahl stehen. Tun sie aber nicht.

cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.9.0-12-amd64 root=/dev/mapper/vg_ucs-root ro quiet loglevel=0 rootdelay=5 splash
Mastodon