[Bug 841247] New: Grub2 fails with btrfs
https://bugzilla.novell.com/show_bug.cgi?id=841247 https://bugzilla.novell.com/show_bug.cgi?id=841247#c0 Summary: Grub2 fails with btrfs Classification: openSUSE Product: openSUSE Factory Version: 13.1 Beta 1 Platform: i586 OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: jw@suse.com QAContact: jsrain@suse.com Found By: --- Blocker: --- After an apparent successful package installation, I get the following error message: Error occured while installing GRUB2. /usr/sbin/grub2-bios-setup: warning: your core.img is unusually large. It won't fit in the embedding area. /usr/sbin/grub2-bios-setup: error: filesystem `btrfs` doesn't support blocklists. [OK] -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=841247
https://bugzilla.novell.com/show_bug.cgi?id=841247#c1
--- Comment #1 from Mitsutoshi NAKANO
https://bugzilla.novell.com/show_bug.cgi?id=841247
https://bugzilla.novell.com/show_bug.cgi?id=841247#c2
Volker Barth
https://bugzilla.novell.com/show_bug.cgi?id=841247
https://bugzilla.novell.com/show_bug.cgi?id=841247#c3
Mitsutoshi NAKANO
sudo /sbin/fdisk -l
Disk /dev/sda: 64.4 GB, 64424509440 bytes, 125829120 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: dos Disk identifier: 0x00097001 Device Boot Start End Blocks Id System /dev/sda1 * 63 2056319 1028128+ b W95 FAT32 /dev/sda2 2058240 125829119 61885440 f W95 Ext'd (LBA) /dev/sda5 2060288 5124095 1531904 82 Linux swap / Solaris /dev/sda6 5126144 53770239 24322048 83 Linux /dev/sda7 53772288 125804543 36016128 83 Linux -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=841247
https://bugzilla.novell.com/show_bug.cgi?id=841247#c4
--- Comment #4 from Mitsutoshi NAKANO
sudo /sbin/fdisk -l Disk /dev/sda: 64.4 GB, 64424509440 bytes, 125829120 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: dos Disk identifier: 0x0001c622
Device Boot Start End Blocks Id System /dev/sda1 63 2056319 1028128+ b W95 FAT32 /dev/sda2 * 2058240 125829119 61885440 f W95 Ext'd (LBA) /dev/sda5 2060288 5302271 1620992 82 Linux swap / Solaris /dev/sda6 5304320 47247359 20971520 83 Linux /dev/sda7 47249408 125804543 39277568 83 Linux sda[67] are ext4 . -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=841247
https://bugzilla.novell.com/show_bug.cgi?id=841247#c
Ye Yuan
https://bugzilla.novell.com/show_bug.cgi?id=841247
https://bugzilla.novell.com/show_bug.cgi?id=841247#c
Jiri Slaby
https://bugzilla.novell.com/show_bug.cgi?id=841247
https://bugzilla.novell.com/show_bug.cgi?id=841247#c5
Chris Murphy
https://bugzilla.novell.com/show_bug.cgi?id=841247
https://bugzilla.novell.com/show_bug.cgi?id=841247#c6
--- Comment #6 from Juergen Weigert
https://bugzilla.novell.com/show_bug.cgi?id=841247
https://bugzilla.novell.com/show_bug.cgi?id=841247#c7
--- Comment #7 from Chris Murphy
https://bugzilla.novell.com/show_bug.cgi?id=841247
https://bugzilla.novell.com/show_bug.cgi?id=841247#c8
--- Comment #8 from Michael Chang
https://bugzilla.novell.com/show_bug.cgi?id=841247
https://bugzilla.novell.com/show_bug.cgi?id=841247#c
Michael Chang
https://bugzilla.novell.com/show_bug.cgi?id=841247
https://bugzilla.novell.com/show_bug.cgi?id=841247#c9
--- Comment #9 from Chris Murphy
The grub2-install will try to embed boot.img and core.img in favor of blocklist regardless --force afaics.
On Btrfs --force always fails as blocklists are not supported by GRUB on Btrfs.
The question is why the 64kB bootloader area can't hold the grub2 images ?
Right, we'd need to see logs to see what grub2-install is complaining about. My suspicion is that the installer calls grub2-install with --force by default, not merely as a fallback.
Meanwhile his mbr gap is too small, we need his yast2 log to know whether or not other options (like enabled lvm) takes place then mbr is suggested location by installation then failed ...
Even if the MBR gap is too small it wouldn't matter in the case of embedding to the 64KB Btrfs bootloader pad, since the MBR gap isn't used at all in this case. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=841247
https://bugzilla.novell.com/show_bug.cgi?id=841247#c10
--- Comment #10 from Michael Chang
(In reply to comment #8)
The grub2-install will try to embed boot.img and core.img in favor of blocklist regardless --force afaics.
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. 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)
The question is why the 64kB bootloader area can't hold the grub2 images ?
Right, we'd need to see logs to see what grub2-install is complaining about. My suspicion is that the installer calls grub2-install with --force by default, not merely as a fallback.
Meanwhile his mbr gap is too small, we need his yast2 log to know whether or not other options (like enabled lvm) takes place then mbr is suggested location by installation then failed ...
Even if the MBR gap is too small it wouldn't matter in the case of embedding to the 64KB Btrfs bootloader pad, since the MBR gap isn't used at all in this case.
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). -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=841247
https://bugzilla.novell.com/show_bug.cgi?id=841247#c11
--- Comment #11 from Michael Chang
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.
https://bugzilla.novell.com/show_bug.cgi?id=841247
https://bugzilla.novell.com/show_bug.cgi?id=841247#c13
--- Comment #13 from Chris Murphy
/var/log/YaST2/y2log_bootloader 2>&1 - ret 0 + output: Installation finished. No error reported.
Clearly YaST2 uses --force by default, so there must be something different between openSUSE and Fedora forks for GRUB2 because --force definitely doesn't work on Btrfs with the Fedora one. I can confirm the MBR, and MBR gap do not have grub boot.img or core.img in them, while sda6 contains both. The core.img size is 38863 which easily fits in the Btrfs 64KB bootloader pad. Anyway, still need /var/log/YaST2/y2log from the OP or someone who can reproduce the failure. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=841247
https://bugzilla.novell.com/show_bug.cgi?id=841247#c14
--- Comment #14 from Michael Chang
https://bugzilla.novell.com/show_bug.cgi?id=841247
https://bugzilla.novell.com/show_bug.cgi?id=841247#c15
--- Comment #15 from Michael Chang
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.
We don't modify upstream grub-install so probably some fedora patches make the difference ?
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).
We know it's not recommended by upstream. The reason is historical because we need to support existing setups installed by our installer. And we has been proposing partition in favor of MBR since legacy grub era (or even lilo) in sake of better multi-boot compatibility with other distributions via chainloading (there's no os-prober in that age, and os-probe has it's own problems). The --force is therefore required in order to install to a partition (using blocklists if the file system did not have bootloader pad).
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. (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 ..). -- 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.
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.
participants (1)
-
bugzilla_noreply@novell.com