Ok, was just doing a "fsck.ext3 -c -c -C 1 /dev/xvda" from within a rescue OS provided by my VPS provider... and it froze at the middle of it!!!
So I guess Gentoo is not responsible after all... I've opened a support ticket with them... I'll let you know how it turns out. Simon On Fri, Jan 7, 2011 at 2:42 PM, Simon <[email protected]> wrote: > Ok, it actually just "froze" again after the output below... > > ///////////////////////////////////////////// >>>> Emerging (42 of 151) sys-devel/autoconf-2.65-r1 > * autoconf-2.65.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok > ] > * Package: sys-devel/autoconf-2.65-r1 > * Repository: gentoo > * Maintainer: [email protected] > * USE: elibc_glibc kernel_linux userland_GNU x86 >>>> Unpacking source... >>>> Unpacking autoconf-2.65.tar.bz2 to >>>> /mnt/tmp/portage/sys-devel/autoconf-2.65-r1/work > * Applying autoconf-2.65-AC_TYPE_INT_T.patch ... [ ok > ] >>>> Source unpacked in /mnt/tmp/portage/sys-devel/autoconf-2.65-r1/work >>>> Compiling source in >>>> /mnt/tmp/portage/sys-devel/autoconf-2.65-r1/work/autoconf-2.65 ... > * econf: updating autoconf-2.65/build-aux/config.guess with > /usr/share/gnuconfig/config.guess > * econf: updating autoconf-2.65/build-aux/config.sub with > /usr/share/gnuconfig/config.sub > ./configure --prefix=/usr --build=i686-pc-linux-gnu > --host=i686-pc-linux-gnu --mandir=/usr/share/man > --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc > --localstatedir=/var/lib --program-suffix=-2.65 > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... /bin/mkdir -p > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking whether /bin/sh -n is known to work... yes > checking for characters that cannot appear in file names... none > checking whether directories can have trailing spaces... yes > checking for expr... /usr/bin/expr > checking for GNU M4 that supports accurate traces... /usr/bin/m4 > checking whether /usr/bin/m4 accepts --gnu... yes > checking how m4 supports trace files... --debugfile > checking for perl... /usr/bin/perl > checking whether /usr/bin/perl Fcntl::flock is implemented... yes > checking for emacs... no > checking for emacs... no > checking where .elc files should go... ${datadir}/emacs/site-lisp > checking for grep that handles long lines and -e... /bin/grep > checking for egrep... /bin/grep -E > checking for a sed that does not truncate output... /bin/sed > checking whether make is case sensitive... yes > configure: creating ./config.status > config.status: creating tests/Makefile > config.status: creating tests/atlocal > config.status: creating man/Makefile > config.status: creating lib/emacs/Makefile > config.status: creating Makefile > config.status: creating doc/Makefile > config.status: creating lib/Makefile > config.status: creating lib/Autom4te/Makefile > config.status: creating lib/autoscan/Makefile > config.status: creating lib/m4sugar/Makefile > config.status: creating lib/autoconf/Makefile > config.status: creating lib/autotest/Makefile > ////////////////////////////////// > > On Fri, Jan 7, 2011 at 2:40 PM, Simon <[email protected]> wrote: >> Ok, the fsck reported nothing wrong... >> I still got the same bug again... while doing `emerge -e @system`... >> It got stuck right after the ">>> Installing" line below... >> >> Dale, I just checked my python version and it was already 2.6, i set >> it to 2.6 again, just in case, and continued my emerge (the ctrl-z + >> %% worked at this point). >> >> I'll reply here again with the next issue... >> >> Thanks, >> Simon >> >> //////////////////////////////////////////////////////// >>>>> Emerging (35 of 151) sys-devel/binutils-config-1.9-r4 >> * Package: sys-devel/binutils-config-1.9-r4 >> * Repository: gentoo >> * Maintainer: [email protected] >> * USE: elibc_glibc kernel_linux userland_GNU x86 >>>>> Unpacking source... >>>>> Source unpacked in /mnt/tmp/portage/sys-devel/binutils-config-1.9-r4/work >>>>> Compiling source in >>>>> /mnt/tmp/portage/sys-devel/binutils-config-1.9-r4/work ... >>>>> Source compiled. >>>>> Test phase [not enabled]: sys-devel/binutils-config-1.9-r4 >> >>>>> Install binutils-config-1.9-r4 into >>>>> /mnt/tmp/portage/sys-devel/binutils-config-1.9-r4/image/ category >>>>> sys-devel >>>>> Completed installing binutils-config-1.9-r4 into >>>>> /mnt/tmp/portage/sys-devel/binutils-config-1.9-r4/image/ >> >> ecompressdir: bzip2 -9 /usr/share/man >> >>>>> Installing (35 of 151) sys-devel/binutils-config-1.9-r4 >> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >> >> >> >> >> On Fri, Jan 7, 2011 at 1:22 PM, Dale <[email protected]> wrote: >>> Simon wrote: >>>> >>>> Hi there, >>>> something went wrong during a previous update and now revdep-rebuild >>>> will kind-of freeze around 30%. When it freezes like that, the >>>> hosting company shows one of it's CPU core is used at 100% non-stop >>>> and the rest is idle. I have tried `emerge -e world` and with system, >>>> they all fail similarly. >>>> >>>> I managed to reconfigure it to have a working console and started >>>> the `emerge -e system` from the console. After a while it froze, but >>>> typed a ctrl-z to suspend the process, then %% to resume it and it >>>> "unlocked" it. It often hung like in between two phases of the emerge >>>> process (like after unpacking source, or just before doing the >>>> install, etc). I was able to resume the emerge like that a good dozen >>>> times until now, and now it's really locked, not responding at all... >>>> seems like all 4 cores are used at 100%. >>>> >>>> It hung while emerging perl and I've included the output on the >>>> console below so you can see exactly where it hung. I will now force >>>> a reboot on it and retry emerging just perl, I will reply to the list >>>> with my results of that. >>>> >>> >>> <<SNIP>> >>> >>> Have you enabled python3 by any chance? eselect python list should show 2.6 >>> as the active python. >>> >>> Just a thought. Someone else did this the other day and had troubles. >>> >>> Dale >>> >>> :-) :-) >>> >>> >> >
