Module Size Used by
ipchains 33624 7
ipx 18724 0 (unused)
3c59x 27968 1 (autoclean)
nls_cp437 4472 4 (autoclean)
isofs 17264 0 (unused)
loop 8536 0 (unused)
sr_mod 11996 0 (unused)
cdrom 27872 0 [sr_mod]
BusLogic 35832 7
sd_mod 10168 14
scsi_mod 51808 3 [sr_mod BusLogic sd_mod]
However, after running it for an hour, I tried to reboot. The
root file-system was permanently busy so it didn't get un-mounted.
Upon re-boot, there was a very long fsck in which a lot of
stuff had to be "fixed", much more than simply a bad dismount.
Then, fsck failed (stopped) in the middle. I waited about 15 minutes
and hit the reset switch. After than, no executable files could
execute. Booting and mounting an alternate root, I found that
/etc/ld.so.cache had been destroyed as well as several of the
important runtime files. I have retrieved the bad ld.so.cache file
if anyone wants it. Fortunately I have several copies of the
runtime libraries.
Currently, I'm back using 2.4.18 (which works). I have about
40 files in lost+found that I'm reviewing to see if they are
important. There are several pieces of many library files that
were mmapped. I find libc.so.6, libtermcap, etc. These memory-
mapped files should have never been written to, however I
think that a corrupted memory image can get written back to
the file(s). I'm currently building another root file-system to
destroy and I think that if I do `cp /dev/zero /dev/mem` the
underlying memory-mapped files can get written in spite of
that fact that they are read/exec only.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/