-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Message: 5 Date: Thu, 24 Oct 2013 01:37:06 +0100 From: FireIcer <f1r31...@gmail.com> To: grub-devel@gnu.org Subject: Grub PARTUUID vs UUID Message-ID: <52686bb2.2030...@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 <phco...@gmail.com> To: grub-devel@gnu.org Subject: Re: Grub PARTUUID vs UUID Message-ID: <526872b4.4080...@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----- _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
