NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/unix/ultrix/8161

Text File | 1992-11-08 | 5.7 KB | 135 lines

Newsgroups: comp.unix.ultrix
Path: sparky!uunet!haven.umd.edu!decuac!hussar.dco.dec.com!mjr
From: [e-mail] (Marcus J. Ranum)
Subject: Re: Ultrix 4.2a crashed, PLEASE HELP!!!
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Nntp-Posting-Host: hussar.dco.dec.com
Organization: Digital Equipment Corporation, Washington ULTRIX Resource Center
References: <[e-mail]>
Date: Sun, 8 Nov 1992 01:31:53 GMT
Lines: 122

[No offense, but the title is a bit misleading. ULTRIX didn't crash. You
crashed it.]

>      (cd $1; tar cf - .) | (cd $2; tar xvf - )
>
>while in the root directory, I typed 'cpdir' without giving any
>parameters and the nightmare starts. After running the above
>command, the messages showed on the screen say something like
>...
>...
>bin/ls size changed
>bin/mkdir size changed
>bin/cp size changed
>...
>...
>
>I used 'CTRL c' to quit the shell script as soon as I can once I saw
>this happended, but the system was damaged. Afterwards, whenever I use
>those commands (i.e. ls, mkdir, cp...), I got a 'segment fault' and then
>'core dumped'. I 'shutdown' and turned off the machine and the system
>can not be rebooted since then.

    Right, what you did was truncate all those files. They're
zapped and that's all there is to it. Fixing the machine (especially
if you have valuable files) is gonna be a trick. There are 2 ways you
can proceed - I'll tell you the one I think is hardest first and then
I'll describe the one I suggest trying.

    I'm going by memory here and this should be *about* right.
You may need to read a few manual pages here and there if the
exact commands I list don't work - but the gist of them is correct,
I assure you. If worst comes to worst, keep the machine DOWN and
email me monday and I'll give you my office phone #.

    The *hard* way is to get another DECstation with ULTRIX on an
external disk, and plug it onto your SCSI chain, boot off it, then
mount the filesystem you trashed and try to replace the binaries
by running a find to see what files changed on those filesystems.
Build a list of all the things that changed since that day and assume
that those are zapped files, then write a script to copy new copies
of things like /bin/ls and so on from the "good" hard disk to the
"dead" one.

    If you have a working system on another disk, just boot
off it (as suggested above) and make tape copies of the files you
want to save, then re-install. If you don't have a working system,
that you can pirate a disk from, then you need to proceed as follows,
which requires only a tape drive.

    The *easy* way, and the one I suggest, is to boot from
tape (or whatever your installation media is) and select the
"systems management" option. This will drop you into a completely
minimal shell in an in-memory filesystem. Remember that in the
minimal filesystem there arent a lot of programs and there is no
PATH set to search /bin and /etc. You may need to type complete
pathnames for commands (as I do in my examples below) and you
may beed to use "echo" instead of "ls" to see what is in the
directories! Don't panic, though - the bare minimum of what you
need *IS* there.

Then you need to
cd to /dev and make a device node for the trashed disk. Suppose
your filesystems were on scsi disk 0, you would:

# cd /dev
# MAKEDEV rz0

    Here we're assuming that *ALL* we're trying to do is save your
valuable data. You're going to need to re-install the operating system
from scratch, but we'll try to save your files. Let's pretend they're
user files in /usr/users or something like that. Let's pretend that
/usr/users was on /dev/rz0g. If you can't remember what was on where,
then you need to mount the *root* filesystem of the original disk
and see if you can read the /etc/fstab, or just follow the
procedure outlined below for each partition on the disk, to see which
is the one you want.

# fsck /dev/rz0g
  (here it should *say* where it was last mounted, so you'll know if
    you have the right partition. if not, just try fscking another.)
# /bin/mount /dev/rz0g /mnt

    At this point you can cd to /mnt and look around and see if the
files you need are there.

    Now you have a couple of options. If you've got an existing
ULTRIX machine that is up and running, I suggest you get a copy of
"tar" from it. I don't *THINK* the standalone system has "tar".
(the standalone system is all a root filesystem in a RAM disk, and
has not got a lot of room to waste). The way to do that is to just
get onto a working machine, mount a tape, and use dd to copy the
executable to tape, then copy it back onto the system you're
trying to repair.

on some other machine:
otherbox# dd if=/bin/tar of=/dev/rmt0h

mount the tape in the hosed machine and:
# cd /dev
# MAKEDEV tz<scsinumber>  (if you have a TK50 as SCSI ID 5, it would be tz5)
# cd /bin
# dd if=/dev/rmt0h of=tar
# chmod 755 tar

    Now you have a tape archiver, and you're in good shape. Figure
out what files you want to save and just use tar to copy them to tape.
If you don't even have another machine running ULTRIX then, well,
you're going to need to look in /bin and /etc on the in-memory disk
and see if there is a copy of "dump". I know there is a copy of
restore, but I can't recall if ther's a copy of "dump" or "tar"
on the in-memory system. If there isn't, then you've got one last resort,
and that is to find and mount (as above) the old / partition
from the trashed disk, and *pray* that /bin/tar or /bin/dump are
still there and intact.

    Assuming you can get a copy of tar or dump by any of these
means, save your user files, save /etc and /usr/spool/mail and so on,
then re-install ULTRIX and reload your user files. Also, don't
ever write programs (even shell scripts) that don't check for valid
parameters.

mjr.