Bug 495176 - CryptoError: luks_close failed
CryptoError: luks_close failed
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Martin Sivák
Fedora Extras Quality Assurance
Depends On:
Blocks: AnacondaStorage
  Show dependency treegraph
Reported: 2009-04-10 01:21 EDT by Mike Wolf
Modified: 2009-04-21 05:55 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-04-21 05:55:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Attached traceback automatically from anaconda. (209.54 KB, text/plain)
2009-04-10 01:21 EDT, Mike Wolf
no flags Details
Attached traceback automatically from anaconda. (100.45 KB, text/plain)
2009-04-15 00:46 EDT, Mike Wolf
no flags Details
Attached traceback automatically from anaconda. (90.92 KB, text/plain)
2009-04-15 18:52 EDT, Mike Wolf
no flags Details

  None (edit)
Description Mike Wolf 2009-04-10 01:21:53 EDT
The following was filed automatically by anaconda:
anaconda exception report
Traceback (most recent call first):
  File "/usr/lib/anaconda/storage/devicelibs/crypto.py", line 100, in luks_close
    raise CryptoError("luks_close failed for %s" % name)
  File "/usr/lib/anaconda/storage/formats/luks.py", line 131, in teardown
  File "/usr/lib/anaconda/storage/deviceaction.py", line 261, in __init__
  File "/usr/lib/anaconda/iw/partition_dialog_gui.py", line 227, in run
    actions.append(ActionCreateFormat(request, format))
  File "/usr/lib/anaconda/iw/partition_gui.py", line 1121, in editPartition
    actions = parteditor.run()
  File "/usr/lib/anaconda/iw/partition_gui.py", line 1082, in editCB
CryptoError: luks_close failed for luks-0ed1caa2-5ca7-45d6-a971-e2441dcd4f2c
Comment 1 Mike Wolf 2009-04-10 01:21:59 EDT
Created attachment 339059 [details]
Attached traceback automatically from anaconda.
Comment 2 Mike Wolf 2009-04-10 01:52:43 EDT
Installing on Acer Aspire 3680-2686.  Celeron M 440, 1.5G RAM, 80G SATA, DVD.

This was my second install of F11 beta on this machine.  First install was successful, but reinstall resulted in the above traceback.  I think the changes I made in the first install are related to the failure in the second, so first here are the changes I made to the partitioning on the first install:

1.  I removed 30720MB from root, which was located in the default LVM on sda2.
2.  I removed 4MB from SWAP, on the default LVM on sda2.  I did this because I was encrypting the LVM, and this is the work around described in bug 493575.
3.  I created a new ext4 partition on sda3. size=30720MB, mnt=/home.  Encrypted.

That install went without a hitch.  I wanted to test reinstalling and saving /home, so I did the following.

1.  Began install with F11b DVD.
2.  Entered global passphrase to unlock encrypted partitions.
2.  Chose 'Create Custom Layout' when partition time came.
3.  Edited sda3 (I just told it the mount point was /home).  This is where I first noticed something "wrong".  Though I clicked "okay", it did not show that sda3 was now mounted at /home.

4.  I edited the LVM on sda2 by:
     a.)  Editing what was the default root partition.  I told it the mount point was '/' (without the quotes, of course), and told it to format as ext4.
     b.)  Editing the former SWAP partition.  I told it to format as swap.

5.  I clicked on /dev/sda2, and then clicked "Edit".  I wanted to make sure the LVM was going to be encrypted still, because there were no lock icons.
6.  I clicked "Format As" and changed the option from "EFI System Partition" to "Physical Volume (LVM)".  "Encrypt" checked itself when I checked "Format As".
7.  I clicked "Okay" and got the traceback.

BTW, I just repeated this as I was typing, so if you need more details, I can repeat as often as needed.
Comment 3 Mike Wolf 2009-04-10 02:12:07 EDT
Just in case it's important...  I actually reinstalled because I had a power issue while YUM was cleaning up after the first "yum update", after which I couldn't get YUM to work (even after "yum-transaction-complete" and "yum clean all").  That's when I decided to reinstall and test saving /home.  I'm mentioning this in the event that this error is because the old partitions are corrupt somehow.  Once someone gives me the green light, I will do a fresh install and try to recreate the bug without the power issue ever being involved.
Comment 4 Martin Sivák 2009-04-14 10:46:21 EDT
Is it possible to get into the installer's shell and get the status of device mapper using `dmsetup info`?

And can you please describe the exact disk setup you had before the instalation so I can try to reproduce this bug?

Comment 5 Mike Wolf 2009-04-14 11:25:28 EDT
I will give more detailed instructions on my original setup when I get home from work tonight, but you may be able to achieve the setup by following the first set of instructions on Comment #2.  Just start with the default partitioning scheme, then go 1-3 on the first instructions.

Please explain how I get into the installer's shell and issue the "dmsetup info" command.

Just thought of something else -- since the second install resulted in the described bug, no changes were ever written to the hard drive during that install.  So my initial install still functions (except yum), so if you give me (or direct me to) instructions, I can also export/attach my original disk setup.

Comment 6 Mike Wolf 2009-04-14 22:17:49 EDT
Original disk setup is as follows: (According to Anaconda)

Single Drive: /dev/sda
Size: 76317MB
Model: ATA Hitachi HTS54168


/dev/sda1:  200MB, ext3, /boot
/dev/sda2:  45396MB, LVM (This is encrypted)
/dev/sda3:  30720MB, ext4, /home (This is encrypted)

On /dev/sda2 (which is encrypted), I have:

lv_root:  42420MB, ext4, /  (root)
lv_swap:  2972MB, swap

sda2 & sda3 are encrypted with the same passphrase.

I hope that helps.  Please explain where I enter "dmsetup info" so I can provide more info.  I Googled it, but it didn't get me anywhere.


Comment 7 Mike Wolf 2009-04-15 00:46:20 EDT
Created attachment 339622 [details]
Attached traceback automatically from anaconda.
Comment 8 Mike Wolf 2009-04-15 00:56:18 EDT
I was able to recreate the error on a different machine.  Comment #7 is from a Dell Dimension B110.  I did a fresh install of F11 beta, as I described above.  Then I reinstalled, mimicking my actions from Comment #2.

I ran into a separate (but possibly related) bug by slightly modifying my actions during the reinstall.  See Bug 495848 for details.
Comment 9 Mike Wolf 2009-04-15 18:52:23 EDT
Created attachment 339757 [details]
Attached traceback automatically from anaconda.
Comment 10 Mike Wolf 2009-04-15 18:57:44 EDT
Comment #9 on a Dell Optiplex GX270.  This time, I used the default layout for the initial install.  The only changes I made were to encrypt the disk, and to subtract 4MB from SWAP (workaround for Bug #493575).

Everything in the 2nd install remains the same.  I am going to try to recreate this without encryption -- I'll let you know the results in a few hours.
Comment 11 Mike Wolf 2009-04-16 23:01:43 EDT
FYI, you can't recreate this error if the disk is not initially encrypted.  At the part where you select sda2 and click "edit", you are greeted with a dialogue box that says ""You cannot edit this device:  This device is part of the
LVM group 'vg_gx2701'."  This would be the expected behaviour when the drive is encrypted as well.
Comment 12 Mike Wolf 2009-04-20 19:10:28 EDT
I just tried the nightly rebuild for 4-20-2009.  This bug is fixed as of anaconda, thanks!
Comment 13 Martin Sivák 2009-04-21 05:55:23 EDT
Thanks for your help Mike. I'm closing this bug per your comment #12.

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