[comp.unix.ultrix] using installation tape for disaster recovery

rusty@GARNET.BERKELEY.EDU (rusty wright) (09/18/90)

I'm trying to reinstall my system from dump 0 tapes using the
installation tape.  (In case you're wondering why, I tried to install
Ultrix 4.0 on my MicroVAX II/GPX and found out after it was too late
that 4.0 won't work on an RD53.)  When you boot the installation tape
there are 3 options, basic installation, advanced installation, and
system administration.  If you select system administration you get
dropped into the shell on a unix running on a ram disk.  My confusion
is that only mkfs is provided for initializing the disk, not newfs,
and it's newfs that installs the boot block, so I don't see how I can
install the boot block.  Can anybody enlighten me?

hudson@ux1.cso.uiuc.edu (John Hudson) (09/18/90)

In article <9009171852.AA03774@garnet.berkeley.edu> rusty@GARNET.BERKELEY.EDU (rusty wright) writes:
>I'm trying to reinstall my system from dump 0 tapes using the
>installation tape.  (In case you're wondering why, I tried to install
>Ultrix 4.0 on my MicroVAX II/GPX and found out after it was too late
>that 4.0 won't work on an RD53.)  
>My confusion
>is that only mkfs is provided for initializing the disk, not newfs,
>and it's newfs that installs the boot block, so I don't see how I can
>install the boot block.  Can anybody enlighten me?

This is convered the documentation, System Backup and Restore (in my
version it is on page 3-14).

In summary, after making the proper files in /dev and mounting the disk
(see the sequence in the docs), use 'dd' to copy the boot block to the
disk - 'something like'

# dd if=/vaxboot of=/dev/r*0a conv=sync

where * is your RD53 (probably 'ra').

John Hudson
hudson@ux1.cso.uiuc.edu

envbvs@epb2.lbl.gov (Brian V. Smith) (09/18/90)

In article <9009171852.AA03774@garnet.berkeley.edu>, rusty@GARNET.BERKELEY.EDU
(rusty wright) writes:
|> I'm trying to reinstall my system from dump 0 tapes using the
|> installation tape.  (In case you're wondering why, I tried to install
|> Ultrix 4.0 on my MicroVAX II/GPX and found out after it was too late
|> that 4.0 won't work on an RD53.) 

Where does it say that Ultrix 4.0 won't work on an RD53?

To quote the Release notes, page 1-29, section 1.9:

"All hardware components supported in the previous release (ULTRIX-32,
Version 3.1) remain supported in ULTRIX Version 4.0."


--
Brian V. Smith    (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL; they don't pay me enough for that.

steven@uicadd.csl.uiuc.edu (Steven Parkes) (09/18/90)

In article <7033@dog.ee.lbl.gov>, envbvs@epb2.lbl.gov (Brian V. Smith) writes:
|> In article <9009171852.AA03774@garnet.berkeley.edu>,
|> rusty@GARNET.BERKELEY.EDU (rusty wright) writes:
|> |> I'm trying to reinstall my system from dump 0 tapes using the
|> |> installation tape.  (In case you're wondering why, I tried to install
|> |> Ultrix 4.0 on my MicroVAX II/GPX and found out after it was too late
|> |> that 4.0 won't work on an RD53.) 

|> Where does it say that Ultrix 4.0 won't work on an RD53?
|> To quote the Release notes, page 1-29, section 1.9:
|> "All hardware components supported in the previous release (ULTRIX-32,
|> Version 3.1) remain supported in ULTRIX Version 4.0."

Yea, but in the release notes it says that the RD53 is supported as a `data
device only.'  RD53's are pretty small -- the whole /, /usr, and swap won't
fit on one disk, at least not with the install script.

I did the same thing to install on a GPX/II -- I dumped the root of a system
I'd just installed (they share /usr anyway.)  The way I got around no-newfs
was to get a tape and cat the appropriate files onto it for another system
(newfs, /etc/disktab, the proper boot directory) ... sort of a pain, but
more reliable than trying to figure out what set of options newfs calls
mkfs with.

So why doesn't somebody (I hate SPRing) write an spr asking to have newfs,
disktab, and the boot directory put onto the ram filesystem.  Also, what about
rsh?  On the IBM/RT under AOS the way you do an install is to install the ram
filesystem and rsh a dump/restore to an installed machine.  Worked great.

And finally, has anyone played with RIS?  We don't use it -- our of our machines
have local root and swap and doubling up on software (doc's say you can't
share with the server, right?).  What I'm wondering is, can I install just
enough RIS stuff to allow me to boot a ram filesystem over the network.
The way it is now, I have to move our scsi tk50 from machine to machine.
I could spare the space to boot a ram filesystem, but I don't want to
double the space for all the other subsets.


steven parkes ---------------------------------------
University of Illinois Coordinated Science Laboratory
steven@pacific.csl.uiuc.edu -------------------------

wdg@unccvax.uncc.edu (Doug Gullett) (09/18/90)

In article <9009171852.AA03774@garnet.berkeley.edu>, rusty@GARNET.BERKELEY.EDU (rusty wright) writes:
> I'm trying to reinstall my system from dump 0 tapes using the
> installation tape.  (In case you're wondering why, I tried to install
> Ultrix 4.0 on my MicroVAX II/GPX and found out after it was too late
> that 4.0 won't work on an RD53.)  

Is this true??  4.0 just arrived and is in a waiting pattern for a while.
If it does not run on RD53s we are in big trouble. Is this documented
somewhere (say the release notes)??o

			thanks,
			wdg

mike@raven.uss.tek.com (Mike Ewan) (09/18/90)

In article <2748@unccvax.uncc.edu> wdg@unccvax.uncc.edu (Doug Gullett) writes:
>In article <9009171852.AA03774@garnet.berkeley.edu>, rusty@GARNET.BERKELEY.EDU (rusty wright) writes:
>> Ultrix 4.0 on my MicroVAX II/GPX and found out after it was too late
>> that 4.0 won't work on an RD53.)  
>
>Is this true??  4.0 just arrived and is in a waiting pattern for a while.
>If it does not run on RD53s we are in big trouble. Is this documented
>somewhere (say the release notes)??o

Ultrix 4.0 _will_ run on RD53's.  The catch is that you need at least
2 of them and you need to do an advanced install and put /usr on the
second RD53.  I'm running Ultrix 4.0 on a VAXstationII/GPX with three
RD53's.  I'm using the third for /home and X11R4.

Mike


--
 Michael Ewan    (503)627-6468      Internet:  mike@raven.USS.TEK.COM
 Unix Systems Support                   UUCP:  ...!tektronix!puffin!raven!mike
 Tektronix, Inc.                  Compuserve:  73747,2304
"Fig Newton: The force required to accelerate a fig 39.37 inches/sec."--J. Hart

D. Allen [CGL]) (09/19/90)

>And finally, has anyone played with RIS?  We don't use it -- our of our
>machines
>have local root and swap and doubling up on software (doc's say you can't
>share with the server, right?).  What I'm wondering is, can I install just
>enough RIS stuff to allow me to boot a ram filesystem over the network.
>The way it is now, I have to move our scsi tk50 from machine to machine.
>I could spare the space to boot a ram filesystem, but I don't want to
>double the space for all the other subsets.

I support two DS5400, five VS3200, eight VS3100, and a dozen VS2000
using network boot and download via setld/RIS from one of two machines,
each of which contains the full complement of VAX and MIPS subsets.

If net boot is all you want, you can just keep the stuff under
/usr/lib/dnet that mop_mom looks at when doing a net boot.  Shouldn't
take more than a few Mb.  Once you've net booted, you have rsh, so you
can rsh in the things you're missing (such as newfs and /etc/disktab).

Once I've done a proper Ultrix install on one machine from subsets, I
"clone" machines by doing dump/restore over the network while running the
ramdisk.  Copy the remote machine's disks, change the host name in
/etc/rc.local, remove the old syserr files, refreeze the sendmail.cf
file, and presto a functioning workstation without the pain of the
full Ultrix install.  No tape drive needed.
-- 
-IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu
 [129.97.128.64]  Computer Graphics Lab/University of Waterloo/Ontario/Canada

DAYHOFF@ddnvx1.afwl.af.mil (harvey) (09/20/90)

In article <1990Sep17.232146.25995@ux1.cso.uiuc.edu>, steven@uicadd.csl.uiuc.edu (Steven Parkes) writes:
> 
> And finally, has anyone played with RIS?  We don't use it -- our of our machines
> have local root and swap and doubling up on software (doc's say you can't
> share with the server, right?).  What I'm wondering is, can I install just
> enough RIS stuff to allow me to boot a ram filesystem over the network.
> The way it is now, I have to move our scsi tk50 from machine to machine.
> I could spare the space to boot a ram filesystem, but I don't want to
> double the space for all the other subsets.
> 
> steven parkes ---------------------------------------
-- 
I can not say for sure that you need to do anything more than register
the workstation.  On 4.0 it looks as though the load sets are commpressed
tars.  It may be that something out of mdec or mop gets loaded.

Can say that loading the required sets provides the capability to 
use ether to get the minimal ramdisk system.  You might try loading
enough to get is started and then delete loadsets to see for sure.

NB:  I was quite taken aback when VS3100 se0 went to ln0 (3.1 to 4.0).
I, myself, munged the install (failed to note that root went from 
7.4 meg to 15.5 meg) by not reading first.  But I could find nothing
to tell me why the ethernet died.   Would have at least be nice to 
see se(4) say 'See ln(4)' instead of disappearing.

oh well, harv
--
   my sig, managements header.
   dayhoff@ddnvx1.afwl.af.mil   --> all std gov disclaimers apply
Lex-dizzya:  A non twisted-pair language disorder; the SDI of the mind. -rsd

steven@uicadd.csl.uiuc.edu (Steven Parkes) (09/24/90)

|> > And finally, has anyone played with RIS?  We don't use it -- our of our
|> > machines have local root and swap .......

Well, I did this last weekend ... and it worked pretty well.

1) If you only want to boot the ram vmunix, you only need the ROOT subset
in /usr/adm/ris/ris?.*.  In fact, ROOT is a dump image, and all you really need
is vmunix.sas and netload.  However, in order not to change the ris script, I
kept all the .inv type files since they're pretty small.

2) the computation of size in setld doesn't work very well.  I ended up
commenting it out because neither symbolic links nor nfs redundant mounts could
get the stupid thing too look at the right partition.

smp