Bug#594472: grub-pc: more info

[Andreas v. Heydwolff]

Package: grub-pc
Severity: normal


After installing a rescue system into sda2 I could unlock
md1 in the usual half second or second, start the lvms 
and mount them. I chrooted into the mounted root partition
and could add options to the rescue partitions's grub.cfg
and update the MBRs 

I added md0 as /boot that indeed had not been added to fstab.

Other than that nothing had changed. A few observations though:

- The  /sys/devices/virtual/block/md1 (numbers) section
flies past also when I boot into the rescue system, doesn't
do any visible harm though.

- It seems to me that when vg0 is not being found, searching 
for the crypto partition drives CPU load up and then it never 
goes down again. Might be the same with unencrypted lvm. If 
the assumed high CPU load went down, perhaps unlocking would not
be the problem just as it is no problem in the rescue system.

- in grub.cfg 
   set root=(md/0)  
looks like a mistake to me. (md0) doesn't help either.

- On a machine with grub-pc 1.98~20100101-1 
the stanzas are 
   linux   //vmlinuz-2.6.30-2-686 root=/dev/mapper/vg1-slash ro single                                                                                 
   initrd  //initrd.img-2.6.30-2-686

while the current amd64 machine install's grub displays only one slash
   linux   /vmlinuz-2.6.32...
   initrd  /initrd...

but again, playing with these variables changed nothing.

--AvH