|
From: | Steve Burtchin |
Subject: | Re: Getting Started |
Date: | Fri, 13 Apr 2012 05:39:59 -0400 |
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. > As I've explained in a parallel thread (the one concerning SoC), any > writing to disk is potentially dangerous and so we need a good reason to > do it. Why would you want to regularly create and destroy partitions in > GRUB? Firstly, I do not wish ever to create or destroy any partition using
GRUB. 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 (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.
Secondly, in regards to the 'SoC' thread, any changes to the partitioning
layout would obviously make the current 'menu.cfg' file obsolete, and therefore,
any practical integration of parted with GRUB would necessarily require that
'menu.cfg' be updated in lockstep. With the exception of small
adjustments, I would agree that in almost all cases (all) the partitioning work
should be done prior to installing any bootloader. In this respect, 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.
>>
>> 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. Each older OS has its own caveats as to which filesystem
types it can use. Having a universal data-share partition in FAT16 (or
FAT12) would not be practical in many situations involving modern OSs, so at
least two data sharing partitions are usually needed for practical reasons in a
mix with old an new OSs. There are also good reasons for wanting more than
one partition for data storage. These too must be compatable with the
caveats of the OSs wanting to use them. Further if a second disk is added
it will likely be greater than 2TB in the near future, necessitating that it too
will be GPT partitioned, resulting in a net gain of only 3 more available
partitions for any GPT-unaware OS. So for the greater majority of current
PCs, and especially those purchased before 2012, the only flexible solution for
those who want to include GPT-unaware OSs is that at least one HDD be MBR
partitioned -- that being the first HDD. There is also the issue that with
a GPT partitioned disk, all such GPT-unaware imaging tools one might have (and
like using, eg. Ghost) and other utilities (eg. PTEDIT) would become
unusable.
If a user has only GPT-unaware OSs, the only benefit to be gained with a
GPT partitioned disk is that setup of a multiboot system may in some cases be
easier, but with the severe tradeoffs in flexibility already mentioned.
One could, in theory, dedicate one GPT partition in the hybrid MBR as a logical
partition, but this partition would have to be hidden from all GPT-aware OSs,
and such a partitioning layout would not be directly supported by any one
partitioning utility. There are also known (and potentially unknown)
problems when using hybrid MBRs (see http://www.rodsbooks.com/gdisk/hybrid.html).
I would speculate that 'gptsync' could be used to zero out slots 2, 3 & 4 of
the MPT before booting any problem OS, and before using any utility not known to
be safe with hybrid MBRs, but these issues are usually not known until it is too
late (and wrt. using utilities, it is easy to forget to do so).
The typical usage for my 'eptedit' command was to zero out the second slot
of an EPBR (combined with redefining the size of the extended partition with
'partnew') such that a much shorter extended partition could be presented to OSs
not capable of accessing more than 1024 cylinders. For LBA-aware OSs
'eptedit' was used to repopulate the second slot of this EPBR. The same
technique might also be used on large disks for OSs subject to the 128GiB
barrier. I also used 'eptedit' in this way to hide non-FAT partitions at
the end of an extended partition from Win9x OSs to avoid the 'Last Logical
Partition Bug'.
Here is an example (see attached file "file #12285 SecMastr.png"):
Note that there are two alternate definitions for the extended partition
hdb2. The shorter extended partition definition is used for booting all
OSs that use CHS addressing. The longer extended partition definition is
used for booting all OSs that use LBA addressing. When using the shorter
extended partition definition, the EPBR at hdb15 should have all zeroes in the
second slot of its partition table (see attachment "file #12289
b15_old.png"). When using the longer extended partition definition, the
EPBR at hdb15 should have the second slot of its partition table populated with
the information for the next logical partition (see attachment "file #12286
b15_std.png").
>> NOTE: Not mentioned in the original bug report: with the ability to >> edit EPBRs, the potential number of logical partitions is limited only >> by the disk geometry for any SATA, PATA or SCSI disk. In one of my multiboot PC's with a single HDD I had 35 logical partitions. Most held OSs. Some were small unused placeholders used to occupy a drive letter such that all MicroSoft OSs would recognize all partitions (that each could see) by the same drive letters. MicroSoft OSs at least thru WindowsXP and many utilities cannot function predictably with this many logical partitions. To work around these issues, I used my 'eptedit' command (ref: http://savannah.gnu.org/bugs/?19410) in GRUB Legacy to rewrite one or more EPBRs to skip over some logical partitions, or to present a truncated extended partition to the OS. Potentially the same technique could be used (with much flexibility wrt. data and sharing partitions) to boot hundreds of OSs. For OSs requiring their own primary partition to boot, I used 'partnew' to (duplicate) define a logical partition as a primary partition (eg. I used this technique to boot DOS v5.0 residing on a logical partition). This is essentially identical to what you are doing with 'gptsync', but with the flexibility that you would still have potentially 20+ partitions available to the GPT-unaware OS. These same 20+ partitions would also be available to any GPT-aware OS. I would agree that with a mix of only GPT-aware OSs, and in some (rare
IMHO) situations in a 2+ HDD system with a mix of GPT-unaware and GPT-aware OSs
(assuming at least one HDD is MBR partitioned), it would be superior to have the
first HDD GPT partitioned. However, in a single disk system, and in
systems where the second HDD is > 2TB, it is MHO that the superior
arrangement would be to have the first HDD 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).
As you said, writing to disk always carries some risk, however, it is JMHO
that it is far safer writing to the partition tables in a controlled way using
GRUB than to create a hybrid configuration when it is not an essential
requirement for booting. With the proposed new features, the most common
problem that might occur would be some mucked-up partition tables that would be
easy to recognize and fix. I believe it to be a much greater risk to
introduce a hybrid state where an unsuspecting user might try to use a
GPT-unaware partitioning or data recovery tool.
|
file #12285 SecMastr.png
Description: PNG image
file #12289 b15_old.png
Description: PNG image
file #12286 b15_std.png
Description: PNG image
[Prev in Thread] | Current Thread | [Next in Thread] |