Description of problem: Fedora Beta TC6 Workstation netinst booted with vpodzimek's update (http://vpodzime.fedorapeople.org/1207317_updates.img This happens right after anaconda starts. Version-Release number of selected component: anaconda-22.20.7-1 The following was filed automatically by anaconda: anaconda 22.20.7-1 exception report Traceback (most recent call first): File "/tmp/updates/blivet/devices/md.py", line 103, in __init__ raise e File "/tmp/updates/blivet/devicetree.py", line 1638, in handleUdevMDMemberFormat exists=True) File "/tmp/updates/blivet/devicetree.py", line 1878, in handleUdevDeviceFormat self.handleUdevMDMemberFormat(info, device) File "/tmp/updates/blivet/devicetree.py", line 1260, in addUdevDevice self.handleUdevDeviceFormat(info, device) File "/tmp/updates/blivet/devicetree.py", line 2178, in _populate self.addUdevDevice(dev) File "/tmp/updates/blivet/devicetree.py", line 2112, in populate self._populate() File "/tmp/updates/blivet/blivet.py", line 277, in reset self.devicetree.populate(cleanupOnly=cleanupOnly) File "/tmp/updates/blivet/osinstall.py", line 1117, in storageInitialize storage.reset() File "/usr/lib64/python2.7/threading.py", line 766, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 244, in run threading.Thread.run(self, *args, **kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 115, in wait self.raise_if_error(name) File "/usr/lib64/python2.7/site-packages/pyanaconda/timezone.py", line 75, in time_initialize threadMgr.wait(THREAD_STORAGE) File "/usr/lib64/python2.7/threading.py", line 766, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 244, in run threading.Thread.run(self, *args, **kwargs) DeviceError: RAID level container is an invalid value. Must be one of (linear, raid4, raid0, raid1, raid6, raid10, raid5). Additional info: addons: com_redhat_kdump cmdline: /usr/bin/python2 /sbin/anaconda cmdline_file: BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-22_B_T6-x86_64 quiet inst.updates=http://vpodzime.fedorapeople.org/1207317_updates.img dnf.rpm.log: Apr 02 13:03:33 INFO --- logging initialized --- executable: /sbin/anaconda hashmarkername: anaconda kernel: 4.0.0-0.rc4.git0.1.fc22.x86_64 product: Fedora release: Cannot get release name. type: anaconda version: 22
Created attachment 1010173 [details] File: anaconda-tb
Created attachment 1010174 [details] File: anaconda.log
Created attachment 1010175 [details] File: dnf.log
Created attachment 1010176 [details] File: environ
Created attachment 1010177 [details] File: lsblk_output
Created attachment 1010178 [details] File: nmcli_dev_list
Created attachment 1010179 [details] File: os_info
Created attachment 1010180 [details] File: program.log
Created attachment 1010181 [details] File: storage.log
Created attachment 1010182 [details] File: syslog
Created attachment 1010183 [details] File: ifcfg.log
Created attachment 1010184 [details] File: packaging.log
mulhern, could you please have a look at this? It is a follow-up of bug #1207317 and I have no idea how to move further.
This is another bug in the F22 'firmware RAID doesn't work' series, so nominating as a Beta blocker: https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria#Hardware_and_firmware_RAID , "The installer must be able to detect and install to hardware or firmware RAID storage devices."
We should build an MDContainerDevice if the level is "container" and the member format's biosraid attr is True.
Test image at: http://mulhern.fedorapeople.org/tests/1208536.img
I combined vpodzime's http://vpodzime.fedorapeople.org/1207317_updates.img with http://mulhern.fedorapeople.org/tests/1208536.img in the following way: mv 1207317_updates.img 1207317_updates.img.gz mv 1208536.img 1208536.img.gz gunzip 1207317_updates.img.gz gunzip 1208536.img.gz mkdir new cd new cpio -idv < ../1208536.img cpio -idv < ../1207317_updates.img find . | cpio -c -o | pigz -9cv > updates-1207317-1208536.img the resulting image is https://www.happyassassin.net/updates/updates-1207317-1208536.img if I boot with that, I get a new failure: ValueError("device is already in tree"). I'll attach the anaconda-tb from that test.
Created attachment 1010360 [details] anaconda-tb from the new failure
Anne updated her updates.img, latest version of the combined image is https://www.happyassassin.net/updates/raid.img (cos I didn't want to type all those numbers). It now doesn't crash, but the RAID set does not show up as an available installation target device on the INSTALLATION DESTINATION screen. Will attach logs from this test.
Created attachment 1010374 [details] program.log with most recent updates image (no crash, set not visible on INSTALL DESTINATION screen)
Created attachment 1010375 [details] storage.log with most recent updates image (no crash, set not visible on INSTALL DESTINATION screen)
The previous problem was that the array was being looked up with the UUID being supplied by udev...but being constructed with the UUID being supplied by mdadm --examine. When udev doesn't supply any UUID for the array and it happens twice then you get the array constructed and added twice. Making sure to search for the array using the mdadm UUID seems to fix that. But that opens up another problem which starts to show up just after the array is created. 21:37:56,228 ERR blivet: failed to update sysfs path for Volume0: [Errno 2] No such file or directory: '/dev/md/Volume0' Then later, when constructing the MDBiosRaidArrayDevice (which is what anaconda would like to present) we fail because we can't find the container device that we added previously. 21:37:57,611 ERR blivet: No device at '/class/block/md127' 21:37:57,611 ERR blivet: failed to find md container imsm at /class/block/md127 So, the basic hypothesis is that udev is not supplying enough information for the container device to be located when the actual array device is being processed.
Created attachment 1010377 [details] patch to fix stupid sysfs path problem This should get you a bit further on. I missed this one when porting to python-pyudev, whose sysfs paths are absolute instead of omitting the sysfs mountpoint.
New updates img available at: http://mulhern.fedorapeople.org/tests/1208536.img.
This bug has enlarged in scope from original, so changing title.
Discussed at 2015-04-06 blocker review meeting: https://meetbot.fedoraproject.org/fedora-blocker-review/2015-04-06/f22-blocker-review.2015-04-06-16.00.log.txt . Accepted as a blocker as a clear violation of the criterion cited in #c14.
With the latest updates image from #c23, combined with vpod's image for the libblockdev fixes, I have a fully successful install and boot to a RAID-0 set - thanks. We need libblockdev and anaconda/blivet builds with the fixes, now. thanks again!
(In reply to awilliam from comment #27) > With the latest updates image from #c23, combined with vpod's image for the > libblockdev fixes, I have a fully successful install and boot to a RAID-0 > set - thanks. HOOOOOOORAAAAAAYYYYYY!!!
libblockdev-0.9-1.fc22, python-blivet-1.0.7-1.fc22, anaconda-22.20.9-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libblockdev-0.9-1.fc22,python-blivet-1.0.7-1.fc22,anaconda-22.20.9-1.fc22
Fix verified with a test image built with the bits from #c29.
Update has gone stable, closing (will verify FW RAID with RC2 shortly).