Summary: | sys-libs/glibc-2.11.2-r3: disk full -> system hosed when $D is merged to $ROOT | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Paweł Hajdan, Jr. (RETIRED) <phajdan.jr> |
Component: | [OLD] Core system | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | robbat2 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log (merge)
build.log (unmerge) |
Description
Paweł Hajdan, Jr. (RETIRED)
2010-11-15 17:47:26 UTC
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 *** |