From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KN98c-0008QH-0c for mharc-grub-devel@gnu.org; Sun, 27 Jul 2008 12:30:26 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KN98Z-0008Q5-Hj for grub-devel@gnu.org; Sun, 27 Jul 2008 12:30:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KN98Y-0008Pt-4R for grub-devel@gnu.org; Sun, 27 Jul 2008 12:30:23 -0400 Received: from [199.232.76.173] (port=49296 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KN98X-0008Pq-UJ for grub-devel@gnu.org; Sun, 27 Jul 2008 12:30:21 -0400 Received: from c60.cesmail.net ([216.154.195.49]:25507) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1KN98X-00073M-AI for grub-devel@gnu.org; Sun, 27 Jul 2008 12:30:21 -0400 Received: from unknown (HELO relay.cesmail.net) ([192.168.1.81]) by c60.cesmail.net with ESMTP; 27 Jul 2008 12:30:19 -0400 Received: from [192.168.1.225] (pool-71-185-138-248.phlapa.east.verizon.net [71.185.138.248]) by relay.cesmail.net (Postfix) with ESMTP id 1A4F9618F22 for ; Sun, 27 Jul 2008 12:30:19 -0400 (EDT) From: Pavel Roskin To: The development of GRUB 2 In-Reply-To: <20080727121914.GA11242@thorin> References: <20080722133416.GB5524@archvile> <20080722095021.p15u40gtyc88csco-cebfxv@webmail.spamcop.net> <3FA357AE49694559941A663191155DE2@fz> <5A50C2D990914B3F8A73A02D520E8DED@fz> <1216918145.22586.14.camel@dv> <20080725210840.GA19505@thorin> <1217022420.3957.3.camel@dv> <20080725221050.GA31179@thorin> <1217034532.6376.13.camel@dv> <20080727121914.GA11242@thorin> Content-Type: text/plain Date: Sun, 27 Jul 2008 12:29:43 -0400 Message-Id: <1217176183.4029.20.camel@ct> Mime-Version: 1.0 X-Mailer: Evolution 2.23.4 (2.23.4-3.fc10) Content-Transfer-Encoding: 7bit X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading) 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: Sun, 27 Jul 2008 16:30:24 -0000 On Sun, 2008-07-27 at 14:19 +0200, Robert Millan wrote: > > We could also use UUID for single-drive installs and fallback to the > > partition prefix only if UUID is unsupported or the user requests not to > > use UUID. Then it won't be a big deal if we hardcode the drive. > > Based on the rest of your mail I assume the goal you're pursuing here is > deleting make_install_device(). The problem I see is that if you fallback > when UUIDs are unsupported, you still need to have the code to handle the > fallback case, even if it's rarely used. You are right, I'm thinking how to get rid of make_install_device(). It looks wrong to me that we are converting binary data to text, which will be parsed back to the binary data. If we want to keep the GRUB core aware of the textual device names, we should try to avoid the binary-to-text conversion. But it turns out that the binary format can represent something that the text format cannot, namely "partition N on the current drive". I think it's an omission, since we have representation for files on the current partition (the drive and partition part is omitted). I'm thinking of implementing grub-install for PowerPC. It should work like yaboot because that's what it will likely replace. In means that the hfs boot partition may be short and not mounted. Then it would be better to put core.img there, perhaps with a wrapper script, and put all modules and grub.cfg to /boot/grub, which will be on a native mounted partition. Thus it will be necessary to specify the root partition in core.img. It would be nice to implement it in a platform independent way. > OTOH, since UUIDs are supported in all major FSs we have, I don't think > it'd be such a big deal if we abort the install when they can't be probed. > > But then, this would need to be carefuly discussed IMHO, as it's a more > radical change. I'm also concerned that UUID may not be unique. For instance, a disk was cloned, and a filesystem of the clone was modified without changing the UUID. -- Regards, Pavel Roskin