The following was filed automatically by anaconda:
anaconda 13.21.39 exception report
Traceback (most recent call first):
File "/usr/lib/anaconda/booty/util.py", line 5, in getDiskPart
path = storage.devicetree.getDeviceByName(dev).path[5:]
File "/usr/lib/anaconda/booty/x86.py", line 411, in writeDeviceMap
drive = getDiskPart(dev, self.storage)
File "/usr/lib/anaconda/booty/x86.py", line 229, in writeGrub
self.writeDeviceMap(instRoot, usedDevs, upgrade)
File "/usr/lib/anaconda/booty/x86.py", line 507, in write
File "/usr/lib/anaconda/bootloader.py", line 217, in writeBootloader
kernelList, otherList, defaultDev)
File "/usr/lib/anaconda/dispatch.py", line 205, in moveStep
rc = stepFunc(self.anaconda)
File "/usr/lib/anaconda/dispatch.py", line 126, in gotoNext
File "/usr/lib/anaconda/gui.py", line 1260, in nextClicked
File "/usr/lib/anaconda/iw/progress_gui.py", line 79, in renderCallback
File "/usr/lib/anaconda/gui.py", line 1281, in handleRenderCallback
AttributeError: 'NoneType' object has no attribute 'path'
Created attachment 415153 [details]
Attached traceback automatically from anaconda.
Created attachment 415155 [details]
logs from the system
This was on KVM domU.
On the first install I did "Use all space" and "Encrypt system".
On the second install I've selected Cancel when anaconda asked me for password for /dev/vda2 to work around for bug #593671. Then manually created /boot, swap and 4 software raid partitions which I selected to be encrypted. Then / on RAID1 including all members.
Partitioning went without error. This traceback happens right after package installation is completed and we're about to write grub to the MBR.
Let me see if I've read the logs and understood your description correctly:
You were doing an install with / on mdraid level 1, and the members of the raidset were all encrypted, and you did not have a separate /boot. That is not supported, as grub cannot read from encrypted partitions, so you would need a separate /boot for this which is unencrypted (/boot may be a mdraid level 1, but that mdraid set then must use plain partitions as members).
Did I understand this correctly ?
Then this bug is just a matter of tightening up our sanity checks for /boot, for which I've a patch on master already.
I do have a separate /boot. This bug also happens on a clean disk with the following configuration:
/boot, swap, two encrypted raid members, raid1 for /
This is fixed in anaconda-13.21.50-1, moving to modified.
Tested with RHEL6.0-20100617.0 and I had no traceback. Moving to VERIFIED.
Red Hat Enterprise Linux Beta 2 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.