Installing Fedora with LVM and LUKS, using the encryption layer on top of the LVM layer.

yudi v yudi.tux at gmail.com
Tue Jul 19 10:28:02 UTC 2011


On Tue, Jul 19, 2011 at 7:06 AM, yudi v <yudi.tux at gmail.com> wrote:

>
>
> On Tue, Jul 19, 2011 at 12:27 AM, Bruno Wolff III <bruno at wolff.to> wrote:
>
>> On Mon, Jul 18, 2011 at 23:02:00 +1000,
>>  yudi v <yudi.tux at gmail.com> wrote:
>> >
>> > I did not know that, I was under the impression once the encryption
>> > container is open all the data in that container is decrypted.
>>
>> No. That wouldn't be practical. Blocks are decrypted as needed.
>> > > It might be a significant savings if you are doing snapshots or the
>> like
>> > > when LVM is manipulating the data opaquely. The encrypted data can be
>> > > copied around without having to decrypt it.
>> > >
>> >
>> > I guess you mean LV's can be moved around not the data per se.
>>
>> From the LVs point of view the data is opaque. So if some of the data
>> needs to be moved around it would not need to be decrypted first. If the
>> LV is on an encrypted device (instead of containing one), then any work
>> with the LV would need to be encrypted or decrypted as appropriate. So
>> There could be savings when you are manipulating the LVs.
>>
>> > I was playing with Debian and tried this method with even the /boot in
>> the
>> > LVM as GRUB2 can handle booting straight from the LVM but it fails when
>> I
>> > try to have encryption on top of the LVM. Without encryption it works
>> just
>> > fine.
>>
>> Fedora has the same limitation. /boot cannot be encrypted and there are
>> some
>> limitations on file systems (though I think the normal ones will all work)
>> and raid (BIOS supported raid should work as well as software raid 1 where
>> the meta data is at the end of the partition). I am not sure what the
>> status of lvm support for /boot in Fedora.
>>
>
> It's not the limitation of Fedora, it's GRUB legacy, GRUB2 can handle the
> /boot partition in the LVM. /boot still cannot be encrypted. Debian Squeeze
> comes with GRUB2 thats why I was trying to move the /boot partition to the
> LVM and encrypt /,/home, and swap LVs.
>
> --
> Kind regards,
> Yudi
>
>
I have noticed something peculiar, the existing test setup looks like this:
(encryption at the PV level, i.e below the LVM layer)

sda1   ntfs
sda2  /boot  ext
sda3 - PV and VG (encrypted at the PV level)
- lv_swap  swap
-lv_root  / ext4
-lv_home  /home ext4
-rest unassigned
sda4 extended
sda5  vfat


Now I wanted to change this to: (encryption on top of the LVM layer,
encrypting individual LVs)

sda1   ntfs
sda2   /boot  ext
sda3 - PV and VG
- lv_swap  swap  (encrypted LV)
-lv_root    / ext4 (encrypted LV)
-lv_home /home ext4 ( (encrypted LV))
-rest unassigned - I will assign and encrypt as the need arises.
 sda4 extended
sda5  vfat


When I try to install over the existing setup, anaconda tells me that sda3
is encrypted and asks for the passphrase. If  I do not provide the
passphrase sda3 gets excluded. Thats not what  I want and I want to get rid
of the encryption layer at the sda3 PV level and have it on top of the LVM
layer at individual LV level.

Wasn't sure what to do so fired up Gparted live cd and used FDISK to delete
sda3 and create an LVM partition. Left the break down to the Fedora
installer.

Back in Fedora installer, it again asks me for the sda3 passphrase.

Fired up Gparted CD again and used gparted this time to look at the
partition scheme.  gparted still says the file system on sda3 is crypt-luks.

Not sure why this is happening.

Finally, I just deleted the partition with fdisk and left it unassigned.
Then Fedora install went through as expected.

Was I doing something wrong?
Should I have given the Fedora installer the passphrase for sda3 partition?
- would this allow the deletion of the encrypted PV?
Also why does the fedora installer assign partition ID 83 to sda3, shouldn't
it be 8e for an LVM?

-- 
Kind regards,
Yudi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/users/attachments/20110719/0b5484ae/attachment-0001.html 


More information about the users mailing list