[solved] GRUB cmdline root=/dev/sdx problematisch

[ingo2]

Schon seit längerem passiert es immer mal wieder, dass GRUB zwar bootet, aber dann (meist kurz nach dem fsck der root-Partition hängt und auf eine BusyBox zurückfällt. Das ist zwar recht selten, ca. 1:50 und tritt bisher nur bei Systemen mit Kernel 5.4 (Buster-backports) oder auch etwas öfter 5.8 (Bullseye) auf. Vorzugsweise passiert's wenn ich vorher ein Live-System von USB-Stick gebootet hatte.
Die Meldungen:

Code: Alles auswählen

Waiting for root file system
  Running /scripts/local/block ... done		(ca. 15 solche Zeilen)
Gave up waiting for root file system, common problems:
  - Boot args (cat /proc/cmdline) -> root=/dev/sda5
    - Check rootdelay= (did the system wait long enough?)
ALERT! /dev/sda5 does not exist
Dropping to a shell		(Busybox)

Ich muß dazu sagen, es handelt sich um eine SSD mit 4 bootfähigen Linuxen, wovon die Bootpartition mit GRUB ein Minimales Buster mit ein paar Scripten für Backups und Wartung ist, GRUB liegt im MBR.
Für ein einfaches und praktisches Menu habe ich eine "/etc/grub.d/09_custom" erstellt (die 40_custom umbenannt), welche am Anfang je einen "Menuitem-Eintrag" nach diesem Schema für jedes System enthält:

Code: Alles auswählen

menuentry "Debian-Buster auf sda2" {
insmod part_msdos
insmod ext2
set root='hd0,msdos2'
linux /vmlinuz root=/dev/sda2 ro quiet
initrd /initrd.img
}

Das hat den großen Vorteil, ich boote einfach den zuletzt installierten Kernel über den Symlink in /.
Da konnte man sogar eine Partition neu formatieren und ein Backup darauf zurückkopieren oder auch bei Bedarf auf einer anderen Partition restoren - es hat immer gebootet.
Das ging bisher über ca. 10 Jahre (seit Wheezy) völlig problemlos und absolut zuverlässig.
Die sporadischen Hänger treten bisher auch nur bei den beiden genannten Systemen mit Kerneln 5.x auf, nicht beim normalen Buster-Kernel auf der Boot- und Service-Partition auf.

Habe inzwischen auch probiert, mit dem Boot-Parameter "rootdelay=" eine Verzögerung einzubauen, hilft nicht. Im Moment teste ich mit einer cmdline, die das device per UUID definiert - das scheint das Problem zu lösen, muß ich aber noch eine Weile beobachten.

Gibt's schon ähnliche Beobachtungen, ist die Angabe von Devicees im Filesysten (/dev/sdx) veraltet, habe nichts dergleichen gelesen?

Ingo

[hikaru]

Device-Namen sind nicht stabil. Was jetzt /dev/sda ist kann beim nächsten Boot /dev/sdb sein und umgekehrt. Das war aber schon immer so. Wenn es bisher bei dir funktioniert hat, war es pures Glück.
Wenn dir UUIDs zu kryptisch sind, dann verwende Labels!

[ingo2]

Was ich noch zusätzlich beobachtet habe:

Offenbar findet GRUB den Kernel (und evtl. die Initrd) korrekt auf der richtigen Partition, aber der Kernel findet sein root-Filesystem nicht, denn:

habe schon beobachtet, dass sogar ein "fsck" der richtigen Partition noch voll durchläuft (ist mit tune2fs alle 10 Mounts konfiguriert) und sogar etliche Scripte dieser Art erfolgreich ausgeführt werden

Code: Alles auswählen

Running /scripts/local/block ... done

bevor er dann nach Timeout

Code: Alles auswählen

ALERT! /dev/sda5 does not exist
Dropping to a shell

zur Busybox zurückfällt.

Das hat offenbar auch etwas mit den neuen Kerneln (5.x) und deren Initrd zu tun - kann ich mir anders nicht erklären.

Zu deinem Hinweis

Was jetzt /dev/sda ist kann beim nächsten Boot /dev/sdb sein und umgekehrt.

kann ich nur sagen, das passiert eigentlich nur, wenn ich z.B. die HD an einen anderen SATA-Port anschließe oder umpartitioniere. Habe ich aber nie gemacht und seit Wheezy auf der identischen Hardware nie beobachtet.

EDIT:
Habe irgendwo auch gelesen, dass der Kernel sein root-Filesystem per UUID sucht/findet. Dazu bräuchte dann aber eine aktuelle "/run/blkid/blkid.tab". Ob das eine Timingfrage ist?

[DeletedUserReAsG]

bevor er dann […] zur Busybox zurückfällt.

Und existiert dort sda5, und du kannst weiterbooten?

Zu deinem Hinweis […] kann ich nur sagen, das passiert eigentlich nur, wenn ich z.B. die HD an einen anderen SATA-Port anschließe oder umpartitioniere.

Wie hikaru schon schrieb: dann hast du bislang eben meist Glück gehabt. Aber sollte doch kein Drama sein, das mal auszuschließen, indem man die Datenträger wie empfohlen anspricht?

[ingo2]

bevor er dann […] zur Busybox zurückfällt.

Und existiert dort sda5, und du kannst weiterbooten?

Bisher leider nein. Habe immer den Affengriff benutzen müssen und danach hat er immer korrekt gebootet.

Wie hikaru schon schrieb: dann hast du bislang eben meist Glück gehabt. Aber sollte doch kein Drama sein, das mal auszuschließen, indem man die Datenträger wie empfohlen anspricht?

Habe ich ja gerade laufen, habe überall erst mal die Filesystem-UUID des root-Filesystems eingetragen und trotz vieler Versuche nie einen Hänger gehabt. Wenn das 1-2 Wochen problemlos geht, lasse ich's auch bei der UUID.
Natürlich sind dann so Sachen wie Partition neu formatieren und Backup zurückspielen ohne Booteintäge anzupassen nicht mehr möglich. Oder alternativ danach auch noch die UUID auf den alten Wert ändern.

[hikaru]

Natürlich sind dann so Sachen wie Partition neu formatieren und Backup zurückspielen ohne Booteintäge anzupassen nicht mehr möglich. Oder alternativ danach auch noch die UUID auf den alten Wert ändern.

... oder Label verwenden!

[fischig]

das passiert eigentlich nur, wenn ich z.B. die HD an einen anderen SATA-Port anschließe oder umpartitioniere. Habe ich aber nie gemacht und seit Wheezy auf der identischen Hardware nie beobachtet.

Nunja, soweit könnte ich das bestätigen, aber ich arbeite auch permanent mit wesentlich schlichteren Systemen und versuche auch nicht nochmal'n anderes Live-Systeme via USB zu booten. Mag schon sein, dass neuere Kerne sich da bei dir verschlucken, zumal das mit den UUIDs im bootloader jetzt seit mehr als einem Jahrzehnt Standard ist.

[ingo2]

Es war tatsächlich de Eintrag mit der device-Bezeichnung (wie /devsdx) die Ursache.
Seit ich jetzt vor ca. 2 Wochen auf UUID's umgestellt habe, sind die Hänger beim Booten restlos verschwunden.
Aber, wie gesagt, davon waren nur Installationen mit Kernel 5.4 oder 5.8 betroffen.

Habe es deshalb als gelöst markiert