https://bugzilla.novell.com/show_bug.cgi?id=841247
https://bugzilla.novell.com/show_bug.cgi?id=841247#c12
--- Comment #12 from Chris Murphy
(In reply to comment #9)
On Btrfs --force always fails as blocklists are not supported by GRUB on Btrfs.
It will not be *always* fail but the fallback (blocklist) installation will.
I've tried it dozens of times, maybe close to a hundred, in various configurations and it always fails to install to a partition formatted either Btrfs or XFS.
The --force provides nothing useful for Btrfs. (But some other file systems like extX could fallback to blockslist via --force if installing on a vbr)
Seems like it's only used for ext, which GRUB upstream actively recommends not doing because they consider it fragile. ext devs think this is overly cautious. And syslinux devs think its the only correct way to boot a system (i.e. use of the MBR gap is a hideous practice). I think better than --force on ext would be to use --grub-setup=/bin/true which causes core.img to be created, without stepping on the MBR, MBR gap, or VBR. And then the first bootloader points to core.img: grub legacy use the kernel command, and syslinux/extlinux and grub2 use the linux command. Blocklists not required, and still works even if core.img is overwritten, moved, or defragmented.
We need the log to know what's really happened. I just had some information from YaST team that MBR is proposed by default for btrfs (which might contribute to this error).
Yeah I'm still not sure why that matters if grub2-install /dev/sdXY. If pointed to a partition, grub2-install without --force always works, and with --force never works. Regardless of MBR or GPT, whether or not there is a small or large MBR gap, whether or not there is a BIOS Boot partition. Also, GRUB upstream prefers the use of a 1MB MBR gap or BIOS Boot over the 64KB Btrfs bootloader pad. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.