Red Hat Bugzilla – Bug 836235
DeviceError: ('device has not been created', '/dev/md0') while trying upgrade
Last modified: 2013-01-10 01:50:42 EST
Created attachment 595011 [details] errorlogs Description of problem: DeviceError: ('device has not been created', '/dev/md0') while trying upgrade to Fedora 17 Version-Release number of selected component (if applicable): Fedora 17 DVD How reproducible: Have F16 install with raid5 and lvm2, insert DVD, boot, choose upgrade Actual results: DeviceError: ('device has not been created', '/dev/md0') Expected results: Upgrade to F17 Additional info: See attachment
This blocks upgrade to F17
Relevant log: The following was filed automatically by anaconda: anaconda 17.29 exception report Traceback (most recent call first): File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 702, in _preSetup raise DeviceError("device has not been created", self.name) File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 718, in setup if not self._preSetup(orig=orig): File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 2012, in _parseOneLine device.setup() File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 2112, in parseFSTab device = self._parseOneLine((devspec, mountpoint, fstype, options, dump, passno)) File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 1676, in mountExistingSystem fsset.parseFSTab(anaconda=anaconda) File "/usr/lib64/python2.7/site-packages/pyanaconda/upgrade.py", line 178, in upgradeMountFilesystems mountExistingSystem(anaconda, anaconda.upgradeRoot[0], allowDirty = 0) File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 383, in dispatch self.dir = self.steps[self.step].target(self.anaconda) File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 247, in go_forward self.dispatch() File "/usr/lib64/python2.7/site-packages/pyanaconda/gui.py", line 1201, in nextClicked self.anaconda.dispatch.go_forward() DeviceError: ('device has not been created', '/dev/md0')
Please don't attach archives, bugzilla can't search them. Can you re-upload the log files individually as text files?
Which file do you need besides the relevant log?
Created attachment 915471 [details] Comment (This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).
Just to prevent further back and forth, everything from /tmp/*log would suffice. anaconda.log, storage.log, program.log, syslog etc..
Ugh. Normally we like those uploaded as an attachment, not a comment. But can't be undone now.
To me it looks like anaconda was not able to resolve the makings of md0. Is the machine still bootable into F16? If so, can you provide details about your md0 device from f16?
md0 worked very well until recently. Didn't test after trying the F17 DVD. it contains the /boot directory. it is a raid-1 consisting of sda1, sdb1 and sdc1. Is that enough info?
I did not gather anything form /tmp. just the crash report from anaconda and waht is in there. I posted the biggest file's contents and teh description file. Is there anythign else you need? The box has three 500 GB harddisks. partition 1 is raid-1 for /boot partition 2 is raid-5 for the lvm2 partition 3 is encrypted swap Recognising storage was not an issue for the F16 upgrade.
Actually, anaconda appears to be really confused. When I wait for the first graphical screen to occur, after seeing a part of the kernel startup messages with blinking (!) background characters, I cna then switch to a text console and see /proc/mdstat. I see and md126 and md127 active there. md127 using the disks for md0 and md126 using the disks for md1. So yes, md0 wass not created.
The problem is that you used /dev/md0 in your /etc/fstab, but that name is not persistent. If you replace /dev/md0 with the UUID of the filesystem (UUID=4282abf8-1b0a-4cdc-9d70-5ee438e18cbd) things should work just fine for that device. Anaconda does not support crypttab's swap option, so there's a good chance your encrypted swaps will cause other problems. I would recommend that you comment the swap entries out before upgrade and uncomment them afterward.
md0: I think you nailed it there, after editing the fstab and restarting an upgrade attempt the installer now progresses farther. Weird thing is that md0 was no problem in earlier upgrade cases. The swap was taken care of. Thanks.
after the update /usr was mounted ro. no Fedora 17 kernel installed. /etc/crypttab was 0 bytes long Could these be caused by the md0 issue or all reason for a new bugreport?
Yes, those are new issues and should get their own bugs. This bug was about use of /dev/md0 in fstab and since that has been worked around I'll close this bug out.