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

Toni Mueller support at oeko.net
Tue Sep 14 21:01:42 UTC 2010


Hi,

On Tue, 14.09.2010 at 21:28:17 +0200, Andreas von Heydwolff <106624.446 at compuserve.com> wrote:
> After upgrading mdadm I had

since I really need my machine now, I didn't yet dare to reboot. I also
don't understand the issue too well, but simply want to contribute my
data for comparison.

> [snip]
> >> Generating udev events for MD arrays...done.
> >> Verarbeite Trigger für man-db ...
> >> Verarbeite Trigger für initramfs-tools ...
> >> 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 -

I guess that this 'Generating udev events...' messages comes from
mdadm's postinst?

> On 2010-09-12 21:43, Darren wrote:
> >initramfs of ..-amd64 did not get updated. I could not see the
> >crypttab error message.

> >For me it helped to run a separate
> ># update-initramfs

I can't remember any specific error messages, too, but noticed that my
initrds are all out of date. Then I regenerated one for an older kernel
that I usually don't use.

> >If that does not help, how does your /etc/crypttab look like?

I didn't yet verify that this does not work, but my crypttab looks
fishy:

>   My /etc/crypttab reads
> 
> md1_crypt UUID=3a10eb55-2dd8-4846-97e5-74649abf234f none luks
> md2_crypt UUID=e78a6bea-cafb-41a7-89e9-03e999b38d6c none luks


Mine looks like this:

$ cat /etc/crypttab 
md1_crypt /dev/md1 none luks
$

And:

# blkid | grep crypt
/dev/md1: UUID="656f1d28-32c9-435b-b785-e7c1962c4a56" TYPE="crypto_LUKS" 
/dev/mapper/md1_crypt: UUID="604eXQ-VtTT-dRFX-2x2r-JTSg-fgW0-nret5y" TYPE="LVM2_member" 
#

> Perhaps it boils down to some bug where "Calling hook cryptroot" is
> being issued? The format of crypttab seems to be correct, isn't it?
> 
> The initramfs system does not find the encrypted RAID1 device that
> contains the vg with root, and when I unlock the device manually and
> start the vg the pv  gets mapped to /dev/dm-0 and /dev/dm-11 a
> second time when booting resumes after unlocking the volume group
> that contains / as can be seen here:
> 
> # pvscan
>   Found duplicate PV c1Evvwvx3ZfBwDWRyhhI0nY864wtPZ3o: using
> /dev/dm-11 not /dev/dm-0
>   PV /dev/dm-12   VG vg-md2dm1   lvm2 [197,43 GiB / 17,43 GiB free]
>   PV /dev/dm-11   VG vg-md1dm0   lvm2 [32,59 GiB / 1,31 GiB free]
>   Total: 2 [230,02 GiB] / in use: 2 [230,02 GiB] / in no VG: 0 [0   ]

I can't confirm this one:

# pvscan
  PV /dev/dm-0   VG ev0   lvm2 [931.32 GiB / 0    free]
  Total: 1 [931.32 GiB] / in use: 1 [931.32 GiB] / in no VG: 0 [0   ]
#


HTH


Kind regards,
--Toni++






More information about the Pkg-grub-devel mailing list