Re: Major filesystem problems after crash on 7.0-BETA3 (SOLVED)
On Tue, November 27, 2007 15:22, Kris Kennaway wrote: > 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: >>> >>> >>> BLK(S) MISSING IN BITMAPS SALVAGE? >>> >>> * 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 > New external harddrive solved the problem quite nicely. -- Regards, Doug ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Major filesystem problems after crash on 7.0-BETA3
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: BLK(S) MISSING IN BITMAPS SALVAGE? * 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]"
Re: Major filesystem problems after crash on 7.0-BETA3
On November 27, 2007 09:22:42 am 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: > > > > > > BLK(S) MISSING IN BITMAPS > > SALVAGE? > > > > * 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. I have an older Maxtor drive (40GB) that refuses to allow FreeBSD to install, but has worked flawlessly with Linux. (It would work very slowly in PIO mode, but not DMA, which is not a whole lot of use). I would be interested to hear if your replacement disk works. -- Mike Jeays http://www.jeays.ca ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Major filesystem problems after crash on 7.0-BETA3
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: > > > BLK(S) MISSING IN BITMAPS > SALVAGE? > > * 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. -- Regards, Doug ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Major filesystem problems after crash on 7.0-BETA3
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: BLK(S) MISSING IN BITMAPS SALVAGE? * FILE SYSTEM WAS MODIFIED * So it would appear that fsck is unable to repair damage, is that correct? -- Regards, Doug ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
