FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 06-01-2010, 09:27 AM
Paul Menzel
 
Default Bug#583917: initramfs-tools: long delay (6–200 minutes) during boot (root device detection) after upgrade on RAID/LVM/LUKS setup

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
 
Old 06-01-2010, 11:32 AM
martin f krafft
 
Default Bug#583917: initramfs-tools: long delay (6–200 minutes) during boot (root device detection) after upgrade on RAID/LVM/LUKS setup

also sprach Paul Menzel <pm.debian@googlemail.com> [2010.06.01.1127 +0200]:
> Dear Debian mdadm maintainers and Debian LVM Team,
>
> could you please comment on the first issue if it is related to your
> packages.

I don't see a way in which mdadm could be responsible for this. Have
you tried downgrading it to see if the error persists?

--
.'`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems

"vulgarity is simply the conduct of other people."
-- oscar wilde
 

Thread Tools




All times are GMT. The time now is 12:56 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org