Bug 836235 - DeviceError: ('device has not been created', '/dev/md0') while trying upgrade
DeviceError: ('device has not been created', '/dev/md0') while trying upgrade
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-06-28 09:01 EDT by udo
Modified: 2013-01-10 01:50 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-07-13 18:43:43 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
errorlogs (79.88 KB, application/x-gzip)
2012-06-28 09:01 EDT, udo
no flags Details
Comment (561.33 KB, text/plain)
2012-06-28 11:09 EDT, udo
no flags Details

  None (edit)
Description udo 2012-06-28 09:01:53 EDT
Created attachment 595011 [details]

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
Comment 1 udo 2012-06-28 09:02:54 EDT
This blocks upgrade to F17
Comment 2 udo 2012-06-28 09:04:33 EDT
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
  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
  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
  File "/usr/lib64/python2.7/site-packages/pyanaconda/gui.py", line 1201, in nextClicked
DeviceError: ('device has not been created', '/dev/md0')
Comment 3 Jesse Keating 2012-06-28 11:03:03 EDT
Please don't attach archives, bugzilla can't search them.  Can you re-upload the log files individually as text files?
Comment 4 udo 2012-06-28 11:07:50 EDT
Which file do you need besides the relevant log?
Comment 5 udo 2012-06-28 11:09:21 EDT
Created attachment 915471 [details]

(This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).
Comment 6 Jesse Keating 2012-06-28 11:10:53 EDT
Just to prevent further back and forth, everything from /tmp/*log would suffice.

anaconda.log, storage.log, program.log, syslog etc..
Comment 7 Jesse Keating 2012-06-28 11:11:52 EDT
Ugh.  Normally we like those uploaded as an attachment, not a comment.  But can't be undone now.
Comment 8 Jesse Keating 2012-06-28 11:18:40 EDT
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?
Comment 9 udo 2012-06-28 11:44:27 EDT
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?
Comment 10 udo 2012-06-28 11:46:31 EDT
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.
Comment 11 udo 2012-06-28 12:12:31 EDT
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.
Comment 12 David Lehman 2012-06-28 12:35:45 EDT
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.
Comment 13 udo 2012-06-28 12:52:04 EDT
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.
Comment 14 udo 2012-06-29 08:59:17 EDT
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?
Comment 15 Jesse Keating 2012-07-13 18:43:43 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.