Am Montag, den 31.05.2010, 22:29 +0200 schrieb Michael Prokop: > * Paul Menzel <pm.deb...@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
signature.asc
Description: This is a digitally signed message part
