🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.sys.next.sysadmin
4 messages
4 total messages Started by Steven Sietz Mon, 10 Aug 1992 13:04
Internal SCSI error
#427
Author: Steven Sietz
Date: Mon, 10 Aug 1992 13:04
37 lines
1522 bytes
Help!  My SCSI disk [internal] won't boot and I can't get up!

I came in this morning and saw my NeXT Cube attempting to boot up but was 
stuck in the startup sequence "Testing System" and "Loading from Disk" followed
by a "SCSI Error".

I put it in the ROM monitor and tried a "bsd" and got the following:

NeXT>bsd
boot sd(0,0,0)
booting SCSI target 1,  lun 0
sdmach: not a directory
sdmach: not found
load failed

blk0 boot:


I was out last week but I am told that someone tried to scan in a large
image and then the system hung.  They then hit the power key to try and
reboot and then it sat for an hour trying to come back up.  It obviously
didn't.

The worst part about this is that we didn't back up the system (we have no 
OD media).  Any help would be *greatly* appreciated.  

		Thanks!

			-Steve-

PS.  No NeXTmail please, just regular email (until this thing gets
fixed).
-- 
Steven Sietz	        |  Internet:  ssietz@cs.rutgers.edu
77A West Bluebell Lane  |  uucp:      {backbone}!rutgers!cs.rutgers.edu!ssietz
Mount Laurel, NJ 08054  |
Re: Internal SCSI error
#732
Author: jypai
Date: Fri, 14 Aug 1992 02:29
22 lines
1341 bytes
In article <Aug.10.09.04.03.1992.20063@dartagnan.rutgers.edu>  
ssietz@dartagnan.rutgers.edu (Steven Sietz) writes:
> 
> Help!  My SCSI disk [internal] won't boot and I can't get up!
> 
> I came in this morning and saw my NeXT Cube attempting to boot up but was 
> stuck in the startup sequence "Testing System" and "Loading from Disk"  
followed
> by a "SCSI Error".

I have similar error message on my cube. It happened after
a power OFF then (immediately) power ON.
Is this an serious problem that I must call the dealership?


--

Yuan
+----------------------------------------------------------+
| Internet Address         : jypai@csie.nctu.edu.tw        |
| NeXT mail GLADLY accepted: jypai@ccnext.csie.nctu.edu.tw |
+----------------------------------------------------------+
Re: Internal SCSI error
#815
Author: bruce
Date: Sun, 16 Aug 1992 08:19
166 lines
8384 bytes
Sorry to take so long answering...  We just had the EXACT same symptoms,
and while I cannot guarantee that what it was for us will be the exact
same thing as you're suffering, it seems quite likely...

ssietz@dartagnan.rutgers.edu (Steven Sietz) writes:
: 
: Help!  My SCSI disk [internal] won't boot and I can't get up!
: 
: I came in this morning and saw my NeXT Cube attempting to boot up but was 
: stuck in the startup sequence "Testing System" and "Loading from Disk" 
: followed by a "SCSI Error".
: 
: I put it in the ROM monitor and tried a "bsd" and got the following:
: 
: NeXT>bsd
: boot sd(0,0,0)

-- Booting SCSI with defaults

: booting SCSI target 1,  lun 0
: sdmach: not a directory
: sdmach: not found
: load failed
 
: blk0 boot:

-- Your BOOT RECORD on the Hard drive is clobbered.  While it MAY be possible
to boot from one of the alternates (for us it wasn't), it's time to look at
re - low-level (SCSI level) formatting the drive.

Despite much talk over in the MS-DOS World, with the Integrated-Drive-Elect-
ronics drives (IDE) ``not requiring LLF'', unless the controller re-maps on
the fly, which is normally an ESDI feature, not found on SCSI drives, the mag-
netic capacity of the ``tracks'' changes over time, even if no surface defects
arise to clobber the drive.

: I was out last week but I am told that someone tried to scan in a large
: image and then the system hung.  They then hit the power key to try and
: reboot and then it sat for an hour trying to come back up.  It obviously
: didn't.

Likely a coincidence, though it is possible that configuration errors caused
a wrap from the last cylinder on your disk to overwrite cylinder zero.

: The worst part about this is that we didn't back up the system (we have no 
: OD media).  Any help would be *greatly* appreciated.  

I DO hope you have your distribution OD!, as this is apt to be your best way
of getting back up.  I'll describe what WE did.  WE LOST NOTHING but time :),
and ended up ahead of where we had been, cleaning up some strange NetInfo
structures.

: 		Thanks!
: 			-Steve-
: PS.  No NeXTmail please, just regular email (until this thing gets
: fixed).
: -- 
: Steven Sietz	        |  Internet:  ssietz@cs.rutgers.edu
: 77A West Bluebell Lane  |  uucp:      {backbone}!rutgers!cs.rutgers.edu!ssietz
: Mount Laurel, NJ 08054  |

FIRST
   Allocate a day or so for the following :) depending on your H/D size and
   your communication paths, and just how much recent additions you want to
   be able to rescue since your last full or incremental backup.

   Boot from an alternate.  This may be the distribution OD (for us it was).

SECOND
   Using the mount(8) command in a shell, ``manually'' mount the SD onto the
   filesystem which is now based on the alternate boot device.  If you're
   limited to NetBoot, you may find someone with more Net experience than I
   have yet developed to help.

