Grub PARTUUID vs UUID

[FireIcer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Message: 5
Date: Thu, 24 Oct 2013 01:37:06 +0100
From: FireIcer <address@hidden>
To: address@hidden
Subject: Grub PARTUUID vs UUID
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1

Hey

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.

At present the situation forces the user to enable a working initramfs
to work around grub2.

Why is this a problem? well because initramfs can be used to decorate
ones boot display and many other things other than it's intended use.
This means that UUID as a parameter in the grub.cfg wont work. I
understand that Windows partitions use a shortened UUID only, so
compatibility needs to be able to differentiate between the two types.
UUID for windows partitions and PARTUUID for other GPT partitions.

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 people enable the option in Grub to use PARTUUID's then surely they
would know to setup GPT disks. 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. Now we have an Intel contribution "GPT" which
works much better is it not right that we encourage the use of GPT
over MBR?

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?

A option/switch parameter when using mkconfig to output the cfg file
maybe?

Thanks

f1r31c3r




- ------------------------------

Message: 6
Date: Thu, 24 Oct 2013 03:07:00 +0200
From: Vladimir '?-coder/phcoder' Serbinenko     <address@hidden>
To: address@hidden
Subject: Re: Grub PARTUUID vs UUID
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"

On 24.10.2013 02:37, FireIcer wrote:
> Hey
> 
> 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.
> 
> At present the situation forces the user to enable a working
> initramfs to work around grub2.
> 
> Why is this a problem? well because initramfs can be used to
> decorate ones boot display and many other things other than it's
> intended use. This means that UUID as a parameter in the grub.cfg
> wont work. I understand that Windows partitions use a shortened
> UUID only, so compatibility needs to be able to differentiate
> between the two types. UUID for windows partitions and PARTUUID for
> other GPT partitions.
> 
> 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.
> 
Please do not confuse how GRUB finds disks itself and what is passed as
root= parameter. Those are separate discussions and second one touches
exclusively grub-mkconfig.
> If people enable the option in Grub to use PARTUUID's then surely
> they would know to setup GPT disks. 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.
Completely wrong. MBR partition table does not imply any microsoft
product. It's used for very different disks in different systems, some
of them never had windows at all.
Also this is wrong to say that there is no partition ID in MBR. There is
MBRID which is concatenated with partition offset to give the ID.
> Now we have an Intel contribution "GPT" which works much better is
> it not right that we encourage the use of GPT over MBR?
> 
Intel is very low on my esteem with all the crapware which got out of it
recently.

> 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?
> 
This sounds like Linux limitation, doesn't it?
> A option/switch parameter when using mkconfig to output the cfg
> file maybe?
> 
I don't see any patch attached.

- -------------------------------

I have done more investigating and hacking regarding the UUID vs PARTUUID.

You are correct, sorry for getting it wrong in my last message, yes
Grub finds disks via UUID. It is unfortunate the kernel works like
this at present.

A dilemma, dig into the kernel code and find out if or stick to my
workaround that is not ideal.

I have found that if i put PARTUUID=xxxxx... into the
/etc/default/grub "GRUB_CMDLINE_LINUX_DEFAULT" then it works but big
BUT it breaks the os-probe.

"grub2-probe: error: failed to get canonical path of `PARTUUID=xxxx'"

The question is, should one add support to grub2-probe to correct the
error when using PARTUUID with the workaround when using this as a
kernel command line parameter or find another solution entirely.

I have not attached a patch yet as i am still working on figuring it
out. Just posting ideas and problems found for further development.

Thanks

f1r3c1c3r
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSaJnNAAoJEBzkvPKQNuh25esH/05ZV8iwasuCHcK/jfkI81s6
oVwX06Ds9g5RtUuiQCibvwkoIMXIcqlJK7snYCTXMSAtJ4ccM4xsI6ph4idfbqzG
JgsP/cTnljmyclm+QzrgzDJ3m99GOYem2PSVURzhJR5vM5GzdgMTFNXrN8XO+eCI
X0/2BpI1ucrCrLXVROBwDONIpmIIny9vRUy5u/CDaTTpupkTg9Icj0gfd0M8CYvB
WM0m5soLG6ytl3LpnGqYmlPQ4YNdrkT8mhxnMXDxyWOJlXjdGvbKZ4cQN91jew1J
mx4Zp/n0TyHXOHGVfRUDotrvgsZtWXEr1GchvcDX4Z/FC8PQCsBrw3QZ+sqHy34=
=RwwX
-----END PGP SIGNATURE-----