Comment 8 for bug 855871

You've noted that reiserfs and xfs behave differently from ext4 here. The reason for this is that GPT disks ordinarily require you to dedicate a partition to boot loader code (as distinct from the MBR format where boot loader code was often stuffed into unused space in a rather risky way). In your tests, you have not been doing so. This means that GRUB falls back to leaving its core image in the filesystem containing /boot/grub, which it does by computing "block lists" - that is, a sequence of offset/length pairs for each of the blocks on disk making up /boot/grub/core.img - and storing those in the boot sector.

At this point you are in very risky territory. Firstly, GRUB has to check that it can actually read from the filesystem using its own code bypassing the kernel's filesystem code, and historically XFS has not played very well with this; something like that may well be the cause of the specific failure here. Secondly, you're relying on the filesystem not moving blocks around, which is a particularly unsafe assumption with reiserfs but may very well break with other filesystems too. A dedicated boot loader partition is much safer. In bug 856763, you indicate that you thought you were leaving "several megabytes free at the beginning of the disk for the GPT/bios_grub partition", but this *is not what happens* - what is actually happening is that that space is left entirely unused and GRUB falls back to the dangerous blocklist approach instead. It happens to get away with it for ext4, at least for long enough to complete an installation and boot, but that doesn't make it a good idea. You must actually create the partition or it will not be used.

Therefore, based on this reasoning, I intend to fix both this bug and bug 856763 by adding a warning to manual partitioning if you fail to create an EFI System Partition or a BIOS Boot Partition on systems with only GPT disks, as appropriate for the firmware.