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 10-09-2011, 10:26 PM
Jort Koopmans
 
Default Bug#644876: initramfs-tools: Boot failure from software RAID1 + LVM2 by timing of mdadm + lvm initiation

Package: initramfs-tools
Version: 0.98.8
Severity: important


Dear kernelteam,

After installing a vanilla debian kernel (2.6.32-5-amd64) to 2 similar USB thumbdrives in software RAID1 and using LVM2 an error occurs at boot stating ROOT can not be found. In my case / is locted on an lv managed by lvm (/dev/mapper/vgbase-lvroot), of which the volume group is located on a raid1 (using partitions from both usb drives)
The origin of the problem is the combination of late detection of the USB devices in combination with the bootsequence.

After some research it became clear to me that the mdadm and lvm routines (located in /scripts/local-top?) are performed before the rootdelay loop (located in /scripts/local).
On systems without a complex raid or lvm setup this poses no problem since the root will instantly be present when the slow device is recognised.

In my case adding a rootdelay=x does NOT solve the problem because when the USB drives become available there are still no started MD devices or LVM volumes.
The (quick and dirty) solution for me was adding 3 lines to the /scripts/local file after the rootdelay loop (ends at line 42);

/sbin/mdadm --assemble --scan
/sbin/lvm vgscan --ignorelockingfailure
/sbin/lvm vgchange --ignorelockingfailure -a y

In essence this repeats the mdadm and lvm2 routines but then without the nice checking of earlier mentioned scripts.

Of course it would be better to get the routines programmed nicely after the rootdelay parameter.
Is it possible to fix this? I am happy to assist in testing better solutions than the dirty one I proposed. Also I will try to answer any questions if the above is unclear or if more information is needed.

See also bug #433905 for a similar case (only first post applies).

Best regards,
Jort Koopmans


-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 11M Oct 9 22:59 /boot/initrd.img-2.6.32-5-amd64
-rw-r--r-- 1 root root 11M Oct 9 11:57 /boot/initrd.img-2.6.32-5-amd64.bakorig
-rw-r--r-- 1 root root 11M Oct 9 15:22 /boot/initrd.img-2.6.32-5-amd64.bakworks
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-2.6.32-5-amd64 root=/dev/mapper/vgbase-lvroot ro quiet

-- resume
RESUME=/dev/mapper/vgbase-lvswap
-- /proc/filesystems
ext3

-- lsmod
Module Size Used by
loop 11799 0
evdev 7352 4
pcspkr 1699 0
i2c_i801 7830 0
i2c_core 15819 1 i2c_i801
snd_hda_intel 20035 0
snd_hda_codec 54244 1 snd_hda_intel
snd_hwdep 5380 1 snd_hda_codec
snd_pcm 60487 2 snd_hda_intel,snd_hda_codec
snd_timer 15598 1 snd_pcm
snd 46526 5 snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_ timer
soundcore 4598 1 snd
snd_page_alloc 6249 2 snd_hda_intel,snd_pcm
ioatdma 34876 16
dca 3761 1 ioatdma
button 4650 0
processor 29935 8
ext3 106710 3
jbd 37221 1 ext3
mbcache 5050 1 ext3
sd_mod 29921 6
crc_t10dif 1276 1 sd_mod
dm_mod 53898 9
raid1 18431 2
md_mod 73872 3 raid1
usbhid 33292 0
hid 63257 1 usbhid
usb_storage 40057 4
uhci_hcd 18521 0
ahci 32534 0
libata 133776 1 ahci
scsi_mod 126533 3 sd_mod,usb_storage,libata
ehci_hcd 32081 0
e1000e 124772 0
usbcore 122674 5 usbhid,usb_storage,uhci_hcd,ehci_hcd
nls_base 6377 1 usbcore
thermal 11674 0
thermal_sys 11942 2 processor,thermal

-- /etc/initramfs-tools/modules

