donaldg@Stardent.COM (Donald Gale) (04/02/91)
Howdy,
We've currently got an OS10.2 network running on approximately
60 Apollo nodes (3000's, 3500's, 4500's). We would like to upgrade
a couple of nodes to OS 10.3 to run Mentor Boardstation and Package
station.
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 ? Also, how
is the actual installation performed - can we install 10.3 "on top of"
an existing 10.2 OS node ? 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. Am I correct in assuming that
the 10.2 to 10.3 upgrade can occur without involling the 10.2 disk ???
Any info. would be appreciated. I find the release notes too sketchy
in areas. Please email.
Don Gale - Stardent Computer, Inc.
email: donaldg@stardent.com
phone: (508) 371-9810 x268thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (04/02/91)
> 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!!!
mike@bellcorebellcore.com (Mike Lukacs 21341) (04/03/91)
In article <1991Apr1.191325.1239@Stardent.COM>, donaldg@Stardent.COM (Donald Gale) writes: |> Howdy, |> |> We've currently got an OS10.2 network running on approximately |> 60 Apollo nodes (3000's, 3500's, 4500's). We would like to upgrade |> a couple of nodes to OS 10.3 to run Mentor Boardstation and Package |> station. |> 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 |> Don Gale - Stardent Computer, Inc. Unless you have a very good reason to keep 10.2 (ie: some third party software vendor has told you it WONT work with my software. [not "We Don't Know" but literally "we tried and it doesn't"]) then don't bother, go fully to SR10.3. We all remember thw nightmare of the 9.7 -> 10.x transition and have become leary of the upgrade process. In this case, caution is not needed. SR10.3 is VERY close to 10.2. Virtually nothing should be affected. I converted a mixed ring of 10.1, 10.2, and 10.0p nodes over to 10.3 about 2 months ago and had no problems whatsoever, either while the ring was running mixed, or after transition. The one exception was flakey availability of the registry server. This was cured by running just one glbd on the same node as the master rgyd, and making sure that they knew about each other. In the last two months, our rate of software problems has gone way down. 10.3 is a good stable functional OS and the transition pain is minimal. DO IT! Good Luck, Mike Lukacs DISCLAIMER: The opinions expressed | M. E. Lukacs NVC-3X-330 in the above are my own, and not | Bell Communications Research(BELLCORE) those of Bell Communications Research. | 331 Newman Springs Road By Law, BELLCORE may not have such | Red Bank, New Jersey, USA 07701-7040 opinions; and if they did, they would | not tell you for free. And I am not | (201)or(908) 758-2876 FAX: 758-0889 the person who would be giving out | official opinions anyway. And unless | mike@nyquist.bellcore.com you can PROVE that this isn't a | "First 'mike' on the UUCP network" forgery, I did not say this. | (ca.1974)