Bug 506189 - mkinitrd not processing all PVs in required VG
mkinitrd not processing all PVs in required VG
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
11
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: LVM and device-mapper development team
Fedora Extras Quality Assurance
: Regression
: 511338 512555 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-15 18:53 EDT by Ian Pilcher
Modified: 2009-08-20 17:04 EDT (History)
8 users (show)

See Also:
Fixed In Version: 6.0.87-3.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 512855 (view as bug list)
Environment:
Last Closed: 2009-06-30 15:01:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed patch to mkinitrd (634 bytes, patch)
2009-06-29 12:58 EDT, Ian Pilcher
no flags Details | Diff

  None (edit)
Description Ian Pilcher 2009-06-15 18:53:10 EDT
Description of problem:
mkinitrd not processing all PVs in root filesystem LV.

Version-Release number of selected component (if applicable):
mkinitrd-6.0.86-2.fc11.x86_64

How reproducible:
100%

Steps to Reproduce:
1.  Create 2 md RAID devices
2.  Create a PV on each md device
3.  Create a VG consisting of the 2 md devices
4.  Create a LV on the VG
5.  Copy a Fedora 11 root filesystem onto the new LV
6.  Fixup /etc/fstab, etc., on the the LV
7.  Boot Fedora 11 LiveCD and mount the new LV at /mnt/sysimage
8.  chroot /mnt/sysimage
9.  Mount /proc, /sys, /boot, etc. to create a "complete" chroot environment
10.  Run mkinitrd to create an initrd for the new Fedora 11 installation.
  
Actual results:
initrd created by mkinitrd will not work, because the generated init
script will only include an "mdadm -A ..." command for one of the md
devices.  Digging into mkinitrd, it appears that the logic which
discovered and processed all of the PVs in a VG (handlelvordev in
Fedora 10) is gone, and it doesn't look like there's anything there to
replace it.  In addition to the multiple md devices case, this could
bite someone that needed different SCSI drivers for different PVs.

Expected results:
mkinitrd should process all of the PVs that make any required VG, like
Fedora 10.

Additional info:
I had to use the above procedure, because anaconda is bombing out on my
storage setup.
Comment 1 Hans de Goede 2009-06-16 04:18:10 EDT
Hmm,

Yes we got rid of the horrible handlelvordev hack, instead we traverse the
slaves as listed in sysfs, so we should be able to find both md raid sets
just fine, can you please do the following:

1:
ls /sys/block/dm-0/slaves
And paste the output here, note change the 0 if needed to match the minor
numer of an LV on the troublesome VG

2:
mkinitrd -v -f test.img $(uname -r )&> log
And attach the resulting log file

3:
bash -x /sbin/mkinitrd -f test.img $(uname -r ) &> log
And attach the resulting log file

Thanks!
Comment 2 Ian Pilcher 2009-06-16 10:37:13 EDT
(In reply to comment #1)
> Yes we got rid of the horrible handlelvordev hack, instead we traverse the
> slaves as listed in sysfs, so we should be able to find both md raid sets
> just fine, can you please do the following:

This assumes that sysfs will actually list all of the physical volumes that
make up a logical volume's volume group.  This is not the case.

For a linear LV, sysfs will *only* list PVs that actually hold data from
that LV.  I verified this by booting a LiveCD in a VM with two drives and
doing the following:

  * create two partitions on each drive -- sda1, sda2, sdb1, and sdb2
  * create two RAID-1 devices -- md0 (sda1 and sdb1) and md1 (sda2 and sdb2)
  * pvcreate /dev/md0 /dev/md1
  * vgcreate test_vg /dev/md0 /dev/md1
  * vgdisplay -- note the number of extents in the VG
  * create a LV that occupies the entire VG
  * note that sysfs lists both PVs as slaves of the LV
  * lvremove the LV
  * create a LV that is smaller that the smallest md device
  * note that sysfs only lists one PV as a slave of the LV

mkinitrd cannot rely on sysfs to do this.
Comment 3 Hans de Goede 2009-06-17 05:22:38 EDT
I've talked to Peter Jones about this and we believe this to be an lvm bug,
sysfs should give us a way to find all disks on which a device depends, that
is what the slaves dir is for!

Re-assigning to lvm-team.
Comment 4 Milan Broz 2009-06-17 05:40:52 EDT
Sorry?

If LV (say it is in kerne name dm-0) uses two PVs, there will be properly set up two slaves on undelying devices is sysfs.

If LV is only on one device, there will be only one device as slave.

Kernel device mapper have no idea what VG is - this is higher level abstraction.

You should use lvm tools to properly check which devices must be activated to have all PVs prepared for you volume group.

(What wrong with "vgs --noheadings -o pv_name <VGNAME>" to discover which devices are PVs in VG and need to be activated in initrd for example?)
Comment 5 Hans de Goede 2009-06-17 06:29:44 EDT
(In reply to comment #4)
> Sorry?
> 
> If LV (say it is in kerne name dm-0) uses two PVs, there will be properly set
> up two slaves on undelying devices is sysfs.
> 
> If LV is only on one device, there will be only one device as slave.
> 
> Kernel device mapper have no idea what VG is - this is higher level
> abstraction.
> 
> You should use lvm tools to properly check which devices must be activated to
> have all PVs prepared for you volume group.
> 
> (What wrong with "vgs --noheadings -o pv_name <VGNAME>" to discover which
> devices are PVs in VG and need to be activated in initrd for example?)  

Whats wrong with it is that it is not generic, using the sysfs slaves to find out which drivers we need to load for the underlying devices works fine for dmraid / mdraid / whatever, except for lvm.

I agree this is not a kernel bug, its an lvm userspace tools bug, they
should set up things so that first there is one device map for the entire volume group and then the lv's are devicemaps of that devicemap, just like how its done with dmraid sets and partitions on dmraid sets, this way the sysfs tree will properly represent the dependency tree as it actually is.

The fact that the whole VG concept only exists in lvm metadata and is in no
way visible in the kernel representation is a bug.
Comment 6 Alasdair Kergon 2009-06-17 07:33:02 EDT
There's a fundamental misunderstanding of device-mapper here.

Volume groups are now entirely a userspace concept - part of LVM.  Device-mapper is much more generic than LVM and works at a lower level.

The dependencies you are seeking are only dependencies within userspace and there is no prospect whatsoever of putting them into the kernel.
Comment 8 Hans de Goede 2009-06-20 17:25:40 EDT
Ian,

I would welcome a patch to mkinitrd to fix this, the best way to fix this is to
modify the handledm() function, and then specifically the "if [ -n "$vg" ]; then"
block, to ask lvm to list all the PV's and then call
findstoragedriver /dev/devicenode

for each PV.
Comment 9 Ian Pilcher 2009-06-21 19:05:46 EDT
(In reply to comment #8)
> I would welcome a patch to mkinitrd to fix this, the best way to fix this is to
> modify the handledm() function, and then specifically the "if [ -n "$vg" ];
> then"
> block, to ask lvm to list all the PV's and then call
> findstoragedriver /dev/devicenode
> 
> for each PV.  

Excellent!  I will try to get this done ASAP.
Comment 10 Ian Pilcher 2009-06-29 12:58:01 EDT
Created attachment 349820 [details]
Proposed patch to mkinitrd
Comment 11 Hans de Goede 2009-06-30 15:01:11 EDT
Thanks for the patch, this is fixed in mkinitrd-6.0.90 .
Comment 12 Ian Pilcher 2009-07-13 01:44:03 EDT
How about an F11 update that includes this fix?  mkinitrd-6.0.87-1.fc11.x86_64
just came out and overwrote my patched version.  Could have been nasty if I
hadn't caught it.
Comment 13 Hans de Goede 2009-07-13 03:12:19 EDT
(In reply to comment #12)
> How about an F11 update that includes this fix?  mkinitrd-6.0.87-1.fc11.x86_64
> just came out and overwrote my patched version.  Could have been nasty if I
> hadn't caught it.  

6.0.87 hit updates-testing long before your patch became available, if there is going to be another F-11 update I'll add your patch to it.
Comment 14 Hans de Goede 2009-07-15 04:13:46 EDT
*** Bug 511338 has been marked as a duplicate of this bug. ***
Comment 15 Hans de Goede 2009-07-27 04:38:08 EDT
*** Bug 512555 has been marked as a duplicate of this bug. ***
Comment 16 Fedora Update System 2009-07-27 11:34:34 EDT
mkinitrd-6.0.87-3.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/mkinitrd-6.0.87-3.fc11
Comment 17 Ian Pilcher 2009-07-27 12:07:23 EDT
mkinitrd-6.0.87-3.fc11 works on my system.
Comment 18 Fedora Update System 2009-08-20 17:04:35 EDT
mkinitrd-6.0.87-3.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.