First: The problem described in this bug report has been solved (by creating the "eptedit" function) and thoroughly tested by me on my Compaq Deskpro EN. For reference see How To Write Extended Partition Tables from GRUB?.

Second: I would have thought this to be a feature request, but . . . from the GRUB Legacy Patch Submission Policy:

"If your system is technically impossible to be booted only with existing features and your patch addresses that problem, it is a bugfix."

So maybe this is a bugfix - ??? - I'll let someone else decide that.

Third: If GRUB Legacy maintainers want to classify this as a new feature, I will gladly volunteer my time to become a maintainer for the "eptedit" function.

Why I Need to Create Logical Partitions

The attached files "PriMastr.png" and "SecMastr.png" show the partition layouts for the three HDD's used in my flexible multiboot system. What is obvious is that there are much more than four Primary partitions defined for each of the internal HDD's. The highlighted Primary partitions are standard. The others can be swapped for the standard ones to address specific boot situations. Note also, that this multiboot includes at least two 'non-LBA aware' operating systems, and that the standard Extended partition continues past the 1024th cylinder. The Extended partition on the second HDD also contains three Logical partitions dedicated as 'scratchpads' for sharing data between all operating systems, so it is essential that these three Logical partitions are visible to all of them. The only way this is possible without risking the potential for data corruption, is to define a smaller Extended partition for the 'non-LBA aware' operating systems. I also want to have the DOS5 and Win3.1 partitions contained within the Extended partition, rather than defined as Primary partitions, because this makes it much more convenient for making image backups (as opposed to creating a custom boot configuration to image each OS partition).

How It Will Be Used (Mostly, but see "Other Potential Uses")

The attached file "mbr2std.png" shows what the MPT of the second HDD should look like when booting most of the 'LBA aware' OS's. In this situation, the file "b15_std.png" shows the EPT that should be found at LBA 7680960.

The attached file "mbr2dos5.png" shows what the MPT of the second HDD should look like when booting MS-DOS 5.0, and the file "mbr2Win3.png" shows what the MPT of the second HDD should look like when booting Windows 3.1. In these situations, the file "b15_old.png" shows the EPT that should be found at LBA 7680960. Note that the DOS5 and Windows 3.1 partitions are defined as both Primary and Logical partitions in this configuration. I could have redefined the start of the Extended partition for these two OS's, but the documentation was made simpler by just hiding the Logical definitions (this seems to have no ill effects).

The most significance differences between these two situations is the size of the Extended partition, and the EPT at LBA 7680960. The "partnew" command is used to fix the MPT. The "eptedit" command is used to zero out the second slot of the EPT at LBA 7680960 for booting MS-DOS 5.0 and Windows 3.1, and to put the data back into this EPT for booting the 'LBA aware' OS's. See the file "MenuItms.txt" for excerpts from my "menu.lst".

You may be wondering why the "geometry" function is called within my "menu.lst" file. In the process of testing this new function, I discovered another bug: GRUB apparently forgets at least some of the geometry information. When the "eptedit" function performs validation checks on some of the input parameters, a check against invalid information in memory results in "Error 18". Issuing the "geometry" command refreshes the geometry information for the disk, and avoids the error. I could easily avoid the error by not performing input data validation, but I don't like hiding problems.

The Patch

The syntax is like this:

Most parameters are easily calculated or obtained with freeware utilities. "SLOT" can be "C" (current) or "N" (next). "PART" and "TYPE" are as for the "parttype" function.

Most of the new "eptedit" function is based on code borrowed from the "parttype" and "partnew" functions. See the attached "builtins.c" file.

Other Potential Uses for "eptedit"

1. "eptedit" can be used to avoid the DOS/Win9x "last logical partition" bug. These os's must see the last logical partition as FAT/FAT16/FAT32 or data corruption could result. If you wish to format the last logical partition as something else, then the same solution can be applied such that DOS/Win9x see a shorter extended partition ending in one of these recognized file systems.

1. If you want to thoroughly hide a Logical partition (rather than just changing the filesystem type), you could use "eptedit" to edit the 'Next' slot of the previous EPT to jump past it. Then it would appear to be unpartitioned space within the Extended partition.

1. I have found that some Microsoft operating systems can get confused in certain situations when there are too many Logical partitions. By jumping over one or more Logical partitions as explained previously, the number can be effectively reduced. I had to do this with manual disk edits the last time I migrated to new HDD's. I could have saved a lot of tedious work if I had had "eptedit" at that time.

1. Many older operating systems cannot see past 128GiB. Having an Extended partition stradling this limit can lead to filesystem corruption with these older OS's. "eptedit" could be used for them in the same way that I use it now to prevent DOS5 and Win3.1 from seeing past the 1024th cylinder.

1. Another situation deals with data recovery. If the partition tables happen to become corrupted, fixing these errors can be the first and best step to data recovery. There are tools for doing this, but a much quicker approach would be to add a "Restore All Partition Tables" selection to the GRUB menu. This is easily scripted in "menu.lst" using a combination of "partnew" and "eptedit" commands.

1. I have not tested this yet, but I think it should be possible to parition a HDD from a bootable GRUB floppy or CD by using a combination of "partnew" and "eptedit" commands - just by pressing <Enter>! The required "menu.lst" is very easy to create (see Re: How To Write Extended Partition Tables from GRUB? - sburtchin Feb 1, 2007; 11:51pm). I will post back my test results.

What Next?

I will agree to maintain the "eptedit" function if that is necessary.

I should write the information for the GRUB Manual. What file do I edit for that?

Can someone help me get started writing ChangeLog? Is there a template or standard format I have to follow?

What other files do I need to attach to this bug report?

What do I have to do to get the "eptedit" function into GRUB 2. Is it stable enough yet that I can test it on my working computer? How do I get involved with GRUB 2 development?