-- /etc/kernel-img.conf
# Kernel image management overrides
# See kernel-img.conf(5) for details
do_symlinks = yes
do_bootloader = 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/initramfs-tools/update-initramfs.conf
update_initramfs=yes
backup_initramfs=no

-- /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sda2[0] sdb2[1]
15051704 blocks super 1.2 [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
306164 blocks super 1.2 [2/2] [UU]

unused devices: <none>

-- mkinitramfs hooks
/etc/initramfs-tools/hooks/:

/usr/share/initramfs-tools/hooks:
busybox
dmsetup
keymap
klibc
lvm2
mdadm
thermal
udev


-- System Information:
Debian Release: 6.0.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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

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+b1 utilities for finding files--find,
ii klibc-utils 1.5.20-1+squeeze1 small utilities built with klibc f
ii module-init-tools 3.12-1 tools for managing Linux kernel mo
ii udev 164-3 /dev/ and hotplug management daemo

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

Versions of packages initramfs-tools suggests:
ii bash-completion 1:1.2-3 programmable completion for the ba

-- no debconf information



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111009222615.2271.27583.reportbug@muscovite.jabo-solutions.eu">http://lists.debian.org/20111009222615.2271.27583.reportbug@muscovite.jabo-solutions.eu
 
Old 10-10-2011, 09:49 AM
Jort Koopmans
 
Default Bug#644876: initramfs-tools: Boot failure from software RAID1 + LVM2 by timing of mdadm + lvm initiation

Additional thoughts;

As I'm no expert on the whole initramfs boot sequence I'm unsure about
the total workings of timing of device scanning, mdadm + lvm2 routines
and rootdelay.

Imho it should be something like this;

init Device scanning
|
some scanning delay parameter (for slow devices)
|
init Mdadm routine
|
some mdadm delay parameter? (see #633024)
|
LVM2 routine
|
Checking and setting ROOT

Again, I'm not too familiar with the current workings but I see these
steps are currently running in a more parallel way to speed up the boot
process, as the local-top init scripts are called right at the start of
the local script.
I've confirmed this by trying another method of fixing my problem,
instead of my previous fix;

Adding 'sleep 10' at the top of /scripts/local-top/mdadm also solves the
problem (mdadm is then performed after device scanning)

Is there a unifiable way of getting the timings right of all the scripts
and still maintaining a quick bootprocess? If not, is it possible to add
extra kernel boot options providing the delay options (avoiding manual
tampering with the initrd)?

Best regards,
Jort Koopmans




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1318240153.20978.51.camel@localhost">http://lists.debian.org/1318240153.20978.51.camel@localhost
 
Old 03-13-2012, 11:29 PM
Dave Whitla
 
Default Bug#644876: initramfs-tools: Boot failure from software RAID1 + LVM2 by timing of mdadm + lvm initiation

I believe this might be the culprit:

In /usr/share/initramfs-tools/scripts/local-top/mdadm:


if [ -x "$(command -v udevsettle)" ]; then
verbose && log_begin_msg "Waiting for udev to process events"
udevsettle 10
verbose && log_end_msg
fi

The condition will never be true because udevsettle was a symlink to /sbin/udevadm which has been absent from Debian since Lenny.

Try editing this file to replace the above with:

if [ -x "$(command -v udevadm)" ]; then
verbose && log_begin_msg "Waiting for udev to process events"
udevadm settle --timeout=10
verbose && log_end_msg
fi


Dave


This email (including any attachments) is confidential and may be privileged. If you have received it in error, please notify the sender by return email and delete this message from your system. Any unauthorised use or dissemination of this message in whole or in part is strictly prohibited. Please note that emails are susceptible to change and we will not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. We do not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference.



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CDDDC097-1FDD-4D4B-8546-60DADD81622F@wotifgroup.com">http://lists.debian.org/CDDDC097-1FDD-4D4B-8546-60DADD81622F@wotifgroup.com
 

Thread Tools




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

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