Hi,
The master branch has this piece of code, causing dmraid arrays to potentially
be brought down and then up again when executing actions:
def processActions(self, dryRun=None):
<snip>
for action in self._actions:
log.info("executing action: %s" % action)
if not dryRun:
try:
action.execute(intf=self.intf)
except DiskLabelCommitError:
# it's likely that a previous format destroy action
# triggered setup of an lvm or md device.
self.teardownAll()
action.execute(intf=self.intf)
udev_settle(timeout=10)
This is a problem as pyblock does the following when bringing up a set:
1) Add a device map for the set, remember the set map
2) Read partition table from the map for the set
3) Create device maps for the partitions, remember them
And then when bringing down a set:
1) Remove device maps for the partitions as remembered
2) Remove device map for the set
Now when the set gets brought down after some actions have
been executed, 1) from the pyblock teardown may fail,
as the partition table may have been modified and
parted's commit_to_os will update the partition device
maps when this happens. This means some of the partition
maps pyblock tries to remove may no longer be there, causing
a backtrace. Or there might be more maps then it has remembered,
and then 2) will fail as the set map is still busy
There are 2 solutions to this:
1) Stop the ping pong up down of BIOS RAID sets, there is no need
for this, we dont go unload / reload sd_mod either (I know it aint
modular anymore). BIOS RAID sets are really just plain disks,
and we already acknowledge this by hiding the real disks and only
showing / using the set.
Please lets just stop this ping pong. While testing dmraid with F-12
yesterday for the first time in a while I found and fixed 3 separate
bugs all triggered by this ping ponging. 2 of which where dmraid
specific and would have not been an issue if not for this ping ponging.
2) Let pyblock re-read the partition table on teardown, and let it
create and remove mappings based on the current state of the partition
table. This could be rather tricky though.
In case it is not clear already I greatly prefer solution 1.
Regards,
Hans
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
