Currently (Fedora 20), installing onto a btrfs subvolume with /boot as a
btrfs subvolume or as a directory on the btrfs rootfs is disabled. This
was done primarily because grubby had problems and could not handle
these configuration.
With development of Fedora 21 in process, it is time to reconsider the
BTRFS support question. Let me be clear, I want BTRFS supported in all
configurations of /boot.
"New" status as of the "current" rawhide:
1. grub2-2.02 has pulled in all of the upstream fixes related to btrfs
and now supports /boot on a btrfs subvol, /boot as a directory on a
btrfs rootfs, /boot on a btrfs volume, and /boot as a directory on a
rootfs installed into a btrfs volume. Also, multi-devce btrfs volumes
are also supported.
2. os-prober is being updated to fix btrfs support and reduce messaging
to syslog:
https://bugzilla.redhat.com/show_bug.cgi?id=982009
https://admin.fedoraproject.org/updates/FEDORA-2014-5611/os-prober-1.58-5.fc20
3. Of course, anaconda has installing on btrfs or LVMlvs and this needs
to be re-enabled.
4. grubby ... and here as been the "long pole in the tent."
4a. I believe that the "correct" solution is to re-implement the
fuctionality in the grubby package with bash shell scripts to replace
grubby.c. The current grubby package maintainer (Pjones) disagrees and
thus my patches to implement this are ignore.
4b. So, in the interest of moving this along, I have found the problem
in grubby.c and developed a patch to fix it. I am currently doing
testing to make sure that this patch works as intended.
According to this code fragment from anaconda:
+From anaconda: every platform that wants a bootloader:
+ platform.X86: GRUB2,
+ platform.EFI: EFIGRUB,
+ platform.MacEFI: MacEFIGRUB,
+ platform.PPC: GRUB2,
+ platform.IPSeriesPPC: IPSeriesGRUB2,
+ platform.NewWorldPPC: MacYaboot,
+ platform.S390: ZIPL,
+ platform.ARM: EXTLINUX,
+ platform.omapARM: EXTLINUX
with x86 and ARM as the primary architectures and EXTLINUX and GRUB2 as
the primary bootloaders.
Using a install x86_64 Fedora 20 DVD with a modified anaconda (to
re-enable btrfs and LVMlv installs), I have performed the following
successful tests:
----------------------------------------------------------------------------
1. ext4 rootfs partition with /boot on a ext2 partition
2. ext4 rootfs partition with /boot as a directory
3. ext4 rootfs on a LVMlv with /boot on another ext4 LVMlv
4. ext4 rootfs on a LVMlv with /boot as a directory
5. xrf rootfs partition with /boot on a ext4 partition
6. xrf rootfs partition with /boot on a xrf partition
7. xrf rootfs on a LVMlv with /boot on another ext4 LVMlv
8. xrf rootfs on a LVMlv with /boot on another xrf LVMlv
9. xrf rootfs on a LVMlv with /boot as a directory
10. btrfs rootfs subvol with /boot on a ext2 partition
11. btrfs rootfs subvol with /boot on a btrfs subvol
12. btrfs rootfs subvol with /boot as a directory
13. btrfs rootfs volume with /boot as a directory
----------------------------------------------------------------------------
Testing is currently based on a patched gruggy-8.28-1. The test
consists of doing the install (kernel-3.12.5-302.fc20), updating grubby
to the patched 8.28-1, and then doing "yum update kernel."
I intend to also do some testing on x86_32 and to do tests where
grub2-2.02, os-prober-1.58-5, and patched grubby-8.33-1 are used.
I do not have access to other hardware and would appreciate it if
someone could do some regression testing on S390, ARM, and PPC
architectures.
Comments? Suggestions?
Gene
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
