Dear Debian mdadm maintainers and Debian LVM Team,
could you please comment on the first issue if it is related to your
packages.
Am Dienstag, den 01.06.2010, 00:59 +0200 schrieb Paul Menzel:
> 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.
Unfortunately I spoke too soon. I experienced the same issue this
morning. This time waiting 80 minutes.
[ 1.726144] md1: detected capacity change from 0 to 499595214848
[ 1.729583] md1: unknown partition table
[ 1.739554] device-mapper: uevent: version 1.0.3
[ 1.740216] device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-devel@redhat.com
[ 4811.891105] PM: Starting manual resume from disk
Any hints on how I could debug this? I guess it is a mdadm or LVM issue
due to the following observation. (I upgraded the following packages on
Saturday.)
[AKTUALISIERUNG] lvm2 2.02.62-1 -> 2.02.64-1
[AKTUALISIERUNG] mdadm 3.1.1-1 -> 3.1.2-2
It seems to me that every LVM volume is scanned since the udevd-work
messages [1][2] are printed to the screen one by one with certain amount
of time difference in between. The larger the partition/volume the
larger the amount of time in between.
udevd-work[255]: kernel-provided name 'dm-0' and NAME= 'mapper/lvm-usr' disagree, please use SYMLINK+= or change the kernel to provide the proper name
udevd-work[255]: kernel-provided name 'dm-3' and NAME= 'mapper/lvm-home' disagree, please use SYMLINK+= or change the kernel to provide the proper name
[ several more ]
`mapper/lvm-root` is actually printed out/found at the very beginning,
but it seems to be waiting until all partitions are scanned (dm-0 to
dm-8 on my system).
After the last volume is found, the boot continues normally.
> 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
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582639
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583948
Attachment:
signature.asc
Description: This is a digitally signed message part