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.