Bug 497237 - CryptoError: luks_open failed for /dev/mapper/VolGroup02-fedora11x64
Summary: CryptoError: luks_open failed for /dev/mapper/VolGroup02-fedora11x64
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Martin Sivák
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-04-22 22:32 UTC by Clyde E. Kunkel
Modified: 2009-04-24 10:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 497239 (view as bug list)
Environment:
Last Closed: 2009-04-24 10:07:33 UTC
Type: ---
Embargoed:


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

Description Clyde E. Kunkel 2009-04-22 22:32:38 UTC
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):
anaconda-11.5.0.47

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:
traceback

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 14:09:45 UTC
Hi,

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 15:13:57 UTC
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 20:46:21 UTC
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-24 01:41:29 UTC
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 10:07:33 UTC
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.