I have FEATURES=test enabled on a stable x86 system, and during the test phase of sys-libs/glibc the disk became full. However, the installation continued, i.e. the old working glibc got removed, and nothing got installed in place of it. This happened in a VM, so all details should be recoverable (when I'm writing this, the system is still running). I have logs on disk, but I don't know how to upload them without rebooting. If you'd like to get some info from the system before it's rebooted, please let me know. Here are some log snippets: libs/glibc-2.11.2-r3/temp/ccY7QVPH.s: No space left on device compilation terminated. make[2]: *** [/var/tmp/portage/sys-libs/glibc-2.11.2-r3/work/build-default-i686-pc-linux-gnu-nptl/elf/check-localplt] Error 1 make[2]: Target `tests' not remade because of errors. make[2]: Leaving directory `/var/tmp/portage/sys-libs/glibc-2.11.2-r3/work/glibc-2.11.2/elf' make[1]: *** [elf/tests] Error 2 ... e/wctype.h > /var/tmp/portage/sys-libs/glibc-2.11.2-r3/work/build-default-i686-pc-linux-gnu-nptl/begin-end-check.out make[1]: Target `check' not remade because of errors. make[1]: Leaving directory `/var/tmp/portage/sys-libs/glibc-2.11.2-r3/work/glibc-2.11.2' make: *** [check] Error 2 ^[[33;01m*^[[0m make check failed for default-i686-pc-linux-gnu-nptl Traceback (most recent call last): File "/usr/lib/portage/bin/filter-bash-environment.py", line 148, in <module> re.compile(var_pattern), file_in, file_out) File "/usr/lib/portage/bin/filter-bash-environment.py", line 79, in filter_bash_environment file_out.write(line.replace("\1", "")) IOError: [Errno 28] No space left on device >>> Install glibc-2.11.2-r3 into /var/tmp/portage/sys-libs/glibc-2.11.2-r3/image/ category sys-libs >>> Completed installing glibc-2.11.2-r3 into /var/tmp/portage/sys-libs/glibc-2.11.2-r3/image/ ^[[33;01m * ^[[39;49;00mQA Notice: Expected SLOT='2.2', got '' [Errno 2] No such file or directory: /bin/bash -c "/usr/lib/portage/bin/ebuild.sh" postinst Traceback (most recent call last): File "/usr/lib/portage/pym/portage/process.py", line 249, in spawn env, gid, groups, uid, umask, pre_exec) File "/usr/lib/portage/pym/portage/process.py", line 378, in _exec os.execve(binary, myargs, env) File "/usr/lib/portage/pym/portage/__init__.py", line 228, in __call__ rval = self._func(*wrapped_args, **wrapped_kwargs) OSError: [Errno 2] No such file or directory [Errno 2] No such file or directory: /usr/bin/sandbox "/usr/lib/portage/bin/misc-functions.sh" die_hooks Traceback (most recent call last): File "/usr/lib/portage/pym/portage/process.py", line 249, in spawn env, gid, groups, uid, umask, pre_exec) File "/usr/lib/portage/pym/portage/process.py", line 378, in _exec os.execve(binary, myargs, env) File "/usr/lib/portage/pym/portage/__init__.py", line 228, in __call__ rval = self._func(*wrapped_args, **wrapped_kwargs) OSError: [Errno 2] No such file or directory !!! FAILED postinst: 1 [Errno 2] No such file or directory: /usr/bin/sandbox "/usr/lib/portage/bin/misc-functions.sh" success_hooks Traceback (most recent call last): File "/usr/lib/portage/pym/portage/process.py", line 249, in spawn env, gid, groups, uid, umask, pre_exec) File "/usr/lib/portage/pym/portage/process.py", line 378, in _exec os.execve(binary, myargs, env) File "/usr/lib/portage/pym/portage/__init__.py", line 228, in __call__ rval = self._func(*wrapped_args, **wrapped_kwargs) OSError: [Errno 2] No such file or directory [Errno 2] No such file or directory: /usr/bin/sandbox "/usr/lib/portage/bin/misc-functions.sh" die_hooks Traceback (most recent call last): File "/usr/lib/portage/pym/portage/process.py", line 249, in spawn env, gid, groups, uid, umask, pre_exec) File "/usr/lib/portage/pym/portage/process.py", line 378, in _exec os.execve(binary, myargs, env) File "/usr/lib/portage/pym/portage/__init__.py", line 228, in __call__ rval = self._func(*wrapped_args, **wrapped_kwargs) OSError: [Errno 2] No such file or directory
Include portage version and re-assign to dev-portage, I'd guess.
phajdan.jr: yes, those logs would be nice to have. You have a bash shell, so use the TCP functionality of bash to send the data to netcat. on some other system, near the VM ideally: # nc -l -s $COLLECTOR_IP -p 9999 | tee /tmp/glibc.log on the broken system: # exec 3<>/dev/tcp/$COLLECTOR_IP/9999 # cat $LOGFILE >&3 done :-) (you'll have to make sure your firewalls are suitably open). vapier: at a glance, the glibc src_test should correctly stop portage on failure, but maybe I missed something?
(In reply to comment #2) > # exec 3<>/dev/tcp/$COLLECTOR_IP/9999 > # cat $LOGFILE >&3 I don't have cat there (bash: /bin/cat: No such file or directory). Of course it exists, it just can't be launched. Anyway, I can get the logs by booting from a LiveCD. I'm just waiting in case there is something in the running system that would disappear after reboot.
hmm, do you have a static copy of busybox around on the system? launch that to give yourself space to recover. As long as none of your critical stuff is on tmpfs, you're good to reboot.
base-system has nothing to do with the toolchain that said, i dont see the need to implement any specific hack in the glibc ebuild to workaround detection problems in the PM. there are plenty of ebuilds which could "screw" the system, but as Robin points out, there is always the static busybox rescue shell.
vapier: i'm more concerned at that src_test didn't fail when I think it should.
Created attachment 254435 [details] build.log (merge)
Created attachment 254437 [details] build.log (unmerge)
(In reply to comment #0) > Traceback (most recent call last): > File "/usr/lib/portage/bin/filter-bash-environment.py", line 148, in <module> > re.compile(var_pattern), file_in, file_out) > File "/usr/lib/portage/bin/filter-bash-environment.py", line 79, in > filter_bash_environment > file_out.write(line.replace("\1", "")) > IOError: [Errno 28] No space left on device This part should be handled in portage-2.1.9, by this commit: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=451f102ad2e3bf62c9c6bdf5b1786c88352bad10 Checking space prior to merge still isn't implemented (bug #23851). Due to the practice of using separate filesystems for things like /usr and /var, I guess we'll have to do statvfs calls on (at least) each of the relevant top-level directories.
duping to newer bug as it has technical general discussions for this (not specific to glibc) *** This bug has been marked as a duplicate of bug 451024 ***
