After one of the last crashes, the system would lock up a short time after
rebooting. I found the problem caused by background fsck locking up the
system. I took the partition out of the startup check for now. I 'think' I
was installing a port during the last crash, but it has been a while.
I performed a fsck and a dump (to /dev/null) confirming that both do crash
the freebsd 7.2 and 6.2 (which I booted off of a separate drive). A tar
to /dev/null did run successfully, but I recall reading that that is not a
recommended way to backup/move a filesystem. The /usr partition where it
causes trouble is in a raid5 geom_vinum three drive array. I did not yet have
the array rebuild the parity nor do I know if there is any
advantage/disadvantage in doing so (for this problem). I ran a long test on
the drives using smartctl (which is a safer surface check than dd because 1
bad sector on my promise controller will cause a panic; I have an unrelated
drive with a corrupted sector if the promise controller dirver has an
When running fsck, it is somewhere within phase 1 when it crashes. I ran a
truss run of fsck with -aedD and snapped a photo of my screen when it crashed
which I can type up if it is of any use. At the time of freebsd freezing, the
hard drive activity light goes from a faint flicker to on solid for about a
second and then goes out. The system is completely unresponsive where it
locks showing no sign of activity that I have been able to notice.
I imagine the recommendation is start over, but before I do (and likely just
try a tar backup/restore), are there any other suggestions and questions
before I blow away the problem? It would be nice for freebsd users to not be
able to run into such a problem.
As a final question, is there any safe way to crash freebsd (or pull system
power) without a risk of filesystem corruption?
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"