Bug 728301

Summary: F16 Alpha TC1 installer | entering secondary LUKS passphrase => unknown filesystem
Product: [Fedora] Fedora Reporter: Michael Schwendt <bugs.michael>
Component: anacondaAssignee: Martin Sivák <msivak>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: anaconda-maint-list, awilliam, jonathan, lsof, tflink, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: AcceptedBlocker, AcceptedNTH
Fixed In Version: anaconda-16.22-1.fc16 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-21 14:50:56 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 713565, 713568    
Attachments:
Description Flags
Not reproducable?
none
Update image with new crypto for testing none

Description Michael Schwendt 2011-08-04 12:14:07 EDT
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.
Comment 1 David Lehman 2011-08-04 15:29:09 EDT
Without consulting the criteria I expect this is at least a Beta blocker.
Comment 2 David Lehman 2011-08-04 17:18:57 EDT
Bah, commented in the wrong bug. This may only be a final release blocker.
Comment 3 Tim Flink 2011-09-01 13:27:48 EDT
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 14:40:51 EDT
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 16:51:55 EDT
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 15:12:01 EDT
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 06:48:55 EDT
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.
Comment 8 Michael Schwendt 2011-10-17 07:56:53 EDT
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 08:45:23 EDT
*** Bug 741538 has been marked as a duplicate of this bug. ***
Comment 10 Martin Sivák 2011-10-18 09:08:22 EDT
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.
Comment 11 Martin Sivák 2011-10-18 09:22:44 EDT
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?
Comment 12 Martin Sivák 2011-10-18 10:47:02 EDT
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 11:16:50 EDT
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 12:26:39 EDT
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 14:25:21 EDT
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 15:45:34 EDT
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!
Comment 17 Michael Schwendt 2011-10-20 16:02:01 EDT
I had confirmed the fix already in comment 14.
Comment 18 Adam Williamson 2011-10-20 16:10:51 EDT
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 07:19:38 EDT
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 07:24:11 EDT
# 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 07:51:55 EDT
File a new bug please.
Comment 22 Need Real Name 2011-10-21 07:59:43 EDT
Separate bug 747920 filed.
Comment 23 Adam Williamson 2011-10-21 14:50:56 EDT
Looks like the bug filed here is indeed fixed in TC2, closing.