Re: Getting Started

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4561 bytes --]

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.
> > 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
Please stop inventing your own shortcuts, it makes it difficult to read
and understand you.
> (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.
>  
> 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.
You need partition table in the first place in order to access grub.cfg
(and it's not menu.cfg).
> >> 
> >> 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.
>  
> 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.
One would have regular GPT partitions with few gaps, or special type
partitions left for putting EBR there.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]