Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 03 Mar 1998 15:02:45 -0500 (EST)
From:      Stunt Pope <markjr@shmOOze.net>
To:        Doug White <dwhite@resnet.uoregon.edu>
Cc:        freebsd-questions@FreeBSD.ORG
Subject:   Re: superblock corrupted (is BROKEN_KEYNOARD_RESET still applica
Message-ID:  <XFMail.980303151212.markjr@shmOOze.net>
In-Reply-To: <Pine.BSF.3.96.980303110730.20782A-100000@gdi.uoregon.edu>

next in thread | previous in thread | raw e-mail | index | archive | help

On 03-Mar-98 Doug White wrote:
>On Mon, 23 Feb 1998, Stunt Pope wrote:
>
>> We're running several PPro200's with freebsd-current 2.2.2. So far these
>> boxes are in development, not end use. The load on the system is
>> next to nothing. The hardware was purchased brand new about a month
>> ago.
>> 
>> Motherboard: ASUS KN97-X
>> Chipset: Triton Intel 440FX PCIset
>
>Okay; I assue you're not overclocking the PPro.

We're not.

>> At any rate, someone used the "reboot" command to reboot the one server
>> and it came back up with a "Insert System Disk" prompt. I.e. the boot
>> sector was hosed, the superblock toast, or the BSD disklabel was gone. 
>
>Are these disks runing in dedicated mode or compatibility mode, i.e. do
>they have a proper partition table?
>

These are dedicated unix boxes. No multiple boot images, no other o/s.

>> All this alarms me. It's is my first project using freeBSD and I'm not 
>> used to seeing superblocks get wasted for no good reason.
>
>Me neither.  I assume you're keeping backups?

We lost some data the first time. We had backups but we missed some of
it  (yes, i felt like sh*t about it)

>
>> I'm guessing there has to be something we can do, a la recompile the
>> kernel with customized options, etc. Looking through the mailing list
>> archives the closest symptoms I can find were references to setting
>> BROKEN_KEYBOARD_RESET in the kernel. I think this might be what we're
>> looking for. Anyone have any info regarding this or similar experiences? 
>
>I can't see how BROKEN_KEYBOARD_RESET would have anything to do with it;
>it just controls how the system is restarted during a reboot.  I.e., if
>your system sticks up at the `Rebooting...' on a shutdown, then you need
>it.
>

In the archives there are multiple references to it, i.e:

Date:      Wed, 2 Oct 1996 00:52:40 -0700 (PDT)
From:      "Bryan K. Ogawa" <bkogawa@primenet.com>
To:        freebsd-questions@freebsd.org
Subject:   2.1.5, BROKEN_KEYBOARD_RESET, and \
                AHA-2840 VLB = overwrite super , block on reboot

which mentions:

<quote>
With the new kernel in place, the system works fine.  Unfortunately,
whenever FreeBSD triggers a reboot (e.g. shutdown -r or pressing a key on
the console after shutdown -h), the SCSI drive loses its super block.

I have confirmed that this happens only when FreeBSD triggers the reset,
and not when the system is reset via the reset button.  Waiting for a
while after the shutdown -h for the controller to write out its cache
doesn't matter.  I also noticed that the drive light on the SCSI drive
(which is in its own housing) flashes briefly after the system resets.

This reliably appears to destroy the entire super block--fsck cannot
run on the drive (no magic number), and instructs me to manually fsck the
drive (which will not work unless I use fsck -b 32 /dev/rsd0e ). 
</quote>

Mind you it's not the same gear as I'm using, but it sounds pretty 
similar. I'll keep digging around though.

>I'd suggest checking termination on your SCSI bus just for good measure.

I'll do that too. Thanks for the reply. When I figure it out, I'll post.

-markjr

---
Mark Jeftovic                   aka: mark jeff or vic, stunt pope. 
markjr@shmOOze.net              http://www.shmOOze.net/~markjr
PWC's BOFH                      http://www.PrivateWorld.com
irc: L-bOMb                     Keep `em Guessing

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980303151212.markjr>