Bug 728301 - F16 Alpha TC1 installer | entering secondary LUKS passphrase => unknown filesystem
Summary: F16 Alpha TC1 installer | entering secondary LUKS passphrase => unknown files...
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 16
Hardware: x86_64
OS: Unspecified
Target Milestone: ---
Assignee: Martin Sivák
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker, AcceptedNTH
: 741538 (view as bug list)
Depends On:
Blocks: F16Beta-accepted, F16BetaFreezeExcept F16Blocker, F16FinalBlocker
TreeView+ depends on / blocked
Reported: 2011-08-04 16:14 UTC by Michael Schwendt
Modified: 2011-10-21 18:50 UTC (History)
6 users (show)

Fixed In Version: anaconda-16.22-1.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-10-21 18:50:56 UTC

Attachments (Terms of Use)
Not reproducable? (41.64 KB, image/png)
2011-10-17 10:48 UTC, Martin Sivák
no flags Details
Update image with new crypto for testing (1.84 KB, application/octet-stream)
2011-10-18 15:16 UTC, Martin Sivák
no flags Details

Description Michael Schwendt 2011-08-04 16:14:07 UTC
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:

Additional info:
I can only access that encrypted LV when entering the primary passphrase, which is accepted with a single prompt.

Comment 1 David Lehman 2011-08-04 19:29:09 UTC
Without consulting the criteria I expect this is at least a Beta blocker.

Comment 2 David Lehman 2011-08-04 21:18:57 UTC
Bah, commented in the wrong bug. This may only be a final release blocker.

Comment 3 Tim Flink 2011-09-01 17:27:48 UTC
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

Comment 4 David Lehman 2011-09-01 18:40:51 UTC
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.

Comment 5 Tim Flink 2011-09-30 20:51:55 UTC
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?

Comment 6 Adam Williamson 2011-10-14 19:12:01 UTC
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!

Comment 7 Martin Sivák 2011-10-17 10:48:55 UTC
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.


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


Boot F16 Beta CD again and use twice the "abcdefgh" password. Then select custom partitioning and see the screen in attachment.

Comment 8 Michael Schwendt 2011-10-17 11:56:53 UTC
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.

Comment 9 David Lehman 2011-10-18 12:45:23 UTC
*** Bug 741538 has been marked as a duplicate of this bug. ***

Comment 10 Martin Sivák 2011-10-18 13:08:22 UTC

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.

Comment 11 Martin Sivák 2011-10-18 13:22:44 UTC

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?

Comment 12 Martin Sivák 2011-10-18 14:47:02 UTC
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.

Comment 13 Martin Sivák 2011-10-18 15:16:50 UTC
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.

Comment 14 Michael Schwendt 2011-10-18 16:26:39 UTC
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.

Comment 15 Need Real Name 2011-10-18 18:25:21 UTC
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.

Comment 16 Adam Williamson 2011-10-20 19:45:34 UTC
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:


and then we can close this? Thanks!

Comment 17 Michael Schwendt 2011-10-20 20:02:01 UTC
I had confirmed the fix already in comment 14.

Comment 18 Adam Williamson 2011-10-20 20:10:51 UTC
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.

Comment 19 Need Real Name 2011-10-21 11:19:38 UTC
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)

Comment 20 Need Real Name 2011-10-21 11:24:11 UTC
# 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.

Comment 21 Martin Sivák 2011-10-21 11:51:55 UTC
File a new bug please.

Comment 22 Need Real Name 2011-10-21 11:59:43 UTC
Separate bug 747920 filed.

Comment 23 Adam Williamson 2011-10-21 18:50:56 UTC
Looks like the bug filed here is indeed fixed in TC2, closing.

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