What this indicates to me is that an inode table block was written tothe wrong location on disk. In fact, given large numbers of inodenumbers involved, it looks like large numbers of inode table blockswere written to the wrong location on disk.

So what happend with the file "/etc/rcS.d/S90mountdebugfs" is probably_not_ that it was deleted on September 22nd, but rather sometimerecently the inode table block containing to inode #524788 wasoverwritten by another inode table block, containing a deleted inodeat that relative position in the inode table block.

This must have happened since the last successful boot, since with/etc/rcS.d/S90mountdebugfs pointing at a deleted inode, any attempt toboot the system after the corruption had taken place would haveresulted in catastrophe.

I'm surprised by how many inode tables blocks apparently had gottenmis-directed. Almost certainly there must have been some kind ofhardware failure that must have triggered this. I'm not sure whatcaused it, but it does seem like your filesystem has been toastedfairly badly.

At this point my advice to you would be to try to recover as much datafrom the disk as you can, and to *not* try to run fsck or mount thefilesystem read/write until you are confident you have recovered allof the critical files you care about, or have made a image copy of thedisk using dd to a backup hard drive first. If you're really curiouswe could try to look at the dumpe2fs output and see if we can find thepattern of what might have caused so many misdirected writes, butthere's no guarantee that we would be able to find the definitive rootcause, and from a recovery perspective, it's probably faster and lessrisk to reinstall your system disk from scratch.

Good luck, and I'm sorry your file system had gotten so badlydisrupted.