2

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.

Pablo
  • 430
  • 2
  • 9
Jepsenwan
  • 160
  • 3
  • 11

2 Answers2

3

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!

Pablo
  • 430
  • 2
  • 9
  • It does help me get the point. Thanks. I was wondering – Jepsenwan Jun 22 '17 at 12:28
  • I was wondering if we can find the core.img in a running Linux system. Thanks. – Jepsenwan Jun 22 '17 at 12:29
  • I use Debian mostly, that packages all grub images here: `pkg -l | grep grub | awk '{ print $2 }' | xargs dpkg -L | grep .img`: In `/usr/lib/grub//`, with `` being `i386-pc`, `x86_64-xen`, etc. – Pablo Jun 24 '17 at 14:47
1

GRUB can be installed on both GUID Partition Table (GPT, both BIOS & UEFI) and Master Boot Record (MBR, BIOS only). Therefore, the type of the partition wasn't the problem here.

This is what actually happened:

  1. When the partition was removed, the GRUB was removed along with it.
  2. When the partition was recreated, it was created as an empty partition.
  3. The grub-install installed GRUB to this empty MBR/GPT partition based on configuration in /boot/grub/grub.cfg. This configuration was possibly generated with grub-mkconfig i.e. simple configuration from settings in /etc/grub.d/.
Pablo
  • 430
  • 2
  • 9
Esa Jokinen
  • 43,252
  • 2
  • 75
  • 122
  • 1
    CAUTION: It is true that GRUB can be installed on both partition types. BUT, the partition table change from DOS disklabel to GPT will probably mess with GRUB and was the reason for the problem shown here: GRUB2 `stage1.5` on MBR partitions is usually located on the first empty sector after the MBR, and that sector is where the GPT partition starts, so the change overwrote it. – Pablo Jun 23 '17 at 14:14
  • 1
    It would have been more correct to say that the partition type didn't **cause** the problem. – Esa Jokinen Jun 23 '17 at 14:32