|
|
Subscribe / Log in / New account

Fedora and LVM

Fedora and LVM

Posted Nov 1, 2012 1:38 UTC (Thu) by mstefani (guest, #31644)
In reply to: Fedora and LVM by marcH
Parent article: Fedora and LVM

I have full disk encryption on my laptop with dm-crypt and *no* LVM but separate partitions. Works out of the box aka just the one password prompt at boot. And it works since at least F14 after 2-3 bugs in dracut were fixed after I reported them.


to post comments

Fedora and LVM

Posted Nov 1, 2012 7:56 UTC (Thu) by marcH (subscriber, #57642) [Link] (4 responses)

Care to share more details? Is it really just one password or three times the same password?

Fedora and LVM

Posted Nov 1, 2012 21:34 UTC (Thu) by mstefani (guest, #31644) [Link] (3 responses)

I type the password only once at boot time and all partition (including swap) are decrypted. The UI is exact the same, if you use LVM or not; even in Anaconda.

Fedora and LVM

Posted Nov 1, 2012 23:55 UTC (Thu) by marcH (subscriber, #57642) [Link] (2 responses)

Sorry I wasn't clear. Let me rephrase: do you just have something like three partitions individually encrypted but all in the same way with the same password?

I'm not actually asking about the user interface or about how many times you type this or that but about the internal design. Once I understand the design I (we) will be able to draw my (our) own conclusions :->

Fedora and LVM

Posted Nov 2, 2012 1:15 UTC (Fri) by lacos (guest, #70616) [Link]

I think I can answer, because I have tested both "stackings" (not on Fedora but on RHEL-6).

/dev/sda1 is plaintext boot.

In experiment (a), /dev/sdb2 was handed to dm-crypt (--> /dev/mapper/luks-UUID), which was then formatted as the single PV in a VG, having three LVs (/, /home, and swap). In this case a single password is used.

In experiment (b), /dev/sdb2 was formatted as a single PV in a VG. Three LVs were created, individually encrypted with dm-crypt (using the same password), and then the three separate luks-UUID devices were formatted as /, /home, and swap. The boot process still only asks for "the" password once.

(Unfortunately, the real goal of this experimentation was not reached. The goal was to see if separately encrypting block devices (ie. in exp. (b)) would keep kcryptd from merging "request streams" targeting those separate devices, before they reach the IO scheduler. Alas, it's insufficient; as far as I understand, kcryptd instances (kernel threads?) are spawned per-CPU, not per-device, and whatever requests a given kcryptd instance issues looks same-origin to the IO scheduler, ie. serialized.

Even in experiment (b), an fsync() that follows a big, scattered write on "/" blocks a read request targeting "/home". I've seen stalls as long as 13 seconds on my laptop.

But it's my understanding that this is being worked on.)

Fedora and LVM

Posted Nov 5, 2012 10:26 UTC (Mon) by mstefani (guest, #31644) [Link]

There are four good old standard partitions, all encrypted and I have only one password. As it just worked, without being a nuisance, I happily ignored the implementation details.

Fedora and LVM

Posted Nov 1, 2012 21:01 UTC (Thu) by josh (subscriber, #17465) [Link] (1 responses)

I have the same use case for LVM: I want to encrypt both / and swap, but only enter my passphrase once at boot time. If that works without LVM, I'd happily stop using LVM.

Several encrypted partitions with one password and derived keys

Posted Nov 7, 2012 13:24 UTC (Wed) by emmi3 (subscriber, #62443) [Link]

On my Arch Linux and Ubuntu systems this works with "derived keys" see here: http://crunchbang.org/forums/viewtopic.php?id=4299 for a well written howto. It's a bit dated (now there is 'cryptsetup luksHeaderBackup') but still works.
But I remember reading that systemd did not support the "keyscript" option in /etc/crypttab, which is needed in this setup. Hope this is fixed by the time I upgrade to systemd on my Arch system.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds