Re: Grub PARTUUID vs UUID

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- 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 --]