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).
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
10-10-2011, 09:49 AM
Jort Koopmans
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
03-13-2012, 11:29 PM
Dave Whitla
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