On Tue, Jun 8, 2010 at 2:01 PM, Mick <michaelkintz...@gmail.com> wrote: > On 8 June 2010 18:42, Mick <michaelkintz...@gmail.com> wrote: >> On 8 June 2010 10:47, Neil Bothwick <n...@digimed.co.uk> wrote: >>> On Mon, 7 Jun 2010 23:46:19 +0200, Alan McKinnon wrote: >>> >>>> Neil is likely correct - filesystem corruption. A quick easy way to >>>> check is to run ls -al starting with the target then going up on >>>> directory in turn. If you start getting lots of "???" in the output, >>>> corruption is almost certain. >>> >>> Paul's suggestion of running lsof may be valid too. If a process had a >>> lock n a file that was then deleted, the file wouldn't show up in ls but >>> would prevent the directory being deleted until the lock was released. >>> >>> If you don't want to mess around with lsof and tracking down the process, >>> a reboot will solve that one. >> >> It seems that the fs was well and truly corrupted. :-( >> >> I looked carefully for ????? output of ls -la, which is a sure warning >> something went sideways with the fs, but unfortunately I couldn't find >> anything wrong. >> >> I have tried throughout the day to recover my machine to no avail. I >> downloaded gcc ebuild and sources from a snapshot and recompiled it >> using a live cd. The same file problem as reported above arose at >> least twice. I have so far run fsck three times - everytime it seems >> to fix the error and then I can delete the rogue directories. >> >> Now tell me, is it possible that each time the fs corrupts itself in >> the same manner - i.e. at the /var/tmp/portage/sys-devel/... ? >> >> I found that /, /var and /usr/portage were corrupted. Each one on its >> own separate partition. Each one on a reiser4 type fs ... >> >> Smartmontools doesn't show any failures/errors. >> >> Is reiser4 prone to corruption? Thankfully my home partition and a >> large data partition both on reiser4 are OK. > > I used dd to zero the partitions, formatted them afresh (again with > reiser4) and then installed gcc-4.4.3-r2 with the Live-CD as part of > re-installing my system. > > I couldn't believe my eyes where I saw this at the end of the emerge: > ======================================================= >>>> /usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3/g++ -> x86_64-pc-linux-gnu-g++ >>>> /usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3/gcc -> x86_64-pc-linux-gnu-gcc >>>> /usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3/gfortran -> >>>> x86_64-pc-linux-gnu-gfortran > * Switching native-compiler to x86_64-pc-linux-gnu-4.4.3 ... [ > ok ] > > * If you have issues with packages unable to locate libstdc++.la, > * then try running 'fix_libtool_files.sh' on the old gcc versions. > >>>> Regenerating /etc/ld.so.cache... > rm: cannot remove > `/var/tmp/portage/sys-devel/gcc-4.4.3-r2/work/gcc-4.4.3/libjava/classpath/resource/gnu/java/locale': > Directory not empty > ======================================================= > > To save me from losing it, can you please tell me if your > /var/tmp/portage has such a stale file in there following your emerge > of gcc-4.4.3-r2 ? Surely I can't blame the fs this time?
Bizarre - out of curiousity, since you've already wiped the partition once - what happens if you dd/wipe/reformat again, but with ext2 or something similarly basic (and non-experimental)? > > -- > Regards, > Mick > >
