Description of problem: Tried to do an LVM-on-soft-RAID install of Fedora 24 Beta 1.6 over an LVM-on-soft-RAID install of Fedora 24 Beta 1.4. It no longer hits the infinite recursion bug, but crashes this way instead. Version-Release number of selected component: anaconda-24.13.4-1 The following was filed automatically by anaconda: anaconda 24.13.4-1 exception report Traceback (most recent call first): File "/usr/lib64/python3.5/site-packages/gi/overrides/BlockDev.py", line 420, in wrapped raise transform[1](msg) File "/usr/lib/python3.5/site-packages/blivet/devices/md.py", line 488, in teardown blockdev.md.deactivate(self.path) File "/usr/lib/python3.5/site-packages/blivet/devices/storage.py", line 483, in _preDestroy self.teardown() File "/usr/lib/python3.5/site-packages/blivet/devices/storage.py", line 492, in destroy self._preDestroy() File "/usr/lib/python3.5/site-packages/blivet/deviceaction.py", line 363, in execute self.device.destroy() File "/usr/lib/python3.5/site-packages/blivet/actionlist.py", line 280, in process action.execute(callbacks) File "/usr/lib/python3.5/site-packages/blivet/devicetree.py", line 381, in processActions callbacks=callbacks) File "/usr/lib/python3.5/site-packages/blivet/blivet.py", line 164, in doIt self.devicetree.processActions(callbacks=callbacks) File "/usr/lib/python3.5/site-packages/blivet/osinstall.py", line 1096, in turnOnFilesystems storage.doIt(callbacks) File "/usr/lib64/python3.5/site-packages/pyanaconda/install.py", line 195, in doInstall turnOnFilesystems(storage, mountOnly=flags.flags.dirInstall, callbacks=callbacks_reg) File "/usr/lib64/python3.5/threading.py", line 862, in run self._target(*self._args, **self._kwargs) File "/usr/lib64/python3.5/site-packages/pyanaconda/threads.py", line 253, in run threading.Thread.run(self, *args, **kwargs) gi.overrides.BlockDev.MDRaidError: Process reported exit code 256: mdadm: Cannot get exclusive access to /dev/md/pv00:Perhaps a running process, mounted filesystem or active volume group? Additional info: addons: com_redhat_kdump cmdline: /usr/bin/python3 /sbin/anaconda cmdline_file: BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-S-dvd-x86_64-24 quiet dnf.rpm.log: May 04 17:44:48 INFO --- logging initialized --- executable: /sbin/anaconda hashmarkername: anaconda kernel: 4.5.2-302.fc24.x86_64 product: Fedora release: Cannot get release name. reproducible: Not sure how to reproduce the problem type: anaconda version: 24
Created attachment 1153960 [details] File: anaconda-tb
Created attachment 1153961 [details] File: anaconda.log
Created attachment 1153962 [details] File: dnf.log
Created attachment 1153963 [details] File: environ
Created attachment 1153964 [details] File: lsblk_output
Created attachment 1153965 [details] File: lvm.log
Created attachment 1153966 [details] File: nmcli_dev_list
Created attachment 1153967 [details] File: os_info
Created attachment 1153968 [details] File: storage.log
Created attachment 1153969 [details] File: syslog
Created attachment 1153970 [details] File: ifcfg.log
Created attachment 1153971 [details] File: packaging.log
Created attachment 1153972 [details] File: program.log
This was with the server netinst. I had started with two disks, wiped them completely, and done an LVM-on-RAID install of Fedora 24 Beta 1.4 on them - that is, I selected both disks, went into custom part, deleted all existing contents of both disks, hit 'create them automatically', and changed the LVM VG to RAID-1. That install went OK. Then I tried to re-install over the top in exactly the same way, with 1.4, and hit https://bugzilla.redhat.com/show_bug.cgi?id=1331630 . 1.6 is supposed to have that bug fixed, so I tried the same thing again with 1.6, and hit this crash.
Proposing as a Beta blocker because, well, if https://bugzilla.redhat.com/show_bug.cgi?id=1331630 was one, I guess this is too? i.e: Seems to be a conditional violation of "The installer must be able to detect and install to hardware or firmware RAID storage devices" in the case of installing over an existing FW RAID install and of "When using the custom partitioning flow, the installer must be able to: ... Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions, LVM and/or btrfs volumes, and/or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions ... Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions" in the case of installing over an existing SW RAID install... (I haven't confirmed this one also affects firmware RAID yet, testing that now).
I don't see any calls to collect info about pvs.
I was able to reproduce this by re-running the test. However, as with https://bugzilla.redhat.com/show_bug.cgi?id=1259953 , when I retried *again* after encountering the crash, it worked - though that seems a bit strange, because unlike that bug, the existing layout did not seem to have been deleted by the first (crashed) attempt, on the second attempt, it was still shown in the custom part dialog. But when I chose to delete the existing volumes and create a new LVM-on-RAID layout and ran the install, it worked. I can try this a few more times tomorrow morning to see if it's reproducible; pschindl, it'd be great if you could also try.
I tried to reproduce this (installing software raid by erasing disks where is software raid) and after crash the abrt reported it as bug 1333301 The traceback seems to be a duplicate but the error message is different.
Discussed at a go/no-go meeting [1]. Voted as RejectedBlocker (Beta) AcceptedFreezeException (Beta) - as per bug 1259953 this is a fairly well-identified case with an apparently reliable and simple workaround, we find that acceptable for Beta [1] https://meetbot.fedoraproject.org/fedora-meeting-1/2016-05-05/f24-beta-go_no_go-meeting.2016-05-05-17.30.html
*** Bug 1359554 has been marked as a duplicate of this bug. ***
*** Bug 1383622 has been marked as a duplicate of this bug. ***
*** Bug 1396285 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 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.