On Oct 23, 2013, at 6:37 PM, FireIcer <f1r31...@gmail.com> 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
