Subject: initramfs-tools: long delay during boot after upgrade
Package: initramfs-tools
Version: 0.95.1
Severity: normal
Tags: sid

*** Please type your report below this line ***

Dear Debian folks,


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.

$ dmesg
[…]
[ 1.588141] usbcore: registered new interface driver usbhid
[ 1.588144] usbhid: v2.6:USB HID core driver
[ 1.676754] md: raid1 personality registered for level 1
[ 1.689704] md: md0 stopped.
[ 1.690573] md: bind<sda1>
[ 1.692913] raid1: raid set md0 active with 1 out of 2 mirrors
[ 1.692944] md0: detected capacity change from 0 to 509804544
[ 1.694098] md0: unknown partition table
[ 1.701276] md: md1 stopped.
[ 1.703642] md: bind<sda2>
[ 1.706108] raid1: raid set md1 active with 1 out of 2 mirrors
[ 1.706140] md1: detected capacity change from 0 to 499595214848
[ 1.707746] md1:
[ 1.715665] device-mapper: uevent: version 1.0.3
[ 1.715825] device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-devel@redhat.com
[ 1.745488] unknown partition table
[ 1144.682200] PM: Starting manual resume from disk
[ 1144.682205] PM: Resume from partition 253:2
[ 1144.682207] PM: Checking hibernation image.
[ 1144.693923] PM: Error -22 checking image file
[ 1144.693927] PM: Resume from disk failed.
[…]

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.

Sorry if I filed this against the wrong package. Any hints are welcome. Please ask for additional information if needed.


Thanks,

Paul


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583284


PS: Upgrading from 0.95 to 0.95.1 today did not help.

-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 9.8M May 31 11:28 /boot/initrd.img-2.6.32-5-686
-rw-r--r-- 1 root root 9.9M May 31 11:29 /boot/initrd.img-2.6.32-5-amd64
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-2.6.32-5-amd64 root=/dev/mapper/speicher-root ro quiet

-- resume
RESUME=/dev/mapper/speicher-swap
-- /proc/filesystems
ext3
fuseblk
xfs
reiserfs

-- lsmod
Module Size Used by
binfmt_misc 6399 1
via 32847 0
drm 142199 1 via
ppdev 5030 0
lp 7462 0
ip6table_filter 2384 0
ip6_tables 14867 1 ip6table_filter
iptable_filter 2258 0
ip_tables 13675 1 iptable_filter
x_tables 12685 2 ip6_tables,ip_tables
kvm_amd 31222 0
kvm 213448 1 kvm_amd
powernow_k8 10978 1
cpufreq_conservative 5162 0
cpufreq_userspace 1992 0
cpufreq_stats 2659 0
cpufreq_powersave 902 0
reiserfs 193756 1
xfs 436189 2
exportfs 3122 1 xfs
fuse 49982 1
loop 11607 0
firewire_sbp2 11418 0
firewire_core 36624 1 firewire_sbp2
crc_itu_t 1307 1 firewire_core
snd_hda_codec_realtek 235026 1
snd_hda_intel 19907 4
snd_hda_codec 53892 2 snd_hda_codec_realtek,snd_hda_intel
snd_hwdep 5236 1 snd_hda_codec
snd_pcm_oss 32415 0
snd_mixer_oss 12478 1 snd_pcm_oss
snd_pcm 60119 4 snd_hda_intel,snd_hda_codec,snd_pcm_oss
snd_seq_midi 4256 0
snd_rawmidi 15323 1 snd_seq_midi
snd_seq_midi_event 4628 1 snd_seq_midi
snd_seq 41281 2 snd_seq_midi,snd_seq_midi_event
snd_timer 15486 2 snd_pcm,snd_seq
snd_seq_device 4493 3 snd_seq_midi,snd_rawmidi,snd_seq
amd64_edac_mod 13630 0
tpm_tis 7336 0
parport_pc 18855 1
edac_core 29197 3 amd64_edac_mod
snd 45918 18 snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec, snd_hwdep,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_ra wmidi,snd_seq,snd_timer,snd_seq_device
tpm 9549 1 tpm_tis
i2c_viapro 5483 0
parport 27682 3 ppdev,lp,parport_pc
soundcore 4566 1 snd
psmouse 49777 0
asus_atk0110 7686 0
tpm_bios 4489 1 tpm
edac_mce_amd 6433 1 amd64_edac_mod
k8temp 3139 0
shpchp 26232 0
snd_page_alloc 6217 2 snd_hda_intel,snd_pcm
pcspkr 1699 0
serio_raw 3752 0
evdev 7352 16
i2c_core 15328 2 drm,i2c_viapro
pci_hotplug 21203 1 shpchp
processor 30167 1 powernow_k8
button 4650 0
ext3 106326 5
jbd 36861 1 ext3
mbcache 5050 1 ext3
sha256_generic 8644 2
aes_x86_64 7340 2
aes_generic 25714 1 aes_x86_64
cbc 2507 1
dm_crypt 10491 1
dm_mod 53434 27 dm_crypt
raid1 17999 2
md_mod 73040 3 raid1
usbhid 33244 0
hid 62793 1 usbhid
sg 18632 0
sr_mod 12250 0
sd_mod 29553 3
crc_t10dif 1276 1 sd_mod
cdrom 28631 1 sr_mod
ata_generic 2983 0
sata_via 7789 2
uhci_hcd 18521 0
pata_via 7461 0
libata 133008 3 ata_generic,sata_via,pata_via
ehci_hcd 31023 0
thermal 11610 0
thermal_sys 11942 2 processor,thermal
scsi_mod 121717 5 firewire_sbp2,sg,sr_mod,sd_mod,libata
via_rhine 17371 0
mii 3210 1 via_rhine
usbcore 121671 4 usbhid,uhci_hcd,ehci_hcd
nls_base 6361 1 usbcore

-- /etc/kernel-img.conf
# Kernel image management overrides
# See kernel-img.conf(5) for details
do_symlinks = yes
relative_links = yes
do_bootloader = no
do_bootfloppy = no
do_initrd = yes
link_in_boot = no

-- /etc/initramfs-tools/initramfs.conf
MODULES=most
BUSYBOX=y
KEYMAP=n
COMPRESS=gzip
BOOT=local
DEVICE=
NFSROOT=auto

-- /etc/crypttab
# <target name> <source device> <key file> <options>
md1_crypt /dev/md1 none luks


-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages initramfs-tools depends on:
ii cpio 2.11-4 GNU cpio -- a program to manage ar
ii findutils 4.4.2-1 utilities for finding files--find,
ii klibc-utils 1.5.18-1 small utilities built with klibc f
ii module-init-tools 3.12~pre2-3 tools for managing Linux kernel mo
ii udev 154-1 /dev/ and hotplug management daemo

Versions of packages initramfs-tools recommends:
ii busybox 1:1.15.3-1 Tiny utilities for small and embed

initramfs-tools suggests no packages.

-- no debconf information

* 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.

regards,
-mika-

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