Hi, I think a little more information would be helpful. IMHO your problem can be divided into three parts. Let's discuss them separately:
1. Just for the record: You do have mdadm 3.1.4-1+8efb9d1 installed (it
should migrate to squeeze today[1])?
Am Freitag, den 17.09.2010, 01:38 +0200 schrieb Andreas von Heydwolff:
> Hm. All three variants yielded the same result:
>
> # update-initramfs -u
> update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64
> cryptsetup: WARNING: invalid line in /etc/crypttab -
> cryptsetup: WARNING: invalid line in /etc/crypttab -
2. Ok I really want to know why this error message appears. This is the
relevant code:
$ sed -n '179,187p' /usr/share/initramfs-tools/hooks/cryptroot
opt=$( grep "^$target\b" /etc/crypttab | head -1 | sed
's/[[:space:]]\+/ /g' )
source=$( echo $opt | cut -d " " -f2 )
key=$( echo $opt | cut -d " " -f3 )
rootopts=$( echo $opt | cut -d " " -f4- )
if [ -z "$opt" ] || [ -z "$source" ] || [ -z "$key" ] || [ -z
"$rootopts" ]; then
echo "cryptsetup: WARNING: invalid line in /etc/crypttab -
$opt" >&2
return 1
fi
Looking at your error message, I guess $opt is empty (which would
also make the other variables empty). That can only happen if the
grep which is supposed to fill $opt returns nothing. Can you
* append the complete output of
+ ls -l /dev/mapper
+ mount
+ cat /etc/fstab
+ cat /etc/crypttab
* temporarily change line 185 of /usr/share/initramfs-tools/hooks/cryptroot
like this for more information:
echo "cryptsetup: WARNING: invalid line in /etc/crypttab - $opt
(target=$target, extraopts=$extraopts, @=$@)" >&2
* run update-initramfs -u with the modified hook and send me the
output?
> Then I followed this previously mentioned error message:
>
> # update-grub
> Generating grub.cfg ...
> Found background image: moreblue-orbit-grub.png
> Found linux image: /boot/vmlinuz-2.6.32-5-amd64
> Found initrd image: /boot/initrd.img-2.6.32-5-amd64
> Found duplicate PV c1Evvwvx3ZfBwDWRyhhI0nY864wtPZ3o: using /dev/dm-11
> not /dev/dm-0
> Found Debian GNU/Linux (squeeze/sid) on /dev/sda2 [my rescue system]
> done
>
> # blkid | grep Evv
> /dev/mapper/md1_crypt: UUID="c1Evvw-vx3Z-fBwD-WRyh-hI0n-Y864-wtPZ3o"
> TYPE="LVM2_member"
> /dev/mapper/vg-md1dm0: UUID="c1Evvw-vx3Z-fBwD-WRyh-hI0n-Y864-wtPZ3o"
> TYPE="LVM2_member"
>
> # l /dev/mapper/
> insgesamt 0
> crw------- 1 root root 10, 59 14. Sep 20:59 control
> lrwxrwxrwx 1 root root 8 14. Sep 20:59 md1_crypt -> ../dm-11
> lrwxrwxrwx 1 root root 8 14. Sep 20:59 md2_crypt -> ../dm-12
> lrwxrwxrwx 1 root root 7 14. Sep 20:53 vg-md1dm0 -> ../dm-0
>
> Perhaps this is the source of confusion? Identical UUIDs for the
> encrypted RAID1 pv and the vg that emerges when the pv has been unlocked
> with cryptsetup? This is the configuration on the running system on
> which md1_crypt and the vg had been unlocked and started manually. Do I
> have to remove one symlink, either to dm-0 or to dm-11 in order to
> create a functioning initramdisk? I had to unlock md1_crypt twice, once
> from within busybox and once after exiting lvm and busybox.
3. I don't know much about LVM. I tend to think that the
identical UUIDs might actually be correct - but I may be wrong here.
It would be very helpful if you could give a short overview over your
block devices and how the work together (a drawing would be great).
Please include everything from the physical disks, physical and
logical partitions, RAID, LVM, CRYPTO up to the FS level. Please
also include the UUIDs in this.
Finally the complete output of `blkid' would be great.
Please excuse me if I'm asking for information you have already provided
- the bug report is just quite long by now and I might have missed it.
If this is the case, just tell me.
Best regards
Alexander Kurtz
[1] http://release.debian.org/migration/testing.pl?package=mdadm
signature.asc
Description: This is a digitally signed message part
