On 2010-09-18 23:46, Alexander Kurtz wrote:
> Ehm... I suggested to change that line for *diagnosing only*. The "fix"
> was that apparently you forgot the ">&2" part at the end
Sorry, what a stupid mistake I made. Corrected the diagnosis is:
# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64
cryptsetup: WARNING: invalid line in /etc/crypttab - (target=vg-md1dm0,
extraopts=rootdev,lvm=vg--md1dm0-slash, @=vg-md1dm0
rootdev,lvm=vg--md1dm0-slash)
cryptsetup: WARNING: invalid line in /etc/crypttab - (target=vg-md1dm0,
extraopts=lvm=vg--md1dm0-swap, @=vg-md1dm0 lvm=vg--md1dm0-swap)
I have no idea why / and swap lvs are affected - I had assumed this
referred to md1_crypt and md2_crypt, but no.
> Questions:
>
> * What exactly fails at booting during the initramfs stage?
> Do the raid devices get assembled correctly?
Yes.
Do the crypto
> devices get unlocked?
No.
What about LVM?
> In short: What works, what doesn't?
>
> * 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
[System asks for Passphrase]
# <Passphrase>
[System silently accepts passphrase]
# lvm
lvm> vgchange -ay vg-md1dm0
[System reports the logical columes as active]
lvm> exit
# exit [from rescue shell]
Then the normal booting resumes, asking the question for md1's
passphrase, and when md1 has been unlocked, the same happens for md2,
and then the system completes the boot process in the proper way.
> * The double-UUID-problem: What is /dev/mapper/vg-md1dm0?
> Do somehow manually create it when booting the system by hand?
> What happens if you use *only* "vgscan; vgchange -ay" to activate
> all logical volumes?
That's what I think (manual creation). And without specifying the vg I
receive the error message that no volume groups are found
Best regards,
Andreas v. Heydwolff
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
