Re: Grub PARTUUID vs UUID

[Chris Murphy]

On Oct 23, 2013, at 6:37 PM, FireIcer <address@hidden> wrote:

> I am looking at the impact in general with changing the grub-mkconfig
> scan not to pickup and update the grub.cfg with the UUID code but the
> PARTUUID code instead.

grub doesn't require volume UUID, this is something that the kernel wants 
because that's the only reliably present UUID of some kind since MBRs don't 
have UUIDs. So yes, it's probably marginally more reliable to use the GPT 
UniquePartitionGUID: a.) there are two copies, checksummed; b.) they're 
unlikely to change until repartitioning occurs, whereas file system UUID 
changes if the file system is recreated on an existing partition.

> I cant understand why UUID's were used rather than PARTUUID's. If the
> code was modified to use PARTUUID's instead, what would be the impact
> on compatibility on a large scale.

If /boot or rootfs are restored using rsync or some file copy, then the file 
system is new and UUID is new which means the system may not boot until 
initramfs is rebuilt, true. So use of UniquePartitionGUID makes this slightly 
more reliable in the cases were the disk is also not being replaced or 
repartitioned, in which case there's a new UniquePartitionGUID also.

> I feel it should be encouraged to
> remove the MBR tables as it is old and useless not to mention tied in
> to microsoft products.

This was tried with Fedora around 14 or 15, and backed out because too many 
BIOS firmware puked upon finding only GPT. So for UEFI computers, sure GPT. For 
BIOS, MBR is more reliable short of testing a particular system if it won't 
face plant upon encountering GPT.

> 
> The point of this post is to raise alarm to the fact UUID's wont work
> without initramfs or initrd as so to read the UUID but the kernel can
> read PARTUUID without the use of initrd. Would that not be far better
> to not rely on init ram filesystem?

Well it assume the user creates a new file system, thereby making UUID 
different and thus root isn't locatable by UUID anymore; and further assumes 
the GPT UniquePartitionGUID is not changed.

I think that combination is possible but probably not really common. I think 
the common case is a drive dies and it's going to get all new UUIDs in any case.



Chris Murphy