O/S v7.3-2 bugcheck on start-up

[VMSdude]

Have cloned a V7.3-2 system disks from a two node cluster. The first server alpha1 is ok but the other memeber alpha2 bugchecks with the following error message.

>>>b -fl 4,1
block 0 of dga1.1001.0.1.1 is a valid boot block
etc
etc
SYSBOOT> !! from here I can review things
SYSBOOT> C

OpenVMS (TM) Alpha Operating System, Version V7.3-2
© Copyright 1976-2003 Hewlett-Packard Development Company, L.P.
%DECnet-I-LOADED, network base image loaded, version = 05.10.00
%CNXMAN, Using remote access method for quorum disk
%VMScluster-I-LOADSECDB, loading the cluster security database
%VMScluster-W-WARNING, error configuring SCA ports, LOAD_PORTS return status, STS = 0000034C
**** OpenVMS (TM) Alpha Operating System V7.3-2 - BUGCHECK ****

** Bugcheck code = 0000036C: PROCGONE, Process not in system
** Crash CPU: 00 Primary CPU: 00 Active CPUs: 0000000F
** Current Process = STACONFIG
** Current PSB ID = 00000001
** Image Name = STACONFIG.EXE

Whats the problem?

[labadie_1]

PROCGONE means a process should be here, but has died in the meantime.

By the way,
$ exit %X34C
%system-f-ivbuflen, invalid buffer length

Do both your alpha have the same hardware (for example, both are DS25) or not ?

[Richard Whalen]

34c = %SYSTEM-F-IVBUFLEN, invalid buffer length

Could be an error from creating the LANACP process. Though the values for its quotas are hard coded and I suspect would cause no problems if everything else is operating at or above minimum values.

Could also be an error loading the PEDRIVER.

Probably the best way to get beyond this is to set SYSTARTUP_P1 = "MIN" from the SYSBOOT>
prompt and do an @SYS$UPDATE:AUTOGEN GETDATA SETPARAMS NOFEEDBACK after the system comes up.

[Duncan Morris]

VMSdude,

welcome to the ITRC OpenVMS forum!

Your error message is coming from sys$system:staconfig.exe

The %x34c response, as indicated by the other replies, shows a problem with some buffer length.

From a quick look at the image, it should read cluster_authorize.dat and iogen$prefix.dat. As the former will probably be in the sys$common:[sysexe] area, whilst iogen$prefix.dat is in the root specific [SYSMGR] directory, I would suggest that you do a dir/full on iogen$prefix.dat in both root directories and look for significant differences in structure.

Duncan

[Jon Pinkley]

VMSdude,

We really need more info. Do you have a valid crash dump?

How did you clone the system disk? (HSG80, EVA, backup/physical, backup/image, something else)

Did the cluster from which the disk was cloned work correctly?

First, are you trying to boot new systems into the existing cluster from which the system disk was cloned? If so you will need to ensure the new members have unique cluster SCSNODE and SCSSYSTEMID values. And the second system disk will need to have a unique disk label.

If you are not trying to boot into the existing cluster, at least for the initial test, make sure your new two node cluster is on its own LAN with no connection to the original cluster. And don't present the same DG disks as are being presented to the other cluster. Otherwise, expect disk corruption.

If isolating the new cluster allows the nodes to boot, the crash is probably due to both clusters using the identical CLUSTER_AUTHORIZE.DAT (cloned with the rest of the disk). This contains a cluster group number and cluster password that are used to tag cluster traffic so each cluster can recognize traffic that belongs to it. If you are running two unique clusters on the same ethernet, each cluster must have a unique group number.

http://h71000.www7.hp.com/doc/731FINAL/4477/4477pro_003.html#index_x_168

I am not sure if this bugcheck could be explained by the above, I didn't try to reproduce it. However, the bugcheck messages are not always as descriptive as we might like.

Perhaps you have already solved your problem. If so can you report back what the cause/fix was?

Jon

[Volker Halle]

VMSdude,

STACONFIG is trying to load the SCA port drivers and has incurreced some error condition.

Try setting the debug boot flags:

>>> b -fl 0,30000

and see if you can get more information about the underlying reason for this problem.

Also condier setting DUMPSTYLE bit 1 to get the register printout and report the value of R0 from the crash output.

Volker.