SAN BOOT from OpenVMS

[Robert Jacobs]

Hi all

I am going to create a SAN boot disk soon from my current configuration. All has gone well with the GS160 system that has two partions that I have clusterd with two separate local systems disks. I have them working with some SAN storage using a Quorum disk. Things are working great.

I will uncluster these systems by just turning off the cluster parameter in modparams and regen. I will make sure one node comes up stand alone.

1. I have created a backup image of the systems disk.

2. I plan on restoring this image to a SAN available disk i.e. $1$dga12

3. I plan on setting the boot flag at the >>> prompt something as follows

B -fl 0,1 $1$dga12

4. Do I need to do some set up in WWIDMGR utility or can someone give in any addtional set up tasks I need to do

Thank You

Robert J.

[Andy Bustamante]

You do need to use wwidmgr to enable the the Alpha to use a SAN boot device. In your case

>>>wwidmgr -quickset -udid 12

This will enable the Alphaserver to use this device as a boot disk and define the paths. To permanently set a boot environment

>>> init
>>> set boot_osflags #,0 (where # is the boot root)
>>> set bootdef_dev device1,device2,device3,device4
>>> boot

Andy

[Sheldon Smith]

And if you have somewhat recent firmware, you can use wildcards instead of entering each specific device path when setting bootdef_dev:

>>> set bootdef_dev dg*12.*.*.*.*

[DICTU OpenVMS]

Or even better, sometimes --quickset does the trick with bootdef_dev...

[Robert Jacobs]

Thank for the input

When I booted the device I got a bugcheck

Perhaps my backup image was bad I do not know.

I am looking for the steps to install the os on the SAN disk.

1. Should I install from the CD?

2. Should I try and do a backup/restor to this disk again?

below is what I set

P00>>>wwidmgr -quickset -item 45 -unit 777

Disk assignment and reachability after next initialization:


6005-0768-0183-000e-7800-0000-0000-0000
via adapter: via fc nport: connected:
dgb777.1001.0.1.2 pgb0.0.0.1.2 5005-0768-0110-066e Yes
dgb777.1002.0.1.2 pgb0.0.0.1.2 5005-0768-0130-01cf Yes
dgb777.1003.0.1.2 pgb0.0.0.1.2 5005-0768-0130-066e Yes
dgb777.1004.0.1.2 pgb0.0.0.1.2 5005-0768-0110-01cf Yes
dgc777.1001.0.3.2 pgc0.0.0.3.2 5005-0768-0110-066e Yes
dgc777.1002.0.3.2 pgc0.0.0.3.2 5005-0768-0130-01cf Yes
dgc777.1003.0.3.2 pgc0.0.0.3.2 5005-0768-0130-066e Yes
dgc777.1004.0.3.2 pgc0.0.0.3.2 5005-0768-0110-01cf Yes
P00>>>set bootdef_dev dgb777.1001.0.1.2,dgb777.1002.0.1.2

[Robert Brooks_1]

What was the bugcheck? What was the execlet and offset?

-- Rob

[Robert Jacobs]

This is the output from the console

I had used this image from a cluster before but I modified modparams and set cluster params to 0 and did not remove it from the cluster using the cluster config com procedure.

Should I try another restore or how to install the OS from cd on what is now seen as
dgb777.1001.0.1.2 $1$dga777


the bugcheck info is below


%SMP-I-SECMSG, CPU #01 message: P01>>>START
%SMP-I-CPUTRN, CPU #01 has joined the active set.
%SMP-I-SECMSG, CPU #04 message: P04>>>START
%SMP-I-SECMSG, CPU #05 message: P05>>>START
%SMP-I-CPUTRN, CPU #04 has joined the active set.
%SMP-I-CPUTRN, CPU #05 has joined the active set.

**** OpenVMS (TM) Alpha Operating System V7.3-2 - BUGCHECK ****
waiting for poll to complete pgb0.0.0.1.2
.Poll done

** Bugcheck code = 0000019C: INCONSTATE, Inconsistent I/O data base
** Crash CPU: 00 Primary CPU: 00 Active CPUs: 00000033
** Current Process = SWAPPER
** Current PSB ID = 00000001
** Image Name =

**** Starting compressed selective memory dump at 25-OCT-2005 13:00...
.......................................
...Complete ****

[John Travell]

Robert,
Can you post the CLUE file for this crash ? There should be a file in SYS$ERRORLOG: named CLUE$'nodename'_251005_1300.LIS, although the time in the filename may be a bit different.
Once we can see the complete footprint we may be able to tell you which eco fixes it, and if one doesn't you will need to log a case with HP for escalation to engineering. (You DO have an HP support contract, don't you ? :-)
An INCONSTATE bugcheck usually means that the view of hardware that VMS has seen does not match what VMS is expecting to see...

