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 <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 > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
