Linux – Grub-install actually doing

gptgrublinuxpartition

I have a client who accidentally converted the partition table of one of their Linux system from DOS to GPT. Unfortunately, the GRUB version is 2, and the system didn't have a BIOS boot partition for the additional boot loader code to reside in.

Then the following steps were used to fix it:

  1. Add a BIOS boot partition to the boot disk.
  2. Reinstall the grub application for the disk.

Afterwards, the system can boot normally now.
There was one point that I could not figure out, please help.

I first tried adding a BIOS boot partition to the boot disk, but the system didn't work either. As soon as the GRUB was reinstalled, it could boot well…

Would anyone please figure out whether or not the re-installation involves storing part of the GRUB 2 code into the BIOS boot partition? Thanks.

Best Answer

There is a good explanation here, and here is my brief summary:

Both GRUB Legacy (GRUB1) and GRUB2 have a "two stage" three-staged boot process (pun intended).

The first stage (stage1) lives in the MBR, and I think it was not harmed by the switch to GPT in you case, as it lives on the first sector of the disk, before any partition table.

Most often on DOS partition setups, stage1 loads a stage1.5 (the reason for the pun above). On a MBR partition (or DOS disklabel), that stage is written on the empty sectors after the partition table, before the first actual partition data starts. See the upper part of this graphic.

As creating a GPT partition table involves creating a "Protective" MBR, that wiped out you stage1.5. This protective partition table exists to avoid a legacy partition tool destroying a GPT table it does not know about.

Obviously, stage1.5 is the one that load modules, understands partitions, search for filesystems, and executes the configuration script to looks for stage2.

This last stage is the one that knows how to boot all kind of kernels, and lives on the /boot/grub directory of some filesystem, on a official partition.

The grub-install process in you case just injected a stage1.5 (core.img) in the new place when a GPT table is used: a partition with BIOS_grub flag. See the lower part of that image.

Depending on the disk geometry and partition software, it can sometimes put it after the GPT table, before the first partition, but that is quite rare.

Hope it helps!

Related Topic