Summary: | emerge -Duv system results in "'portage' user or group not found" (error 530 due to cloexec & broken kernel) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | c1de0x |
Component: | [OLD] Unspecified | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED INVALID | ||
Severity: | major | CC: | python, toolchain |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://sourceware.org/bugzilla/show_bug.cgi?id=5227 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
c1de0x
2009-03-16 19:29:24 UTC
Anyone have any ideas for a workaround on this? It is currently blocking a production server! Can you roll back to the previous version of glibc? you're using 2.6.18 ... that's pretty uncommon nowadays and probably why it's not working try running: python -c 'import os; print os.listdir("/");' Zac: How do I roll back without portage? SpanKY: # python -c 'import os; print os.listdir("/");' ['tmp', 'dev', 'home', 'var', 'sbin', 'lib', 'sys', 'root', 'bin', '.bash_history', 'mnt', 'lost+found', 'usr', 'boot', 'opt', 'proc', 'etc', '.joe_state'] # uname -a Linux hostname 2.6.18-8.1.10.el5xen #1 SMP Thu Sep 13 13:20:55 EDT 2007 i686 Intel(R) Core(TM)2 Quad CPU @ 2.40GHz GenuineIntel GNU/Linux As it is a hosted VPS running on xen, I don't think I can easily upgrade the kernel. Or can I? If so, can you point me at some info on how to do so? yes, but antiquated systems like 2.6.18 means they receive little testing and so you're likely to hit very narrow corner case bugs like this that listdir working is kind of annoying because it'll be hard to reduce down what is actually failing ... if we can narrow things down on your system, it'll make my search of the source code a lot easier how about this snippet: mkdir -p /var/tmp/portage/a/b/c/d/e/f/g python -c 'import shutil; shutil.rmtree("/var/tmp/portage/a");' # mkdir -p /var/tmp/portage/a/b/c/d/e/f/g # python -c 'import shutil; shutil.rmtree("/var/tmp/portage/a");' # BTW: I'm on the IRC if you prefer to communicate that way. i booted a 2.6.18 system under qemu and it has glibc-2.8, but i wasnt able to reproduce your error i dont suppose you can create a non-root account for me to create a test case ? http://dev.gentoo.org/~vapier/ssh-pub-key it would seem that your kernel is rejecting open() when O_CLOEXEC is specified (0x80000 == O_CLOEXEC) open("/proc/2264/fd", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = -530 open("/etc/passwd", O_RDONLY|0x80000 /* O_??? */) = -530 along those lines, can you try this test: $ cat test.c main(){open("/dev/null", 0x80000);} $ gcc test.c -static $ strace -eopen ./a.out ok, your kernel is broken, sorry. see the upstream URL for more details. ive added a check to the glibc ebuild so it'll abort if a broken kernel is detected. you'll have to get a kernel update to resolve the issue. http://sources.gentoo.org/sys-libs/glibc/glibc-2.7-r2.ebuild?r1=1.14&r2=1.15 http://sources.gentoo.org/sys-libs/glibc/glibc-2.8_p20080602.ebuild?r1=1.13&r2=1.14 http://sources.gentoo.org/sys-libs/glibc/glibc-2.8_p20080602-r1.ebuild?r1=1.10&r2=1.11 http://sources.gentoo.org/sys-libs/glibc/glibc-2.9_p20081201.ebuild?r1=1.3&r2=1.4 http://sources.gentoo.org/sys-libs/glibc/glibc-2.9_p20081201-r1.ebuild?r1=1.5&r2=1.6 http://sources.gentoo.org/sys-libs/glibc/files/eblits/pkg_setup.eblit?r1=1.1&r2=1.2 |