Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!PAN.SSEC.HONEYWELL.COM!thompson
From: thompson@PAN.SSEC.HONEYWELL.COM (John Thompson)
Newsgroups: comp.sys.apollo
Subject: re: 10.2 to 10.3 upgrade q's (help)
Message-ID: <9104020040.AA11426@pan.ssec.honeywell.com>
Date: 2 Apr 91 00:40:56 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 61


>     I'd like to know what people's experience has been with upgrading
> 10.2 nodes to 10.3 nodes. Specifically, should we strive to maintain
> two different authorized areas, a 10.2 and a 10.3 version ?  
With 60 nodes, I assume that you have more than one AA.  (If not, why?)
We maintain 5 AAs for our 67 node network (although we should only have
four).  If you have multiple AAs, I'd make sure that nobody references one
of them, and then load up that AA with 10.3.  You'll be asked whether you
want to conserve space by removing the earlier O/S branch(es).  I would
say 'no', unless there isn't enough disk space.  Only after 10.3 has been
loaded and checked out (at least slightly) would I trash the earlier
O/S package.

> Also, how
> is the actual installation performed - can we install 10.3 "on top of"
> an existing 10.2 OS node ?  
From the standpoint of minst/distaa/cfgsa, you have two different versions
of a software package.  They can each sit in the AA quite comfortably, 
although they are rather large.  From the standpoint of 'install' (or
'install++'), you have to say whether you're upgrading or not.  In our
case, when we went to 10.3, we changed our configuration fairly drastically.
We used to have Aegis/BSD only, and BSD was linked out to the AA node.
We then went in later and played around even more with the links.  The
10.3 config included Aegis/BSD/SysV, and so the install program gave us
grief.  We found the dirs/files/links that it complained about, and wrote
a quick script to trash them out (from the 10.2 node) just before it was 
upreved to 10.3.  If your configuration is static, you should have fewer
problems.  You can even run config or install++ on your current O/S
configuration file, and tell it to update the packages (update os).  Then,
all the questions in your original config will get the same answers as
you originally gave -- only new questions will remain to be answered 
(e.g. ANSI C header files info).

> As I see it, we could use the mrgii tool to
> merge the 10.3 AA with the 10.2 AA and then install the software, but we 
> lose the 10.2 AA. Alternatively, we could keep two separate AA's and main-
> tain the ability to install either OS version. 
Not unless I've been reading the manuals backwards.  The mrgri tool is
not intended for merging new versions of software with the old.  It is
only for merging (most) patches and (some?) PSKs into the main software
package (generally the O/S), and for merging 2 hardware versions of the
same software together (e.g. DSEE 3.3.2 and DSEE 3.3.2.p) in to a
compound executable (cmpexe).  I would hope that mrgri would simply fail
if you tried to merge two versions of the O/S, but it might trash out 
the O/S loads in the AA as well.

> Am I correct in assuming that
> the 10.2 to 10.3 upgrade can occur without involling the 10.2 disk ???
Yes, you are.  You can invol the disk, in which case the block size will
go from 1K to 4K (this is for the BSD fast file system??).  This will
use up additional space when you start putting things onto the newly 
INVOLed disk.  I have loaded 10.3 on newly INVOLed disks and on top of
10.2 with no INVOL, and haven't noticed a difference.

-- jt --
John Thompson
Honeywell, SSEC
Plymouth, MN  55441
thompson@pan.ssec.honeywell.com

Me?  Represent Honeywell?  You've GOT to be kidding!!!