On 07/31/2015 08:28 AM, Dave Johansen wrote:
I was luck enough to be bitten by this issue (
https://bugzilla.redhat.com/show_bug.cgi?id=1212907 ) when attempting
to do a clean install of F22.
That bug looks like it's triggered only when the LVs are encrypted,
which is non-standard and not at all optimal. The default and optimal
configuration is to encrypt the disk partition, and to use that LUKS
container as a PV.
I copied all of my data off and then tried manually setting things up
as separate partitions (instead of in an LVM) but it kept telling me
that /boot couldn't be on a LUKS partition.
That's correct, it cannot. UEFI and BIOS both need an un-encrypted
/boot to read the kernel and initrd. If those are in an encrypted
container, the boot loader is incapable of reading the kernel and initrd
into memory.
The config I had was /home was encrypted and / was encrypted but then
the biosboot partition was not encrypted, and all 3 were standard
partitions. Is this something that's just not supported? Or was I
doing something wrong?
It sounds like you have an UEFI system, and your /boot/EFI was not
encrypted, but /boot was on the / filesystem which *was* encrypted. That
would be an unsupported configuration. /boot and /boot/EFI must both be
on non-encrypted filesystems.
The default layout for UEFI systems is one partition (with fat16) for
/boot/EFI, a second partition (with ext4) for /boot, and a third
partition (optionally encrypted) as a PV. / and swap, and any other
filesystems, are LVs within that VG. They are encrypted because they
are inside the encrypted third partition. They don't need to be
encrypted again.