Hi All,
While doing what should be testing a simple iscsi related patch,
I encountered the following issue:
Take a system with a single disk, sda, which has a /boot on
sda1 and a PV on sda2. This PV is the PV for the 1 PV VG:
VolGroup, which contains LV's lv_swap, lv_root and lv_home.
"Attach" an iscsi disk to this system, which becomes sdb,
which has a /boot on sdb1 and a PV on sdb2. This PV is the PV
for the 1 PV VG: VolGroup, which contains LV's lv_swap and
lv_root.
Notice that:
1) The 2 VG's have the same name
2) Only sda has a lv_home LV.
Now in the filter UI select only disk sdb to install to, then
the following may (depending on scanning order) happen:
Assume sdb gets scanned first by devicetree.py:
- when scanning sdb2, handleUdevLVMPVFormat() will
call "lvm lvchange -ay" for all LV's in this VG
(as seen by udev, more on that later).
- at this point, sda has not been scanned yet, so
isIgnored has not been called for sda2 yet, and thus
lvm_cc_addFilterRejectRegexp("sda2") has not been called
yet.
- thus lvm lvchange sees both sda2 and sdb2, it complains
that there are 2 identically named VG's and picks the one
using the sda2 PV.
- note that the same is happening when the udev rules execute
and as lvm picks the sda based VG, udev sees 3 LV's
so lvm lvchange gets called for lv_root, lv_swap and lv_home.
However all is well here, as the sda VG actually has all 3
of these.
- sda gets scanned, and sda2 gets added to
lvm_cc_addFilterRejectRegexp()
- devicetree,populate is done and calls teardownAll()
- teardownAll() calls "lvm lvchange -an" for all 3
LV's. However at this point its --config argument tells
it to ignore sda2, so it reads the VG metadata from
sdb2, and when called to stop lv_home, it complains that
lv_home is not part of the VG, and then anaconda backtraces.
Note we really have 2 issues here:
1) udev rules don't know about our lvm_cc_addFilterRejectRegexp(),
2) We are calling "lvm lvchange ..." with a changing (growing)
device filter list, which sometimes confuses it.
I've been thinking about how to fix this, and all I can come up
with is a 2 fase scan.
Notice that at first it seems tempting to simply first
call isIgnored on all devices to scan, and then scan them all.
This won't work as new PV candidates may show up while scanning:
with BIOS RAID the sets wont get activated until the members get
scanned, and the set itself could be ignored, so it could become
part of the lvm_cc_addFilterRejectRegexp(), which won't happen
until the set itself gets scanned (which happens in the next
pass in populate).
So what I've come up with (not yet coded, I'm first soliciting
feedback) is:
1) populate as one normally would, but don't call
handleUdevLVMPVFormat() from handleUdevDeviceFormat()
2) When done populating, write out lvm_cc_addFilterRejectRegexp
to lvm.conf, retrigger udev (so that we get the correct
info in the udev database in cases where there
were PV / VG conflicts before the filtering).
3) call handleUdevLVMPVFormat() for all devices in the
devicetree with a PV format
4) Go through the populate loop once more to handle the format
on all the brought up LV's.
Yes this means that something which ends up being a PV on a PV
will not work (the second PV will be pretty much ignored),
I suggest we simply declare this as not supported.
Regards,
Hans
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
