Thu 27 Sep 2012 09:35:14 PM UTC, original submission:
Description of problem:
grub2-install /dev/sdb1, with or without --force, fails to install to ext[234] formatted partitions.
Version-Release number of selected component (if applicable):
grub2-2.00-5.fc18.x86_64
How reproducible:
100% for ext4, i.e. /boot on its own partition formatted as ext4
Steps to Reproduce:
1. new blank disk
2. gpt or mbr partitioned, 1GB
3. mkfs.ext4 /dev/sdb1
4. Either
grub2-install /dev/sdb1
grub2-install --force /dev/sdb1
Actual results:
/usr/sbin/grub2-bios-setup: warning: File system `ext2' doesn't support embedding.
/usr/sbin/grub2-bios-setup: error: filesystem `btrfs' doesn't support blocklists.
To test if there were file system changes, before grub2-install:
hexdump -C /dev/sdb1 > beforegrubinstall.bin
After grub2-install:
hexdump -C /dev/sdb1 > aftergrubinstall.bin
After grub2-install --force:
hexdump -C /dev/sdb1 > aftergrubforceinstall.bin
diff says these files are identical.
Expected results:
Unsure. History says it's possible to install grub this way but perhaps we're supposed to place core.img on /dev/sdb1 and then chainload or multiboot it? Documentation could be more clear on alternatives if installing to a partition is not recommended; the idea is how to avoid stepping on a legacy bootloader the user may want to retain, in multi-boot scenarios.
Additional info:
Attaching --debug file from grub2-install failure.
On irc.freenode.net #grub Jordan_U suggested: "grub-install shouldn't fail just because we don't have an embedding area (even if we think users should, and can, avoid this)."
Original bug filed against Fedora 18:
https://bugzilla.redhat.com/show_bug.cgi?id=861192
|