[Robert Jacobs]

Hi John

I will try and do this soon I am working on a few projects

Thank you Robert J.

[Robert Brooks_1]

John wrote . . .

An INCONSTATE bugcheck usually means that the view of hardware that VMS has seen does not match what VMS is expecting to see...

----

Which is not accurate -- INCONSTATE is used all over the I/O Exec to indicate problems that has nothing to do with hardware.

-- Rob

[Robert Jacobs]

I tried to install the OS from the distribution and still got the bugcheck.

On boot it indicates a valid boot block etc... but then breaks.

perhaps I need to patch the OS with some eco that with work with the Storage I am working with or perhaps a higher version of the OS?

Robert

[Volker Halle]

Robert,

the immediate INCONSTATE bugcheck when booting from a FC SAN device is most typically caused by a mismatch in the naming of the boot device between OpenVMS and the console. This applies, if the crash is in SYS$DKDRIVER and R0 will be 908 and R5 will contain a DGA device UCB.

Please make sure, that you use the following commands to set up the boot device:

>>> wwidmgr -show wwid
>>> wwidmgr -quickset -udid n

where n is your unit number of the boot device, i.e. the IDENTIFIER given to that device on the HSG80 (or EVA). Do NOT use '-item n'

Volker.

[Volker Halle]

Robert,


P00>>>wwidmgr -quickset -item 45 -unit 777


This command is wrong and the actual cause of your INCONSTATE bugcheck. You were talking about DGA12, so I assume, that the IDENTIFIER of your boot disk is set to 12, so you should have used the following command:

>>> wwidmgr -quickset -udid 12

Then everything would have worked flawlessy...

Clear the existing WWIDMGR variables with >>> WWIDMGR -CLEAR ALL and then use the above command to configure your boot device path.

Volker.

[Robert Jacobs]

I am going to use another disk for this effort and use the following commands



>>> WWIDMGR -CLEAR ALL


>>> wwidmgr -quickset -udid 4


The $1$dga12 or 12 unit was just an example

I will keep you posted

Robert J.

[Robert Jacobs]

I did the following

P00>>>WWIDMGR -CLEAR ALL >>>wwidmgr -quickset -udid 2

This worked fine!


I did another restore of the system disk to the $1$dga2 device and things looked good until the following

EIA0, FastFD mode set by console
%EIA0, Full Duplex 100BaseTX connection selected
%EIA0, Link state change: UP
%SYSINIT-I- waiting to form or join an OpenVMS Cluster
%CNXMAN, Sending VMScluster membership request to system GS160B
%CNXMAN, Now a VMScluster member -- system GS160A
%SYSINIT-E- error locking system device, retrying..., status = 00000840
%SYSINIT-E- error locking system device, retrying..., status = 00000840
%SYSINIT-E- error locking system device, retrying..., status = 00000840

.
.
.
SYSINIT-E- error taking out lock on system disk, status = 00000840

**** OpenVMS (TM) Alpha Operating System V7.3-2 - BUGCHECK ****
dismissing I/O Device Interrupt Number 38, not delivered to CPU 1
waiting for poll to complete pgb0.0.0.1.2
.Poll done

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

**** Starting compressed selective memory dump at 26-OCT-2005 10:27...
..................................................
...Complete ****

SYSTEM SHUTDOWN COMPLETE


Fun stuff huh?

Any thoughts on this before I try an use H.P. support

Robert J.

[Volker Halle · Accepted solution]

Robert,

there seems to be another node in this cluster (GS160B). It does seem to have the system disk $1$DGA2: allocated, from which you are trying to boot:

%X840 = %SYSTEM-W-DEVALLOC

Maybe you did the COPY ot that disk from the other node and forgot to $ DISM or/and $DEALLOC that disk.

Yeah, it's fun diagnosing crashes with minimum information ;-)

Volker.

[Robert Jacobs]

Hi Volker

Thank you so much for your help


I was a bit ahead of myself again and did forget to dismount and look for some basic gotchas I did need to boot min and edit the startup file and comment out some mount commands. I did notice that even after starting TCP/IP services and on a mount mismatch label of a disk I was not able to telnet or ssh into the system. I did need to boot min and as indicated comment out some mounts.

I guess even after 25+ years with VMS I still am just playing around compared to you folks that are very strong on internals etc...

Thanks again

Robert J.