cryptsetup: initramfs findet sporadisch UUID nicht

[M4he]

Hallo alle miteinander,

ich hoffe dies ist das passende Unterforum für mein Problem, ansonsten bitte verschieben.

Das Problem

Manchmal findet initramfs die UUID des crypt-Volumes anscheinend nicht mehr.
Nach dem Booten des Bootloaders (Grub) und dem wählen des Booteintrags, erscheint dann statt der üblichen Passphrase-Abfrage für das crypt-Volume "deb_crypt" im Sekundentakt nur die Warnmeldung:

Code: Alles auswählen

cryptsetup: lvm is not available

Bis nach einigen Minuten die Meldung erscheint, dass der die UUID eines Volumes nicht finden kann. Vermutlich handelt es sich dabei um die UUID des zu entsperrenden crypt-Volumes, worin sich die Root-Partition befindet. Dieses befindet sich interessanterweise jedoch auf der gleichen physischen USB-Platte, von der auch der Grub-Bootloader (erfolgreich) startet und ins initramfs übergeht.

Das Problem tritt sporadisch auf und ließ sich bisher über 2 Wege beheben: a) Ab- und Anstöpseln der USB-Platte auf der sich das System (Grub und crypt-Volume) befindet oder b) durch ein chroot von einer Live CD aus mit anschließendem 'update-initramfs' und 'update-grub'.
Ein simpler Neustart des Rechners, an dem die USB-Platte hängt, behebt das Problem nicht.

Mein Setup

Code: Alles auswählen

uname -a
	Linux Jessie 4.3.0-0.bpo.1-amd64 #1 SMP Debian 4.3.5-1~bpo8+1 (2016-02-23) x86_64 GNU/Linux

lsb_release -r
	Release:	8.3

Ich habe ein Debian Jessie 8.3 auf einer USB-Festplatte. Die USB-Festplatte besteht aus einer 32GB SSD, die in ein Inateck USB3 Gehäuse gepackt wurde, welches UASP-Unterstützung bietet. Es ist an einem USB3-Port an meinem Mainboard angeschlossen. Ich nutze den 4.3 Kernel aus jessie-backports, damit dieses Gehäuse auch mit UASP betrieben wird ("Driver=uas" statt "Driver=usb-storage"):

Code: Alles auswählen

sudo lsusb -t

/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 4: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M

Zudem habe ich meine root-Partition mit dm-crypt verschlüsselt aber ohne LVM zu verwenden, da dies beim USB-Boot noch häufiger Probleme machte. Davor liegt noch eine 256M /boot-Partition für den Bootloader. Das ganze sieht wie folgt aus:

Code: Alles auswählen

sudo lsblk

sda             8:0    0  29,8G  0 disk  
├─sda1          8:1    0   243M  0 part  /boot
└─sda2          8:2    0  29,6G  0 part  
  └─deb_crypt 252:0    0  29,6G  0 crypt /

Anmerkung

Nur für den Fall dass es eventuell zur Ursachenforschung beiträgt, merke ich noch an, dass ich nach der Installation das crypt-Volume umbenannt habe. Dazu habe ich folgende Schritte ausgeführt:

1. Ersetzen von 'sde2_crypt' durch 'deb_crypt' in /etc/crypttab
2. Ausführen von

   Code: Alles auswählen

   dmsetup rename sde2_crypt deb_crypt

3. Ersetzen von 'sde2_crypt' durch 'deb_crypt' in /etc/fstab

4. Code: Alles auswählen

   update-initramfs -c -t -k all
   update-grub

5. reboot

Danach war die Bootfähigkeit auch hinüber (er konnte das Volume per UUID nicht mehr finden) und ich musste es per Live CD chroot retten. Anscheinend hatte sich hier jedoch die UUID tatsächlich geändert durch das Umbenennen. Zumindest brachte hier ein Ab- und Anstöpseln der USB-Platte wiederum keine Besserung.

[NAB]

guckst du mal hier:
http://forums.debian.net/viewtopic.php?f=5&t=127068

Wenn der lange genug wartet, dann folgt bei ihm auf das "cryptsetup: lvm is not available" eine Meldung über eine fehlende UUID. Dadurch haben wir zwar noch keine Lösung, aber wenn es bei dir genau so ist, dann liegt vielleicht wirklich eine mysteriös schwankende UUID vor.

[M4he]

Wenn der lange genug wartet, dann folgt bei ihm auf das "cryptsetup: lvm is not available" eine Meldung über eine fehlende UUID. Dadurch haben wir zwar noch keine Lösung, aber wenn es bei dir genau so ist, dann liegt vielleicht wirklich eine mysteriös schwankende UUID vor.

Danke Dir für den Hinweis! Geduld ist eine Tugend. Wenn man lange genug wartet, erscheint tatsächlich eine Meldung über eine fehlende UUID.
Übrigens trat es heute erneut auf, ohne dass vorher ein Kernel-Update o.ä. erfolgte. Diesmal half auch ein einfaches Ab- und wieder Anstöpseln der USB-Platte. Es scheint also nicht am generierten initramfs zu liegen sondern einfach sporadisch aufzutreten.
Ich war so frei und habe den Titel sowie meinen Post oben entsprechend angepasst.

