Description of problem: Not 100% sure about this, sorry if this is noise: did I just not click the right buttons during install.....? From tracing through an F10Spin2 install that set up an encrypted root, it appears that anaconda first "sets up" the encrypted partition, and then "sets up" the LVM (VolGroup00/LogVol00). I think this means that I cannot "extend" VolGroup00-LogVol00 by adding PVs from another partition and still have the encryption enforced on "root". Do I have that right? Would it be any less secure to reverse the above order, and "set up" the LVM/VG first, followed by the cryptsetup of the LogVol00? Or is there a chicken and egg problem here? From reading /etc/rc.d/rc.sysinit, I think this would "work" on boot, since it looks like rc.sysinit calls 'init_crypto' twice, once before and once after running 'vgchange -a y ....' Or is there a simpler way to do this..... Version-Release number of selected component (if applicable): anaconda-11.4.1.62-1.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
You can either encrypt the physical volumes or you can encrypt the logical volumes. Which you do is up to you if you do a custom partition layout. If you choose to have anaconda create the encrypted default layout, you get encrypted physical volumes (not encrypted logical volumes). Whatever device is encrypted must be encrypted before it can be set up as an LVM component or a filesystem or whatever. You can't go backwards. In either case you can add PVs to your VG, regardless of whether your existing PVs are encrypted or your LVs are encrypted.
Thanks for the response. Here's the scenario I am considering: I have installed using the "let anaconda set up the partitions in the free space" method on a drive with 2 previously formatted NTFS partitions. I check the "encrypt" box. I have the following partitions as reported by parted: Disk /dev/sda: 160GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 32.3kB 22.0GB 22.0GB primary ntfs boot 2 22.0GB 63.4GB 41.4GB primary ntfs 3 63.4GB 63.6GB 206MB primary ext3 4 63.6GB 160GB 96.4GB extended 5 63.6GB 160GB 96.4GB logical lvm [Of course, this is reported after the system is booted.] At a later point, I would like to zero out /dev/sda2, run pvcreate on it, and add it to VolGroup00 (in /dev/sda5), and then to LogVol00 to increase the size of my root filesystem. But "cryptsetup status" reports: [root@tlondon ~]# cryptsetup status /dev/mapper/luks-cc25f1b4-d5be-4622-a5be-955e007c2356 /dev/mapper//dev/mapper/luks-cc25f1b4-d5be-4622-a5be-955e007c2356 is active: cipher: aes-cbc-essiv:sha256 keysize: 128 bits device: /dev/sda5 offset: 1032 sectors size: 188280705 sectors mode: read/write [root@tlondon ~]# So LUKS is managing encryption for sda5, not VolGroup00 or LogVol00. So if I add PVs created in sda2 to them, I think LUKS won't encrypt. I can add the PVs, but if the above it right, data stored in them won't be private, unless I set up a second LUKS key/etc. for it. I was hoping I could "just add the PVs" and have it secured with the "anaconda created" crypto. I thought that would be possible if the "/dev/mapper/VolGroup00-LogVol00" device was encrypted (and then resizing the cryptsetup after adding the PVs). If the above is just crazy, I suppose I could do a "luksFormat/luksOpen" on the new device (/dev/sda2) before I do the pvcreate/vgextend/lgextend/ext3-resize. But now boot will require 2 passphrases, .... Am I going down a "bad path" here thinking it would be useful to be able to "extend"?
You can just use the same passphrase for sda2 that you use for sda5. Run luksFormat, specify the same passphrase, then run luksOpen, then pvcreate on the mapped device (eg: /dev/mapper/<something>). If this affects the VG containing the root filesystem or your first (per fstab) swap device, make sure you re-run mkinitrd or you won't be able to boot next time. For some info about managing LUKS devices: http://fedoraproject.org/wiki/Docs/Drafts/DiskEncryptionUserGuide
Thanks. I'll study this, and probably close this in a few days. Perhaps I'll be more thoughtful on my next install ;)
OK. I'll close this, and try LVM install next....