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