Am Montag, den 31.05.2010, 22:29 +0200 schrieb Michael Prokop:
> * Paul Menzel <pm.debian@googlemail.com> [Mon May 31, 2010 at 06:41:45PM +0200]:
>
> > yesterday I upgrade my Debian Sid/unstable system after over a
> > week. Several core packages were upgraded by doing this as lvm2,
> > mdadm, initscripts, initramfs-tools. I have a standard md RAID1
> > setup with LVM over it. Furthermore there is a partition for
> > `/boot` and a LUKS encrypted `/`.
>
> > Now I am seeing the following behavior. After GRUB2 started
> > (`linux /vmlinuz-2.6.32-5-amd64 root=/dev/mapper/lvm-root …`) I
> > first get to see a lot of lines
>
> > sys/devices/virtual/block (some incremented number in 80??)
>
> > (this is from memory). Afterward I am asked for the LUKS
> > passphrase. After that nothing happens. Just a lot of – according
> > to my Web research unrelated –udev-work messages about `NAME` and
> > `SYMLINK` stuff and nothing happens. Then after six to ten minutes
> > booting finally continues.
>
> [...]
>
> > Is that related to the `root` argument passed in GRUB to `linux`.
> > In [1] the solution is to use a UUID instead of the path. Though I
> > did not find how I can find out the correct value for my RAID
> > device or LVM partition.
>
> Executing 'blkid /dev/mapper/lvm-root' should provide you the UUID
> of the LVM partiton for use as root=UUID=... argument.
Thank you. While waiting during the now four hour long boot I found that
too over the comment about `vol_id` in `/etc/fstab`. ;-) Adding
`root=UUID=…` to `/boot/grub/grub.cfg` fixed the long boot for me. There
are still the following issues.
1. What upgrade introduced this behavior?
2. According to `/etc/default/grub` the `root=` entry should be set to
the UUID.
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
Somehow that does not work on my system.
3. The comment in `/etc/fstab` should be updated to use `blkid` instead
of `vol_id`.
4. I still see those `sys/devices/virtual/block/md{0,1} (number)`
running by. Once before entering the LUKS passphrase dialog and after
it. Each time this seems to cause a delay of several seconds to the boot
process. I guess that is debpkg:mdadm related.
Thanks,
Paul
Attachment:
signature.asc
Description: This is a digitally signed message part