Bug 446567

Not that it's not a good idea, but multiple partitions certainly isn't in any of
the 'default' partitioning setups.

The default partition setup has / and swap. If you encrypt them with LUKS, that
makes 2 passwords already ;)

Add to that a /home (which I'll never understand why it's not separated from /
in the default setup) and you have a third one.

Instead of a single password, what I'd like to have is a private key system. The
key could be located on a USB stick. If the stick is plugged and the key can be
located and used at boot time, then the partitions can be decyphered and used
without password (or with a single passphrase for the key). There could even be
a "safe mode" where the user is prompted for all the passwords for the
partitions (as it is the case right now) if the key cannot be located (someone
stole your USB stick for example :)

I ran into this problem.  I solved it by creating the partitions under the
default LVM.  You encrypt the LVM and not the individual partitions within the
LVM.  This allows for single login.

You can still encrypt individual partitions under the LVM with a separate key
for additional security if needed, from what I've seen.

That doesnt' solve the problem perfectly.  Some other operating systems don't
support booting from an encrypted LVM physical volume, nor can one always delete
and start over.

That said, I am afraid I'll have to do just that, just to keep my sanity at boot up.

The question is, how should we mark this bug?  Is someone going to work on it in
the long run?

I do have my "/" on a raid0 and /home on a raid1. As far as I see there is no
way to use only one password. :-(

Anaconda allows you to specify a "global" password when you are opening multiple
encrypted partitions.  If you specify the password as global (by checking the
box under the password) then it assumes that password will unlock all
partitions.  I think this could be implemented at the start up.

That's because a single instance of anaconda is running for the entirety of
partitioning.

Each LUKS unlock event on boot is an independent event and process.

Just to be clear, we may look at this for future releases - this isn't somethign
that's going to change for a F9 update.

should have been closed a while ago, re: what bill nottingham said.