[bug #19410] Unable to Create Logical Partition with "partnew" Command

[Steve Burtchin]

URL:
  <http://savannah.gnu.org/bugs/?19410>

                 Summary: Unable to Create Logical Partition with "partnew"
Command
                 Project: GNU GRUB
            Submitted by: sburtchin
            Submitted on: Sunday 03/25/2007 at 09:27
                Category: Disk &amp; Partition
                Severity: Major
                Priority: 5 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: Steve Burtchin
        Originator Email: address@hidden
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 0.97
         Reproducibility: Every Time
         Planned Release: 

    _______________________________________________________

Details:

*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?
<http://www.nabble.com/How-To-Write-Extended-Partition-Tables-from-GRUB--tf2594470.html>.

*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:


eptedit PART SLOT TYPE BCYL BHEAD BSEC ECYL EHEAD ESEC RSEC TSEC


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" =

0 "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.

0 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.

0 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.

0 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.

0 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.

0 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
<http://www.nabble.com/How-To-Write-Extended-Partition-Tables-from-GRUB--tf2594470.html>).
 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?



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Sunday 03/25/2007 at 09:27  Name: PriMastr.png  Size: 22kB   By:
sburtchin

<http://savannah.gnu.org/bugs/download.php?file_id=12283>
-------------------------------------------------------
Date: Sunday 03/25/2007 at 09:27  Name: mbr2std.png  Size: 4kB   By:
sburtchin

<http://savannah.gnu.org/bugs/download.php?file_id=12284>
-------------------------------------------------------
Date: Sunday 03/25/2007 at 09:27  Name: SecMastr.png  Size: 25kB   By:
sburtchin

<http://savannah.gnu.org/bugs/download.php?file_id=12285>
-------------------------------------------------------
Date: Sunday 03/25/2007 at 09:27  Name: b15_std.png  Size: 3kB   By:
sburtchin

<http://savannah.gnu.org/bugs/download.php?file_id=12286>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?19410>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/