Description of problem: Started up anaconda on a Live Respin (KDE) to reinstall Fedora 23. A mdadm array was present (but not intended to be used for installation disk) Version-Release number of selected component: anaconda-core-23.19.10-1.fc23.x86_64 The following was filed automatically by anaconda: anaconda 23.19.10-1 exception report Traceback (most recent call first): File "/usr/lib/python3.4/site-packages/blivet/populator.py", line 246, in _addSlaveDevices raise DeviceTreeError("no slaves found for device %s" % name) File "/usr/lib/python3.4/site-packages/blivet/populator.py", line 364, in addUdevMDDevice self._addSlaveDevices(info) File "/usr/lib/python3.4/site-packages/blivet/populator.py", line 718, in addUdevDevice device = self.addUdevMDDevice(info) File "/usr/lib/python3.4/site-packages/blivet/populator.py", line 1692, in _populate self.addUdevDevice(dev) File "/usr/lib/python3.4/site-packages/blivet/populator.py", line 1623, in populate self._populate() File "/usr/lib/python3.4/site-packages/blivet/devicetree.py", line 554, in populate self._populator.populate(cleanupOnly=cleanupOnly) File "/usr/lib/python3.4/site-packages/blivet/blivet.py", line 279, in reset self.devicetree.populate(cleanupOnly=cleanupOnly) File "/usr/lib/python3.4/site-packages/blivet/osinstall.py", line 1157, in storageInitialize storage.reset() File "/usr/lib64/python3.4/threading.py", line 868, in run self._target(*self._args, **self._kwargs) File "/usr/lib64/python3.4/site-packages/pyanaconda/threads.py", line 253, in run threading.Thread.run(self, *args, **kwargs) File "/usr/lib64/python3.4/site-packages/pyanaconda/threads.py", line 171, in raise_if_error raise exc_info[0](exc_info[1]).with_traceback(exc_info[2]) File "/usr/lib64/python3.4/site-packages/pyanaconda/threads.py", line 116, in wait self.raise_if_error(name) File "/usr/lib64/python3.4/site-packages/pyanaconda/timezone.py", line 76, in time_initialize threadMgr.wait(THREAD_STORAGE) File "/usr/lib64/python3.4/threading.py", line 868, in run self._target(*self._args, **self._kwargs) File "/usr/lib64/python3.4/site-packages/pyanaconda/threads.py", line 253, in run threading.Thread.run(self, *args, **kwargs) blivet.errors.DeviceTreeError: no slaves found for device md127 Additional info: cmdline: /usr/bin/python3 /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base cmdline_file: BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=F23-x86_64-KDE-20160324 ro rd.live.image quiet rhgb executable: /sbin/anaconda hashmarkername: anaconda kernel: 4.4.6-300.fc23.x86_64 other involved packages: python3-libs-3.4.3-5.fc23.x86_64, python3-blivet-1.12.8-1.fc23.noarch product: Fedora release: Fedora release 23 (Twenty Three) type: anaconda version: 23
Created attachment 1140521 [details] File: anaconda-tb
Created attachment 1140522 [details] File: anaconda.log
Created attachment 1140523 [details] File: environ
Created attachment 1140524 [details] File: journalctl
Created attachment 1140525 [details] File: lsblk_output
Created attachment 1140526 [details] File: nmcli_dev_list
Created attachment 1140527 [details] File: os_info
Created attachment 1140528 [details] File: program.log
Created attachment 1140529 [details] File: storage.log
Created attachment 1140530 [details] File: ifcfg.log
An additional and disturbing detail for this bug is that it completely prevents the user from installing until the device is unrecognized by the kernel. User can: 1. Unplug the drives 2. The solution I used, which was to add: libata.force=5:disabled,6:disabled to the kernel arguments upon boot (forces the kernel to ignore ATA drives) adding nodmraid or rd.md=0 or raid=noautodetect have no impact, because the device node is still created and more importantly what this fails on is also present which is the device block location under sysfs (/sys) I could not install until I used the abovementioned libata trick
Exactly the same for me when installing Fedora 24 Workstation Alpha -- I resorted to removing the SATA plugs on each of the drives which allowed anaconda to continue.
If this is present on F24 alpha should it be submitted as a blocker for F24 Beta? I noticed another blivet blocker: https://bugzilla.redhat.com/show_bug.cgi?id=1306808
Proposed as a Blocker for 24-beta by Fedora user xenithorb using the blocker tracking app because: If user has volumes with mdraid superblocks present (i do not know all conditions, for me it was a raid0 set) there is no obvious way for the user to continue the install because anaconda crashes and does not allow the user to continue, additionally the error message is cryptic. Workaround is to remove the device or append "libata.force=N:disabled,[N:disabled]" to the kernel options (this preventing the creation of the sysfs directory. Raid disabling or raid autodetect disabling has zero effect I believe it violates this criterion, among others: 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
The attached logs show what looks like two anaconda runs in close succession (2 seconds between). After scanning storage in the first run we deactivate the md array. When the second run starts udev/sysfs report a /dev/md127, but that device is not usable. I already have an item on blivet's backlog to handle this failure mode since mdadm and/or the kernel does present it sometimes.
Discussed at 2016-04-04 blocker review meeting: [1]. We decided to delay the decision: this looks worrying, but we need more information: from the reporters on whether they had an actual valid RAID set or just disks with stale RAID metadata, and from blivet and/or mdadm developers on what the problem looks like from their end [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2016-04-04/f24-blocker-review.2016-04-04-16.05.html
Could you please provide more information about the state of disks before you run the anaconda? Please see comment 16
Discussed at today's blocker review meeting [1]. Voted as punt (delay decision) - we still didn't get categorical information here, but we suspect it was caused by multiple installer launches, which is an unfortunate UI issue but wouldn't be a blocker. if we don't get new information by next week this will be rejected [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-04-11/
Could someone who is experiencing this issue also try booting from one of the network-install media? We'd like to rule out the possibility that anaconda is being launched twice (possibly without the user's awareness) and therefore triggering the bug that David Lehman referenced above.
Discussed at today's blocker review meeting [1]. Voted as RejectedBlocker (Beta) - no-one has responded to the information requests on this, so for now it is rejected as a blocker on the basis it was likely caused by multiple installer launches and no data is available to indicate otherwise. the bug can be re-proposed as a blocker with the requested information if appropriate. [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-04-18
python-blivet-1.20.0-1.fc24 anaconda-24.13.4-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-45ca29d07c
anaconda-24.13.4-1.fc24, python-blivet-1.20.0-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-45ca29d07c
anaconda-24.13.4-1.fc24, python-blivet-1.20.0-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1332476 has been marked as a duplicate of this bug. ***