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.
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?
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.
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.)
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."
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.