Description of problem: One common usage of a laptop is for a single user, who
installs the OS over multiple partitions. Since theoretically all partitions
may need to be encrypted, this results in multiple encryption keys. When
booting from such a system, not all the keys are queried for at once. In fact,
when /home is separate from / and the swap partition, the password key for /home
is not asked for until much later in the boot process. This presents a serious
Version-Release number of selected component (if applicable):
How reproducible: Very
Steps to Reproduce:
1. Install Fedora 9 on a multiple partition scheme with encryption for all the
partitions (such as using separate partitions for / /var /usr /home and /tmp).
2. Reboot, and type in the encryption key for each partition.
3. Be annoyed and frustrated when forced to reboot constantly for other reasons.
The user is forced to type in the password, and then wait some time to type in
the password again.
The user can configure the setup to require a single password, which is typed in
as close to the Grub screen as possible.
The user is then free to go to the bathroom, or perform other actions such as
fetching nourishing programmer fueling snacks without returning to find that the
computer is asking for yet another password.
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
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.