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? -- Regards, Mick
