grub2 was recently pulled into the distribution including some unsupportable code for handling some limited LVM configurations. Since it seems that people will start to try using this, we should turn it into something that can be supported. Suggestion: 1. Decide precisely what configurations will be supported. E.g. May have /boot as any LV that is linear or striped, is not a snapshot origin and uses exactly one PV. (I'm *not* saying that is the correct statement yet, but it'll be something along those lines.) 2. Determine what flags/version numbers should be added to LVM to signal that an LV is in that "can be booted from" state and how to set them. Could be set automatically. Could be set using 'lvchange'. Prepare to handle code extensions where it could handle more cases in future and versions of grub2/lvm2 could be mixed. E.g. a GRUB2_BOOTABLE flag or a grub2_bootable_version field set to the first grub2 version number that we know can handle it correctly. 3. Update lvm2 to implement 2. 4. Update grub2 to recognise the state set in 2 and not to attempt to boot from the LV otherwise. 5. Update grub2 to parse the relevant parts of the metadata correctly as per the LVM2 metadata specification. Currently it makes assumptions about the metadata layout (whitespace, field sequences etc.) that are not necessarily true.
6. include LVM in the signed UEFI grubx64.efi
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
I'm closing this one as WONTFIX. My colleague Bryn Reeves, who was also looking into this, concluded this very well (citing from bug #1496229): > There are no current plans to extend LVM support to the /boot file system > for Red Hat distributions. Although support for some simple LVM2 volume > types does exist in the upstream Grub2 boot loader, this is not available on > all platforms, and the use of a logical volume for /boot conflicts with the > current direction of standards governing early boot on common PC platforms. > > The uEFI standard requires the use of a GPT partition table and a specific > GPT partition type for the "EFI System Partition" that is conventionally > used as the /boot file system on these systems. Since the uEFI standards > already mandates this volume (and require that it be located on a fixed-size > GPT partition and use a specific file system type), it is cumbersome for > both the distribution and administrators to manage an additional volume > solely for the Linux-specific files that are normally stored in this > location. > > The Boot Loader Specification (supported for optional use in Red Hat > Enterprise Linux 7 and used for system boot entries in Red Hat Enterprise > Linux 8 and later) also requires that the file system used for /boot be > readable by the platform firmware. For EFI systems this also implies the use > of a specific GPT partition and file system type. > > In addition, The Grub2 support for LVM logical volumes is a separate code > base from the main LVM2 user space project and was developed without > substantial input from the LVM2 developers. The support provided is > incomplete and has not been subject to the same level of testing and quality > engineering as the standard LVM2 tools and since the boot loader environment > provides a very restricted software runtime porting code between the LVM2 > and Grub2 projects is costly and high-risk. > > Given this and the fact that increasing adoption of the uEFI standard in new > hardware will substantially reduce the number of users able to take > advantage of these features over the coming years the team has decided not > to pursue this feature and to instead focus on improving tools for managing > system snapshots and providing rollback capabilities without the need to > place the /boot file system on an LVM2 logical volume.