Both grub4dos and grub4UEFI can't see partitions beyond a deleted partition on GPT drives

[Mythenadia]

Please bear with me. It's been years since I've posted here.

Both grub4dos and grub4UEFI can't see partitions beyond a deleted partition on GPT drives.

Take a drive with a GPT partition table and create 5 partitions on it.

Install grub4dos or grub4UEFI on the first partition (hd0,0) and boot it.

From a grub4dos command line, the "find" command returns:
(hd0,0)
(hd0,1)
(hd0,2)
(hd0,3)
(hd0,4)

Next, delete the 3rd partition (hd0,2) and reboot grub4dos.

From a grub4dos command line, the "find" command now returns:
(hd0,0)
(hd0,1)

No attempts to access (hd0,3) or (hd0,4), which still exist, from grub4dos are successful.

Is this a bug in grub4dos/grub4UEFI?

Can anyone else reproduce this?

Should grub4dos scan all 128 GPT partition table entries to find partitions?

[yaya2007]

How to delete it, please explain in detail

[Mythenadia]

In more detail:

Boot a live Linux distro from USB (I used Porteus in this example).

Run gparted.

Set up a GPT partition table on a hard drive.

Create 5 partitions on the hard drive, sda1 thru sda5.

Make the first partition grub4dos-compatible, like fat16 or fat32.

The partition types of the remaining 4 partitions does not matter (I used ext2).

Install grub4dos on the first partition and make it bootable (I copied over grub4dos files, ran bootlace.com, and made sure a grub4dos command line option existed in menu.lst).

Shut down Linux.

Boot the hard drive (grub4dos) and go to the grub4dos command line.

The "find" command returns:
(hd0,0)
(hd0,1)
(hd0,2)
(hd0,3)
(hd0,4)

Shut down grub4dos and reboot Linux from USB.

Run gparted and delete the third partition (sda3 in Linux, (hd0,2) in grub4dos).

In Linux you can still see and mount the remaining 4 partitions:
sda1
sda2
sda4
sda5

Shut down Linux and boot the hard drive (grub4dos) as before.

The "find" command from a grub4dos command line returns only:
(hd0,0)
(hd0,1)

The still-existing partitions (hd0,3) and (hd0,4) are not visible.

[yaya2007]

There is no problem using DiskGenius to delete partitions.
Perhaps gparted is not working properly, it deleted partition item 3 and did not move partition items 4 and 5 earlier, forming a hole.

[a1ive]

There is no problem using DiskGenius to delete partitions. Perhaps gparted is not working properly, it deleted partition item 3 and did not move partition items 4 and 5 earlier, forming a hole.

grub4dos/stage2/disk_io.c

Lines 769 to 795 in f036076

	static unsigned int gpt_part_max;
	static int next_gpt_slice(void)
	{
	redo:
	if (++pc_slice_no >= gpt_part_max)
	{
	errnum = ERR_PARTITION_LOOP;
	return 0;
	}
	grub_u64_t sector = *next_partition_entry + (pc_slice_no >> 2);
	if (! rawread (next_partition_drive, sector,(pc_slice_no & 3) * sizeof(GPT_ENT) , sizeof(GPT_ENT), (unsigned long long)(unsigned int)next_partition_buf, 0xedde0d90))
	return 0;
	P_GPT_ENT PI = (P_GPT_ENT)(unsigned int)next_partition_buf;
	if (PI->starting_lba == 0LL /*|| PI->starting_lba > 0xFFFFFFFFL*/)
	{
	errnum = ERR_NO_PART;
	return 0;
	}
	//skip MS_Reserved Partition
	if (memcmp(PI->type.raw,"\x16\xE3\xC9\xE3\x5C\x0B\xB8\x4D\x81\x7D\xF9\x2D\xF0\x02\x15\xAE",16) == 0 && next_partition_dest == 0xffffff)
	goto redo;
	*next_partition_start = PI->starting_lba;
	*next_partition_len = (unsigned long long)(PI->ending_lba - PI->starting_lba + 1);
	*next_partition_partition = (pc_slice_no << 16) | 0xFFFF;
	*next_partition_type = PC_SLICE_TYPE_GPT;
	return 1;
	}

If an empty partition entry is encountered, it should be skipped instead of ending the search until the number of partitions matches the number of partitions recorded in the GPT header.

[yaya2007]

判断逻辑是有点问题。windows下删除分区会移动后面的分区项。
可以修复。

一般是扩大缩小分区，或者格式化分区，不清楚删除分区为哪般。

[Mythenadia]

Is moving subsequent partition entries down after deleting a partition in the middle a requirement of the GPT specification?

[yaya2007]

This is not clear. But Linux adaptation and Windows development projects are strange and innovative.