| Summary: | genpatches: 2900_dev-root-proc-mount-fix.patch causes failure in grub2-probe when root is mounted via PARTUUID | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | niels |
| Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | base-system, bobbykent32, cardoe, floppym, Manfred.Knick, remy, williamh |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=462748 | ||
| Whiteboard: | 4.0.6,4.1.0 | ||
| Package list: | Runtime testing required: | --- | |
Seems this is still an issue, though I may have stumbled upon a workaround. When stracing grub2-probe I noticed it looks in current working directory for PARTUUID=<root_partition_uuid>, I symlinked /dev/sd<root device><root partition> to $PWD/PARTUUID=<root_partition_uuid> and reran grub2-probe and it succeeded! For example: ln -s /dev/sda5 "PARTUUID=8a813b8d-7bb2-4f62-8a17-0e1d02456bdd" grub2-mkconfig -o /boot/grub/grub.cfg rm "PARTUUID=8a813b8d-7bb2-4f62-8a17-0e1d02456bdd" Without the symlinks grub2-mkconfig returns: /usr/sbin/grub2-probe: error: failed to get canonical path of `PARTUUID=8a813b8d-7bb2-4f62-8a17-0e1d02456bdd'. Tried upgrading from stable sys-boot/grub-2.02_beta2-r3 to sys-boot/grub-2.02_beta2-r7, though the behavior remained the same. Opened bug upstream https://savannah.gnu.org/bugs/index.php?44611. This dates back to an unfortunately un-resolved discussion in 2013 already: "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." [ http://lists.gnu.org/archive/html/grub-devel/2013-10/msg00153.html ] I just experianced similar results via setting "GRUB_DEVICE=PARTUUID=..." in /etc/default/grub. "df -h" lists a "PARTUUID=..." device entry for "/", which grub2-probe cannot resolve, but it can resolve the "classical" link "/dev/sd.." supplied by BobbyK's "trick" above. $ df -h : ... rootfs 40G 19G 19G 50% / PARTUUID=149D7E31-31B0-48CF-BF26-3C9A1A8B4286 40G 19G 19G 50% / ... $ cat /etc/mtab : rootfs / rootfs rw 0 0 PARTUUID=149D7E31-31B0-48CF-BF26-3C9A1A8B4286 / ext4 ... ... No entry like "/dev/sdb5" contained. Can someone experiencing this issue post the following? Feel free to use an attachment(s). Content of /etc/fstab Content of /etc/mtab Content of /proc/self/mounts Content of /proc/self/mountinfo Output of strace -e file /usr/sbin/grub2-probe -t fs / Also, please tell me what kernel you are using (vanilla, gentoo-sources, hardened-sources, etc). I have a feeling this kernel patch may be to blame; the information above will help confirm that. http://dev.gentoo.org/~mpagano/genpatches/trunk/3.19/2900_dev-root-proc-mount-fix.patch Ok, I confirmed this myself. 2900_dev-root-proc-mount-fix.patch is definitely the problem here. This causes entries like this to appear in /proc/self/mountinfo: 13 0 8:1 / / ro,relatime - ext4 PARTUUID=5eda83f5-e295-4f0b-8dcd-123f00c207d3 ro,data=ordered Without that kernel patch, you would see the following: 13 0 8:1 / / ro,relatime - ext4 /dev/root ro,data=ordered When grub-probe sees /dev/root, it treats it as a special case and switches to an alternate code path that finds the actual device node by looking a major and minor device numbers. When grub-probe sees a PARTUUID, it does not know what to do with it and gives up. Convincing grub upstream to work around this would be tricky. I'm giving this to the kernel team since the problem is triggered by a Gentoo-specific kernel patch. My suggestion would be to adjust the kernel patch to not use saved_root_name if it does not contain something that looks like a filesystem path. For example: if (saved_root_name[0] == '/') ... (In reply to Mike Gilbert from comment #7) > When grub-probe sees a PARTUUID, it does not know what to do with it and > gives up. I guess it would be more correct to say that grub-probe treats it as a filesystem path, as indicated in comment 1. Info: Cross-checking with vanilla-sources-3.18.10, I get: [code] # grub-mkconfig -o /boot/grub/grub.cfg Generating grub configuration file ... /usr/sbin/grub-probe: error: cannot find a GRUB drive for PARTUUID=149D7E31-31B0-48CF-BF26-3C9A1A8B4286. Check your device.map. Found linux image: /boot/vmlinuz-3.18.10 /usr/sbin/grub-probe: error: cannot find a GRUB drive for PARTUUID=149D7E31-31B0-48CF-BF26-3C9A1A8B4286. Check your device.map. done [/code] There is no "device.map" below /boot or /boot/grub. [code] /dev/disk/by-partuuid # cll | grep -i "149D7E31-31B0-48CF-BF26-3C9A1A8B4286" lrwxrwxrwx 1 root root 10 Mar 26 18:00 149d7e31-31b0-48cf-bf26-3c9a1a8b4286 -> ../../sdb5 [/code] BUT, nevertheless: A correct grub.conf including "root=PARTUUID=149D7E31-..." gets created. Perhaps this may help ... (In reply to Manfred Knick from comment #10) That should be impossible. Please show /proc/self/moutinfo, and uname -r. Also, do you still have some funky setting of GRUB_DEVICE_ROOT or GRUB_CMDLINE_LINUX in /etc/default/grub? (In reply to Mike Gilbert from comment #11) > (In reply to Manfred Knick from comment #10) > > That should be impossible. . . . .^^^^^^ . . . I agree ;) > Please show /proc/self/moutinfo, and uname -r. # cat /proc/self/mountinfo 15 0 8:21 / / rw,noatime,nodiratime - ext4 /dev/root rw,discard,data=ordered ... # uname -r 3.18.10 > Also, do you still have some funky setting of GRUB_DEVICE_ROOT or > GRUB_CMDLINE_LINUX in /etc/default/grub? # grep -v "#" /etc/default/grub GRUB_DISTRIBUTOR="Gentoo" GRUB_DEFAULT=0 GRUB_TIMEOUT=5 GRUB_DEVICE=PARTUUID=149D7E31-31B0-48CF-BF26-3C9A1A8B4286 GRUB_DISABLE_RECOVERY=true GRUB_CMDLINE_LINUX=". . ." # mv grub.cfg grub.999 # grub-mkconfig -o /boot/grub/grub.cfg Generating grub configuration file ... /usr/sbin/grub-probe: error: cannot find a GRUB drive for PARTUUID=... Check your device.map. Found linux image: /boot/vmlinuz-3.18.10 /usr/sbin/grub-probe: error: cannot find a GRUB drive for PARTUUID=... Check your device.map. done # ll grub.* -rw------- 1 root root 4.6K Mar 26 19:26 grub.999 -rw------- 1 root root 4.6K Mar 26 19:32 grub.cfg # grep "root=" grub.cfg ... linux /vmlinuz-3.18.10 root=PARTUUID=... ... linux /vmlinuz-3.18.10 root=PARTUUID=... ... Strange ... (In reply to Manfred Knick from comment #12) > (In reply to Mike Gilbert from comment #11) > > (In reply to Manfred Knick from comment #10) P.S.: My > GRUB_CMDLINE_LINUX only contains driver sspecific stuff - nothing related to "grub" or "boot": GRUB_CMDLINE_LINUX= "snd-hda-intel.model=6stack-digout acpi_enforce_resources=lax pcie_aspm=off" (In reply to Manfred Knick from comment #12) > GRUB_DEVICE=PARTUUID=149D7E31-31B0-48CF-BF26-3C9A1A8B4286 That's the culprit. grub has never claimed to support that syntax. Not sure it's relevant (or helpful), though I saw the same "/usr/sbin/grub-probe: error: cannot find a GRUB drive for PARTUUID=." message on grub2-mkconfig after I first altered /etc/default/grub, and yet a new grub.cfg was created. After rebooting and seeing PARTUUID in the output of df, the behavior of grub2-mkconfig changed - it would no longer update grub.cfg unless I did the ln -s thing noted in comment 1. If this is a gentoo kernel patch issue, then I should close the upstream bug, right? (In reply to Mike Gilbert from comment #14) > (In reply to Manfred Knick from comment #12) > > GRUB_DEVICE=PARTUUID=149D7E31-31B0-48CF-BF26-3C9A1A8B4286 > > That's the culprit. grub has never claimed to support that syntax. I see :( The GRUB" online documentation is only talking about _file system UUID_ , right? !Sorry! for the noise ... The linux kernel supports "root=PARTUUID=..." - at least for GPT-based root disk partitions; and unfortunately, without an initramfs, AFAIK it's the only way to specify them indepenantly to disk additions/removals ... My misunderstanding that grub2 would be able to manage PARTUUIDs as default entry :( Well: - generate grub.conf with "root=/dev/sdb5" in /etc/defaults/grub - vim: "/dev/sdb5" --> "PARTUUID=..." ? That can't be the final solution ! # grep -R -n "cannot find a GRUB drive for" points to util/grub-probe.c:315 which seems to be a purely "check" loop. So it just "works" somehow "by accident" - because afterwards, although "non-digestible", this string is nevertheless placed into "root=" ? Sorry - at the time being, I'm too tired to investigate this further. HTH Thanks a lot Manfred (In reply to BobbyK from comment #15) > If this is a gentoo kernel patch issue, then I should close the upstream > bug, right? Perhaps not "close" but "modify" ;) A) This heavily (some people say over-) engineered beast should support PARTUUID ! B) It's logic seems - well - "a little bit strange". Humble questions arise in regard to the kernel developers: a1) I still don't really understand why the linux kernel, having the respective filesystems configured as "*" and not as a module, cannot detect/deliver the appropriate _file system UUID_ for root; this seems a "lack" or "anachronism" to me. a2) Similarly: Why only FS UUID - but not FS LABEL? Just my 2 cents ... (In reply to Manfred Knick from comment #16) But then, why does this ERROR message arise twice?! Adding WilliamH, the author of the patch, for his thoughts. (In reply to Mike Pagano from comment #19) > Adding WilliamH, the author of the patch, for his thoughts. According to bug 438380 comment 12, Cardoe authored it. In any case, I think kernel support for mounting via root=PARTUUID=xxx either did not exist at that time, or nobody considered that possibility. (In reply to Mike Gilbert from comment #20) > (In reply to Mike Pagano from comment #19) > > Adding WilliamH, the author of the patch, for his thoughts. > > According to bug 438380 comment 12, Cardoe authored it. > > In any case, I think kernel support for mounting via root=PARTUUID=xxx > either did not exist at that time, or nobody considered that possibility. Thanks for that correction. (In reply to Mike Gilbert from comment #20) > In any case, I think kernel support for mounting via root=PARTUUID=xxx > either did not exist at that time, or nobody considered that possibility. . . . Linux 2.6.37 . . . RC1 2010-11-01 . . . Release: 2011-01-04 (Remember? "Bye bye BKL") was the first to recognize the partition uuid (not not filesystem uuid). One of the first "Cookbooks" exploiting "root=PARTUUID=" I know of dates from 2011-01-25: . . . "The whole point of this exercise is to show you . . . how to avoid the need for an initrd in the first place." [ archives.gentoo.org :) ] GRUB2 "complete rewrite" was announced as early as 2008-06-07. Around 2002, GRUB version 0.9x was renamed GRUB Legacy. Beginning October 2009 till September 2012, the "big" Distributions had switched to GRUB2. Grub-legacy finally phased out around 2012-12-01. Kernel 3.2 brought an additional "offset" as enhancement of the notification: . . . "init: add root=PARTUUID=UUID/PARTNROFF=%d support" [ http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=79975f1327850ef198ada994c2fc44b7d1ea8935 ] (In reply to Mike Gilbert from comment #20) > (In reply to Mike Pagano from comment #19) > > Adding WilliamH, the author of the patch, for his thoughts. > > According to bug 438380 comment 12, Cardoe authored it. > > In any case, I think kernel support for mounting via root=PARTUUID=xxx > either did not exist at that time, or nobody considered that possibility. Did you try your suggestion above if (saved_root_name[0] == '/') ... Looks reasonable to me to exclude root=PARTUUID... A real and clean enhancement would be the addition of a . . . GRUB_DEVICE_PARTUUID parameter and support into GRUB2. Exploiting the kernel "root=PARTUUID=..." parameter, every need for "searching", "translating" and interpretations would be gone. (In reply to Anthony Basile from comment #23) No, I have not personally tested it. (In reply to Manfred Knick from comment #24) If you want to write a patch to make grub support PARTUUIDs, you are welcome to do so. But you would need to get that accepted upstream. Also, you would need to add that support to grub-probe; upstream would want it to get probed rather than having a static value /etc/default/grub. In any case, I think it is outside the scope of this bug report. (In reply to Mike Gilbert from comment #25) > (In reply to Anthony Basile from comment #23) > > No, I have not personally tested it. I have - didn't help :( (In reply to BobbyK from comment #27) > I have - didn't help :( What exactly did you test? Did you remove any reference to PARTUUID from /etc/default/grub? Did /dev/root show up in /proc/self/mountinfo? What was the grub-probe output? (In reply to Mike Gilbert from comment #28) > (In reply to BobbyK from comment #27) > > I have - didn't help :( > > What exactly did you test? > > Did you remove any reference to PARTUUID from /etc/default/grub? > > Did /dev/root show up in /proc/self/mountinfo? > > What was the grub-probe output? I tested: --- if (saved_root_name[0]) +++ if (saved_root_name[0] == '/') in init/do_mounts.c - nothing else I see: 15 0 8:98 / / rw,noatime - ext3 PARTUUID=604e76f6-02 rw,data=ordered in /proc/self/mountinfo (/dev/root does not appear) # grub2-probe / grub2-probe: error: failed to get canonical path of `PARTUUID=604e76f6-02'. I did not remove PARTUUID references from /etc/default/grub - I thought the purpose was to have such a config work. (In reply to BobbyK from comment #29) > I tested: > > --- if (saved_root_name[0]) > +++ if (saved_root_name[0] == '/') > > in init/do_mounts.c - nothing else. I just tested the change, and it worked as expected. I assume that you failed to update the check in the mount_root() function. You're right - i updated the wrong if :(. Apologies. # grub2-probe / ext2 (well it's ext3, though I don't know it matters) # grep root /proc/self/mountinfo 15 0 8:98 / / rw,noatime - ext3 /dev/root rw,data=ordered # grep PARTUUID /etc/default/grub GRUB_DEVICE="PARTUUID=604e76f6-02" Many thanks for setting me straight. Noticed that I no longer have a rootfs entry in df output along the lines of, without the change to do_mounts: # df -m Filesystem 1M-blocks Used Available Use% Mounted on rootfs 57952 13568 41434 25% / PARTUUID=PARTUUID=604e76f6-02 57952 13568 41434 25% / with the change to do_mounts: # df -m Filesystem 1M-blocks Used Available Use% Mounted on /dev/root 57952 13568 41434 25% / Added check to patch and queued as indicated. All gentoo-sources kernel versions that will have this updated patch are now released. Thanks, everyone. This is back in 4.0.5:
# diff linux-3.18.12-gentoo/init/do_mounts.c linux-4.0.5-gentoo/init/do_mounts.c | grep saved_root
< if (saved_root_name[0] == '/') {
> if (saved_root_name[0]) {
# grub2-mkconfig -o /boot/grub/grub.cfg
/usr/sbin/grub2-probe: error: failed to get canonical path of `PARTUUID=604e76f6-02'.
Thanks for reporting. This patch never made it to 4.0. Staged now for 4.0 and 4.1. Closing as it's been in the patchset for awhile now. |
I've just noticed I can no longer update my grub2 configuration using grub2-update, because grub2-probe fails. Even though I've recently updated my system it's hard to correlate this to a specific ebuild other than grub itself because I haven't changed my kernel for a while and this could be the result of a previous round of updates -- or I may not have updated my config after the last update of grub. After installing the kernel, I ran: # grub2-mkconfig /usr/sbin/grub2-probe: error: failed to get canonical path of PARTUUID=1c8134cd-d9c0-4e5c-b347-bb6fc44a777f. My root partition is on a disk with GPT and has the partition GUID as shown above. In my /etc/default/grub, I have added: GRUB_DEVICE="PARTUUID=1c8134cd-d9c0-4e5c-b347-bb6fc44a777f" In the past, this worked fine and generated a working config. The command line passed to my kernel is as follows: # cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.7.10-gentoo root=PARTUUID=1c8134cd-d9c0-4e5c-b347-bb6fc44a777f ro quiet iommu=pt raid=noautodetect This, however, makes the root filesystem show up as PARTUUID=... in both /etc/mtab and /proc/mounts (my mtab is not symlinked): # cat /etc/mtab | grep ' / ' rootfs / rootfs rw 0 0 PARTUUID=1c8134cd-d9c0-4e5c-b347-bb6fc44a777f / ext4 rw,noatime,discard,errors=remount-ro,commit=0 0 0 It seems grub2-mkconfig invokes grub2-probe, and grub2-probe checks either /etc/mtab or /proc/mounts. Running grub2-probe manually does not yield any extra helpful information: # grub2-probe --device-map=/boot/grub2/device.map --target=fs -v / grub2-probe: error: failed to get canonical path of PARTUUID=1c8134cd-d9c0-4e5c-b347-bb6fc44a777f. Probing any other filesystem with grub2-probe which is not mounted using PARTUUID=... works fine ('-v' ommitted): # grub2-probe --device-map=/boot/grub2/device.map --target=fs /boot ext2 Note -- the above error is unrelated to the variables in /etc/default/grub. Reproducible: Always Steps to Reproduce: 1. Use root partition from GPT disk and pass root=PARTUUID=<root_partition_uuid> on kernel command line 2. Run grub2-update Actual Results: Step 2 fails with: grub2-probe: error: failed to get canonical path of PARTUUID=<root_partition_uuid>. Expected Results: Step 2 outputs valid grub configuration. # emerge --info grub Portage 2.1.11.62 (default/linux/amd64/13.0, gcc-4.6.3, glibc-2.15-r3, 3.7.10-gentoo x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.7.10-gentoo-x86_64-AMD_Phenom-tm-_II_X4_910e_Processor-with-gentoo-2.2 KiB Mem: 8114116 total, 7304044 free KiB Swap: 0 total, 0 free Timestamp of tree: Thu, 25 Apr 2013 16:45:01 +0000 ld GNU ld (GNU Binutils) 2.22 app-shells/bash: 4.2_p37 dev-lang/python: 2.7.3-r3, 3.2.3-r2 dev-util/cmake: 2.8.9 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.12.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.6.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.7 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo consistency ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -fomit-frame-pointer -march=native -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /usr/share/openvpn/easy-rsa /usr/share/shorewall/configfiles /var/spool/munin-async/.ssh" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/init.d /etc/php/apache2-php5.4/ext-active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -fomit-frame-pointer -march=native -pipe" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="ftp://ftp.free.fr/mirrors/ftp.gentoo.org/ ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo http://mirror.netcologne.de/gentoo/ rsync://mirror.netcologne.de/gentoo/" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j6" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/consistency" SYNC="rsync://rsync.fr.gentoo.org/gentoo-portage" USE="3dnow X aac acpi alsa amd64 bash-completion bluray bzip2 cli consistency_net_bond consistency_net_vlan consistency_server consistency_sw_raid cracklib crypt css cxx dri exif fat ffmpeg flac foomaticdb ftp gif graphite iconv icu id3tag jpeg jpeg2k live lzma mad matroska mmx modules mp3 mpeg mudflap multilib ncurses nls nptl ntp ogg opengl openmp pam pcre png policykit quicktime readline resolvconf rtsp sdl session sse sse2 ssl syslog tcpd threads tiff truetype udev unicode vcd vcdx vdpau vim-syntax vorbis x264 xattr xcb xml xv xvid xvmc zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias authn_default authz_default authz_host cache cgi cgid dir env file_cache headers info log_config mem_cache mime mime_magic rewrite setenvif status" APACHE2_MPMS="prefork" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" GRUB_PLATFORMS="pc" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en en_US" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-4" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON ================================================================= Package Settings ================================================================= sys-boot/grub-2.00-r2 was built with the following: USE="(multilib) nls (-custom-cflags) -debug -device-mapper -doc -efiemu -libzfs -mount (-sdl) -static (-truetype)" ABI_X86="64" GRUB_PLATFORMS="pc -coreboot -efi-32 -efi-64 -emu -ieee1275 -multiboot -qemu -qemu-mips -yeeloong" CFLAGS="" LDFLAGS=""