Re: Getting Started

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.

From:	Steve Burtchin
Subject:	Re: Getting Started
Date:	Fri, 13 Apr 2012 05:39:59 -0400