☰

Boot.mount schlägt nach dem Upgrade auf 18.04 fehl

tag-icon • tag-icon boot mount fstab lvm
Boot.mount schlägt nach dem Upgrade auf 18.04 fehl

Dieses Problem ist auf vielen unserer Server aufgetreten, die von 16.04 auf 18.04 aktualisiert wurden. Die übliche Konfiguration ist, dass root ein LVM ist und entweder eine /boot-Partition oder eine /boot- und /boot/efi-Partition vorhanden ist. Beispiel:

$ lsblk -f
NAME                         FSTYPE      LABEL UUID                                   MOUNTPOINT
sda                                                                                   
├─sda1                       vfat              C45F-2000                         /boot/efi     
├─sda2                       ext2              a906fd59-cb58-4c94-8560-5d426e4   /boot
└─sda3                       LVM2_member       1P3Rxv-VZMx-gcs9-PlxM-DCI8-kIqr
  ├─node--007--vg-root       ext4              316678d5-aaaf-43bd-bac6-cc3aeb1   /
  ├─node--007--vg-swap_1     swap              0724b0b0-9f2d-42aa-bbe2-7b8aa31   [SWAP]
  ├─node--007--vg--na      ext4              7d42481b-f7fb-4ac6-9cf5-5df3ca17   /cache/na
  ├─node--007--vg-c        ext4              e38d96f8-6afb-4d2c-94cc-28a02e90   /cache/c
  └─node--007--vg-t        ext4              44559b67-869e-4454-b792-792c1a16   /cache/d

Beim Kernel-Debug-Logging sehe ich immer diese Art von Logging über Timeouts beim Warten auf das Gerät

Mar 30 16:14:22 ns1 systemd-udevd[539]: seq 3206 '/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sda' is taking a long time
Mar 30 16:14:22 ns1 systemd[1]: systemd-udevd.service: Got notification message from PID 539 (WATCHDOG=1)
Mar 30 16:14:50 ns1 systemd[1]: dev-disk-by\x2duuid-a906fd59\x2dcb58\x2d4c94\x2d8560\x2d5d426e4.device: Job dev-disk-by\x2duuid-a906fd59\x2dcb58\x2d4
Mar 30 16:14:50 ns1 systemd-journald[501]: Forwarding to syslog missed 70 messages.
Mar 30 16:14:50 ns1 systemd[1]: dev-disk-by\x2duuid-a906fd59\x2dcb58\x2d4c94\x2d8560\x2d5d426e4.device: Job dev-disk-by\x2duuid-a906fd59\x2dcb58\x2d4
Mar 30 16:14:50 ns1 systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-a906fd59\x2dcb58\x2d4c94\x2d8560\x2d5d426e4.device.
Mar 30 16:14:50 ns1 systemd[1]: boot.mount: Job boot.mount/start finished, result=dependency
Mar 30 16:14:50 ns1 systemd[1]: Dependency failed for /boot.

Der Swap und die LVMs sind zu diesem Zeitpunkt bereits gemountet. Der Notfallmodus wird aktiviert und durch Drücken von Strg+D wird der Bootvorgang fortgesetzt und dann ist alles in Ordnung.

Wenn ich alle Dateien unter /boot tarne, /boot und /boot/efi umounte und sie dann entpacke, die fstab ändere, das initramfs aktualisiere und ohne diese Partitionen neu starte, dann bootet der Knoten.

Mir ist aufgefallen, dass das Protokoll, das besagt, dass /dev/sda angeschlossen ist, nicht erscheint, bevor der Notfallmodus aktiviert wird, obwohl die LVMs erfolgreich gemountet wurden. Nachdem ich Strg+D gedrückt habe, um den Bootvorgang fortzusetzen, erscheint das Protokoll und alles, einschließlich sda2, wird problemlos gemountet.

Mar 30 16:15:33 ns1 systemd[1]: dev-sda.device: Changed dead -> plugged

Jede Hilfe ist herzlich willkommen.

Antwort1

Nach langem Suchen habe ich das sehr praktische Debug-Protokoll in /etc/udev/udev.conf aktiviert und mein Initramfs aktualisiert.

$ cat /etc/udev/udev.conf 
# see udev.conf(5) for details
#
# udevd is started in the initramfs, so when this file is modified the
# initramfs should be rebuilt.

#udev_log="info"
#event_timeout=300
udev_log="debug"

Dies hat mir geholfen, das Problem zu identifizieren. Zu Beginn des Bootvorgangs traten Tausende von „Curls“ auf, und diese stammten von einer Udev-Regel, die beim Hinzufügen und Entfernen von „sd*“-Geräten wirkte. Ich habe diese Regelaktionen auskommentiert und jetzt bootet das System! Die Protokolle können mit journalctl -b angezeigt werden.

verwandte Informationen