Bug 836235

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.