The following was filed automatically by anaconda: anaconda 11.5.0.38 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 crypto.luks_close(self.mapName) File "/usr/lib/anaconda/storage/deviceaction.py", line 261, in __init__ self.device.format.teardown() 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 self.editPartition(device) CryptoError: luks_close failed for luks-0ed1caa2-5ca7-45d6-a971-e2441dcd4f2c
Created attachment 339059 [details] Attached traceback automatically from anaconda.
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.
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.
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? Thanks
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. Thanks
Original disk setup is as follows: (According to Anaconda) Single Drive: /dev/sda Size: 76317MB Model: ATA Hitachi HTS54168 Partitions: /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. Thanks, Mike
Created attachment 339622 [details] Attached traceback automatically from anaconda.
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.
Created attachment 339757 [details] Attached traceback automatically from anaconda.
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.
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.
I just tried the nightly rebuild for 4-20-2009. This bug is fixed as of anaconda 11.5.0.46-1, thanks!
Thanks for your help Mike. I'm closing this bug per your comment #12.