From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VZEW0-0001Xf-SJ for mharc-grub-devel@gnu.org; Thu, 24 Oct 2013 02:35:28 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZEVt-0001VG-Hq for grub-devel@gnu.org; Thu, 24 Oct 2013 02:35:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZEVi-0001Sb-Dj for grub-devel@gnu.org; Thu, 24 Oct 2013 02:35:21 -0400 Received: from mail-ea0-x22e.google.com ([2a00:1450:4013:c01::22e]:50192) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZEVi-0001SG-2H for grub-devel@gnu.org; Thu, 24 Oct 2013 02:35:10 -0400 Received: by mail-ea0-f174.google.com with SMTP id z15so933656ead.19 for ; Wed, 23 Oct 2013 23:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=KPqZHRgC5NnqrlKWhVStlBYG8Y9uNwL5uF+lPsXUWVo=; b=I0oMgIzS7CwqvjFsdtgTuDJHC6Fx7/Jhiobf4Z43tC1wxTsA1S79OsV04GoFmyvOhk CF/Pv3Yezdr+EXGCkK42izT6bsw0u7aNGbecmQGNnaKVt3OA1KlVTE4/ETLVdRnFoyNW +ihQiHQWhhXUElts6PL5BhfFboLArms4wmK8kN+jljdivwpUw4cJnrRmTuZGp6yFZN0h 9JABnhsXDO8eJ7GdEUuAYevlLLixXPnwpAA6BboXKe65ycOWjlWjwAbJK9FIZmpztCLi JlipDBn7yHUS+eMB7C1JllNbIJOAGup6sWUTng2dxTAvlaOos5XrGfu+aqk9zBxPiLbW JVCg== X-Received: by 10.15.22.2 with SMTP id e2mr1141163eeu.89.1382596509050; Wed, 23 Oct 2013 23:35:09 -0700 (PDT) Received: from [192.168.42.74] (18-237.197-178.cust.bluewin.ch. [178.197.237.18]) by mx.google.com with ESMTPSA id d7sm217093eem.8.2013.10.23.23.35.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 23:35:08 -0700 (PDT) Message-ID: <5268BF95.6000308@gmail.com> Date: Thu, 24 Oct 2013 08:35:01 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: Grub PARTUUID vs UUID References: <526899CD.3060507@gmail.com> In-Reply-To: <526899CD.3060507@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2BHVQVTEKAQHVLQCMTNGK" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::22e 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 06:35:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2BHVQVTEKAQHVLQCMTNGK Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: >=20 > 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=3DISO-8859-1 >=20 > Hey >=20 > 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. >=20 > At present the situation forces the user to enable a working initramfs > to work around grub2. >=20 > 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. >=20 > 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. >=20 > 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? >=20 > 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? >=20 > A option/switch parameter when using mkconfig to output the cfg file > maybe? >=20 > Thanks >=20 > f1r31c3r >=20 >=20 >=20 >=20 > ------------------------------ >=20 > 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=3D"utf-8" >=20 > On 24.10.2013 02:37, FireIcer wrote: >> Hey >=20 >> 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. >=20 >> At present the situation forces the user to enable a working >> initramfs to work around grub2. >=20 >> 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. >=20 >> 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. >=20 > Please do not confuse how GRUB finds disks itself and what is passed as= > root=3D parameter. Those are separate discussions and second one touche= s > 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 i= s > 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? >=20 > Intel is very low on my esteem with all the crapware which got out of i= t > recently. >=20 >> 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? >=20 > This sounds like Linux limitation, doesn't it? >> A option/switch parameter when using mkconfig to output the cfg >> file maybe? >=20 > I don't see any patch attached. >=20 > ------------------------------- >=20 > I have done more investigating and hacking regarding the UUID vs PARTUU= ID. >=20 > 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. >=20 > A dilemma, dig into the kernel code and find out if or stick to my > workaround that is not ideal. >=20 > I have found that if i put PARTUUID=3Dxxxxx... into the > /etc/default/grub "GRUB_CMDLINE_LINUX_DEFAULT" then it works but big > BUT it breaks the os-probe. >=20 > "grub2-probe: error: failed to get canonical path of `PARTUUID=3Dxxxx'"= >=20 > 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. >=20 > 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. >=20 > Thanks >=20 > f1r3c1c3r >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >=20 ------enig2BHVQVTEKAQHVLQCMTNGK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iF4EAREKAAYFAlJov5UACgkQNak7dOguQglQsQEAtuejAIQEzBjyGXwSdOq4erUk mAQ+863eH9SeFB3WfnUA/111R9KYch8ZntrSfNDZA8g9atncX05DCAXNdb7hACk/ =fOlY -----END PGP SIGNATURE----- ------enig2BHVQVTEKAQHVLQCMTNGK--