No replies to this topic

[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?

 

 

[Wonko the Sane]

It is entirely possible that grub4dos scans the GPT partition table until it finds an empty slot and then stops (but if it does that, it should be corrected).

 

The 128 is just a "default" number, different OS's or programs may use a different amount.

 

In the GPT specifications there is a field that indicates the number of partitions in the whole GPT (actually more like the "reserved size" of the GPT in sectors), there were some experiments done on this, here:

http://reboot.pro/in...showtopic=22553

that were not finalized,

 

In theory grub4dos (or any program) should read that size and parse all entries within that, no matter if there are "holes".

 

If it stops reading at the first empty slot, that is a bug that should be reported.

 

Wonko

[Mythenadia]

Just posted this as a possible bug on chenall's github grub4dos site.