On 12/03/2013 11:55 AM, David Lehman wrote:
pyanaconda/bootloader.py | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/pyanaconda/bootloader.py b/pyanaconda/bootloader.py index 51f7f24..fcb9c4a 100644 --- a/pyanaconda/bootloader.py +++ b/pyanaconda/bootloader.py @@ -1349,8 +1349,7 @@ class GRUB2(GRUB): terminal_type = "console"
# requirements for boot devices
- stage2_device_types = ["partition", "mdarray", "lvmlv", "btrfs volume",
"btrfs subvolume"]
- stage2_device_types = ["partition", "mdarray", "lvmlv", "btrfs volume"] stage2_raid_levels = [mdraid.RAID0, mdraid.RAID1, mdraid.RAID4, mdraid.RAID5, mdraid.RAID6, mdraid.RAID10] stage2_raid_metadata = ["0", "0.90", "1.0", "1.2"]
Close but not a winner. grubby does not like /boot being anywhere near a btrfs filesystem. While you may have disallowed /boot as a btrfs subvolume, it still installs and then boots up with /boot simply being a directory on the rootfs.
Took your patches and created an updates image against anaconda-20.25.13-1. Booted up TC4 and applied the updates to perform a kickstart install with only a regular partition defined for swap and /boot as a simple directory on the rootfs subvol.
Curious, you removed the btrfs subvolume but left in btrfs volume. I do not understand why you would ever install into a btrfs volume. Then again, maybe this let the /boot as a directory work.
I did not but will test /boot being a directory on the rootfs LVM.
Gene
I am going