Problem to upgrade from 6.2 to 7.3 on a restored system disk

[Guillou_2]

Hi,

We try to upgrade from 6.2 to 7.3 on a restored system disk.
We make the save booting on the OpenVMS V6.2 CDROM et we restore the system on another server (from alpha 2100 to alpha 1000 4/200).
The backup command we use, is
backup/image/ign=noback/log dka0: mkb500:fdisk0.bck/save/label=stand

After the first restore we try to make a conversationnal boot but we had an error message, "unable to find sysboot.exe"

We make the restore again, and no problem but during the upgrade whe have several message "ncp.exe, file not found", "sys$network_services.exe, file not found". The upgrade complete and when we search these files on the upgraded disk we are able to find it and their modification date are good.

Any idea about our problem?

Thanks in advance for your help

regards

Steph

[Martin Vorlaender]

You can't directly upgrade 6.2 to 7.3, see http://h71000.www7.hp.com/wizard/faq/vmsfaq_006.html#alpha_path

HTH,
Martin

[Bojan Nemec]

Martin,

Sorry, but I must disagree with you. 6.2 is in the 7.3 upgrade path. See http://h71000.www7.hp.com/doc/73final/6629/6629pro_006.html#upg_path

Steph, maybe there is some hardware problem? Have you figure out why the first restore fail?

The /ignore=nobackup is not needed for this operation (if you dont have some user files marked nobackup)

Bojan

[Uwe Zessin]

Hello Steph,

how did you restore the image backup? There can be a problem when a V6.2 save set is restored by a V7 BACKUP - it can loose directory entries like [000000]VMS$COMMON.DIR. I think the 'trick' is to use either /ALIAS or /NOALIAS (I never can remember which one is right, sorry) on the BACKUP command.

[Bojan Nemec]

Steph,

As Uwe mentioned there can be a problem in backup. Try to restore the backup with the 6.2 CD and then upgrade with the 7.3 CD.

Bojan

[Ian Miller.]

it may be that the filestructure is not quite right on your system disk. Do a ANAL/DISK before the backup or after the restore and before the upgrade. The alias entries for [VMS$COMMON] and [SYS%.SYSCOMMON] are sometimes wrong.

[Guillou_2]

We backup the system with openvms 6.2 CD-ROM.
We also make the restore with this CD-ROM:

BACKUP/IMAGE/IGNORE=LABEL/REW MKB500: DKA0:

We make the upgrade with openvms 7.3 CD-ROM.
Before and after each step, we have made an ANALYSE/DISK/REPAIR and there is no error.
We have sometimes during the upgrade

DKA0: is offline. Mount verification in progress
DKA0: has completed mount verification.

so we will try to change the disk.
But I feel that we have a problem with ALIAS on the VMS$COMMON.DIR.

How can we do to check this and eventually solve this problem?

thanks in advance for your help

regards

Steph

PS: I will assign point as soon as i have time for this. :o)

[Uwe Zessin]

Hello Steph,
you should not see any mount verifications. It looks like you have a problem with you SCSI bus(es).

[Ian Miller.]

I think ANAL/DISK should pick up the alias problem but as another check the file id displayed by
dir/fu sys$sysdevice:[000000]vms$common.dir
dir/fu sys$sysdevice:[sys0]syscommon.dir
should be the same.

If you are getting the disk on/offline you may have a hardware problem. One issue I've seen with AS1000 is ensure the onboard scsi is properly terminated (may be connector on the back).

[Uwe Zessin]

My experience from the past is that BACKUP drops file header(!) of VMS$COMMON.DIR if you don't supply the correct /ALIAS or /NOALIAS qualifier in the situation I have mentioned above.

[Volker Halle]

Steph,

[SYS*]SYSCOMMON.DIR must have the same File-ID as [000000]VMS$COMMON.DIR - you can check this with DIR/FILE_ID

If one of those directory entries would be missing, you can create the appropriate ALIAS entry with

$ SET FILE/enter=alias-filespec filename

But first find out, what's really wrong here and be careful with SET FILE/REMOVE and SET FILE/ENTER.


Check $ HELP BACK/ALIAS regarding the use of the /ALIAS qualifier.

Volker.

[Bojan Nemec]

Steph,

I agree with Ian that you must check the SCSI termination. Disk on/offline is often caused by bad SCSI bus termination (not terminated or terminated on more than one point). Some SCSI devices have a SCSI termination switch.

How about Console Firmware version? Have you upgraded the Console Firmware from the CD which comes with the distribution?

Bojan

[Guillou_2]

Hi all and thanks for your help,

I didn't do an upgrade firmware, i agree that i probably have an hardware problem...

Files have the same id, but if i do a show dev/file sys$sysdevice on the restored system the file have the form
[syscommon.xxxx]xxx.xxx
on the production server this command sends something like [vms$common.xxxx]xxx.xxx

If the file id are the same, could this be a problem for the upgrade?

Steph

[Uwe Zessin · Accepted solution]

Ah, yes. Standard error. The problem is that BACKUP has put the wrong file name in the file header.

$ set default disk:[000000]
$ rename VMS$COMMON.DIR SYSCOMMON.DIR
$ rename SYSCOMMON.DIR VMS$COMMON.DIR

[Volker Halle]

and here is the pointer to the full article describing this problem and the solutions/workarounds:

http://h18000.www1.hp.com/support/askkcs/hpcg/215_0_158064811_3753069.html

Volker.

[Guillou_2]

Thanks all for your precious help

Changing the disk solve the problem of "mount verify".

In order to correct the problem on vms$common/syscommon after a restore we have done:
$ set default disk:[000000]
$ rename VMS$COMMON.DIR SYSCOMMON.DIR
$ rename SYSCOMMON.DIR VMS$COMMON.DIR

All the upgrade is now ok

regards

Stephs