https://bugzilla.novell.com/show_bug.cgi?id=841247
https://bugzilla.novell.com/show_bug.cgi?id=841247#c16
--- Comment #16 from Chris Murphy
We don't modify upstream grub-install so probably some fedora patches make the difference ?
Uncertain, I don't know the last time I even tested --force on Btrfs. Long time. Maybe with 2.02-beta I'll try it but it's a weird use case IMO, and wow what a hassle to support this long term.
Also, GRUB upstream prefers the use of a 1MB MBR gap or BIOS Boot over the 64KB Btrfs bootloader pad.
IF your operating system too old (like Windoze XP) the partition tool with partition in cylinder bounties and the size is determined by sectors per track. In most case it's 63 sectors and you have only 32kB to use, far less than 1MB.
Yeah I understand. No matter what it means something must make use of the Btrfs bootloader pad: extlinux does this explicitly by design, and GRUB2 does it without complaint even though its devs prefer putting it somewhere else.
(it looks typically like comment#4). Plus the logical partition makes the situation even worse .. (the logical partition and bootloader pad in it can't be chainloaded by mbr directly ..).
I don't know if grub2 has an option for this, but boot.img always points to an LBA. It's only a jump command, it doesn't tell the BIOS to "check MBR for partition with active flag and go there". It seems to me it should be possible to put boot.img in the MBR (wipe out the Windows stage1 bootloader) which then points to the LBA for core.img which is e.g. /dev/sdb6 +2 (2nd sector in that partition is the start of core.img, while the 1st sector is boot.img). -- 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.