THIRD
   Now, SAVE whatever you wish/need/must save... This is an emergency condition,
   so you may want to write places you normally wouldn't want to -- i.e. the
   OD, a borrowed disk, whatever.  At worst, you can set up a temporary LAN
   or high-speed serial connection to save-off your salvagable materials.  Our
   option, at the time, was a 38400bps null-modem connection to a non-compat
   ible machine, using one of the LHARC utilities to preserve links, paths,
   filenames with embedded spaces, sticky & suid/sgid directory attributes.
   Many things we arced off, we did so by deliberate choice, to save the post-
   restore debugging, rather than out of absolute need.  Though we wouldn't
   have needed to, we generally used 8+3 (MS-DOS compatible) filenames as a
   precaution, on the output archives.  You could use tar+compress if that
   is all you have, or with plenty of off-machine storage, and a LAN-speed
   link, you may be able to just drag directory trees across, intact.  See 
   TIPS below!

FOURTH
   use disk(8) with the -f switch to re-low-level format the drive.  CAUTION
   this switch is NOT documented in part-8 of the Unix manual, but is docu-
   mented internally in the program, displayable with ``/usr/etc/disk'' with
   no parameters.  THIS WILL DESTROY ALL DATA ON THE DRIVE, but hopefully will
   restore the SCSI device to a working drive.  This should re-map bad spots
   on the disk so that they are not written to.

FIFTH
   Re-Install your NeXT operating system, cleanly, from a distribution disk.
   This is the equivalent of a High-level-format, writing the swapfile, SDMACH
   etc to the drive, and updating boot records to point to it.

FINALLY
   Re-install the things that make it YOUR system... The things you backed up.


TIPS
   Many of the things you will wish to save are the very things you don't often
   change, unless you have a development system.  If you know you already have
   a backup copy of these available, from your own system, don't worry about
   these.  If there's a chance that you've changed things... you may want 
   to grab them during this backup, just to be sure.

   First, if you (like most of us) are running a NetInfo system, you probably
   have lost additional users, devices, services, and the like.  If you have
   been dumping your NetInfo to the non-NetInfo files [nidump(1)]...

	aliases, bootptab, bootparams, fstab, group, hosts
	networks, passwd, printcap, protocols, rpc, services

   There are quite a few possible NetInfo items that are NOT covered by these.
   In addition to this, your crontab.local, /etc/sendmail/*, etc/uucp/* 
   /usr/lib/news/*, /usr/lib/newsbin/*, perhaps your /usr/spool/news/*, any 
   outgoing or untossed incoming /usr/spool/uucp/* datafiles.  If you utilize 
   accounting statistics, you may want to save things in /usr/adm/*.   If there
   are any non-zero-length mailbox files in /usr/spool/mail, or any undelivered
   messages in /usr/spool/mqueue, you may want to grab these.  Many things are 
   hard to advise, as there are so many options which CAN change your needs.

   You will likely want to save ~/.NeXT/* except for .NextTrash, though this
   is usually not essential, and ~/Apps/*, ~/Library/*.   Definitely any
   /usr/local/* and /LocalLibrary/* + /LocalApps/* - if you have made any such
   additions to your system.  If you have multiple users, you may want ~/*
   for each, though it may be that all you have is a / - root account and a
   /me/* account on your system.   REMEMBER -- MANY UTILITIES DEFAULT TO NOT
   HANDLING HIDDEN FILES (those starting with a `.') and even many which will
   forget to traverse directories with a leading `.' when operating in a re-
   cursive tree-walking mode.

   Now is the time to be VERY methodical!  If you're tar'ing up a directory
   tree, go ahead and use the verbose switch, and compress in a separate step.
   Compare the listing with a ``Unix expert'' directory listing.  What's gone
   after you re-LLF the drive is gone forever.

   Finally, in your backup, watch for symbolic links.  You may end up with
   a compressed backup that is larger than the original, and more importantly
   one which will not even fit when you attempt to copy it back...

   Handy aliases for your shell while backing off...

        alias arc (your selected archiver with switches and \!* )
        alias dir "ls -gulFa \!*"
        alias tree "find . -type d -print"

   Using that `dir' in place of `ls' you may find things you never knew
   you had :).

   Also, look at the follow-on post about dumping NetInfo...

Bruce
-- 
Bruce Gingery          bruce@TotSysSoft.com        (Total System Software)
InterNet:  Bruce.Gingery@p1.f5.n310.z1.fidonet.org (  Cheyenne, Wyoming )
       or  bruce@brucext.TotSysSoft.com
NeXT-Mail: bruce@tssnext.rmNUG.org  < -or- > bruce@TotSysSoft.com
Re: Internal SCSI error
#830
Author: Dave Olson
Date: Mon, 17 Aug 1992 06:27
20 lines
1660 bytes
In <1992Aug16.081957.3652@tssnext.rmNUG.ORG> bruce@tssnext.rmNUG.ORG writes:
| Despite much talk over in the MS-DOS World, with the Integrated-Drive-Elect-
| ronics drives (IDE) ``not requiring LLF'', unless the controller re-maps on
| the fly, which is normally an ESDI feature, not found on SCSI drives, the mag-
| netic capacity of the ``tracks'' changes over time, even if no surface defects
| arise to clobber the drive.

This is complete garbage all around.  ESDI does not support remapping
of *grown* bad sectors on the fly, period (there may be some controllers
and drivers that do, but the drives do not).  Many SCSI drives do;
ALL SCSI hard disk drives support badblock mapping in the drive itself (at
least, I've never heard of one that didn't), I've never seen or heard
of an ESDI drive that did (the driver or controller has to do it).

The magnetic capacity of tracks does not change over time, in the sense
you seem to be indicating.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads