gelöst: update-initramfs > cryptroot auf lv bootet niht mehr

[liNixchecker]

Hallo Forum.
Jetzt hab ich mich nach langen mitlesen auch mal angemeldet. Dabei war mir das Board in den ca 3 Jahren* aktiver Linux/ Debian Nutzung durchaus hilfreich, danke dafür...
Doch nun zu meinem aktuellem "Problem":
Mein System besteht aus einer kleineren Platte (320G) mit verschlüsselter Swap-Partition (luks random key), boot Partition (sdc5), luks Partition (sdc7) (+Win7 partition, boote ich nur noch, wenn ich mal zocken möchte... ). Dann noch zwei identische 1T Platten, luks Partition (sda1 und sdb1) mit keyfile im root-fs. sdc7, sda1 und sdb1 sind eine Volume Group; /, /var, /usr, /tmp, /opt (ja, brauch ich...) /home als eigene LVs. Auf den beiden TB-Platten sind drei gespiegelte Daten LVs, mirror-logs auf sdc7. Beim booten kam bisher immer: vg not found, skipped, dann Eingabe der Passphrase, dann beschwerte sich lvm dass nicht alle lv gefunden wurden (die beiden TB Platten waren ja noch nicht geöffnet), aktivierte aber die Volume Group, so dass cryptsetup die beiden key-files finden konnte, die Platten öffnete und danach wurden die verbleibenden LVs aktiviert und gemountet. Alles ganz automatisch.
Doch nachdem ich gestern (wie immer mit aptitude) initramfs-tools von 0.109 auf 0.109.1 updatete (neues initramfs geschrieben), kam heute morgen beim booten nach Eingabe der Passphrase: lvm fs found but no lvm configured, der Bootprozess unterbrach und ich wurde kalt und brutal in eine shell geschmissen
Na ja, hab dann die alte Boot-Partition per dd aus nem Backup einfach wieder zurückgeschreiben, Problem erstmal behoben, aber irgendwie versteh ich nicht, warum der Boot-Prozess unterbrochen wurde... Ich hab zwar eine Bug gefunden, der ziemlich genau das gleiche Problem zeigt:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659688
ist aber schon ein Jahr alt.
Außerdem hab ich mal die neuen initramfs-tools mit einem Backup verglichen. (Zumindest nehme ich das an. Diese sind doch einzig in /usr/share/initramfs-tools oder sind die noch irgendwo anders?)
heraus kam:

Code: Alles auswählen

