Currently grub2 can boot with root=UUID but needs an initrd. With PARTUUID there is no need of anything else. Reproducible: Always Steps to Reproduce: 1. 2. 3.Add UUID statement for rootfs in grub.cfg and leave it without initrd. Actual Results: With +UUID-initrd= kernel panic (unable to find rootfs) Expected Results: To boot with 'root=PARTUUID=' without initrd. There are audev rules for creating '/dev/disk/by-PARTUUID/' here: http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=rules/rules.d/60-persistent-storage.rules;h=b7da8b8bc22e88c4c345963aebae9d5fbb79dcdd;hb=HEAD With those rules we are avoiding installing sgdisk dependency. The '10_linux' script and '/etc/default/grub' file need tweaking ;) Sadly my bash skills are very limited :( That may help: http://archives.gentoo.org/gentoo-user/msg_35eb3187ef8be8a23cdec253b66b5a59.xml
Created attachment 301611 [details] 80-persistent-storage.rules
sounds like something that should get fixed upstream
(In reply to comment #2) > sounds like something that should get fixed upstream I thought that 'grub2-mkconfig -o' is a exclusive Gentoo thing. Currently it's possible to boot with PARTUUID and I'm doing it on my system. The only culprit is that 'grub2-mkconfig -o', '10_linux' script and '/etc/default/grub' does not make the proper input into grub.cfg ;)
hrm, looks like a lot of patches have been merged locally instead of pushing them upstream. you could be right here.
grub2-mkconfig is not gentoo thing, we just rename it from grub-mkconfig which is even supported by upstream build system. FWIW I tried to push all the patches but upstream is not exactly caring so what can we do about them. I would say that if somebody has interesting patch they should push it upstream and if they wont care we should use it...
I still have my hopes for solving this problem :)
Please request this as a feature upstream. As for the udev rules, please file a separate bug.
(In reply to comment #7) > Please request this as a feature upstream. > > As for the udev rules, please file a separate bug. I think that last udev (182 i think) shipped those rules, am i wrong?
(In reply to comment #8) That is possible. I don't really pay attention to it.
Here it is the upstream bug: https://savannah.gnu.org/bugs/index.php?35937
I've got an answer there: "Very low priority. Also note tat GRUB doesn't handle root= at all so many of the claims in original post are wrong." I dont't get it :(
It does work if you do it manually, I use GRUB_DEVICE="PARTUUID=AAAAAAAA-AAAA-BBBB-CCCC-C85A5E5660C3" in /etc/default/grub.
It doesn't work anymore with 3.8.x and newer kernel. When `mount´ reports the root partition like this: > # mount > PARTUUID=AE78FB79-78D8-4E3D-9289-769C658E0A27 on / type xfs (rw,noatime,attr2,discard,nobarrier,inode64,logbsize=256k,noquota) (which I think is new with the 3.8.x-kernels), then grub2-mkconfig will not be able to resolve what canonical path "PARTUUID=AE78FB79-78D8-4E3D-9289-769C658E0A27" resolves to. > # grub2-mkconfig -o /boot/grub2/grub.cfg > /usr/sbin/grub2-probe: error: failed to get canonical path of PARTUUID=AE78FB79-78D8-4E3D-9289-769C658E0A27. I'm guessing grub2-probe must be updated to support partition lookup by /dev/disk/by-partuuid and not just by-uuid.
Upstream does not care as it seems :(
The source code for util/grub-probe.c and grub-core/kern/fs.c doesn't look that inaccessible... I guess that if I try to fix this it'll be a hack that doesn't actually do any probing, but just returns the PARTUUID=-string given from config. Since the grub2 ebuild calls epatch_user, this might not be such a bad idea.
(In reply to comment #15) > The source code for util/grub-probe.c and grub-core/kern/fs.c doesn't look > that inaccessible... I guess that if I try to fix this it'll be a hack that > doesn't actually do any probing, but just returns the PARTUUID=-string given > from config. > > Since the grub2 ebuild calls epatch_user, this might not be such a bad idea. Well, it looks that you know what you are doing ;)
