Omits /etc/lvm/lvm.conf

Bug #113515 reported by Tore Anderson
This bug affects 2 people
Affects Status Importance Assigned to Milestone
lvm2 (Debian)
Fix Released
lvm2 (Ubuntu)

Bug Description

Binary package hint: initramfs-tools

Summary says it all, really...

The generated initramfs doesn't have /etc/lvm/lvm.conf, yet it does lots of LVM stuff. When you have in excess of a hundred SCSI block devices that represent different paths to different volumes on a storage network, and that I/O to these might initiate the volume to transfer from one controller to another (which takes a few seconds), it's quite problematic that LVM defaults to scanning all block devices to look for PVs. Also, in the situations where I actually use such multipathed devices as PVs, I will end up getting problems with duplicate PVs found, since four of the block devices are in reality the same volume.

The solution is of course to put in a filter line in lvm.conf, restricting it from scanning volumes it should not. But since this file isn't included in the initrd it doesn't work as expected until I add a custom hook that copies it in place.

PS: A similar problem is also caused by the I/O generated by the Linux kernel itself when it scans for partition tables on all registered block devices, making volumes bounce around and generally making everything slow. You wouldn't by any chance happen to know if it is possible to deactivate the automatic partition scan upon registration of block devices?


Revision history for this message
Paul McEnery (pmcenery) wrote :

I can confirm this bug.

I run a configuration where a physical volume is the low level device for DRBD. I then use LVM2 to carve up the DRBD disk and present iSCSI LUN's to other systems. In order to get DRBD to start up, there must be no other processes or volumes started on the DRBD low level device. LVM filters are successful in keeping LVM away from the DRBD low level device while the operating system is running, but not when the system boots. The initramfs activates all volume groups it can find. This is not appropriate behaviour. ONLY the volume group required to boot the system should be activated (in my view anyway).

To get around this, I have extracted the initramfs and patched the udev rules to only activate my volume group which is required to boot the system:

--- etc/udev/rules.d/85-lvm2.rules.bak 2008-05-27 11:06:27.000000000 +0100
+++ etc/udev/rules.d/85-lvm2.rules 2008-05-27 11:07:04.000000000 +0100
@@ -3,4 +3,4 @@
 # See udev(8) for syntax

 SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="lvm*|LVM*", \
- RUN+="watershed sh -c '/sbin/lvm vgscan; /sbin/lvm vgchange -a y'"
+ RUN+="watershed sh -c '/sbin/lvm vgscan; /sbin/lvm vgchange -a y rootvg'"

Not that I believe the above to be a fix, I do believe that there should be more control over the volume groups that are activated at boot. Obeying /etc/lvm/lvm.conf is one way to do it. I tried copying this file into the initramfs, but it didn't work as my filters were filtering out /dev/disk-by-uuid/*.

I see that this has also been flagged upstream:

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

A patch has been proposed in debian but not accepted and merged yet.

Thanks for your time.

Changed in initramfs-tools:
status: New → Confirmed
Changed in lvm2:
status: Unknown → New
Changed in lvm2:
status: New → Fix Released
Colin Watson (cjwatson)
affects: initramfs-tools (Ubuntu) → lvm2 (Ubuntu)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.