From: bruce@tssnext.rmNUG.ORG
Subject: Re: Internal SCSI error
Reply-To:  <bruce@TotSysSoft.com> (Bruce Gingery)
Organization:  Total System Software
Date: Sun, 16 Aug 1992 08:19:57 GMT

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
Newsgroups: comp.sys.next.sysadmin