Description of problem: I have an intel imsm raid-1 /dev/md126 assembled with two disks /dev/sda and /dev/sdb. I have some LVM volumes on top of /dev/md126p2. I have a working Fedora 21 installed in some logical volumes. I can not make a fresh Fedora 22 into existing lvm partitions. When the live Fedora 22 installer exposes devices for peaking as a destination, I select /dev/md126. I can see existing Fedora 21 system in the custom disk layout screen, but I can not see any logical volumes on top of /dev/md126p2 to choose. How reproducible: Always Steps to Reproduce: 1. Make a bios imsm raid-1 from two disks 2. Install any previous version of Fedora into the raid volume with LVM layout 3. Create some free logical volumes for future installing of Fedora 22 4. Boot from Fedora-22 live media 5. Install into hard drive 6. Select the raid-1 volume as a destination and check a box "custom disk layout" Actual results: The custom layout screen shows a whole raid-1 partitions but does not show logical volumes on top of it. Expected results: The custom layout screen should expose existing lvm logical volumes instead of the whole raid-1 partition. Additional info: After making some research I found that the reason is that LVM reports that existing volumes belong to /dev/sdb2 instead of /dev/md126p2 so the layout screen does not show them, because /dev/sdb is not selected as a destination. Before starting anaconda I did not have /dev/sdb2 at all. [root@localhost ~]# ls -ld /dev/md* /dev/sd* drwxr-xr-x. 2 root root 120 May 29 03:43 /dev/md brw-rw----. 1 root disk 9, 126 May 29 03:43 /dev/md126 brw-rw----. 1 root disk 259, 0 May 29 03:43 /dev/md126p1 brw-rw----. 1 root disk 259, 1 May 29 03:43 /dev/md126p2 brw-rw----. 1 root disk 9, 127 May 29 03:43 /dev/md127 brw-rw----. 1 root disk 8, 0 May 29 03:43 /dev/sda brw-rw----. 1 root disk 8, 16 May 29 03:43 /dev/sdb brw-rw----. 1 root disk 8, 32 May 29 03:43 /dev/sdc brw-rw----. 1 root disk 8, 33 May 29 03:43 /dev/sdc1 brw-rw----. 1 root disk 8, 34 May 29 03:43 /dev/sdc2 brw-rw----. 1 root disk 8, 48 May 29 03:43 /dev/sdd brw-rw----. 1 root disk 8, 49 May 29 03:43 /dev/sdd1 brw-rw----. 1 root disk 8, 50 May 29 03:43 /dev/sdd2 brw-rw----. 1 root disk 8, 64 May 29 03:43 /dev/sde But after anaconda starts, the extra partitions /dev/sda1, /dev/sda2, /dev/sdb1, /dev/sdb2 appeared. [root@localhost ~]# ls -ld /dev/md* /dev/sd* drwxr-xr-x. 2 root root 120 May 29 03:47 /dev/md brw-rw----. 1 root disk 9, 126 May 29 03:47 /dev/md126 brw-rw----. 1 root disk 259, 2 May 29 03:47 /dev/md126p1 brw-rw----. 1 root disk 259, 3 May 29 03:47 /dev/md126p2 brw-rw----. 1 root disk 9, 127 May 29 03:46 /dev/md127 brw-rw----. 1 root disk 8, 0 May 29 03:47 /dev/sda brw-rw----. 1 root disk 8, 1 May 29 03:47 /dev/sda1 brw-rw----. 1 root disk 8, 2 May 29 03:47 /dev/sda2 brw-rw----. 1 root disk 8, 16 May 29 03:47 /dev/sdb brw-rw----. 1 root disk 8, 17 May 29 03:47 /dev/sdb1 brw-rw----. 1 root disk 8, 18 May 29 03:47 /dev/sdb2 brw-rw----. 1 root disk 8, 32 May 29 03:46 /dev/sdc brw-rw----. 1 root disk 8, 33 May 29 03:46 /dev/sdc1 brw-rw----. 1 root disk 8, 34 May 29 03:46 /dev/sdc2 brw-rw----. 1 root disk 8, 48 May 29 03:47 /dev/sdd brw-rw----. 1 root disk 8, 49 May 29 03:47 /dev/sdd1 brw-rw----. 1 root disk 8, 50 May 29 03:47 /dev/sdd2 brw-rw----. 1 root disk 8, 64 May 29 03:47 /dev/sde Seems this behavior is wrong: the partitions /dev/sda1, /dev/sda2, /dev/sdb1, /dev/sdb2 must not exist because their disks are parts of /dev/md126 raid. Coming of the new partitions with udev forces lvm to switch from /dev/md126 to /dev/sdb2, because lvm always use the last come partition among the similar. What does anaconda do for refreshing devices that changes the /dev/* contents?
Created attachment 1032037 [details] program.log from anaconda
Created attachment 1032038 [details] storage.log from anaconda
Created attachment 1032039 [details] journalctl output
Seems t is an issue of blivet: Blivet.reset() change the udev device tree so /dev/sdb2 appear. Usually it is deleted by mdadm when it assembles arrays. But seems Blivet.reset() forces udev to scan /sdb after mdadm so the extra partitions left and they are the reasons of wrong lvm-over-md behavior
When I run python from blivet import Blivet storage=Blivet() storage.reset() I receive the same result: /dev/sda2 and /dev/sdb2 appear
python-blivet uses python-parted for manipulating with partitions. Seems python-parted is not mdadm-safe: the following code from parted import Device partedDevice=Device("/dev/sda") forces appearance of /dev/sda1 and /dev/sda2 that is not good for md raid member sisks. So blived should not call parted.Device() for raid members.
Created attachment 1032535 [details] A patch that prevents destroying raid members in blivet This patch solves the problem for me.After updating python-blivet I was able to install Fedora 22 into existing lvm partitions on top of bios raid.
*** Bug 1178181 has been marked as a duplicate of this bug. ***
In Fedora 23 this will hopefully become a non-issue as we do not instantiate parted.Device for every block device -- only those that contain valid partition tables and are not members of a fwraid array, multipath, &c.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.