From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1NZCye-00031L-Ud for mharc-grub-devel@gnu.org; Sun, 24 Jan 2010 19:38:48 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZCyd-00030n-JK for grub-devel@gnu.org; Sun, 24 Jan 2010 19:38:47 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZCyZ-0002zY-3R for grub-devel@gnu.org; Sun, 24 Jan 2010 19:38:47 -0500 Received: from [199.232.76.173] (port=48196 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZCyY-0002zV-Ry for grub-devel@gnu.org; Sun, 24 Jan 2010 19:38:42 -0500 Received: from mail-yw0-f177.google.com ([209.85.211.177]:65492) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NZCyY-0008Qn-HW for grub-devel@gnu.org; Sun, 24 Jan 2010 19:38:42 -0500 Received: by ywh7 with SMTP id 7so2544572ywh.24 for ; Sun, 24 Jan 2010 16:38:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=W3pXis0g6L4oDZZss6GK++cwwEHzyKm3LX1UlW1T9/k=; b=aGKA/RFlwWGP/tRzgvLA9lPr7Uj2cC2FBYM8FC+CB7kLohfgYlBDHiZRQnQZycGhXd Po94A41ZcJrVhEpxMFcr/u5nK/PJbSO+14zmDz8auqQ1YQyGOEEjAPkJFjwwBQ4q9RFl dBUinrgOOdkCAAfp7UvW+5zM6Pn4LYOyxJm1M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=JwWH47qpapY5izk9L6fARp8i+Dvhry9ingiH9JfXcrMNb+BBkR3eUDJ/WcvaPOvMyP gc0C6fwru5ExqOnpEJnuzXbmkFhk/sUWDXmbA4asCnr7SBdJSbZ/+MkPL5ZbLRskOzyj GsD1Lweo1QecKl5dPk/T8eiHAfweHa0upHaWY= Received: by 10.101.132.25 with SMTP id j25mr7053055ann.79.1264379921609; Sun, 24 Jan 2010 16:38:41 -0800 (PST) Received: from ?192.168.0.75? (cpe-24-174-183-197.satx.res.rr.com [24.174.183.197]) by mx.google.com with ESMTPS id 8sm1454934yxg.42.2010.01.24.16.38.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 24 Jan 2010 16:38:41 -0800 (PST) Message-ID: <4B5CE810.7060407@gmail.com> Date: Sun, 24 Jan 2010 18:38:40 -0600 From: Bruce Dubbs User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.16) Gecko/20080722 SeaMonkey/1.1.11 MIME-Version: 1.0 To: The development of GNU GRUB References: <20090804201512.GA15811@thorin> <20090817140657.GP32551@thorin> <20100122165300.GA14428@thorin> <4B59E869.700@gmail.com> <20100124204118.GA10054@thorin> In-Reply-To: <20100124204118.GA10054@thorin> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: [PATCH] nested partitions X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 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: Mon, 25 Jan 2010 00:38:47 -0000 Robert Millan wrote: > On Fri, Jan 22, 2010 at 07:03:21PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: >> Partition types are easily screwed. Why not just check for the presence >> of the label? > > I have a feeling I already explained this somewhere. Doesn't seem to be in > this thread, maybe on IRC? Anyway, it won't hurt to ellaborate on it... > > First of all, the whole label type proliferation problem is inherently > impossible to resolve by technical means. Labels overlap each other, > they can coexist without any garantee that the user expects them to be > there at all or include meaningful data. There is a fairly long thread at util-linux-ng that discusses this problem in the context of very slow and very small devices. It starts approximately at http://marc.info/?l=util-linux-ng&m=126353611105795&w=2 The ultimate solution was to not search for multiple partition type signatures on small devices. > You *can't* reliably check for any partition label. ... > So instead of supporting things like: > > (hd0,1) > (hd0,2) > > (ambigous; what does this mean in an hybrid MSDOS/GPT ? What about other > hybrid schemes? GRUB can't tell!) > > ... we could support: > > (hd0,msdos1) > (hd0,gpt1) > (hd0,msdos2) > (hd0,gpt2) > > whose meaning is pretty clear. Then the user can nest as much as they like, > but they will also have to deal with the problem of identifiing the labels. I like this idea, but wonder if it would be useful to have something like (grub drive, partition type, filesystem type) for each partition to consider. For example: (hd0,gpt1,ext2) > Minix: (hd0,msdos1,msdos1) > > Solaris: (hd0,msdos2,sun1) > > *BSD: (hd0,msdos3,bsd1) > With this approach, the burden is no longer in GRUB. Then I don't care > how weird disk layouts can become, because GRUB doesn't have to probe > them. We can even support things like this if it makes users happy: > > (hd0,bsd2,msdos1,sun1,apple4,msdos1) Can you translate that. I don't understand. -- Bruce