OpenVMS Alpha 7.3-2 to 8.3 Upgrade

[Jim Geier_1]

I upgraded a relatively small OpenVMS Alpha cluster from 7.3-2 to 8.3 this past weekend. I noticed a new item on the menu when booted from the distribution CD (actually a disk -- I copy the CD to a locally attached SCSI disk for faster booting), and decided to use it. This new item allows the application of patch kits while the system is booted from the distribution disk, potentially saving a reboot cycle. I did the following:

1. Boot from 8.3 distribution disk
2. Backup system disk to spare disk
3. Upgrade system disk
4. Use the new menu item to apply patches stored on a spare disk to newly upgraded system disk.
5. Booted from upgraded and patched system disk, allowing Autogen to run and reboot.

I expected to see the announcement "OpenVMS 8.3" when the system first mounted the system disk, but instead I saw:

OpenVMS (TM) Alpha Operating System, Version XB9P-N20
Copyright 1976-2007 Hewlett-Packard Development Company, L.P.

And, after going through the Autogen and reboot cycle, the version did not change. I diligently reviewed the console logs, and found no errors or warnings. Knowing that some software checks the OpenVMS version, I started over, doing the normal sequence:

1. Boot from distribution disk
2. Restore system disk from backup copy
3. Upgrade system disk to 8.3
4. Boot from system disk, allow Autogen to run and reboot
5. Apply patches (Update V3, ACMELDAP V2, ACRTL V2, Driver V1, Sys V1, PASRTL V1, Mount96 V1, Fibre-SCSI V1) and reboot.

It is not really that big a deal, but my attempts to save a reboot in the upgrade process failed. Given that we have limited time when we perform this upgrade to the production cluster, saving one reboot cycle can help. Anyone have an idea as to why my first sequence failed?

[Dean McGorrill]

hi Jim,
My first reaction would be someone
did an oops. XB9P, that is the HP engineering resd name the kit was built
on most likely (resd = result disk of a vms OS build) I havn't upgraded a machine in
a few years but I remember seeing the x type
version name in the process up upgrading. so you might want keep the extra reboot in your plans, they usually don't take that
long. Dean

[Jur van der Burg]

I think the problem is that you did not boot from the upgraded disk before you applied the patches, thereby confusing the upgrade. One of the patchkits probably installed a new SYS$BASE_IMAGE (where the version number is kept) that has the base build number in it (XB9P).

Jur.

[Heinz W Genhart]

Hi Jim

I have a similar expirience.
I upgraded my first machine from OpenVMS 7.3-2 to 8.3. I also copied the distribution CD to a spare disk and then I did the upgrade from this disk. But I did a reboot after upgrading to 8.3
After this I used a commandfile to apply the patches, this because I have to upgrade many systems and I will apply all patches in same order. My commandfile looked similar to this:

$ define/user sys$input sys$command
$ product install patch
$ define/user ........

When I installed the SYS100 patch I finally got the SYSVER> prompt.
A show system/noproc showed also the Version XB9P-N20.

In my case I think the problem was the define/user within my commandfile.

It's possible to fix this the following way:

$SET DEF SYS$COMMON:[SYS$LDR]
$RUN SYSVER
SYSVERSION> REPLACE V8.3
SYSVERSION> WRITE
SYSVERSION> EXIT
$
$ REBOOT

I'm not sure if that is a good way, so I used a backup of my 7.3-2 systemdisk, did the upgrade again to 8.3 and the I executed the patches interactive. This time everything went well and my system showed the version 8.3

regards

Geni

[Jim Geier_1]

This same problem occurred while I was upgrading an AlphaServer DS10 from OpenVMS 8.2 to OpenVMS 8.3, and had to work around the LANACP crash during the first reboot after the upgrade. The solution for the crash was to install LAN V3 or UPDATE V5 (which includes LAN V3) while the system was booted from the OpenVMS 8.3 installation CD. I installed UPDATE V5, and got the OpenVMS version XB9P-N20 again.

I went ahead and ran SYSVER to update the version string, and opened a case with OpenVMS Support. The answer is that (1) they have seen this problem several times as users make use of the ability to install patch kits while booted from the installation CD, and (2) the problem really is some difficulty in the installation process running SYSVER to update sys$base_image.exe while booted from the installation CD. They are looking for a solution.

[Hoff]

I have been known to replicate the system disk to a copy (and there are various good and bad ways to clone), upgrade that, test that, then perform a rolling reboot from the old over to the new system disk.

[Jim Geier_1]

OpenVMS support found the problem. It was in the UPDATE patch kit. A SET DEFAULT to the CD was issued just before executing the SYSVER image. The default location was not writeable, so the SYSVER update failed. This will be corrected in the next UPDATE installation kit.