> > I think I know what's going on. Check and make sure /dev/null exists
> > and is a device file. If it isn't e2fsck will hang in a loop in
> > reserve_stdio_fds(). This fix is obvious; if open of /dev/null returns
> > -1, print an error message and break out of the while loop.
> > - Ted
>
> Why would this have happened all of a sudden? A bad package in Potato?
> Would it have anything at all to do with the power going out? I'm not the
> one to fix the code (yet). Does this have anything to do with Linux
> caching stuff in memory and not writing to disk right away like other OS's
> do?
This would have happened if /dev/null doesn't exist (or is a regular
file). e2fsck currently assumes that /dev/null exists and can be opened
read-write even when the root filesystem is mounted read-only. This is
true if /dev/null is a device file.
If a system administrator accidentally deletes /dev/null, or if some
kind of filesystem crash somehow manages to cause /dev/null to get
deleted or its inode corrupted, then e2fsck 1.14 will loop; this is a
bug. So the proximate cause of why this happened all of a sudden is
that /dev/null disappeared or got replaced by a regular file somehow.
Now why **that** happened is a very good question. If you had a
suspicious crash, then that might have caused the problem.
I doubt this has anything to do with Linux cacheing stuff in memory.
All serious OS's (NT, Windows 98, other Unixes, etc.) all don't do write
cacheing and don't write to disk right away. You take a serious
performance hit if you don't.
In any case, the fatest way to recover this is to simply recreate the
/dev/null device. The code change will make e2fsck more robust in the
future, and indeed I've made such a fix to my working sources already.
A new version of e2fsprogs will be released shortly
which obviates this problem. (As well as adding progress bars for
e2fsck, and a number of other nice things.)