Bug 517647

Summary: CryptoError: luks_open failed for /dev/mapper/VolGroup02-xfceRaw9
Product: [Fedora] Fedora Reporter: Clyde E. Kunkel <clydekunkel7734>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: anaconda-maint-list, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: anaconda_trace_hash:019ae0e968a1c6e6ff35084624ea1b7c693dca8bfab459ad81803d9cf8faf3f4
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-08-17 13:53:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Attached traceback automatically from anaconda.
none
tty screenshot of mdadm lock condition (partial) none

Description Clyde E. Kunkel 2009-08-15 15:38:23 UTC
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
    key_file=self._key_file)
  File "/usr/lib/anaconda/storage/devices.py", line 1555, in setup
    self.slave.format.setup()
  File "/usr/lib/anaconda/storage/__init__.py", line 1091, in mountExistingSystem
    device.setup()
  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
    self.moveStep()
  File "/usr/lib/anaconda/gui.py", line 1201, in nextClicked
    self.anaconda.dispatch.gotoNext()
CryptoError: luks_open failed for /dev/mapper/VolGroup02-xfceRaw9 (luks-883fc152-87f7-4d35-aa5c-82712d70faf6)

Comment 1 Clyde E. Kunkel 2009-08-15 15:38:34 UTC
Created attachment 357543 [details]
Attached traceback automatically from anaconda.

Comment 2 Clyde E. Kunkel 2009-08-15 18:13:28 UTC
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.

Your choice.

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.

Comment 3 Clyde E. Kunkel 2009-08-15 18:16:24 UTC
Created attachment 357545 [details]
tty screenshot of mdadm lock condition (partial)

Comment 4 Chris Lumens 2009-08-17 13:53:51 UTC
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.

Comment 5 Andy Lindeberg 2009-08-21 17:11:37 UTC
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 ***