Re: Getting Started

["Steve Burtchin" <sburtchin@woh.rr.com>]

On Mon, 07 May 2012 22:25:21 +0200 Vladimir '?-coder/phcoder' Serbinenko
wrote:
> On 02.05.2012 06:27, Steve Burtchin wrote:
> > 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.
> The only difficulty with creating logical partition is a need to have
> some space before partition for pointer. This can be encapsulated into a
> GPT partition of newly defined type. Having same partitions in GPT and
> as logical is of no problem otherwise. parted and gpart can be extended
> to offer creating such buffers when requested.
> . . . in the light of recent developpement
> it's preffered to use GPT for "permanent storage".
I shall set-up a test machine with GPT partitioned disk including extended
parition to see what trade-offs might be needed compared to my current
practice before arguing this point (MBR partitioning) further.  In theory,
two primaries + extended should always be sufficient for any GPT-unaware OS.

> > 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.
> It applies to all kind of MBR workarounds
Your point is well taken.  In practice I only use naturally occuring
partition configurations (which usually includes some "apparent" free
space).  With capacity to mess with partition tables, another user may
create any kind of wierd partitioning arrangement.

> > 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.
> Some features are usable but are a recipe for a disaster in long term
> like e.g. if you move your partitions and forget to change numbers in
> config file. This is like asking people to locate their files by sectors
> or enter the programs in hex manually. Such arrangements should be
> discouraged when better ones are available.
The analogy of "locating files by sector" is a good one.  I will agree with
that, and that changing numbers in a config file is prone to error.  In
defining a truncated extended partition for the LBA-unaware OSs, these are
mostly old and have well understood space requirements.  In practice I never
found the need to move this transition point.  Skipping over some logicals
(to keep Windows from going nuts) on my disk with 39 partitions was a bit
trickier.  The typical worst case after resizing some logicals was that GRUB
Legacy could not find where to write the revised EBR (the "55AAh" wasn't
found, so nothing was written) or wrote an EBR pointing to the wrong sector.
Any user knowing enough of partition tables to mess with the EBRs in the
first place should immediately recognize the problem when half the extended
partition disappears.  However, I will experiment with the possibilities of
creating alternate extended partitions on a GPT disk before arguing this
point further.

> > 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.
> Nobody is forcing anyone to this.
> . . .
> Argument "implement this or you deprive me of my freedom" is an old
> trick and it's not how free software works
"Coercing" would have been a better choice of words, but I see you point.  I
am still free to install GRUB2 to the partition boot sector of any distro
which demands it, and chainload GRUB2 from GRUB Legacy or any other boot
loader I choose.

Regards
Stephen Burtchin