Now we are getting somewhere! Here's what I suspect to be the problem: Am Montag, den 20.09.2010, 09:59 +0200 schrieb Andreas von Heydwolff: > > * What exactly do you have to do to boot your system manually > > after being thrown to a rescue shell (precise commands)? > > # cryptsetup luksOpen /dev/md1 vg-md1dm0 That is wrong. According to your /etc/crypttab[1] the cleartext device for /dev/md1 is "md1_crypt" not "vg-md1md0". The line should therefore look like this:
cryptsetup luksOpen /dev/md1 md1_crypt If you use the wrong command this is what happens: * The LVM you set up manually (which contains your root fs) will use /dev/mapper/vg-md1dm0 as its physical volume. * When the initramfs is regenerated, the cryptsetup hooks searches for "vg-md1dm0" in /etc/crypttab as this contains the PV for the LV on which the root fs of the currently running system is. Since there is of course no such entry you get those error messages and your crypto devices don't get unlocked before the root fs is mounted. * Since cryptsetup therefore thinks that /dev/md1 is just a normal encrypted volume, it will unlock it together with /dev/md2 (your /home) during normal boot. That's why why you have to enter /dev/md1's passphrase again and why you also have /dev/mapper/md1_crypt which (of course) has the same UUID as /dev/mapper/vg-md1md0. > That's what I think (manual creation). And without specifying the vg I > receive the error message that no volume groups are found That's because you didn't scan the devices. Use vgscan vgchange -ay Note that you don't need to enter the LVM shell for that. Best regards Alexander Kurtz [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594472#169
signature.asc
Description: This is a digitally signed message part