[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != ro

From: Pavel Roskin
Subject: Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading)
Date: Sun, 27 Jul 2008 12:29:43 -0400

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

> 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.

Pavel Roskin

reply via email to

[Prev in Thread] Current Thread [Next in Thread]