Comment 6 for bug 1652332

In your original report, you said "in the root partition". The technique we use on MBR disks is to write the GRUB core image *outside* any partition, in the area before the first partition sometimes called the "boot track" or the "embedding area". This is at least safe against being rearranged by file system implementations, as I noted above.

But having the boot loader's code outside any partition has its problems. It means that the space in question isn't clearly allocated for use by the boot loader, so it's possible for it to be capriciously overwritten by something else that decides to make use of an unallocated area of disk. (Such software in fact exists, and has resulted in quite a few very strange bug reports. GRUB has to take some quite exotic defensive measures against it.) The reason that we don't normally use a partition on MBR disks despite this problem is that the MBR format has rather restrictive rules for partitions, especially if you're trying to install the OS on a system that already has some other OS installed, and it works out better to avoid using a whole partition just for the boot loader.

GPT has much more sensible partitioning rules, and it's straightforward to just use a partition there. This gets us the best of both worlds: we don't have to worry about our bits being overwritten by other software (malicious or otherwise - I've seen both) that writes into the area before the first partition, and we don't have to worry about them being moved around by a file system implementation because that partition is just raw and doesn't contain a file system. In a way it is a bit like the behaviour you observe on MBR disks, except it's better: rather than hoping that nobody else will write into the same area of disk, we require that it be made it clear in the partition table which area of disk we're using.

So it is true that it would be technically possible to return GPT disks to the prior practice from MBR disks of not bothering to indicate in the partition table what area of disk we're using and just picking an area that's unlikely to be used by anything else; but it would be a step backwards, and so we won't do that.