From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SS2cx-0006E0-KO for mharc-grub-devel@gnu.org; Wed, 09 May 2012 04:52:07 -0400 Received: from eggs.gnu.org ([208.118.235.92]:53584) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SS2ct-00069p-1l for grub-devel@gnu.org; Wed, 09 May 2012 04:52:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SS2cl-0003mu-9e for grub-devel@gnu.org; Wed, 09 May 2012 04:52:02 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.122]:28344) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SS2cl-0003mR-5Y for grub-devel@gnu.org; Wed, 09 May 2012 04:51:55 -0400 X-Authority-Analysis: v=2.0 cv=OMylLFmB c=1 sm=0 a=mDgWK73dBuBIoefmGD85HA==:17 a=yCWh9YYOXtQA:10 a=05ChyHeVI94A:10 a=8nJEP1OIZ-IA:10 a=A2ISaVMC80UMW6k1uS0A:9 a=f-tz8hiDAwLixfRmSDMA:7 a=wPNLvfGTeEIA:10 a=mDgWK73dBuBIoefmGD85HA==:117 X-Cloudmark-Score: 0 X-Originating-IP: 98.31.10.175 Received: from [98.31.10.175] ([98.31.10.175:60545] helo=Compaq1) by hrndva-oedge02.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 46/4F-27984-6203AAF4; Wed, 09 May 2012 08:51:51 +0000 Message-ID: <002c01cd2dc0$909420d0$6500a8c0@Compaq1> From: "Steve Burtchin" To: References: Subject: Re: Getting Started Date: Wed, 9 May 2012 04:48:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.2001 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.2001 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 71.74.56.122 Cc: Steve Burtchin 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: Wed, 09 May 2012 08:52:05 -0000 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