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

[John Abbott_2]

FWIW I upgraded a GS80 on a SAN from V7.3-2 (fully patched) to V8.3 + UPDATE V2 and all patches listed in the master ECO list, excluding LAN V1 & ACMELDAP V2 no problems before for after (well, 7 days and counting...)

Regards
John.

[Jan van den Boogaard]

I did the startup_p1 MIN and startup_p2 VPC, see output attached, but then it didnt crash.
I believe Anton is right. I suspect highly the site specific startup stuff, so I'll focus on that for the moment.
Thnx sofar.

[Jan van den Ende]

Jan,

next time you post a .LOG file, please rename to .TXT before postin ( the PITD firewall does not even allow lowercase .txt extension!)
Some (at least my) browser does NOT know that .LOG means ASCII, and after binary transfer it takes some effort to read it.

So now, the next try will be with STARTUP_P1 empty, and STARTUP_P2 again for full output?

Success.

Proost.

Have one on me.

jpe

[Jan van den Boogaard]

Found the location of the ACCVIO.

The commands SHOW SHADOW and SHOW SHADOW /POLICY=HBMM cause the accvio. The command SHOW SHADOW/POLICY=HBMM/NAME=DEFAULT does not give an ACCVIO, strangely enough.

Those commands were somewhere in a sitespecific startup. So:
1) yes, cause was in the site startup.
2) the command crashing is SHOW SHADOW

It might have something to do with upgrading from a 7.3-2 system with HBMM kit installed to 8.3. I didnt have these problems on a system that I installed straight from 8.3 DVD, and using the same site startup....

so the problem is little more pinpointed now.

[Jan van den Ende]

Jan,

Great!.

So now the issue is:

WHY does the upgraded disk crash, where the fresl installed does NOT.

What version/patch level of HBMM is/was on the 7.3-2 system?

Is there any difference in SYSGEN SHD* & SHAD* params?

Proost.

Have one on me.

jpe

[Jan van den Ende]

Jan,

Great!

So now the issue is:

WHY does the upgraded disk crash, where the fresl installed does NOT.

What version/patch level of HBMM is/was on the 7.3-2 system?

Is there any difference in SYSGEN SHD* & SHAD* params?

Proost.

Have one on me.

jpe

[Robert Brooks_1]

From talking with the shadowing engineer a couple of weeks ago, this is a known problem. He knows exactly what the issue is, and how to fix it.

I'd formally contact your HP support centre to make the problem resolution process moves along quickly.


-- Rob

[Jon Pinkley]

Jan van den Boogaard,

Several questions.

Please verify that there are no 7.3-2 versions of images in the sys$specific directories. Under some circumstances an image gets placed in the sys$specific area instead of the sys$common area, and the upgrade only places things in the sys$common area. In this case, after the upgrade most images will not be found in the sys$specific area (intended behavior), but the images that do exist in the specific directory will be used instead of the ones in the common directory.

What do you get from the following command?

$ directory sys$system:setshoshadow/date/size=all

If you see two flles, one in sys$specific and one in sys$common, you should determine the version of each. If the one in sys$specific is an older version (perhaps from a patch), you should rename it to something like .exe_old and then reboot.

You can determine the image ident with the following command:

$ analyze/image/select=(ident,link) sys$system:setshoshadow

or for sys$common version

$ analyze/image/select=(ident,link) sys$common:[sysexe]setshoshadow

You should still open a call as suggested by Robert Brooks.

Jon

[Thomas Ritter]

While this answer may not help, I thought I would comment on the way we perform upgrades. We NEVER perform rolling upgrades on major upgrades. Always a new empty disk and complete install from scratch. This is an approach adopted because our outage windows are very very small and because it works so well. We also design our systems so that the system disks are basically read only. Our layered products installations and patch installations are always in batch mode. This way when two or more administrators are performing upgrades, absolute certainly is assured. No patch or product installation will be missed.

[Robert Brooks_1]

Unless the problem you've discovered is quite different from the one that's already known by the guy within VMS Engineering who deals with shadowing, it's likely that you have done nothing wrong with your upgrade. The SETSHOSHADOW image is not particularly dependent on any of the shadowing SYSGEN params. As Jon Pinkley pointed out, an image incorrectly placed in SYS$SPECIFIC, as opposed to SYS$COMMON:, would be a bad deal, as that image is quite dependent on shadowing-specific data structures that do change from version to version, and it's almost a guarantee that a V7.3-2 image would be really unhappy on a V8.3 system.

The point of the above is to suggest that spending any time figuring out what went wrong is not likely to be worth your time; it's likely that the fault is ours.

-- Rob