The following was filed automatically by anaconda:
anaconda 12.15 exception report
Traceback (most recent call first):
File "/usr/lib/anaconda/storage/devicelibs/crypto.py", line 94, in luks_open
raise CryptoError("luks_open failed for %s (%s)" % (device, name))
File "/usr/lib/anaconda/storage/formats/luks.py", line 137, in setup
File "/usr/lib/anaconda/storage/devices.py", line 1555, in setup
File "/usr/lib/anaconda/storage/__init__.py", line 1091, in mountExistingSystem
File "/usr/lib/anaconda/upgrade.py", line 180, in upgradeMountFilesystems
allowDirty = 0)
File "/usr/lib/anaconda/dispatch.py", line 204, in moveStep
rc = stepFunc(self.anaconda)
File "/usr/lib/anaconda/dispatch.py", line 127, in gotoNext
File "/usr/lib/anaconda/gui.py", line 1201, in nextClicked
CryptoError: luks_open failed for /dev/mapper/VolGroup02-xfceRaw9 (luks-883fc152-87f7-4d35-aa5c-82712d70faf6)
Created attachment 357543 [details]
Attached traceback automatically from anaconda.
Occurred after selecting upgrade an existing installation and then selecting as the installation to upgrade a rawhide installation created with anaconda 12.14.
The luks LV had received a proper pass phrase. It was not in the fstab of the installation to be upgraded.
COULD NOT REPRODUCE. Instread ran into problem with existing software raid devices with some kind of lock condition. After entering the pass phrase, anaconda just sat there and never moved. I'll attach a screen shot of what I could get. The lock condition prevented the mounting of a device in tty2 and so I could not save syslog.
I rebooted into a fedora 11 installation and checked the raid devices with mdadm --detail. All ok. The next try with anaconda 12.15 was successful and the anaconda 12.14 installation was easily upgraded.
Before the first attempt I had been working to get the same raid devices working in the rawhide installation I was going to update.
This bz can be closed as insufficient data or can't reproduce or deferred.
However, something is going on with mdadm created software raid devices between Fedora 11 and current rawhide. For that reason, deferred may be appropriate and I'll continue testing to see if I can develop more information.
Created attachment 357545 [details]
tty screenshot of mdadm lock condition (partial)
Closing on the basis of comment #2. Feel free to reopen if you are able to reproduce. These bugs can be pretty tough to consistently reproduce.
I haven't been able to reproduce either, but I have an open bug on what looks like the same issue - duping.
*** This bug has been marked as a duplicate of bug 513405 ***