Everything using Portage, like emerge, equery, euse, etc-update etc. fails with the follwing error: !!! Failed to complete portage imports. There are internal modules for !!! portage and failure here indicates that you have a problem with your !!! installation of portage. Please try a rescue portage located in the !!! portage tree under '/usr/portage/sys-apps/portage/files/' (default). !!! There is a README.RESCUE file that details the steps required to perform !!! a recovery of portage. No module named missingos This happens after I updated gcc, glibc etc. and did `emerge -e system' twice overnight, which finished without errors. After that everything related to portage fails Reproducible: Always Steps to Reproduce: 1.invoke portage 2. 3. Actual Results: exits with error Expected Results: working Portage `emerge --info' doesn't work obviously. Stable x86 system hardened profile hardened kernel (w/ PaX and grsecurity w/o RBAC) Portage 2.0.51.19 Python 2.3.4 Honestly I don't know if this is PEBKAC or an actual bug, I just want to know what's going on. FYI, I found bug #34820 but it is rather old and I don't know what ot make of it thanks in advance
What python version are you running?
Hi, `python -V' says 2.3.4
What does the following give you? python -c 'import os; print dir(os)'
homer root # python -c 'import os; print dir(os)' ['EX_CANTCREAT', 'EX_CONFIG', 'EX_DATAERR', 'EX_IOERR', 'EX_NOHOST', 'EX_NOINPUT', 'EX_NOPERM', 'EX_NOUSER', 'EX_OK', 'EX_OSERR', 'EX_OSFILE', 'EX_PROTOCOL', 'EX_SOFTWARE', 'EX_TEMPFAIL', 'EX_UNAVAILABLE', 'EX_USAGE', 'F_OK', 'NGROUPS_MAX', 'O_APPEND', 'O_CREAT', 'O_DIRECT', 'O_DIRECTORY', 'O_DSYNC', 'O_EXCL', 'O_LARGEFILE', 'O_NDELAY', 'O_NOCTTY', 'O_NOFOLLOW', 'O_NONBLOCK', 'O_RDONLY', 'O_RDWR', 'O_RSYNC', 'O_SYNC', 'O_TRUNC', 'O_WRONLY', 'P_NOWAIT', 'P_NOWAITO', 'P_WAIT', 'R_OK', 'TMP_MAX', 'UserDict', 'WCONTINUED', 'WCOREDUMP', 'WEXITSTATUS', 'WIFCONTINUED', 'WIFEXITED', 'WIFSIGNALED', 'WIFSTOPPED', 'WNOHANG', 'WSTOPSIG', 'WTERMSIG', 'WUNTRACED', 'W_OK', 'X_OK', '_Environ', '__all__', '__builtins__', '__doc__', '__file__', '__name__', '_copy_reg', '_execvpe', '_exists', '_exit', '_get_exports_list', '_make_stat_result', '_make_statvfs_result', '_pickle_stat_result', '_pickle_statvfs_result', '_spawnvef', 'abort', 'access', 'altsep', 'chdir', 'chmod', 'chown', 'chroot', 'close', 'confstr', 'confstr_names', 'ctermid', 'curdir', 'defpath', 'dup', 'dup2', 'environ', 'error', 'execl', 'execle', 'execlp', 'execlpe', 'execv', 'execve', 'execvp', 'execvpe', 'extsep', 'fchdir', 'fdatasync', 'fdopen', 'fork', 'forkpty', 'fpathconf', 'fstat', 'fstatvfs', 'fsync', 'ftruncate', 'getcwd', 'getcwdu', 'getegid', 'getenv', 'geteuid', 'getgid', 'getgroups', 'getloadavg', 'getlogin', 'getpgid', 'getpgrp', 'getpid', 'getppid', 'getuid', 'isatty', 'kill', 'killpg', 'linesep', 'link', 'listdir', 'lseek', 'lstat', 'major', 'makedev', 'makedirs', 'minor', 'mkdir', 'mkfifo', 'mknod', 'name', 'nice', 'open', 'openpty', 'pardir', 'path', 'pathconf', 'pathconf_names', 'pathsep', 'pipe', 'popen', 'popen2', 'popen3', 'popen4', 'putenv', 'read', 'readlink', 'remove', 'removedirs', 'rename', 'renames', 'rmdir', 'sep', 'setegid', 'seteuid', 'setgid', 'setgroups', 'setpgid', 'setpgrp', 'setregid', 'setreuid', 'setsid', 'setuid', 'spawnl', 'spawnle', 'spawnlp', 'spawnlpe', 'spawnv', 'spawnve', 'spawnvp', 'spawnvpe', 'stat', 'stat_float_times', 'stat_result', 'statvfs', 'statvfs_result', 'strerror', 'symlink', 'sys', 'sysconf', 'sysconf_names', 'system', 'tcgetpgrp', 'tcsetpgrp', 'tempnam', 'times', 'tmpfile', 'tmpnam', 'ttyname', 'umask', 'uname', 'unlink', 'unsetenv', 'utime', 'wait', 'waitpid', 'walk', 'write'] On an additional note, the only problem with portage I could find during the 'emerge -e system' was, quoting from PORT_LOGDIR: > Recalculating the counter... FAILED to update counter. > -rw-r--r-- 1 root root 4 Apr 17 13:58 /var/cache/edb/counter.old > !!! This is a problem.
And there's the problem.
mmmh, you mean the counter thing? How did it happen? Because frankly I fail to see how I could have contributed to this. So it is a bug? After greping through the logfiles like madman, I think it happened during the 2nd run of 'emerge -e system'. There are some error messages like the first one but everything compiled and merged fine, AFAICT. So, is there a way to solve this or should I take the README.RESCUE route? TIA, max
so this works? python -c "import os; print os.lchown"
Nope. homer root # python -c "import os; print os.lchown" Traceback (most recent call last): File "<string>", line 1, in ? AttributeError: 'module' object has no attribute 'lchown'
can you try doing the following? just to test whether you have a glibc with lchown. if you do, then it is very odd that python didn't compile with LCHOWN support. $ cat > lchown-test.c #include <sys/types.h> #include <unistd.h> int main(int argc, void **argv) { lchown(NULL, 0, 0); return 0; } $ gcc -c lchown-test.c see if the above produces any errors, i would doubt that it will fail. anyway, if that works, extract the source of python from your /usr/portage/distfiles and then run ./configure on it and attach the config.log
Created attachment 56764 [details] Python config.log Odd, lchown-test.c compiled fine and the config.log tells me that lchown is there. After searching through the portage logs it seems that everything before and after python (like perl or coreutils) found lchown, but python did not?? config.log is attached. Thanks, max
well, that means the lchown wasn't missing, but something transient made it so that python's configure couldn't detect it. without being able to reproduce it, i can't see how to prevent it from happening agian. although this is the first time i've seen this happen.
So am I correct assuming that there's no (relatively) easy way to reproduce this or find out what happened? If logs or access to the system is of any help, by all means contact me. Oh well, just for reassurance that means portage rescue, remerge python, remerge portage (and a 'emerge -e system' for good measure?) and I'll be good to go. Right? Thanks for your help, much appreciated. Max
unfortunately, i can't think of anything that could help us reproduce it. basically, the easiest way to get it working again. one is to change all instances of "lchown(" to "os.chown(" in /usr/lib/portage/pym/portage.py temporarily, and then emerge python first, then emerge portage. lchown is basically just a safe version of chown that doesn't follow symlinks.
Yes! It worked, though i had to change the lchown stuff in portage_data.py as well. Many thanks! So I guess this bug can be closed now or whatever the appropriate action is to deal with this kind of bug. One last question, could the missing support for lchown halfway trough the 'emerge -e system' have any negative side-effects, IOW should I 'emerge -e system' again? Thanks again, Max
as long as lchown is in python and portage is back using it, then it all should be fine. detection failed at some point in python, but i don't know any other package that requires lchown specifically.
