Bug 497237 - CryptoError: luks_open failed for /dev/mapper/VolGroup02-fedora11x64
CryptoError: luks_open failed for /dev/mapper/VolGroup02-fedora11x64
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Martin Sivák
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-04-22 18:32 EDT by Clyde E. Kunkel
Modified: 2009-04-24 06:07 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 497239 (view as bug list)
Last Closed: 2009-04-24 06:07:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
CryptoError: luks_open failed for /dev/mapper/VolGroup02-fedora11x64 (2.34 MB, text/plain)
2009-04-22 18:32 EDT, Clyde E. Kunkel
no flags Details

  None (edit)
Description Clyde E. Kunkel 2009-04-22 18:32:38 EDT
Created attachment 340844 [details]
CryptoError: luks_open failed for /dev/mapper/VolGroup02-fedora11x64

Description of problem:
traceback after clicking write changes to disk

Version-Release number of selected component (if applicable):

How reproducible:
2nd attempt failed with different error on same drive--probably because it was left in undefined state

Steps to Reproduce:
1. boot.iso, askmethod
2. install.img from download.fedora.redhat.com
3. custom paritioning
4. select VolGroup02-fedora11x64 as root, format ext4 nd check crypto box
5. complete custom partitioning
Actual results:

Expected results:
normal installation

Additional info:
This is a regression, since selecting the same LV, formating it ext4 and encrypting it worked in earlier rawhide anaconda versions.
Comment 1 Martin Sivák 2009-04-23 10:09:45 EDT

I took one of our test boxes woth encrypted FS, booted the instalation, used the replace method and checked review partitioning, selected lv_root, Edit, selected lv_root, Edit, Encrypt.. then confirmed all questions and the system installed correctly.

Can you give us more information about the "undefined state"? Or some detailed reproduction steps?
Comment 2 Clyde E. Kunkel 2009-04-23 11:13:57 EDT
A working non-encrypted ext4 root file system existed on LV fedora11x64.  On the first install attempt, I selected the LV for editing, checked format (ext4 was default) and clicked the encrypt box.  The failure occurred when formating was attempted after I specified the pass phrase.  On the next attempt to install, during the storage detection phase, the LV was seen as encrypted and a pass phrase was requested but refused (for testing purposes I use a standard pass phrase) so I clicked cancel, acknowledged with continue and went on to custom partitioning.  I selected the same LV and tried to edit it, but got a traceback when I clicked ok (BZ 497239).  Since the passphrase was rejected and I couldn't edit the LV I called it in an undefined state.  I subsequently booted into a working rawhide installation and deleted the LV, then recreated it without a file system and retried the installation and was able to edit the LV, format it ext4, encrypt it and use it.  Then with a working installation, created another LV, formated it ext4 and was going to try to repeat the original test, but couldn't keep my eyes open any more.  Will try shortly.  Will also try creating a LV withing anaconda.  I use download.fedora.redhat.com as the source and it is different today--don't think that will affect anaconda tho.
Comment 3 Clyde E. Kunkel 2009-04-23 16:46:21 EDT
I cannot reproduce this error so far.  Tried with LV created outside anaconda with ext4 FS and with anaconda creating the LV.  However, I have not completely recreated the initial conditions since the original LV that had the error had a fully loaded rawhide system installed.  What that has to do with anything, I don't know, but from my many years of testing I take nothing for granted.  I am going to try to recreate the conditions that led to this error now, but it will take some time.

(small rant:  waiting for an hour or more for dependencies to be checked is really getting old.)
Comment 4 Clyde E. Kunkel 2009-04-23 21:41:29 EDT
Just spent the last 6 hours trying to recreate the same conditions that existed when CryptoError: luks_open failed for /dev/mapper/VolGroup02-fedora11x64
happened and can't.  At a minimum this is probably an edge case and it could even have been a hardware hiccough.

Recommend closing as "Can't Duplicate."
Comment 5 Martin Sivák 2009-04-24 06:07:33 EDT
I'm closing this bug per comment #4. It crashed, but we were unable to reproduce the behaviour, so insufficient data. If you find a reproducer, please reopen this bug. Thanks for your effort.

Note You need to log in before you can comment on or make changes to this bug.