Description of problem: grub2 fails to install in the btrfs bootloader area, apparetnly thinkng that it needs to resort to blocklists when there in fact is 64KB space available for use by the bootloader (double that of the DOS MBR unmanaged space). Version-Release number of selected component (if applicable): grub2-1.99-10.fc16 How reproducible: always Steps to Reproduce: 1. Try to install grub2 onto an btrfs partition (not MBR) 2. 3. Actual results: grub2 complains about needing to use a blocklist and refuses to install Expected results: grub2 embeds itself in the 64KB bootloader area of btrfs, similar to how it embeds itself in the MBR unmanaged space. Additional info:
This might be covered by Bug 689518 - "need to make sure btrfs support works properly". However, AFAIK: Grub "1" could fit stage1 in 32k and jump from that to stage2. Grub2 doesn't use stages. It prefers to put all the ~500k in "free" space outside the partitions, and best practice is thus to let the first partition start at 1M. If grub2 doesn't find enough room it will fail unless -f is used, which will make it use a blocklist. Grub2 can thus not embed itself in 32k MBR unmanaged space and will also not be able to embed itself in the 64k bootloader area of btrfs. That's just how it was designed and that is how it is.
Using a blocklist may be acceptable on ext*, but it's generally not on btrfs as things may move around unless special care is taken. saying that grub2 is the single grand bootloader and should be embedded in the MBR unmanaged area or a special system-global grub2 special partition is not the answer to this. That's only a workaround to a broken design. a) MBR unmanaged area may be needed for other things. b) Bootloaders are pretty core to getting the machine booted, and forcing the main bootloader to be reinstalled on every Fedora installation is not really feasible in multiboot setups. The design with chain loading from the MBR to the boot partition for the active OS (note, not system global) is a proven design that works well. The grub2 documentation says 31K should be sufficient for the boot area, but I suspect you may be right that it's often not. A quick check gives the following sizes for core.img as created by grub2-install ext2: 29237 bytes btrfs: 39951 bytes but even the btrfs core.img size is far below the 64K size of the btrfs boot area and embedding it there as proposed is very feasible. My use case is a multiboot machine with several OS:es installed and an existing system-global bootloader doing the OS selection. I do not want to replace this system global bootloader with grub2. I have up to 2 OS:es installed currently, and could be 3 but one bootable partition i OS less and used for storing install media & boot files on reinstalls. I rarely ever touch the MBR bootloader, which guarantees the system will always be bootable to some of the OS:es even if I totally screw up installing one.
FWIW: I don't necessarily disagree, but I think it should be discussed (and probably developed) upstream ... unless things already has changed there. http://lists.gnu.org/archive/html/grub-devel/2011-05/msg00032.html says: * Add `grub-probe' support for the btrfs filesystem, permitting / to reside on btrfs as long as /boot is on a filesystem natively supported by GRUB.
btrfs is natively supported by grub2-1.99, and having /boot on btrfs do work fine but is unneededly using the fragile blocklist method for loading core.img. not sure on the upstream status of this. But feels like it's almost there.. embedding in the btrfs boot area is pretty much the same as embedding in a GPT bios boot partition except that it's /boot and the grub boot partition is the same. End result the same, but code differ as the GPT boot partition embedding is apparently placed specific to the partitioning model.
I doubt further changes will happen for f16. Have you tested with f17?
have not tested f17 yes. But 2.00-beta2 sources looks very promising.
Can't test f17 easily. btrfs is no longer available in the anaconda partitioning screen.
We could close this with a bold statement that it works in f17, but please try to verify it first - even though it is non-trivial.
IMO this is NOTABUG. ext[234] start at 1024 bytes from the beginning of the partition. XFS and NTFS start immediately at the start of the partition. Just because btrfs has a 64KB blank area at the beginning does not mean this is a bootloader area. Putting bootloaders inside partitions for file systems is way more fragile than block lists. It's like putting a tablespoon of salt carefully on top of the sugar in the sugar bowl. Everything should have it's proper place, and the GRUB2 core.img belongs in the MBR gap on MBR disks; in 'BIOS Boot' on GPT disks on BIOS systems; in 'EFI System' on GPT disks on EFI systems. (In reply to comment #2) > The design with chain loading from the > MBR to the boot partition for the active OS (note, not system global) is a > proven design that works well. A proven design that depends on the MBR gap which you previously referred to as an "unmanaged area". GRUB legacy's stage 1.5 by default was written to this MBR gap, just as GRUB2's core.img is written to this MBR gap. What is the difference? > but even the btrfs core.img size is far below the 64K size of the btrfs boot > area and embedding it there as proposed is very feasible. It's ridiculous. It's always been ridiculous to put boot loaders on partitions. For all the other irritants of UEFI, at least this much is well understood and there is a dedicated partition for boot loaders and a spec for how they are to be organized. > My use case is a multiboot machine with several OS:es installed and an > existing system-global bootloader doing the OS selection. I do not want to > replace this system global bootloader with grub2. Then let it boot linux and don't install grub2 at all.
Works with grub2-2.00-12.fc18.x86_64. 'grub2-install /dev/sda2' installs grub without complaint only to the 64KB zero'd region of a btrfs volume, the resulting btrfs only system is bootable. And this 64KB region is intended for this purpose: http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg20470.html I think this bug can be closed.