Bug#594472: grub-pc: scary messages and very long boot time after upgrade

[Alexander Kurtz]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20100917/1be24c7d/attachment.pgp>