Docker lässt sich nicht starten

UCS - Univention Corporate Server
#1

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

#2

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.

#3

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

#4

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
#5

Problem gelöst. Der richtige Kerrnel wird geladen, Docker startet, Nextcloud und Rocketchat laufen wieder.

Lösung:

Nach der Installation sah die Partitionierung so aus:

sda
sda1 /boot
sda5 LVM2 Member

  • vgs_ucs-root
  • vgs_ucs-tmp
  • vgs_ucs-swap

sdb
sdb5 LVM2 Member

  • vgs_ucs-home

sdc
sdc5 LVM2 Member

  • vgs_ucs-var

Nachdem Problem mit dem veralteten Kernel aufgetreten is, so:

lsblk -f
NAME              FSTYPE      LABEL UUID                                   FSAVAIL FSUSE% MOUNTPOINT
sda
├─sda1            ext2              5ae8788b-8fb4-4d47-8427-3d4e9dde949f
├─sda2
└─sda5            LVM2_member       p0dJK4-4tcf-uOpZ-6QoQ-NLy7-axOV-X3f786
sdb
├─sdb1            ext2              90c04d46-a69d-4897-92c2-4da418d0203c    367,6M    16% /boot
├─sdb2
└─sdb5            LVM2_member       ziU7an-cYON-RZnq-bKng-vWjo-vrcv-iL0r5h
  ├─vg_ucs-root   ext4              f9ece1f6-773f-41bc-806e-30d5509d10f0     17,8G    15% /
  ├─vg_ucs-var    ext4              00c7265d-66aa-4624-98c3-e25918543505    809,5G     8% /var
  ├─vg_ucs-swap_1 swap              f42eeaf9-bcdd-4837-a760-e61298d8ac06                  [SWAP]
  ├─vg_ucs-tmp    ext4              b57668bb-1d46-4fa2-b1c7-be8430c59a57     14,8G     0% /tmp
  └─vg_ucs-home   ext4              f964fc9d-06f7-44dc-b3a0-e087abaeae24     98,1G    83% /home
sdc
├─sdc1
└─sdc5            LVM2_member       xp5pKv-4Cz3-UBnG-d5Ii-i1WD-c8wj-6e3hrB
  └─vg_ucs-var    ext4              00c7265d-66aa-4624-98c3-e25918543505    809,5G     8% /var

lvscan
  ACTIVE            '/dev/vg_ucs/root' [23,28 GiB] inherit
  ACTIVE            '/dev/vg_ucs/var' [<961,31 GiB] inherit
  ACTIVE            '/dev/vg_ucs/swap_1' [7,73 GiB] inherit
  ACTIVE            '/dev/vg_ucs/tmp' [<16,28 GiB] inherit
  ACTIVE            '/dev/vg_ucs/home' [853,94 GiB] inherit
  inactive          '/dev/vg_ucs/root' [23,28 GiB] inherit
  inactive          '/dev/vg_ucs/var' [29,80 GiB] inherit
  inactive          '/dev/vg_ucs/swap_1' [7,73 GiB] inherit
  inactive          '/dev/vg_ucs/tmp' [<16,28 GiB] inherit
  inactive          '/dev/vg_ucs/home' [853,94 GiB] inherit

sda war als Bootplatte im Bios eingestellt.

Trennung der Platten sdb und sdc. Beim Booten von sda wird eine UCS 4.x Version mit dem Kernel 4.9.0-12 geladen.
Start mit sdb und sdc. Kernel 4.19.0.26 wird geladen, UCS 5.06 startet. Docker und somit Nextcloud und Rocketchat laufen wieder

Gruß
George

1 Like
Mastodon