Bug 679166

Summary: installer overwrites all new device passphrases with first-specified/global passphrase
Product: [Fedora] Fedora Reporter: tsukebumi
Component: anacondaAssignee: David Lehman <dlehman>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 14CC: anaconda-maint-list, jonathan, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 679223 (view as bug list) Environment:
Last Closed: 2011-05-18 18:30:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
example kickstart file
none
f14 updates to not overwrite passphrases with first/global passphrase
none
anaconda installation log none

Description tsukebumi 2011-02-21 19:25:21 UTC
Description of problem:
Documentation for kickstart configuration for partitions says there is a --passphrase parameter to specify each partition's passphrase.
However after installation all partitions are mounted with the same passphrase as if it was a global default

Version-Release number of selected component (if applicable):
pykickstart 1.77-2
anaconda 13.22-1

How reproducible:

always

Steps to Reproduce:
1. Create a kickstart configuration file with a set of partitions where at least two are encrypted and define a different passphrase
2. make an unattended installation with said kickstart

  
Actual results:
At boot, there is a password prompt for mounting a partition. If entered correctly, all partitions are mounted and boot process continiues.

Expected results:
It should be needed to enter all passphrases in order to continue.


Additional info:

Comment 1 tsukebumi 2011-02-21 19:26:18 UTC
Created attachment 479981 [details]
example kickstart file

Comment 2 Chris Lumens 2011-02-21 21:46:59 UTC
*** Bug 679165 has been marked as a duplicate of this bug. ***

Comment 3 David Lehman 2011-02-21 22:50:31 UTC
Created attachment 480014 [details]
f14 updates to not overwrite passphrases with first/global passphrase

Place the attached updates.img file in os/images/ in your install directory to get it picked up and used automatically. We don't do official fixes for the installer for Fedora 14 after the initial release, but this updates image should fix the problem you have seen.

Let me know if this doesn't solve your problem.

Comment 4 David Lehman 2011-02-22 22:21:22 UTC
If you've tried the updates.img and it didn't work, please attach /var/log/anaconda.log from the installed system (after the reboot).

Comment 5 tsukebumi 2011-02-22 22:27:43 UTC
I put the file on the nfs server used by the kickstart. (os/images/updates.img)
It didn't work out.

I am wondering if I missed something, or if the file must go on the
installation media, in which case how to get it there.
I used pungi to generate the install cd.

(sorry if I posted on the wrong place the first time)

Comment 6 David Lehman 2011-02-22 23:12:54 UTC
If you attach the log file I asked for in comment 4 I can help you figure out what went wrong with the updates image.

Comment 7 tsukebumi 2011-02-22 23:24:26 UTC
Created attachment 480293 [details]
anaconda installation log

Comment 8 David Lehman 2011-02-22 23:35:31 UTC
You probably should put the updates.img in images/ instead of os/images/. The images/ subdirectory should already exist.

Comment 9 tsukebumi 2011-02-23 00:18:42 UTC
I put it on the nfs repository I set up.
path is
mirror/download.fedora.redhat.com/pub/fedora/linux/releases/14/Everything/i386/os/images
 and the source is set up on the kickstart as 
nfs --server=172.16.3.39 --dir=mirror/download.fedora.redhat.com/pub/fedora/linux/releases/14/Everything/i386/os

On checking, it gets mounted at /mnt/source, so /mnt/source/images and /mnt/source/Packages and /mnt/source/repodata exist.

I will try out putting images at the same level as os, and modifying the kickstart so it mounts i386 instead of os and see if it works.

Comment 10 David Lehman 2011-02-23 00:54:29 UTC
It sounds like you're doing it right. Maybe the permissions are preventing anaconda from finding the updates.img?

19:22:34,086 INFO loader: Looking for updates in /mnt/stage2/images/updates.img

And then nothing, which indicates that it found nothing there. Strange.

Comment 11 Chris Lumens 2011-02-23 15:25:38 UTC
You can tell the updates image worked if /tmp/updates exists, has a pyanaconda/ directory, and is full of symlinks back into /usr/lib/python?.?

Comment 12 tsukebumi 2011-02-23 16:15:29 UTC
From the logs, it looks like it looks for updates on /mnt/stage2/images, which is part of the cd-rom.

It looks like it does not search the ntfs system on /mnt/source/images nor any other place.

What I did now was put the updates on the web server that hosts the kickstart, and at install time edited the boot options to append updates=http://.../updates.img and it worked allright.

So, how should my tree on the nfs system look like?

As of right now, it only has :
images
packages
repodata
(GPG keys from fedora)
GPL

because from the previous log file it looks like anaconda looked for updates on /mnt/stage2/images only

So my guess is the updates are used before the kickstart is loaded or before the source is mounted.

Comment 13 David Lehman 2011-05-18 18:30:42 UTC
(In reply to comment #12)
> What I did now was put the updates on the web server that hosts the kickstart,
> and at install time edited the boot options to append
> updates=http://.../updates.img and it worked allright.

This is the best approach. My apologies for not suggesting it initially.