Bisher traten die letzten beiden Male auf, nachdem die USB-Platte über Nacht am ausgeschalteten Rechner hing, aber noch mit Strom versorgt wurde (LED leuchtet durchweg), da mein Mainboard auch im ausgeschalteten Zustand die USBs mit Strom versorgt. Vielleicht verklemmt sich da was im USB-Controller vom Inateck-Gehäuse über die Zeit oder es hat mit folgender Meldung zutun:

Code: Alles auswählen

Failed to finalize DM devices

die ich jedes Mal beim Herunterfahren für einen Bruchteil einer Sekunde aufblitzen sehe, bevor der Rechner ausgeht.

Interessant finde ich dennoch, dass Grub immer anstandslos bis ins initramfs bootet, obwohl sich beide ja auf der ersten Partition der gleichen physischen USB-Platte befinden wie das (teils nicht auffindbare) crypt-Volume.

[debianoli]

Wozu eigentlich das

Code: Alles auswählen

dmsetup rename sde2_crypt deb_crypt

War das überhaupt nötig?

Und was sagt

Code: Alles auswählen

blkid

Stimmen die UUID der Ausgabe von blkid mit dem Inhalt der /etc/crypttab überein?

[M4he]

Wozu eigentlich das

Code: Alles auswählen

dmsetup rename sde2_crypt deb_crypt

War das überhaupt nötig?

Ich hatte nach einer Methode zum Umbenennen des crypt-Volumes gesucht und habe mich an der akzeptierten Antwort von folgendem Link orientiert: http://unix.stackexchange.com/a/81020

Und was sagt

Code: Alles auswählen

blkid

Stimmen die UUID der Ausgabe von blkid mit dem Inhalt der /etc/crypttab überein?

blkid

Code: Alles auswählen

/dev/sda1: UUID="7c5177f9-a5ea-4dac-8a3d-3bb9a3be8316" TYPE="ext2" PARTUUID="f07b5d3c-01"
/dev/sda2: UUID="b49b4fde-d624-4264-a259-adc84b22da03" TYPE="crypto_LUKS" PARTUUID="f07b5d3c-02

cat /etc/crypttab

Code: Alles auswählen

deb_crypt UUID=b49b4fde-d624-4264-a259-adc84b22da03 none luks

Wie gesagt versagt die Bootfähigkeit sporadisch. Wenn die Werte nicht übereinstimmen würden, wäre es meines Erachtens nach überhaupt nicht bootfähig.

[debianoli]

Ging das denn mit einem anderen Kernel, zB dem Jessie Standard-Kernel ohne Probleme?

Und wie behandelt das BIOS/UEFI das USB-Device? Sieht man da irgendwas auffälliges im Boot-Menü des BIOS?

[NAB]

M4he, wenn ich das richtig verstehe, findet er im Fehlerfall die UUID von sda2 nicht, oder?

Mich würde jetzt erst mal interessieren, ob er im Fehlerfall die gesamte Partition sda2 nicht findet, oder ob die auf einmal eine andere UUID hat. Der Betroffene aus meinem Link oben landet auf einem Prompt des initramfs und konnte von dort anscheinend blkid ausführen. Wenn das bei dir auch so ist, schau doch mal, was da los ist.

[M4he]

Ging das denn mit einem anderen Kernel, zB dem Jessie Standard-Kernel ohne Probleme?

Da der 3.16er Standard-Kernel noch in der /boot-Partition lag, hatte ich über Grub auch schon versucht diesen zu booten als das Problem auftrat, jedoch ohne Erfolg.

Und wie behandelt das BIOS/UEFI das USB-Device? Sieht man da irgendwas auffälliges im Boot-Menü des BIOS?

Ich starte dieses System immer manuell über das Boot-Menü (F12) meines BIOS, da ist mir noch nie was aufgefallen. Da steht immer "Inateck" und eine Kennung dahinter. Mehr ist da nicht zu sehen.

M4he, wenn ich das richtig verstehe, findet er im Fehlerfall die UUID von sda2 nicht, oder?

Korrekt. Er bemängelt immer, dass er eine UUID beginnend mit "b49..." nicht finden kann; das müsste die von sda2 sein.

Mich würde jetzt erst mal interessieren, ob er im Fehlerfall die gesamte Partition sda2 nicht findet, oder ob die auf einmal eine andere UUID hat. Der Betroffene aus meinem Link oben landet auf einem Prompt des initramfs und konnte von dort anscheinend blkid ausführen. Wenn das bei dir auch so ist, schau doch mal, was da los ist.

Das ist ein guter Tipp! Gut zu wissen, dass selbst das initramfs diese Befehle unterstützt. Sobald es wieder auftritt, werde ich mich in der initramfs-Shell mal ein bisschen austoben

[M4he]

