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
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
