Doug Poland wrote:
On Mon, November 26, 2007 15:03, Doug Poland wrote:
On Mon, November 26, 2007 14:26, Doug Poland wrote:
Hello,
This morning my 7.0-BETA3 i386 system (Compaq nx7400) reset shortly
after starting X11. I didn't think much of it and went to get a cup
of coffee while the background fsck took care of the file systems.
Unforunately, something's still broke. At first, when I tried to
access the /var or /tmp filesystems, I received panics similar to:
mode = 0100644, inum = 31127, fs = /tmp
panic: ffs_valloc: dup alloc
cpuid = 0
Uptime: 9s
Physical memory: 3435 MB
Dumping 101 MB:Aborting dump due to I/O error.
status == 0x4, scsi status == 0x0
** DUMP FAILED (ERROR 5) **
Automatic reboot in 15 seconds - press a key on the console to abort
After doing some googling, it looked like my filesystems weren't
really clean after several manual runs of fsck. So I disabled
softupdates on /var and /tmp and ran fsck on those file systems
again. After mounting them rw, I attempted to hit the filesystem
again, this time getting a panic:
panic: ffs_clusteralloc: map mismatch
cpuid = 1
Uptime: 6m40s
Physical memory: 3435 MB
Dumping 149 MB:Aborting dump due to I/O error.
status == 0x4, scsi status == 0x0
** DUMP FAILED (ERROR 5) **
Automatic reboot in 15 seconds - press a key on the console to abort
Is there a way to identify and fix these errors? I'm thinking a
newfs of both /var and /tmp is in order. I don't really care
about /tmp, and I've backed up /var using dump(8). My concern is
if I restore /var on top of a newfs'd filesystem, I'll restore my
broken files and have the same problem again.
Just a follow-up... Everytime I run a manual fsck on the problem
filesystems, it returns:
<snip>
BLK(S) MISSING IN BITMAPS
SALVAGE?
<snip>
***** FILE SYSTEM WAS MODIFIED *****
So it would appear that fsck is unable to repair damage, is that
correct?
Well, having stumped all the experts, I decided to reinstall from
7.0-BETA3 CD-ROM. After a few minutes of writing to the disk after
newfs, I got more panic: ffs_clusteralloc: map mismatch errors. Since
the device I'm writing to is a 3-day old Maxtor OneTouch III external
HD, I've decided it must be a hardware failure and am returing the
drive.
Yes, for whatever reason FreeBSD is unable to reliably perform I/O to
the drive (hence the errors dumping).
Kris
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
