Description of problem: One of my LVs is an encrypted /home partition to be shared on a multi-boot system. It has an alternative passphrase set up for LUKS encryption. In Anaconda, if I enter the secondary (alternative) passphrase for that partition, the prompt closes and opens a second time. No feedback is given on whether the input was wrong. If I type it in once more, Anaconda proceeds but later on doesn't recognise the partition. It displays type "unknown" instead of ext4. Version-Release number of selected component (if applicable): 16.14, F16 Alpha TC1 netinstall ISO image How reproducible: Always Additional info: I can only access that encrypted LV when entering the primary passphrase, which is accepted with a single prompt.
Without consulting the criteria I expect this is at least a Beta blocker.
Bah, commented in the wrong bug. This may only be a final release blocker.
Discussed in the 2011-08-26 blocker review meeting. Rejected as a Fedora 16 beta blocker as it does not violate any of the beta release criteria[1]. However, the bug was accepted as a Fedora 16 final blocker as it does violate the following final release criterion [2]: The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above. Accepted as Fedora 16 NTH since it is annoying. [1] https://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria [2] https://fedoraproject.org/wiki/Fedora_16_Final_Release_Criteria
Martin, this one is easily reproducible and is something going on in the cryptsetup bindings AFAICT. It only happens when using a passphrase other than the first slot.
It's been a while since this was reported and there have been no new reports since then. Can you reproduce this with beta or has there been movement on it?
Discussed at 2011-10-14 blocker review meeting. David, Martin: can you please provide a status update on this? It's a final blocker and needs fixing. Thanks!
Created attachment 528515 [details] Not reproducable? Well I tried to reproduce this and it worked for me, here are the steps. If you see anything I did differently, tell me. Prep: Boot F16 Beta CD wait for installer shell to start Ctrl-Alt-F2 to the shell fdisk a drive into two partitions cryptsetup luksFormat /dev/vda1 [password: abcdefgh] cryptsetup luksFormat /dev/vda2 [password: aaaaaaaa] cryptsetup luksAddKey /dev/vda2 [password: abcdefgh] cryptsetup luksOpen /dev/vda1 first cryptsetup luksOpen /dev/vda2 second mkfs.ext4 /dev/mapper/first mkfs.ext4 /dev/mapper/second reboot Reproduce: Boot F16 Beta CD again and use twice the "abcdefgh" password. Then select custom partitioning and see the screen in attachment.
It is still reproducible for me with F16 Beta DVD with exactly the same symptoms as in the original bug report. > cryptsetup luksFormat /dev/vda1 [password: abcdefgh] > cryptsetup luksFormat /dev/vda2 [password: aaaaaaaa] > cryptsetup luksAddKey /dev/vda2 [password: abcdefgh] What happens if you don't share "abcdefgh" between vda1 and vda2? Have you tried to make the second "abcdefgh" a different passphrase? > Boot F16 Beta CD again and use twice the "abcdefgh" password. Why twice? It doesn't become clear what you test. I want to enter the alternative passphrase, which is specific to the /home partition and is not shared with any other partition. The prompt closes, reopens, I enter the same passphrase a second time, the prompt closes again, and later in the partitioning tool, the partition fs type is "unknown". I don't make any mistakes when entering the passphrase, since it is just a short one for testing, and it works fine when booting into Fedora 14 to 16.
*** Bug 741538 has been marked as a duplicate of this bug. ***
Michael: I entered it twice because anaconda asked me for a password for vda1 and then vda2. After that both partitions were recognized as ext4. I will try again using three separate passwords then.
So.. I reformatted the vda1 partition to use different LUKS passphrase and got new results. Anaconda really asks twice for the vda2 passphrase (+ once for the vda1 pass.), but recognizes the filesystem properly afterwards. Dave, do you have any idea what could be causing it? I doublechecked the cryptsetup code we have in anaconda and we are using SLOT_ANY everywhere. Could this be a weird GUI-storage issue of not passing the proper pass to the right calls?
Ok, I found one error in my code related to non-first keyslot. Once it hits nightlies we will be able to test this again.
Created attachment 528833 [details] Update image with new crypto for testing Ok, there is another way. If you start the installation with updates=http://<somewhere>/updates.img you can test this change right now.
That fixes it. An explicit updates=... kernel boot arg is not needed. For install from HDD, the image files updates.img and product.img are searched for in the same directory that contains the install image (such as the DVD ISO). Alternatively, using updates=file://<somewhere>/updates.img also is accepted.
Kind of fixes it for me. The installer proceeds but I get two problems: 1. The new kernel is missing from the grub.conf file (although the kernel and initrd image are under /boot) 2. I have to enter my passphrase three times once the kernel loads.
it looks like the fix for this was included in anaconda 16.22, according to the package changelog: "cryptsetup returns positive nonzero when activating by different than the first keyslot (msivak)" it wasn't mentioned in the update list of bugs fixed, though. Michael, can you please confirm this is fixed in TC2: http://dl.fedoraproject.org/pub/alt/stage/16.TC2/ and then we can close this? Thanks!
I had confirmed the fix already in comment 14.
yes, but we ideally need to double-check that the fix made 16.22 in working order and an actual complete compose with the fix in place works as expected.
I've tried the new version of anaconda on another machine I have, and it works. Entering the passphrase allows the installation to proceed. The problem is that the machine becomes unbootable - there is no entry for the new kernel in the grub configuration. Same as with my other box. I suppose making the machine unbootable qualifies it for blocker status. Would you like a separate bug for that, or can we record this here? (Note: I'm out of boxes to test on now)
# grep grub upgrade.log 12:05:49 Upgrading grubby-8.3-1.fc16.x86_64 grubby fatal error: unable to find a suitable template 12:27:09 Upgrading grub2-1.99-9.fc16.x86_64 12:36:22 Upgrading grub-efi-0.97-83.fc16.x86_64 grubby fatal error: unable to find a suitable template grubby: doing this would leave no kernel entries. Not writing out new config. grubby fatal error: unable to find a suitable template grubby: doing this would leave no kernel entries. Not writing out new config. grubby fatal error: unable to find a suitable template grubby: doing this would leave no kernel entries. Not writing out new config.
File a new bug please.
Separate bug 747920 filed.
Looks like the bug filed here is indeed fixed in TC2, closing.