Grub PARTUUID vs UUID

Grub PARTUUID vs UUID

[FireIcer]

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

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

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

iQEcBAEBAgAGBQJSaGuyAAoJEBzkvPKQNuh2JVcH+gOj1QwfH0jRXDcq1Usm3A0c
EOktkEkz+5yMPbWIPOEQev9ZzIb18Ef6+eNVAEAmTuDVaF3i8stEv+wsnLixhj/R
AR2qjHtTtGcJcq7O+6O6s+HziOEnbMVwdb0Yeg8m/qgr7Xx3MpNxjHQsyhdhMuxU
xw6Mgy/A4TIp4qdyPFEpSYfRdu55LRkQATvP6+j5Vt7OcJn3Qkife+Vy4akdd07G
WY1nq43aiYZP5DjOqeIlE8lq/e28RNJmtn6w8V1DlTC2oj4SM3Dpc96SGPSevNmw
VLegioKa/vztyapJAZAVZ4tgtXnNpXeHxreo0G9HA8C3DkaMlY817Steko9C5cU=
=ah6L
-----END PGP SIGNATURE-----

Re: Grub PARTUUID vs UUID

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]

Re: Grub PARTUUID vs UUID

[Chris Murphy]

On Oct 23, 2013, at 6:37 PM, FireIcer <f1r31c3r@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 PARTUUID vs UUID

[FireIcer]

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


Message: 5
Date: Thu, 24 Oct 2013 01:37:06 +0100
From: FireIcer <f1r31c3r@gmail.com>
To: grub-devel@gnu.org
Subject: Grub PARTUUID vs UUID
Message-ID: <52686BB2.2030004@gmail.com>
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 	<phcoder@gmail.com>
To: grub-devel@gnu.org
Subject: Re: Grub PARTUUID vs UUID
Message-ID: <526872B4.4080903@gmail.com>
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-----

Re: Grub PARTUUID vs UUID

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 5973 bytes --]

Please don't post the exact same mail as response to another message,
it's both ignored and considered annoying.
On 24.10.2013 05:53, FireIcer wrote:
> 
> Message: 5
> Date: Thu, 24 Oct 2013 01:37:06 +0100
> From: FireIcer <f1r31c3r@gmail.com>
> To: grub-devel@gnu.org
> Subject: Grub PARTUUID vs UUID
> Message-ID: <52686BB2.2030004@gmail.com>
> 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 	<phcoder@gmail.com>
> To: grub-devel@gnu.org
> Subject: Re: Grub PARTUUID vs UUID
> Message-ID: <526872B4.4080903@gmail.com>
> 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
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]

Re: Grub PARTUUID vs UUID

[Chris Murphy]

On Oct 23, 2013, at 7:58 PM, Chris Murphy <lists@colorremedies.com> wrote:

> 
> On Oct 23, 2013, at 6:37 PM, FireIcer <f1r31c3r@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.

FWIW, the volume UUID is probably more reliable than partition UUID. Here's an example. I just resized a file system, and after that, I have to change the partition size also. But the tools don't seem to allow changing only the end sector value, I have to delete the partition entry then create a new one. When I create the new partition entry, I've created a new partition UUID. So if I were depending on partition UUID to be stable, and used that instead of volume ID, I'd likely have an unbootable system.


Chris Murphy