Re: Getting Started

[Steve Burtchin]

On Fri, 13 Apr 2012 12:04:26 +0200 Vladimir '?-coder/phcoder' Serbinenko
wrote:
> On 13.04.2012 11:39, Steve Burtchin wrote:
> > On Tue, 10 Apr 2012 14:26:54 +0200 Vladimir '?-coder/phcoder'
> > Serbinenko wrote:
> > >On 10.04.2012 12:56, Steve Burtchin wrote:
> > >> I found the URL to the bug report.  It is
> > >> http://savannah.gnu.org/bugs/?19410.  In summary (and more
> > >> specifically), I wish to add the following features to the GRUB2
> > >> 'parttool' command:
> > >>
> > >> 1) Create or delete a primary partition.  This functionality was
> > >> provided by the 'partnew' command in GRUB Legacy.  See also
> > >> http://savannah.gnu.org/bugs/?19389.

> > I was using the terminology from the GRUB legacy manual:
> > "partnew . . . Create a new primary partition."  IMHO this would be
> > more appropriately described as "Edit a slot in the MPT
> Please stop inventing your own shortcuts, it makes it difficult to read
> and understand you.
Please accept my appologies.  These shortcuts are frequently used on many
computing forums, but I should not have assumed that they were being used
here.  I shall refrain from their use in the future.  For the reference of
anyone following this thread:
IMHO - In My Humble Opinion (although "IMO" has been used here - ref: Vol
98, Issue 18)
MHO - My Humble Opinion
JMHO - Just My Humble Opinion
MPT - Master Partition Table (widespread usage)
"slot in MPT" = "master partition table entry"
wrt. - with respect to
EPBR = PBR - Extended Partition Boot Record (widespread usage)
HDD - Hard Disk Drive
EPT - Extended Partition Table (same as PBR) (PowerQuest terminology - not
in widespread use)
AFAIK - As Far As I Know

> > (to define an alternate primary partition)."  The corresponding
> > terminology ("delete") would IMHO be more appropriately described as
> > "Zero a slot in the MPT (to thoroughly hide a primary partition from
> > aggressive installers)."  For example, suppose I want to install
> > WindowsXP to hda3.  The safest approach would be to create a menuitem
> > in grub.cfg to zero out slots 1, 2 & 4 of the MPT, and then boot the
> > CD.  The installer then only sees one partition with the rest being
> > free space, for which it will ask you before overwriting it.
> Not true. Some installers take free space to silently create some
> partitions it believes should be "always present". Moreover most of
> concerned OS ignore partitions with unknown type so just setting hidden
> flag is enough.
I am sure you are far more knowledgeable in regards to installers than I am.
I have personally been the victum of aggressive installers messing with
defined partitions, and I have read the horror stories of many others, but I
should not have assumed the converse situation was not also a problem.  In
the future, when in doubt, I will leave the partition definitions in place
(when installing OSs).  And of course, always have everything backed-up.
Thank you for this information.

Now that you have pointed this out, would it not be true that except in two
special cases {that is: where the three partitions (other than the '0xEE')
defined
in the hybrid protective MBR are either (physically) the first three or last
three
on the disk} the installer of any GPT-unaware OS would always perceive
there to be some free space on the disk?  {this assumes 'gptsync' modifies
the hybrid MBR in an intelligent way (explained next paragraph)}  It is
beyond my expertise to say
if this is a problem, but as you pointed out, some installers may silently
use any area they believe to be free space.

If the hybrid MBR is modified in an intelligent way by 'gptsync', IMO the
partition of type '0xEE' would ideally span as much of
the space as possible not included in the other three primary partition
entries.  With 'gptsync' as it is described in the GRUB2 manual, what is not
clear to me is how (or if) this entry is kept consistent.  Migrating the
GRUB Legacy
'partnew' functionality to GRUB2 would provide one possibility for dealing
with this issue.

What is worse IMO is an inconsistent hybrid MBR where the '0xEE' entry spans
the entire disk and overlaps the other three entries.  This is the
implication as 'gptsync' is described.  Any unsuspecting user may try to use
a utility that automatically "fixes" something it thinks is amiss.

