Rolling upgrade V7.3-2 to V8.3 problems

[Jan van den Boogaard]

Hi all.

I am interested in the experience of people in this forum on doing a rolling upgrading 7.3-2 Alpha to 8.3 Alpha. I myself am running into crashes.
I upgrade a ES45 from a single system disk on SAN to 8.3. Another node in the cluster keeps on running 7.3-2 on a shadowed system disk in the SAN in the meantime.
After the upgrade (which itself is succesful), on the first boot from 8.3 it runs into ACCVIO.
(see attachment)

The upgrading node does not mount any SAN disk mounted by the other node.

Any ideas what might be wrong? Is this scenario unsupported? Thnx, Jan.

[Jan van den Ende]

Jan,

rather little to go on so far, but
>>>
virtual address=0000000000000000
<<<
pretty much indicates addressing something for which the address has NOT been filled in.

Usually the info should include the name of the image to be forced to exit!

Without any more info to go on, just MAYBE
>>>
The operator console and logfile will not be enabled.
Change OPC$OPA0_ENABLE & OPC$LOGFILE_ENABLE in SYLOGICALS.COM
to enable them.
<<<
indicates that you ARE trying to do some addressing on a not-yet-mounted drive?

Is this system disk using the STK setup?
Can you try a boot with STK disabled
(boot conversational, set STARTUP_P1 to "MIN", and continue. Log in as SYSTEM, and try to run every step of the bootstrap one-by-one by hand. See what happens)

hth

Proost.

Have one on me.

jpe

[Volker Halle]

Jan,

the first question to be answered is: which image is getting the ACCVIO ? Then find out the command invoking that image and try to guess, what this image might be trying to do and why it may be failing.

Boot conversational and enable full verify during STARTUP.COM:

>>> b -fl n,1 (with n=system root)
SYSBOOT> SET STARTUP_P2 "VPC"
SYSBOOT> CONT

Volker.

[Jan van den Ende]

Volker,

agreed!

>>>
SYSBOOT> SET STARTUP_P2 "VPC"
<<<

Jan, do that, but MAKE SURE you have output recording with sufficient buffer hooked to the console!

It might well be, that even a STARTUP_P1 "MIN" will crash even before you can start single startup steps, which is where my suspicion goes because of the missing image name.

The P2 setting will also trap those.

Proost.

Have one on me.

jpe

[Anton van Ruitenbeek · Accepted solution]

Jan,

To do a supported rolling upgrade you must have the original STARTUP and corresponding SYSTARTUP procedures. You may only modify the SYS$SYSTARTUP etc. If you modify the procedures whitch may not modified and during upgrade these procedures are modified by HP there is another chalenge.
Make sure your systemarchitecture will support rolling upgrades.

AvR

[James Cristofero]

Appears something may have been over-wriiten with the upgrade.

Like Anton said, upgrade could have move a new S*.com into your startup stream. Looks like between SYCONFIG and SYLOGICALS.

Do you have the correct SYCONFIG? A Converation boot or boot from CD will allow you to examine the contents. Someone may have left something in the SYS$SYSROOT that may not have made it over, or been superceded.

Also, if a SAN environment, sometimes I've seen the device not be "readY" by the time SYCONFIG runs and you have to put a loop checking for the device either in SYCONFIG or SYLOGICALS (depending on speed of precessor).

[Robert_Boyd]

I had a problem with LANACP during an upgrade to V8.3. HP has all the particulars about my case.

My upgrade would not complete successfully because on the reboot to run AUTOCONFIGURE the system would crash when it tried to fire up LANACP.

I wound up doing numerous things to debug/work around this problem. I finally succeeded in booting the system in interactive mode and set/startup OPA0:

Once the system was up far enough to bring up the STARTUP process I was able to run LANCP and force a convert on the database files BEFORE LANACP could be started. That turned out to be the thing that helped me turn the corner.

I then put the INS_STARTUP.COM back as the startup procedure and rebooted to let it finish its reconfigure and final reboot.

I also discovered that since then, there is a patch kit available. If you should have the luxury of building a hard drive replica of the install CD, you can place the necessary patch kits on the drive before beginning the upgrade. This makes it possible to install the base system and use the new feature for locating and installing patch kits to bring the system past this wretched problem before it ever reboots.

I like to create a directory tree
[PATCHES.1ST]
[PATCHES.2ND]
[PATCHES.REMAINDER]
This way if there are groups of patches that must be installed in a particular order it's easier to do the right thing.

Robert

[Jan van den Boogaard]

Thanks for all hints, I will try 'm out soon as when i get back to work in the morning.
Could it also maybe have something to do with MSCP_LOAD parameter as VMS seems to crash there ? Jan

[Peter Zeiszler]

Is your 8.3 shadow system disk a different unit number than your 7.3-2 shadow disk?

[Volker Halle]

Jan,

the register printout is from an IMAGE incurring an improperly handled condition. The MSCP message is just the most recent message printed by STARTUP.COM before this happens. The OPC$* message is printed after executing SYLOGICALS.COM. The unexpected image termination is anywhere inbetween.

Volker.