On Tue, Jul 19, 2011 at 7:06 AM, yudi v <yudi.tux@xxxxxxxxx> wrote:
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.
On Tue, Jul 19, 2011 at 12:27 AM, Bruno Wolff III <bruno@xxxxxxxx> wrote:
On Mon, Jul 18, 2011 at 23:02:00 +1000,
> I did not know that, I was under the impression once the encryptionNo. That wouldn't be practical. Blocks are decrypted as needed.
> container is open all the data in that container is decrypted.
> > It might be a significant savings if you are doing snapshots or the likeFrom the LVs point of view the data is opaque. So if some of the data
> > 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.
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.
Fedora has the same limitation. /boot cannot be encrypted and there are some
> 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.
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.
--
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-lv_root / ext4
-lv_home /home ext4
-rest unassigned
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-lv_root / ext4 (encrypted LV)
-lv_home /home ext4 ( (encrypted LV))
-rest unassigned - I will assign and encrypt as the need arises.
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
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines