Created attachment 618230 [details] grubinstall debug output 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 Steps to Reproduce: 1. new blank disk 2. gpt partitioned, 1GB linux partition 3. mkfs.ext4 /dev/sdb1 4. 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? Additional info: Attaching --debug file from grub2-install failure. Could be related to Bug 804835.
Hi Chris, so we talked about this in #anaconda, thankfully Matthew Garrett was there and he really understands this stuff (he also pointed to this for reference: https://wiki.archlinux.org/index.php/GRUB2#Install_to_Partition_or_Partitionless_Disk.) Here's my attempt to summarize the issue based on the discussion: - First of all, the filesystem used for /boot shouldn't really matter, so the error/warning message is poorly-worded in that respect. This isn't an ext 2/3/4 specific issue. - So there's two types of hardware you might have; you might have an EFI system or a BIOS sytem. I'm guessing based on all of this that you have a BIOS system with GPT partitions. Here's what happens when you install to /boot for each of these: #1) EFI system EFI systems do not need to embed the bootloader, because the EFI system firmware can read the filesystem. They can simply install it without embedding. No problems there. #2) BIOS system: BIOS systems need to have the bootloader embedded on disk because BIOS firmware cannot read the filesystem. There are two cases for BIOS systems: A) BIOS system with MBR partitions (< 2TB disk) - there's enough space to put the bootloader on disk, so this case is handled okay. B) BIOS system with GPT partitions (2TB+ disk) - there isn't enough space to safely embed grub2 (being much bigger than grub1) at the start of the partition; it has to be put at the start of the disk. However, this poses a big problem if you're trying to set up a multi-boot system, because if you have other OSes installed you're going to necessarily muck with their configuration. Another confounding issue here is that you can only boot off of a primary partition, so if you try to solve the problem by creating a separate BIOS boot partition to write the bootloader to, it needs to be one of the limited primary partitions. If you have any available from your other OS installs. Matthew said he would look into this issue, this is pretty sticky. I'm really glad you pointed it out, I'm hoping we can figure out some kind of solution.
2A = This is a 'grub2-install /dev/sdb' where core.img goes into the MBR gap. It's not an example of installing to a partition. 2B = There is no MBR gap, because the GPT is in that location, which is why BIOS Boot is needed. BIOS Boot can be anywhere on the disk, grub2-install will find it and use it. There is no such thing as primary partitions in GPT. This is also an example of installing grub to a disk, not to a partition that contains a file system. When you say installing grub to /boot that means something like 'grub2-install /dev/sdb[123]' where what would have been installed in the MBR bootstrap code area (first 440 bytes of LBA0), it goes in an equivalent area at the start of the partition. ext[234] have nothing in the first 1024 bytes, so it should be possible to put jump code in there that then points to core.img (?) but it's presently not working no matter what I try. It seems to be a recurring grub2 behavior, in any case. Also, whether my test disk is MBR or GPT formatted, grub2-install --force /dev/sdb1 (i.e. to a partition) always fails with the above message that ext2 doesn't support embedding. It never fails embedding to a whole disk. If the file system is not ext[234] grub does embed successfully, including btrfs (in which case the full 64KB blank gap before btrfs metadata is consumed by embedded grub).
Chris, are you able/willing to pop into #anaconda on freenode right now? Hehe
Bug filed with upstream. https://savannah.gnu.org/bugs/index.php?37454
Block lists successfully produced when not cross-installed to another disk and using --force, using grub2-2.00-5.fc18.x86_64. The cross-installation appears to be the source of the failure in this bug, so it's probably notabug. Additional information/regression: With grub2-2.0-0.38.beta6.fc17.x86_64 block lists failed to be produced with --force under the same conditions (not cross-installed). See upstream bug for more information.
This also happened to me. But after specific the --force option it worked for me.
could it be related? https://bugzilla.redhat.com/show_bug.cgi?id=979805
Re recent activity on this bug report: Background info: When installing to partitions then grub2 can be forced to use blocklists. Blocklists means that grub2-install generates a core.img file, stores it in the filesystem in /boot/grub2, and stores the sector numbers for core.img in the first sectors of the partition. For "simple" filesystems that means that the early boot loader can bootstrap itself by reading sectors, without implementing file systems. The issue in this bug report: 1. ext2 partitions do not have enough free space outside the file system to install the boot loader. It thus had to use blocklists. 2. btrfs is not a simple file system it is thus not possible to refer to core.img just by enumerating sector numbers. 3. The core.img was on another disk than the partition installed to. Just storing sector numbers was thus insufficient - it also needed to be able to find the other disk ... and that is pretty hard (impossible) that early in the boot process. The error messages very thus pretty correct. In the end it was a "user error", trying to do something that for good reasons is unsupported. The summary of this bug report is thus in general not correct. It is just unsupported functionality that is unsupported.