This bug mainly is the result of a long long long debugging session to hunt down bug 551790. The problem is triggered by partitions on dmraid sets being activated with kpartx now a days as that can handle gpt partition tables, which dmraid itself cannot. When anaconda runs from the livecd environment the dmraid set and its partitions mappings are already setup by dmraid + kpartx. In the normal install environment this is not the case, so anaconda tries to activate the sets itself using python-pyblock (which uses libdmraid + libparted + devicemapper for this). This is not a problem as python-pyblock contains code to detect if it is trying to add an already existing mapping (like in the livecd case), and in that case does nothing. Things get troublesome however when there are logical partitions on the disk. The problem is that kpartx creates linear mappings of the extended partition for these instead of creating linear mappings directly of the disk. python-pyblock however does create linear mappings directly of the disk for the logical partitions. So the is this mapping already present check fails, after which the map creation fails and anaconda aborts. My first reaction when I finally figured this out was to modify python-pyblock to match kpartx behavior. But then I realized other tools might be bitten by the too, and indeed they are: parted: Cannot change the partition mappings of a dmraid device with logical partitions activated with kpartx, as it expects logical partitions to be linear mappings of the disk (not the extended partitions), and thus fails to remove the old mappings when trying to re-create the mappings to match changes made to the disk. So even if the entire raidset is not mounted / used in anyway a reboot is required to get the kernel to see the new partition table. python-pyblock: See above dmraid: Cannot stop a raid set (dmraid -an) with logical partitions, even if it is not gpt, as it too expects linear mappings directly of the disk. So I've come to the conclusion that it is not python-pyblock which needs to change, but kpartx as that is the only one handling mapping of logical partitions in this way.
Making this block F13Blocker, as this makes it impossible to install Fedora on dmraid systems with logical partitions (for which we have received several bugs for F-12).
Btw see also 475283 - it was even broken some time ago using wrong offset...
Fixed. kpartx now deals with logical partitions just the same as it did in RHEL5/F-9. They are the build on top of the whole device.
device-mapper-multipath-0.4.9-6.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/device-mapper-multipath-0.4.9-6.fc12
device-mapper-multipath-0.4.9-6.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update device-mapper-multipath'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1129
device-mapper-multipath-0.4.9-6.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.