XXX@YYY:~$ diff -rs  /usr/share/initramfs-tools/ /media/usb/share/initramfs-tools/
Dateien /usr/share/initramfs-tools/conf-hooks.d/cryptsetup und /media/usb/share/initramfs-tools/conf-hooks.d/cryptsetup sind identisch.
diff -rs /usr/share/initramfs-tools/hook-functions /media/usb/share/initramfs-tools/hook-functions
426a427,429
> 			modules="$modules hid-apple hid-cherry hid-generic"
> 			modules="$modules hid-logitech hid-logitech-dj"
> 			modules="$modules hid-microsoft hid-sunplus"
430,446d432
< 
< 			# Include all HID drivers unless we're sure they
< 			# don't support keyboards.  hid-*ff covers various
< 			# game controllers with force feedback.
< 			copy_modules_dir kernel/drivers/hid \
< 				'hid-*ff.ko' hid-a4tech.ko hid-cypress.ko \
< 				hid-dr.ko hid-elecom.ko hid-gyration.ko \
< 				hid-icade.ko hid-kensington.ko hid-kye.ko \
< 				hid-lcpower.ko hid-magicmouse.ko \
< 				hid-multitouch.ko hid-ntrig.ko \
< 				hid-petalynx.ko hid-picolcd.ko hid-pl.ko \
< 				hid-ps3remote.ko hid-quanta.ko \
< 				'hid-roccat-ko*.ko' hid-roccat-pyra.ko \
< 				hid-saitek.ko hid-sensor-hub.ko hid-sony.ko \
< 				hid-speedlink.ko hid-tivo.ko hid-twinhan.ko \
< 				hid-uclogic.ko hid-wacom.ko hid-waltop.ko \
< 				hid-wiimote.ko hid-zydacron.ko
Dateien /usr/share/initramfs-tools/hooks/amd64_microcode und /media/usb/share/initramfs-tools/hooks/amd64_microcode sind identisch.
Dateien /usr/share/initramfs-tools/hooks/busybox und /media/usb/share/initramfs-tools/hooks/busybox sind identisch.
Dateien /usr/share/initramfs-tools/hooks/cryptgnupg und /media/usb/share/initramfs-tools/hooks/cryptgnupg sind identisch.
Dateien /usr/share/initramfs-tools/hooks/cryptkeyctl und /media/usb/share/initramfs-tools/hooks/cryptkeyctl sind identisch.
Dateien /usr/share/initramfs-tools/hooks/cryptopenct und /media/usb/share/initramfs-tools/hooks/cryptopenct sind identisch.
Dateien /usr/share/initramfs-tools/hooks/cryptopensc und /media/usb/share/initramfs-tools/hooks/cryptopensc sind identisch.
Dateien /usr/share/initramfs-tools/hooks/cryptpassdev und /media/usb/share/initramfs-tools/hooks/cryptpassdev sind identisch.
Dateien /usr/share/initramfs-tools/hooks/cryptroot und /media/usb/share/initramfs-tools/hooks/cryptroot sind identisch.
Dateien /usr/share/initramfs-tools/hooks/dmsetup und /media/usb/share/initramfs-tools/hooks/dmsetup sind identisch.
Dateien /usr/share/initramfs-tools/hooks/fuse und /media/usb/share/initramfs-tools/hooks/fuse sind identisch.
Dateien /usr/share/initramfs-tools/hooks/intel_microcode und /media/usb/share/initramfs-tools/hooks/intel_microcode sind identisch.
Dateien /usr/share/initramfs-tools/hooks/keymap und /media/usb/share/initramfs-tools/hooks/keymap sind identisch.
Dateien /usr/share/initramfs-tools/hooks/klibc und /media/usb/share/initramfs-tools/hooks/klibc sind identisch.
Dateien /usr/share/initramfs-tools/hooks/kmod und /media/usb/share/initramfs-tools/hooks/kmod sind identisch.
Dateien /usr/share/initramfs-tools/hooks/lvm2 und /media/usb/share/initramfs-tools/hooks/lvm2 sind identisch.
Dateien /usr/share/initramfs-tools/hooks/ntfs_3g und /media/usb/share/initramfs-tools/hooks/ntfs_3g sind identisch.
Dateien /usr/share/initramfs-tools/hooks/thermal und /media/usb/share/initramfs-tools/hooks/thermal sind identisch.
Dateien /usr/share/initramfs-tools/hooks/udev und /media/usb/share/initramfs-tools/hooks/udev sind identisch.
Dateien /usr/share/initramfs-tools/init und /media/usb/share/initramfs-tools/init sind identisch.
Dateien /usr/share/initramfs-tools/modules und /media/usb/share/initramfs-tools/modules sind identisch.
Dateien /usr/share/initramfs-tools/scripts/functions und /media/usb/share/initramfs-tools/scripts/functions sind identisch.
Dateien /usr/share/initramfs-tools/scripts/init-bottom/udev und /media/usb/share/initramfs-tools/scripts/init-bottom/udev sind identisch.
Dateien /usr/share/initramfs-tools/scripts/init-premount/amd64_microcode und /media/usb/share/initramfs-tools/scripts/init-premount/amd64_microcode sind identisch.
Dateien /usr/share/initramfs-tools/scripts/init-premount/intel_microcode und /media/usb/share/initramfs-tools/scripts/init-premount/intel_microcode sind identisch.
Dateien /usr/share/initramfs-tools/scripts/init-top/all_generic_ide und /media/usb/share/initramfs-tools/scripts/init-top/all_generic_ide sind identisch.
Dateien /usr/share/initramfs-tools/scripts/init-top/blacklist und /media/usb/share/initramfs-tools/scripts/init-top/blacklist sind identisch.
Dateien /usr/share/initramfs-tools/scripts/init-top/keymap und /media/usb/share/initramfs-tools/scripts/init-top/keymap sind identisch.
Dateien /usr/share/initramfs-tools/scripts/init-top/udev und /media/usb/share/initramfs-tools/scripts/init-top/udev sind identisch.
Dateien /usr/share/initramfs-tools/scripts/local und /media/usb/share/initramfs-tools/scripts/local sind identisch.
Dateien /usr/share/initramfs-tools/scripts/local-bottom/cryptopensc und /media/usb/share/initramfs-tools/scripts/local-bottom/cryptopensc sind identisch.
Dateien /usr/share/initramfs-tools/scripts/local-bottom/ntfs_3g und /media/usb/share/initramfs-tools/scripts/local-bottom/ntfs_3g sind identisch.
Dateien /usr/share/initramfs-tools/scripts/local-premount/ntfs_3g und /media/usb/share/initramfs-tools/scripts/local-premount/ntfs_3g sind identisch.
Dateien /usr/share/initramfs-tools/scripts/local-premount/resume und /media/usb/share/initramfs-tools/scripts/local-premount/resume sind identisch.
Dateien /usr/share/initramfs-tools/scripts/local-top/cryptopensc und /media/usb/share/initramfs-tools/scripts/local-top/cryptopensc sind identisch.
Dateien /usr/share/initramfs-tools/scripts/local-top/cryptroot und /media/usb/share/initramfs-tools/scripts/local-top/cryptroot sind identisch.
Dateien /usr/share/initramfs-tools/scripts/local-top/lvm2 und /media/usb/share/initramfs-tools/scripts/local-top/lvm2 sind identisch.
Dateien /usr/share/initramfs-tools/scripts/nfs und /media/usb/share/initramfs-tools/scripts/nfs sind identisch.

