Bug 836235 - DeviceError: ('device has not been created', '/dev/md0') while trying upgrade
Summary: DeviceError: ('device has not been created', '/dev/md0') while trying upgrade
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 17
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-28 13:01 UTC by udo
Modified: 2013-01-10 06:50 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-07-13 22:43:43 UTC
Type: Bug
Embargoed:


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

Description udo 2012-06-28 13:01:53 UTC
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

Comment 1 udo 2012-06-28 13:02:54 UTC
This blocks upgrade to F17

Comment 2 udo 2012-06-28 13:04:33 UTC
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')

Comment 3 Jesse Keating 2012-06-28 15:03:03 UTC
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 15:07:50 UTC
Which file do you need besides the relevant log?

Comment 5 udo 2012-06-28 15:09:21 UTC
Created attachment 915471 [details]
Comment

(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 15:10:53 UTC
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 15:11:52 UTC
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 15:18:40 UTC
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 15:44:27 UTC
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 15:46:31 UTC
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 16:12:31 UTC
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 16:35:45 UTC
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 16:52:04 UTC
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.

Comment 14 udo 2012-06-29 12:59:17 UTC
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 22:43:43 UTC
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.