Bug#644876: initramfs-tools: Boot failure from software RAID1 + LVM2 by timing of mdadm + lvm initiation
Control: fixed -1 3.2.5-6 On Sun, 2015-01-18 at 16:03 +, Ben Hutchings wrote: Version: 3.3-1 The proposed change to udevadm was made in version 3.3-1 but was accidentally omitted from the changelog. Actually, it is mentioned in the changelog but in a version that was never uploaded. The changes file for 3.3-1 probably was not generated using the correct -v option. Ben. -- Ben Hutchings The generation of random numbers is too important to be left to chance. - Robert Coveyou signature.asc Description: This is a digitally signed message part
Bug#644876: initramfs-tools: Boot failure from software RAID1 + LVM2 by timing of mdadm + lvm initiation
reassign 644876 mdadm tags 644876 + patch thanks Le mercredi 14 mars 2012 à 01:29, d'après Dave Whitla dave.whi...@wotifgroup.com : 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 Good catch! And even better, there is a function to do that (defined in scripts/functions and already used by scripts/nfs and scripts/local). Also, this script is shipped by the mdadm package. --- /usr/share/initramfs-tools/scripts/local-top/mdadm.orig 2013-01-24 14:09:11.0 +0100 +++ /usr/share/initramfs-tools/scripts/local-top/mdadm 2013-03-02 18:03:59.0 +0100 @@ -97,11 +97,7 @@ done fi -if [ -x $(command -v udevsettle) ]; then - verbose log_begin_msg Waiting for udev to process events - udevsettle 10 - verbose log_end_msg -fi +wait_for_udev 10 maybe_break post-mdadm -- Thomas Parmelan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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_i8017830 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_pcm60487 2 snd_hda_intel,snd_hda_codec snd_timer 15598 1 snd_pcm snd46526 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 ioatdma34876 16 dca 3761 1 ioatdma button 4650 0 processor 29935 8 ext3 106710 3 jbd37221 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 hid63257 1 usbhid usb_storage40057 4 uhci_hcd 18521 0 ahci 32534 0 libata133776 1 ahci scsi_mod 126533 3 sd_mod,usb_storage,libata ehci_hcd 32081 0 e1000e124772 0 usbcore 122674 5 usbhid,usb_storage,uhci_hcd,ehci_hcd nls_base6377 1 usbcore thermal11674 0 thermal_sys11942 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