Wie erwartet, trat das Problem heute früh nach einem nächtlichen Angesteckt-lassen der USB3-Platte am ausgeschalteten Rechner erneut auf. Diesmal habe ich mich in der initramfs-Shell ein bisschen umgesehen und die Ausgaben notiert:

Bis zum initramfs-Prompt kommt folgende Ausgabe:

Code: Alles auswählen

sd 6:0:0:0: [sda] Asking for cache data failed
sd 6:0:0:0: [sda] Assuming drive cache: write through
cryptsetup: lvm is not available
cryptsetup: lvm is not available
...
  ALERT! /dev/disk/by-uuid/b49b4fde-d624-4264-a259-adc84b22da03 does not exist.
  		Check cryptopts=source= bootarg: cat /proc/cmdline
  		or missing modules, devices: cat /proc/modules; ls /dev
-r Dropping to a shell. Will skip /dev/disk/by-uuid/b49b4fde-d624-4264-a259-adc84b22da03 if you can't fix.
modprobe: module ehci-orion not found in modules.dep
...
BusyBox v1.22.1 ...

blkid:

Code: Alles auswählen

(initramfs) blkid
/dev/sdd1: ...
/dev/sdd2: ...
/dev/sdc1: ...
/dev/sdc2: ...
/dev/sdb1: ...
/dev/sdb2: ...
/dev/sdb3: ...
/dev/sde1: ...
/dev/sde3: ...
/dev/sdf1: ...

• bei blkid kommt kein "sda" vor
• ich kann alle gelisteten Partitionen von blkid eindeutig allen internen Platten zuordnen, bis auf sdf1, das ist ein angeschlossener Live CD USB Stick
• weder "sda" noch die gesuchte UUID kommen in der Ausgabe von blkid vor

/proc/cmdline:

Code: Alles auswählen

(initramfs) cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.3.0-0.bpo.1-amd64 root=UUID=51a55479-ff75-4197-bb94-131c0f83d98f ro initrd=/install/initrd.gz quiet

• die UUID von "root=UUID=51a..." aus "/proc/cmdline" ist auch nicht in der Ausgabe von blkid dabei

/dev:

Code: Alles auswählen

(initramfs) ls /dev/
block
...
sda
sdb
sdb1
sdb2
sdb3
...

• die Ausgabe von "ls /dev/" beinhaltet nur "sda" aber keine Partitionen ("sdaX") für sda, so wie für die anderen Platten

dmesg: (hier mal die relevanten Zeilen rausgepickt)

Code: Alles auswählen

(initramfs) dmesg
...
usbcore: registered new interface driver uas
scsi 6:0:0:0: Direct-Access     Inateck  ASM1153E        0    PQ: 0 ANSI: 6
...
sd 6:0:0:0: Attached scsi generic sg1 type 0
...
sd 6:0:0:0: [sda] Test WP failed, assume Write Enabled
sd 6:0:0:0: [sda] Asking for cache data failed
sd 6:0:0:0: [sda] Assuming drive cache: write through
sd 6:0:0:0: [sda] Attached SCSI disk

• in der Ausgabe von dmesg gibt es dann noch so Zeilen wie " sde: sde1 sde3", wo er die erkannten Partitionen pro Platte listet, eine derartige Zeile fehlt für "sda" komplett

Anscheinend erkennt GRUB die Partitionen noch korrekt und bootet ins initramfs aber dort findet der Kernel gar keine Partitionen für sda mehr. Das einzige was ich mir momentan ausdenken könnte, wäre, dass GRUB die USB3-Platte noch mit BOT (also "usb-storage" Treiber) betreibt, wohingegen es der Kernel dann mit UASP ("uas" Treiber, sh. dmesg Ausgabe) versucht. Vielleicht verklemmt sich da über Nacht etwas im Controller des USB3-Gehäuses, sodass BOT noch geht und daher GRUB vorher anstandslos bootet aber dann UASP versagt beim initramfs.
Ich sollte mal das uas Kernelmodul blacklisten und dann eine Nacht abwarten.

[NAB]

Eine Erklärung habe ich nach wie vor nicht, nur etwas Senf:

Der Kernel erkennt sda, erkennt aber keine Partitionstabelle darauf. Ich vermute, das ist eine MBR-Partitionierung, also steht die gesamte Partitionstabelle im ersten Datenblock von sda. Wenn es da einen Lesefehler gab, müsste der "eigentlich" im dmesg auftauchen. Aber auch nur, wenn das Gehäuse ihn gemeldet hat. Es könnte sich also auch um einen sporadischen Lesefehler handeln, der nicht erkannt wird.

Nun wäre es interessant, mal Leseversuche in funktionierendem und kaputtem Zustand zu machen und zu vergleichen. Das wäre von einem bootenden Betriebssysstem aus natürlich leichter ...

Deine Theorie mit dem gelegentlich kaputten Treiber besagt hingegen ... ehm ... was? sda wird ja erkannt. Kann aber nicht mehr gelesen werden? Man könnte ja mal gucken, was ein dd if=/dev/sda of=/dev/null sagt.