Normally, I seem to be fairly blessed, and go for ages building new systems
without encountering serious trouble, but now I have a major problem.

Some things work, and some don't.  Examples of working programs:
cat
ifconfig
route
ls
dmesg
fsck
ps
mv
mount

Examples of programs that don't work:
more
grep
uname
netstat
head
tail
file
dumpfs
ftp

These commands just hang forever.  I can control-c out of them, and they
don't leave remnants in ps; but if I hit the debugger switch while the
command is hung and say 'trace', all I get is a trace to the debugger
switch, not the command currently executing.  (It does tell the currently
executing command, though.)  Last note before sending the mail: I was just
noticing that the things that work are in /bin and /sbin, and the things
that don't, aren't.  Might that be a ld problem?

I was running on kernel GENERIC-62 until I rebooted to run #71 (just built
from yesterday's sources), and I've tried #68 and #69.  They all show the
same behavior.

I have tried using the installer (versions e, g and h) to copy in a kernel
for testing, but they all say:
/: bad dir ino 2 at offset 0: mangled entry
Yet, fsck finds nothing wrong with the filesystem.  Does this mean my
filesystem is a level greater than the installer can grok?

In any case, I'm stuck.  I can't get new data into the system, and can't
make what's there go.

Any ideas?  If I do a clri on inum 2 (/. and /..) to try to fsck a repair,
will that totally hose my filesystem?  (I expect it will, which is why I
haven't tried it yet...)

Thanks,
~Steve


-- 
Steve Allen - wormey@eskimo.com   http://www.eskimo.com/~wormey/   ICQ 6709819

Faith is the quality that enables you to eat blackberry jam on a picnic
without looking to see whether the seeds move.

Contrary to popular belief, Unix is user friendly.  
It just happens to be selective about who it makes friends with.
	-Kyle Hearn  <kyle@intex.net>

Lowery's Law:
	If it jams -- force it.  If it breaks, it needed replacing
	anyway.