Also wurden nur die HID-hooks geändert (steht auch so im changelog).
Wieso zum Teufel ändert sich dann das LVM-cryptroot pipapo verhalten?!!

Hat irgendwer 'ne Idee?

MfG, Martin

*die ersten Gehversuche mit Woody damals zählen nicht wirklich...

EDITH meint:
ist ein Wheezy System, Kernel 3.2.0-4-amd64

[liNixchecker]

Hi,
auch wenns keinen interessiert hat, hier mal die Lösung wie ich das System mal zum normalen Booten gekriegt hab:

Wie es war:
Nach dem Kernel-Update war es so, dass ich eine neue Initramfs schreiben musste. Dadurch kam nach dem entschlüsseln des ersten Laufwerks immer der Fehler lvm fs found but no lvm configured und die Busybox. Durch Eingabe von vgchange -aly und Beenden der Busybox mit Ctrl+D wurde das lvm teilweise aktiviert und der Boot-Prozess ging erfolgreich weiter.
Mein Fehler:
Das Problem ist, dass sich meine VolumeGroup über drei Festplatten erstreckt. Bei der Verschlüsselung der Root-Part bekommt die initramfs die Root-Partition und das Gerät auf dem die Root-Partition liegt mitgeteilt. In meinem Fall war das sdc7_crypt und (sdc7). Dies stimmt natürlich nicht, denn sdc7_crypt ist ja nur lv-member, auf dem die Volume Group liegt in der das Boot-LV liegt...
Warum das so war? Keine Ahnung, ich nehme an, weil in meiner crypttab sdc7_crypt UUID=bla-bla none luks stand, wodurch das Ziel sdc7_crypt eingetragen wurde. Es wurde nämlich beim Entschlüsseln nicht nach dem Key für sdc7 (sdc7_crypt) gefragt, sondern nach UUID=bla-bla (sdc7_crypt).
Dies funktioniert so lange gut, wie nach dem Entschlüsseln das lvm komplett gestartet werden kann. Dummerweise hab ich aber dann drei Festplatten zu einer Volume Group zusammengestellt, wodurch erstmal das lvm teilweise aktiviert wurde, die Root-Partition gefunden wurde und danach alles seinen Gang ging. Wird jetzt aber die initramfs neu geschrieben, funktioniert das ganze nicht mehr. Anscheinend dauert die Aktivierung der VG zu lange, so dass der ganz Vorgang abbricht. Ein einfaches vgchange -ay reichte aus, um wie gehabrt weiter zu machen...
Die Lösung: cryptroot
Das ist auf Dauer irgendwie unschön. Nach vielem googStartpagen, Lesen, Kopf kratzen usw. fand ich dann heraus, dass die Hooks aus /usr/share/initramfs-tools doch mal nach /etc/initramfs-tools kopiert werden sollten, wenn sie auch ausgeführt werden sollen...
Zumindest initramfs-tools/hooks/cryptroot und initramfs-tools/scripts/local-top/cryptroot müssen dahin. Jetzt muss noch initramfs-tools/conf.d/cryptroot erstellt werden. Dort kann man jetzt dem Script einen Parameter mitgeben, mit dem er die richtige Root-Partition findet. Bei mir steht da jetzt:
CRYPTOPTS=target=vg0-lv0,source=/dev/sdc7,lvm=vg0-lv0
Target gibt an, wie die Root-Partition heist, Source gibt das Device an, das Entschlüsselt werden muss und lvm gibt an, ob sich die Root-Partition auf einem lvm befindet und wie das Volume heist.
Jetzt bootet das System wieder sauber hoch, nach Passphraseneingabe wird das lvm teilweise aktiviert, die Root-Partition gemountet, die beiden zusätzlichen PVs duch die Keyfiles geöffnet, die restliche VG aktiviert, alle Partionen eingebunden und das System gestartet.
Eine Sache gibt es allerdings noch zu beachten: sdc7_crypt heist jetzt cryptroot. Dies führt dazu, dass bei unveränderter crypttab cryptsetup versucht sdc7_crypt zu öffen und fordert die Passphrase an. Da es ja schon offen ist (allerdings unter anderem Namen) scheitert das Ganze natürlich. Die Lösung ist einfach: den Eintrag in der crypttab herausnehmen. Durch den Parameter CRYPTOPTS weiss das System ja schon, wo es welche Platte zu öffen hat.

MfG,
Martin