improving BTRFS support in Fedora

Gene Czarcinski gczarcinski at gmail.com
Sun Apr 27 12:40:45 UTC 2014


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


More information about the devel mailing list