> >
> >  the intended use of my
> > proposed new functionality (wrt. item 1) would be esentially identical
> > to that of the 'gptsync' command, the only difference being that the
> > source of the MPT data would reside in 'menu.cfg' rather than in the
> > GPT partition entries.
> You need partition table in the first place in order to access grub.cfg
> (and it's not menu.cfg).
In my haste I was conflating GRUB Legacy with GRUB2.  My sincere apologies.

Thank you for pointing this out.  In my case, I have a small FAT partition
at the beginning of the disk containing all the GRUB Legacy files.  This
partition (by necessity) remains defined in all boot configurations.  One
would never want
to delete the partition (table entry) containing 'grub.cfg', else GRUB2
would not be able to find it on the subsequent
boot.  The other partition table entries may be changed as appropriate.

I also have GRUB Legacy
installed to a floppy with a special 'menu.lst' residing on
the floppy that can be used to restore the partition
tables in the event of a disaster.  IMO this functionality (not currently in
GRUB2) is a valuable (and safe) asset for recovery if ever the partition
tables get corupted.

> > >>
> > >> 2) Edit extended partition tables (EPBRs).  This functionality was
> > >> added to GRUB Legacy with the 'eptedit' command as described in bug
> > >> report #19410.
> > >>
> > > I feel like improvements into our gptsync (i.a. support for creating
> > > secondary partitions when possible) solves the same problems (having
> > > more than 4 OS requiring primary partitions) but in a more
standartised
> > > way and with a benefit of that GPT-aware tools will handle the whole
> > > thing correctly.
> >
> > It is entirely true that with a GPT partitioned disk and 'gptsync' one
> > could setup GRUB2 to boot more than 100 GPT-unaware operating systems
> > each requiring its own primary partition to boot.  However, in
> > practice this is severly restrictive in the great majority of
> > computers sold for home use (and business workstation computers) which
> > have only one HDD.  With only one HDD, this leaves only two other
> > partitions for sharing and storing data for GPT-unaware OSs.
> As I said: I'd rather add a support for creating extended partitions in
> protective MBR.
Assuming such support is added, this would allow for a few or more
specialized logical partitions that could have shared usage between the
GPT-unaware OSs.  However, this extended partition would not be usable by
any GPT-aware OS unless each logical partition has a duplicate definition in
the GPT.  It is beyond my expertise to say if this is practical or supported
by any partitioning software.

I was unaware any partitioning tool supported this (ie. creating an extended
partition in the protective MBR), and still not convinced such a hybrid
state would be safe for unsuspecting users (ref:
http://www.rodsbooks.com/gdisk/hybrid.html).  I do not have first hand
knowledge to say if this is a potential problem,
but quoting from the referenced link: "There's no telling how some random
disk utility will react to a hybrid MBR; it's conceivable that something
intended to rescue your data will end up destroying it." (Rod Smith).

Except as just stated, I have no concerns with using such a partitioning
scheme, but have my
concerns for leaving the protective MBR in a pseudo-random hybrid state
(that is determined by the most recent boot configuration) to
be seen by utilities or OS's that may think something is amiss and then try
to fix.

If it is the vision for GRUB2 to support an extended partition in the hybrid
MBR, then in my humble opinion the ability to edit an EBR at boot time would
be a desirable feature.  If one wants to share such an extended partition
between LBA-aware and LBA-unaware OSs, then it is an essential feature IMO.

You cut off reading my previous message at this point.  I know that I made
some false assumptions, but I would only hope that you would
reconsider my previous message in its totality.

As I stated in my previous message: "in a single disk system, and in systems
where the second HDD is > 2TB, it is MHO (my humble opinion) that the
superior arrangement would be to have the first HDD (hard disk drive) MBR
partitioned.  In these systems (the greater majority in existence today)
this provides the greatest amount of flexibility in terms of the quantity of
common partitions available to all GPT-unaware and GPT-aware OSs (and
GPT-unaware imaging tools)."

#########################################################

The GNU Project defines free software as having four essential freedoms.  In
'The Free Software Definition' (ref:
http://www.gnu.org/philosophy/free-sw.html) 'freedom 0' is defined as "The
freedom to run the program, for any purpose".  This is further clarified as
follows:

"The freedom to run the program means the freedom for any kind of person or
organization to use it on any kind of computer system, for any kind of
overall job and purpose, . . .  In this freedom, it is the user's purpose
that matters, not the developer's purpose; you as a user are free to run the
program for your purposes, and if you distribute it to someone else, she is
then free to run it for her purposes, but you are not entitled to impose
your purposes on her."

By limiting GRUB2 support to GPT
disks for users wanting more than 4 primary partitions, you are forcing them
to migrate to GPT partitioning even if they are not running any GPT-aware
OSs or have no other reasons to migrate.  You are also denying these users
the right to choose when to abandon use of their favorite partitioning,
imaging, and other utilities.  In essence the 'developer's purpose' is being
imposed on some users of GRUB2, forcing them to make changes in the way they
do their partitioning, imaging, data management, etc.  It is understandable
that in the release of a new software product, it may not initially contain
every feature a user may want or need, and the development team may have to
prioritize its resources.  However, when an outsider such as myself is
willing to donate support for configurations still in widespread usage, and
such support is mandated by your own stated philosophy, I do not understand
why you would not accept the offer.

> -- 
> Regards
> Vladimir '?-coder/phcoder' Serbinenko

Cordially
Stephen Burtchin