Mir ist vor Kurzem aufgefallen, dass beim Versuch, den Linux-Kernel zu booten ( 5.8.0-55-genericin einer Standarddistribution von Ubuntu 20.04), der Kernel zwar bootet, aber während des Bootvorgangs 30 Sekunden lang hängen bleibt (wie in diesen Zeilen von gezeigt ), wenn ich das Root-Laufwerk angebe root=PARTUUID=.....und die UUID der ext4-Partition in Großbuchstaben eingebe :/var/log/dmesg
[ 2.853379] kernel: input: HID 05ac:820b as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.8/2-1.8.1/2-1.8.1.2/2-1.8.1.2:1.0/0003:05AC:820B.0009/input/input10
[ 2.857488] kernel: hid-generic 0003:05AC:820B.0009: input,hidraw8: USB HID v1.11 Mouse [HID 05ac:820b] on usb-0000:00:1d.0-1.8.1.2/input0
[ 2.938013] kernel: usb 2-1.8.1.3: new full-speed USB device number 8 using ehci-pci
[ 3.057584] kernel: usb 2-1.8.1.3: New USB device found, idVendor=05ac, idProduct=8289, bcdDevice= 1.50
[ 3.067746] kernel: usb 2-1.8.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3.077779] kernel: usb 2-1.8.1.3: Product: Bluetooth USB Host Controller
[ 3.087836] kernel: usb 2-1.8.1.3: Manufacturer: Apple Inc.
[ 32.329915] kernel: EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
[ 32.498137] systemd[1]: Inserted module 'autofs4'
[ 33.091557] systemd[1]: systemd 245.4-4ubuntu3.7 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)
[ 33.130184] systemd[1]: Detected architecture x86-64.
[ 33.179603] systemd[1]: Set hostname to <michael-MacBookPro>.
[ 33.342145] systemd[1]: Created slice system-modprobe.slice.
[ 33.350600] systemd[1]: Created slice system-systemd\x2dfsck.slice.
[ 33.358792] systemd[1]: Created slice User and Session Slice.
Wenn ich genau dieselbe PARTUUID in Kleinbuchstaben angebe, gibt es kein Problem:
[ 2.643019] kernel: input: HID 05ac:820b as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.8/2-1.8.1/2-1.8.1.2/2-1.8.1.2:1.0/0003:05AC:820B.0009/input/input10
[ 2.652851] kernel: hid-generic 0003:05AC:820B.0009: input,hidraw8: USB HID v1.11 Mouse [HID 05ac:820b] on usb-0000:00:1d.0-1.8.1.2/input0
[ 2.685911] kernel: EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
[ 2.733247] kernel: usb 2-1.8.1.3: new full-speed USB device number 8 using ehci-pci
[ 2.852575] kernel: usb 2-1.8.1.3: New USB device found, idVendor=05ac, idProduct=8289, bcdDevice= 1.50
[ 2.860616] kernel: usb 2-1.8.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2.867916] kernel: usb 2-1.8.1.3: Product: Bluetooth USB Host Controller
[ 2.875182] kernel: usb 2-1.8.1.3: Manufacturer: Apple Inc.
[ 2.882524] systemd[1]: Inserted module 'autofs4'
[ 3.490681] systemd[1]: systemd 245.4-4ubuntu3.7 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)
[ 3.529529] systemd[1]: Detected architecture x86-64.
[ 3.585335] systemd[1]: Set hostname to <michael-MacBookPro>.
[ 3.732416] systemd[1]: Created slice system-modprobe.slice.
[ 3.740515] systemd[1]: Created slice system-systemd\x2dfsck.slice.
[ 3.748458] systemd[1]: Created slice User and Session Slice.
(Beachten Sie, dass in beiden Protokollen dieselbe Meldung „gemountetes Dateisystem“ steht, nur ein paar Zeilen früher und ohne große Verzögerung im Schnellstartprotokoll.)
Es wird jedoch die Großbuchstabenversion der PARTUUID verwendet (und nicht etwa durch etwas anderes überschrieben): Wenn ich eine falsche Ziffer eingebe, dann hängt sich der Kernel nach 30 Sekunden auf und beschwert sich, dass er das Root-Dateisystem nicht finden kann, wie erwartet.
Kann das jemand erklären? Zumindest scheint es, dass es, wenn es darauf ankommt, überhaupt nicht funktionieren sollte, nicht, dass es nach einer Verzögerung von 30 Sekunden funktionieren sollte.
AKTUALISIERUNG 1: Gleiches (das oben genannte Verhalten und Ähnlichkeiten/Unterschiede zum /etc/fstabVerhalten) gilt root=UUID=...auch für root=PARTUUID=....
AKTUALISIERUNG 2: Ich denke, das muss etwas anders sein als das, was mit passiert /etc/fstab(sowohl weil das Mounten des Root-Verzeichnisses erfolgen muss, bevor /etc/fstabgelesen werden kann, als auch weil – wie in den Kommentaren erläutert – /etc/fstabmit (PART)UUID in falscher Groß-/Kleinschreibung einfach fehlschlägt, während es root=...nach einer Pause von 30 Sekunden erfolgreich ist).