From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SIdND-0000m1-La for mharc-grub-devel@gnu.org; Fri, 13 Apr 2012 06:04:59 -0400 Received: from eggs.gnu.org ([208.118.235.92]:55618) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SIdN9-0000l2-A2 for grub-devel@gnu.org; Fri, 13 Apr 2012 06:04:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SIdN3-0000KE-4B for grub-devel@gnu.org; Fri, 13 Apr 2012 06:04:54 -0400 Received: from mail-ey0-f169.google.com ([209.85.215.169]:56955) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SIdN2-0000K0-Ny for grub-devel@gnu.org; Fri, 13 Apr 2012 06:04:49 -0400 Received: by eaal1 with SMTP id l1so771768eaa.0 for ; Fri, 13 Apr 2012 03:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; bh=OMKmsoON8Z23r4u0r0NbohY8D4sdZjIQAuHv4F+ngCA=; b=C5mt/psN9jzwxHRCEnoQIYHWpL4kozjKCnJ+/mJPx+T4TZN72PpThjiLMRcxeJcuMO 41CQcvdLGvbTwm4dIzmwvakXihzjcsB+7Vyh8gzndREpRObwP4le7RwFT6NXfCCVIq97 fhu8x/cI7gQsgI+wmg2vdAmTrZQ95BCG1/FScuB+dV27x5eKxDwHfzGV30nYpSZLNOIZ DP7zElTPaH6NfeXSqTWeCJcx3ya92XG86tbGArjhA8WotJHxdsaLXxVFloOwLuinLWrm PCwfIFgNc/UOPJmZ5TytdYwx5WiY5gmq/qVjPwnD7GaPOuiuRkhgK+4+aP/vcq/ulP9S ie8w== Received: by 10.14.122.195 with SMTP id t43mr132272eeh.30.1334311486730; Fri, 13 Apr 2012 03:04:46 -0700 (PDT) Received: from debian.x201.phnet (61-234.197-178.cust.bluewin.ch. [178.197.234.61]) by mx.google.com with ESMTPS id m55sm40925499eei.1.2012.04.13.03.04.44 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Apr 2012 03:04:45 -0700 (PDT) Message-ID: <4F87FA2A.5000708@gmail.com> Date: Fri, 13 Apr 2012 12:04:26 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: Getting Started References: <002601cd1959$64cb20f0$6400a8c0@Compaq1> In-Reply-To: <002601cd1959$64cb20f0$6400a8c0@Compaq1> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig3CD0F7DE74EFE2F92A569DCB" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.215.169 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 10:04:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3CD0F7DE74EFE2F92A569DCB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: > >>=20 > >> 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? > =20 > 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. > =20 > 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.=20 > 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). > >>=20 > >> 2) Edit extended partition tables (EPBRs). This functionality was > >> added to GRUB Legacy with the 'eptedit' command as described in bug > >> report #19410. > >>=20 > > 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 standartis= ed > > way and with a benefit of that GPT-aware tools will handle the whole > > thing correctly. > =20 > 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. > =20 > 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. --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig3CD0F7DE74EFE2F92A569DCB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAk+H+jEACgkQNak7dOguQgm+CgD+JecVL1AtrwNMf4RXUiKUpGSI xPV+bjF61ZQanyoiklUBALKcTsV7TNQ8Ink0u6F9TeB/erzsiNhiUy3joG/liVeJ =Y28Y -----END PGP SIGNATURE----- --------------enig3CD0F7DE74EFE2F92A569DCB--