Summary: | sys-boot/grub:2 - Please add possibility of 'root=PARTUUID=' statement into grub.cfg via grub2-mkconfig | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Kamen Dokov <polidevk.polidevk> |
Component: | [OLD] Core system | Assignee: | Mike Gilbert <floppym> |
Status: | RESOLVED UPSTREAM | ||
Severity: | enhancement | CC: | base-system, gokturk, mads, scarabeus |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://savannah.gnu.org/bugs/index.php?35937 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | 80-persistent-storage.rules |
Description
Kamen Dokov
2012-02-12 00:18:27 UTC
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 ;) |