From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VZBzr-0000xf-1o for mharc-grub-devel@gnu.org; Wed, 23 Oct 2013 23:54:07 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44194) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZBzk-0000wc-NO for grub-devel@gnu.org; Wed, 23 Oct 2013 23:54:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZBzc-0002YR-E4 for grub-devel@gnu.org; Wed, 23 Oct 2013 23:54:00 -0400 Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]:58339) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZBzc-0002YG-3J for grub-devel@gnu.org; Wed, 23 Oct 2013 23:53:52 -0400 Received: by mail-wi0-f173.google.com with SMTP id ey11so8354246wid.0 for ; Wed, 23 Oct 2013 20:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=uXRlKSske6DkMmpupo396HyKHH+wG+oRgGozKVW2tXw=; b=MeCBLWGjqs5uCIvN+Oha+73qlmNVkMQezSqu/cgA2XRT+fjKq2n46lcGgy+gwCf6HS w0m4ljJmnMaN7ftvYh21W1POSnhlv21bVxMQgjJrA9jZDN+JvTU+D2/3IBiVpF/q+9tX Ta+9jzJlW0z+VbFFih9Bm4I0V8+H1rpPQXU/pRmicMz547qFnN0CjC/bD5eJhjADF25y hiFIRStz997HPvnD37JGiaCMlJVK2PESAzVf9bqZd4qntel5oUG8kPzYVTzGBozUMXEB Nke7aVWLxk9HymsJ606ZoabNVcG+4YvUQ6jStiZ+RMEQt2soZ5LivfpLm67n6NwrSvOa Os/g== X-Received: by 10.180.83.194 with SMTP id s2mr237675wiy.60.1382586830998; Wed, 23 Oct 2013 20:53:50 -0700 (PDT) Received: from [10.168.2.100] (cpc29-shep11-2-0-cust53.8-3.cable.virginmedia.com. [86.12.56.54]) by mx.google.com with ESMTPSA id s4sm22733910wiy.1.2013.10.23.20.53.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 20:53:50 -0700 (PDT) Message-ID: <526899CD.3060507@gmail.com> Date: Thu, 24 Oct 2013 04:53:49 +0100 From: FireIcer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131012 Thunderbird/17.0.9 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Grub PARTUUID vs UUID X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22d X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 03:54:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Message: 5 Date: Thu, 24 Oct 2013 01:37:06 +0100 From: FireIcer 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 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-----