linux-kernel - 2.6.18-rc4-* LVM issues from initrd.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <200608251835.k7PIZHZv016794@turing-police.cc.vt.edu>
Date:	Fri, 25 Aug 2006 14:35:17 -0400
From:	Valdis.Kletnieks@...edu
To:	linux-kernel@...r.kernel.org
Subject: 2.6.18-rc4-* LVM issues from initrd.

I never saw this under 2.6.18-rc3-mm*, and for a while -rc4-mm1 wasn't
doing it either. However, I'm now seeing a reproducible problem with -rc4
and later...

Setup:  1 disk, basically 2 partitions, an ext3 /boot and a LVM space that
/ and other filesystems live in.  Of late, the 'vgscan' command has been
consistently failing to find the volume group, so we end up falling off
the end of the initrd startup script when there's no init left.  It's not
a every-time thing - after 2 to 10 attempted boots, one will work. I was
suspecting hardware issues after some problems caused a motherboard swap
last week - but -rc3-mm2 is 100% able to boot every time.  It *seems* to
be a timing-related thing - adding 'loglevel=7' to the boot generates more
printk traffic, which seems to slow it down enough to improve chances.

My personal guess is that -rc4 is a few percent faster at booting, and
the initrd (running 'nash') used to take long enough that the hotplug event
that created /dev/sda1 and /dev/sda2 *used* to finish before vgscan got
started, but now vgscan is getting going faster and races the hotplug.

Any alternative hypothesis, or is it time to dive into the wonders of
nash scripting and figure out how to make it wait for hotplug?

Content of type "application/pgp-signature" skipped