From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MMx2p-0006rX-VV for mharc-grub-devel@gnu.org; Sat, 04 Jul 2009 00:40:12 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MMx2n-0006r9-BI for grub-devel@gnu.org; Sat, 04 Jul 2009 00:40:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MMx2j-0006ql-Vd for grub-devel@gnu.org; Sat, 04 Jul 2009 00:40:09 -0400 Received: from [199.232.76.173] (port=59545 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MMx2j-0006qi-P1 for grub-devel@gnu.org; Sat, 04 Jul 2009 00:40:05 -0400 Received: from c60.cesmail.net ([216.154.195.49]:23677) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1MMx2j-0001Od-9g for grub-devel@gnu.org; Sat, 04 Jul 2009 00:40:05 -0400 Received: from unknown (HELO smtprelay2.cesmail.net) ([192.168.1.112]) by c60.cesmail.net with ESMTP; 04 Jul 2009 00:40:04 -0400 Received: from [192.168.0.22] (static-72-92-88-10.phlapa.fios.verizon.net [72.92.88.10]) by smtprelay2.cesmail.net (Postfix) with ESMTPSA id 980F134C6A for ; Sat, 4 Jul 2009 00:47:53 -0400 (EDT) From: Pavel Roskin To: The development of GRUB 2 In-Reply-To: References: <1246572485.20370.77.camel@mj> <1246641749.29642.21.camel@mj> Content-Type: text/plain Date: Sat, 04 Jul 2009 00:40:01 -0400 Message-Id: <1246682401.2544.26.camel@mj> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: Absence notice X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 04:40:09 -0000 On Fri, 2009-07-03 at 19:35 +0200, Vladimir 'phcoder' Serbinenko wrote: > >> > I don't think > >> > there are any objections against supporting nested partitions. > >> Yes but I thought someone may have comments like "let's shave ths part > >> from the kernel". The patch doesn't increase the core.img because > >> increase of kernel size is compensated by pc.mod/bsdlabel.mod split. > >> It the cases when bsdlabel.mod is used usually no modules like raid or > >> lvm are used > > > > Such objections may be raised once there is a patch that compiles. > > Distributors must consider worst case scenarios. > > > If worst-case scenarios don't fit into mbr gap we may consider another > approaches > 1) progressive loading (e.g. FS-parsing bootsectors in worst case > bring some kind of stage1.5 back) I don't think this would be very popular. > 2) replace lzma with xz I'm afraid it's the same thing essentially. > 3) use another embedding areas. E.g. lvm has to divide PV in PE of > equal length. This often results in last block of space being smaller > then PE. This space is reported by pvdisplay as unusable and we may > use it w/o problems. I'm not an lvm expert though so don't rely on my > word Or just use a separate partition. Actually, it's a fair game not to support some especially convoluted configurations. -- Regards, Pavel Roskin