Bug 441018

Fixed the first part in git.

I'm a little bit less clear about the second part.

1) 
Sweet great work..

2)

I chose not to encrypt and the only time I provided password for encryption was
in the dialogue box where anaconda wants the password to access my other
encrypted partitions..

Yet encryption services were enabled and install.

The encryption services are in some weird state as well.. 

The "Staring disk encryption: FAILED" ( fails )

Then I'm asked for the luks password in..
( which by the way is same for them all hence I guess the dialog box )
Starting disk encryption using the RNG:
Enter LUKS passprase: password entered 

which complains about missing padlock-aes.ko and padlock-sha.ko modules..

But things continue.

I'm going to recreate this again tomorrow of the 04.04 live and ensure that
encrypt is not hashed and rule out the fact that I might have entered the
password somewhere and post the results back here.  

Will attach logs this time :) in case of failure..

Yep can duplicate this.

The [ Passphrase ] box is the culprit..
It does this when it's dealing with more then one encrypted partition.
( or maybe just ext4 encrypted partition )

I'm overwriting existing non encrypting default partition ( custom layout, just
choose /boot /swap / and to Format )

I have 5 default installations 2 of them encrypted, one ext3 the other ext4.

First by pressing [cancel] both times when asked for the password to access
the encrypted partitions.

Everything installs as normal.

Then I provided password for the first one of the encrypted partitions ( ext3 )
but press [cancel] when asked to provide password for the second one.

Everything installs as normal.

Then I [cancel] providing password for the first encrypted partition
and provide the password when asked for the second encrypted partition ( ext4 ). 
DUPLICATE!!

Then I provide the password for the first encrypted partition and hash
[] This is a global passphrase. DUPLICATE.

You should be able to reproduce this behavior by doing an install when having
more then one encrypted partition.

Still a problem?  Lots of new anaconda goodness in the last week.  (I'm trolling
blockers that haven't been touched in 7 days).

I'm not 100% on how to repro this or I'd check myself.

I am not completely clear on what behavior is being reported.

Are you saying that entering a passphrase to access preexisting encrypted
partitions is somehow causing anaconda to encrypt new devices you create without
you specifying that it do so? Are you certain that the devices you are creating
your new filesystems on are not the same encrypted devices whose passphrases you
entered?

A few items for clarity:
- the disk encryption service being started has nothing to do with whether or 
  not your system is installed on encrypted devices. it happens regardless.
- we do not add devices whose passphrases you provide to /etc/crypttab (or
  to any other form of record) unless you go on to use those devices for
  filesystems on which the system resides.
- missing padlock-foo.ko messages are a result of module aliases and the fact
  that you, like many others, do not have the hardware those modules are made
  for. it is not indicative of any failure unless you do in fact have the
  specific piece of hardware these modules are for.

"Are you saying that entering a passphrase to access preexisting encrypted
partitions is somehow causing anaconda to encrypt new devices you create without
you specifying that it do so?"

Yes!.

And this does it.

"Then I [cancel] providing password for the first encrypted partition
and provide the password when asked for the second encrypted partition ( ext4 ). 
DUPLICATE!!

Then I provide the password for the first encrypted partition and hash
[] This is a global passphrase. DUPLICATE."

And this does not trigger it.

"First by pressing [cancel] both times when asked for the password to access
the encrypted partitions.

Everything installs as normal.

Then I provided password for the first one of the encrypted partitions ( ext3 )
but press [cancel] when asked to provide password for the second one.

Everything installs as normal."

"Are you certain that the devices you are creating
your new filesystems on are not the same encrypted devices whose passphrases you
entered?"

It's on the same hd ( sda ) and no this was not an encrypted partition before.
this was done on remaining free space on sda when I first noticed it then 
I deleted the installation that created this and did installations until
I narrowed it to the [ Passhprase ]box in anaconda....

I had done 4 installation before this all of them installed 
and all chainloaded to grub this was the fifth installation on the 
same harddrive.

Of those four there are two encrypted one ext3 and another ext4.

I also was not being asked for the Luks password but for RSA ( something other
than Luks anyway ) if I remember correctly. 
( doing exact same installation setup with preview and currently
installing the 3 installation, ext4 unencrypted ) 

I have been unable to reproduce any failure that might be the reported problem.

The steps to reproduce need to be *complete*. I cannot guess what has happened
before or after the portion of the process you choose to describe, nor can I
guess the details you have chosen to omit in the descriptions you have given.

It is also noteworthy that anaconda only supports LUKS encrypted devices, so if
you are seeing messages about some other type of encrypted device you must be
doing something major (and seemingly relevant) that you have not disclosed in
this bug report.

Was going to post update if this still happened with preview live but hit
another bug ( have not filed it yet that prevents me from checking it )

If I can recall correctly same error as in here #443092 and then asked to
provide password not Luks but RNG, or RSA or ( again R something ).. Again
rawhide-live cd...

Should have time to do again.. tomorrow..

Due to other bug I have encounter I have been unable to duplicate this.

I've filed an RFE for total rewrite of the dialogue box ( 445641 ).

Just close this either FIXED ( these where 2 issues one fixed )
or INSUFFICIENT_DATA I will just reopen or comment on this if I wont come
across the other bug I encountered ( and hopefully not come across new ones ) 
and duplicate this in f9 final.

Normal user with default partition layout and default install 
wont come across this issue.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I noted that this bug 441018, originated RFE bug 445641.  Do we close this out
and fold into bug 445641?

Closed since OP was unable to duplicate the unresolved bug. If it pops up again,
please reopen this report or file a new one.