How do we determine why there is no "IPL" on the VNX-5300 disk after

[gr8_lkr]

We are having a problem with a rp3410 booting from an EMC VNX-5300.

We are installing via an Ignite tape made from an image on an internal

disk on the same rp3410. The Ignite install performs flawlessly,

but when the server reboots, it hangs at the message:

Booting...

Boot IO Dependent Code (IODC) revision 10

Whether we install from the Ignite tape or from the original HP-UX

DVD, we get the same result.

With the first reboot after the installation, if we interupt the

boot process and execute "sea ipl":

Main Menu: Enter command or menu > sea ipl

The VNX-5300 disk does not show up. Yet, if we boot to the internal

disk, we can access the VNX-5300 disk just fine. A "lifls -l"

command on the VNX-5300 disk and the internal disk, other than dates

and times, yields exactly the same information:

flo1cswtst /homeroot # lifls -l /dev/rdsk/c6t0d0

volume ISL10 data size 7984 directory size 8 06/10/27 14:23:07

filename type start size implement created

===============================================================

ISL -12800 584 242 0 06/10/27 14:23:07

AUTO -12289 832 1 0 06/10/27 14:23:07

HPUX -12928 840 1024 0 06/10/27 14:23:07

PAD -12290 1864 1468 0 06/10/27 14:23:07

LABEL BIN 3336 8 0 12/03/26 13:29:08

flo1cswtst /homeroot # lifls -l /dev/rdsk/c3t2d0

volume ISL10 data size 7984 directory size 8 06/10/27 14:23:07

filename type start size implement created

===============================================================

ISL -12800 584 242 0 06/10/27 14:23:07

AUTO -12289 832 1 0 06/10/27 14:23:07

HPUX -12928 840 1024 0 06/10/27 14:23:07

PAD -12290 1864 1468 0 06/10/27 14:23:07

LABEL BIN 3336 8 0 12/03/23 09:16:06

flo1cswtst /homeroot #

While booted to the internal disk, we are able to import the

Volume Group on the VNX-5300 disk and mount all the file systems.

We've install the latest Firmware, the latest HW Enablement patch,

the latest version of Ignite, and the latest Fibre Channel drivers.

How do we determine why there is no "IPL" on the VNX-5300 disk after

a successful install?

Any thoughts,  hope I am in correct board.

[Torsten.]

Check this page:

http://www.hp.com/products1/serverconnectivity/mass_storage_devices.html

It says boot is supported. Now it depends on the array settings and on the FC HBA inside your server ...

You cannot find it using the "search" command from boot menu, this is normal.

What happens, if you just let it boot? Any messages after a while?

What happens, if you select "interact with ISL"?

[gr8_lkr]

Hi Torsten and thank You!  I can always count on you.

well it appears to hang forever for sure overnight

We are installing via an Ignite tape made from an image on an internal

disk on the same rp3410.

 The Ignite install performs flawlessly,

but when the server reboots, it hangs at the message:

Booting...

Boot IO Dependent Code (IODC) revision 10

Whether we install from the Ignite tape or from the original HP-UX

DVD, we get the same result.

-------------------------------------------------------------

now we did try and remove the disk and present another and really are getting tied up with lun presentation and not what we expected to see but I will save that for later if interested. here are som emore notes:

o1cswtst /homeroot # swlist | grep -i 11i

BUNDLE11i B.11.23.0409.3 Required Patch Bundle for HP-UX 11i v2 (B.11.23), September 2004

FEATURE11i B.11.23.1009.083 Feature Enablement Patches for HP-UX 11i v2, September 2010

HPUX11i-OE B.11.23.0512 HP-UX Foundation Operating Environment Component

HWEnable11i B.11.23.1012.085a Hardware Enablement Patches for HP-UX 11i v2, October 2010

QPKAPPS B.11.23.1012.086a Applications Patches for HP-UX 11i v2, December 2010

QPKBASE B.11.23.1012.086a Base Quality Pack Bundle for HP-UX 11i v2, December 2010

flo1cswtst /homeroot #

And yes, /dev/rdsk/c6t0d0 is the VNX-5300 disk.

-Greg

[Torsten.]

While accessing the LUN from hp-ux or while doing an ignite restore, the LUN access is always from a running hp-ux, this means the FC driver is used.

But while booting the pdc code (server firmware) must provide all the functionality to the fc hba.

Now the question is:

- what fc hba do you have (supported for boot)?

- is servers firmware up to date?

Type "SYSREV" to display system revision information. The following should be displayed if the current firmware is installed.
Current firmware revisions

        MP FW        : E.03.32
        BMC FW       : 03.53
        System FW    : 50.40
        

 http://h20566.www2.hp.com/portal/site/hpsc/template.PAGE/public/psi/swdDetails/?sp4ts.oid=1828449&spf_p.tpst=psiSwdMain&spf_p.prp_psiSwdMain=wsrp-navigationalState%3Dlang%253Den%257Ccc%253DUS%257CprodSeriesId%253D2512013%257CprodNameId%253D1828449%257CswEnvOID%253D54%257CswLang%253D13%257CswItem%253Dpf-92188-3%257Caction%253DdriverDocument&javax.portlet.begCacheTok=com.vignette.cachetoken&javax.po...

And finally, why do you want this "old" system to boot from SAN?

[gr8_lkr]

Hello Torsten,  and sorry for the late response server is offsite.

here we go :

SYSREV

  Current firmware revisions

   MP FW     : E.03.32

   BMC FW    : 03.53

   System FW : 50.40

  [flo1cswtstmp] MP:CM>

So it looks like we are at the latest versions?

Torsten, I am also going to attach a rather lengthy file that has alot of question possibly answered for you .  I really appreciate the help.  -gr8-lkr

[gr8_lkr]

Torsten,

1. "Now it depends on the array settings and on the FC HBA inside your server"

We have the A6795A HBA.  I know that's just a "marketing" name.  I've attached

below the output from some fcmsutil and scu commands that ought to show you

the configuration.

2. "You cannot find it using the 'search' command from boot menu, this is

normal."

Hmmm?

Main Menu: Enter command or menu > sea

Searching for potential boot device(s)

This may take several minutes.

To discontinue search, press any key (termination may not be immediate).

IODC

   Path#  Device Path (dec)  Device Path (mnem)  Device Type               Rev

   -----  -----------------  ------------------  -----------               ---

-

   P0     0/0/2/0.0          ide.0               Random access media       1                         

   P1     0/1/1/1.2          intscsib.2          Random access media       1                         

   P2     0/1/1/1.0          intscsib.0          Sequential access media   1                         

   P3     0/4/1/0.0                              Random access media       10                         

Main Menu: Enter command or menu > bo p3 Interact with IPL (Y, N, or Cancel)?>

n

Booting...

Boot IO Dependent Code (IODC) revision 1

                              ...and then we just hang, ad infinitum

So we do "find" it.  But the results are not stellar.

3. "What happens, if you just let it boot? Any messages after a while?"

I assume you mean the Primary Boot Device is set to the VNX5300 disk and we do

not interrupt the boot process... Well, it gets here...

  Boot IO Dependent Code (IODC) revision 1

and hangs...

4. "What happens, if you select "interact with ISL"?"

I'll explain in a minute why I can't show you a test of this, but it's

basically the same as without interacting with the ISL.  It gets to where it's

trying to pull something down from the VNX5300 disk and we never see anything

else happen.

Now for our current status which might interest you.  Last week, EMC support

asked me "What happens if you use a different disk"?  Early in this process (

i.e. summer of 2011... ) I had tried that.  But I couldn't remember the

specifics of what happened or didn't happen.

I already had two LUNs defined on the array.  So I removed the one I had been

using from the Storage Group, then assigned the other one to the Storage

Group.  Whereas the first LUN was assigned Host LUN Id of "0", I assigned Host

LUN Id of "1" to the second LUN.  You'll see on the ioscan output below that

the server still sees this disk as LUN "0" (0/4/1/0.76.5.0.0.0.0 ).  And now,

during an Ignite Tape Install ( attempt ), the device scan at the beginning

cannot find any disks to install to.  All this is obviously a problem.  We

discovered this last Friday, right before our End-Of-Quarter weekend, me

getting sick, and my assistant leaving for a week of vacation.

So we've not really progressed against that issue yet.  But it harkens back to

where you said "Now it depends on the array settings...".

EMC Support wants to have a WebEx session with me again which I'm all in favor

of.  But with us being off on Friday for Good Friday, I suspect that will not

happen until next week.

So, with all that said, there is one question I have for HP Support.

Simply because of my lack of in-depth knowledge of the HP9000/HP-UX

architecture, I don't really know what has to be physically on the disk ( and

where ) to enable the boot process.  I've run the "lifls" command against both

the internal ( c3t2d0 ) and VNX5300 ( c6t0d0 ) disks:

  flo1cswtst /homeroot # lifls -l /dev/rdsk/c6t0d0

  volume ISL10 data size 7984 directory size 8 06/10/27 14:23:07

  filename   type   start   size     implement  created

  ===============================================================

  ISL        -12800 584     242      0          06/10/27 14:23:07

  AUTO       -12289 832     1        0          06/10/27 14:23:07

  HPUX       -12928 840     1024     0          06/10/27 14:23:07

  PAD        -12290 1864    1468     0          06/10/27 14:23:07

  LABEL      BIN    3336    8        0          12/03/26 13:29:08

  flo1cswtst /homeroot # lifls -l /dev/rdsk/c3t2d0

  volume ISL10 data size 7984 directory size 8 06/10/27 14:23:07

  filename   type   start   size     implement  created

  ===============================================================

  ISL        -12800 584     242      0          06/10/27 14:23:07

  AUTO       -12289 832     1        0          06/10/27 14:23:07

  HPUX       -12928 840     1024     0          06/10/27 14:23:07

  PAD        -12290 1864    1468     0          06/10/27 14:23:07

  LABEL      BIN    3336    8        0          12/03/23 09:16:06

  flo1cswtst /homeroot #

Just from the standpoint of being able to say to EMC "Ye verily, this disk is

bootable", is this all I need to do?  Looking at the type, start, and size

columns it looks to me like the boot sectors are the same.  Any comments or

suggestions?

[Torsten.]

The A6795A is supported for boot with PDC 44.06 or higher on a rp34x0 according to the matrix.

But a search cannot find the LUN, because the system firmware is not "clever" enough to search the SAN.

You need to set the complete path as boot path (ignite does this for you).

MENU> path

to show.

This is the contents of the disks boot area:

ISL -12800 584 242 0 06/10/27 14:23:07

AUTO -12289 832 1 0 06/10/27 14:23:07

HPUX -12928 840 1024 0 06/10/27 14:23:07

PAD -12290 1864 1468 0 06/10/27 14:23:07

LABEL BIN 3336 8 0 12/03/26 13:29:08

ISL - Initial system loader

AUTO - the AUTO file (contains the boot string)

HPUX - the OS loader, loads the kernel

PAD - filling the space

LABEL - contains boot specific settings

So all needed files are there.

[gr8_lkr]

Thank You Torsten,  As soon as I can get an onsite we will look into this.

I will let you know how things progress.

Sorry I didnt get back sooner and thank you very much for your time! as always.

-G

[gr8_lkr]

Hi Torsten, still no luck.

Thanks for the suggestion of "setting the complete path" for boot.  If you mean something like this:

  Main Menu: Enter command or menu > boot 0/4/1/0.76.5.0.0.0.0

the above boot attempt always fails/hangs.

Let me step back just a little bit here.  A week, or so, EMC guys asked me "Have you tried a different disk"?

Though I had used a different Array LUN many months ago, with all the work/changes going on I thought it was a good idea to try a different disk ( Array LUN ).  I have had two Array LUNs created and available for testing with this server since I started trying to get it to boot from the VNX5300.  They happen to be named LUN10 and LUN11.  With this "Attempt to boot" process, I've only been using LUN10.  When I allocate it to the Storage Group for this server, I assign it Host LUN Id "0".

So, I removed LUN10 from the Storage Group, and added LUN11 to the Storage Group.  I assigned LUN11 a Host LUN Id of "1".  That's when I noticed a problem ( other than the fact that I still can't boot to the VNX5300 Array ).

On HP-UX, I was seeing LUN11 as LUN Id "0".  It should have been showing up as LUN Id "1".  Here is the output of "ioscan -fnC disk":

  disk  2  0/4/1/0.76.0.255.0.0.0  sdisk  CLAIMED  DEVICE  DGC  LUNZ

           /dev/dsk/c5t0d0   /dev/rdsk/c5t0d0

  disk  3  0/4/1/0.76.5.0.0.0.0    sdisk  CLAIMED  DEVICE  DGC  VNX5300WDUNB

           /dev/dsk/c6t0d0   /dev/rdsk/c6t0d0

So I decided to "regroup".  I captured a fresh Ignite Tape of the working system on the internal disk.  I was going to do a fresh install from that tape to the disk ( LUN10 / Host LUN Id "0" ) on the VNX5300.  That's when I ran into a problem that I think is HP-UX related.

A couple little side notes:

  1)  When I do these installs to the VNX5300 Array, I always remove the

      internal disk to ensure I don't overwrite a working system.  Yes,

      I'm paranoid.

  2)  As I've been addressing this problem ( for months now ), I've always

      had the gut feeling that the real issue was related to the VNX5300

      and/or its' configuration.  I say that because I have rp34x0's

      booting quite successfully from an EMC CLARiiON and from a HP

      MSA-1000.  This is the first problem I've seen that I can identify

      as being related to HP-UX and/or its' utilities.

I'm at a loss now because throughout this months long process, I've always been able to successfully install to the VNX5300 Array.  Now, I'm unable to even do that.

So let me step you through my install attempt from this morning and I'll identify where things go downhill.  Remember that I've pulled the internal disk out and there is only one Array Lun ( LUN10 / Host LUN Id "0" ) visible to this server across the SAN. (this will be in the attachment)  any thing you can suggest I would REALLY appreciate.

[Torsten.]

This is strange:

disk 2 0/4/1/0.76.0.255.0.0.0 sdisk CLAIMED DEVICE DGC LUNZ

/dev/dsk/c5t0d0 /dev/rdsk/c5t0d0

disk 3 0/4/1/0.76.5.0.0.0.0 sdisk CLAIMED DEVICE DGC VNX5300WDUNB

/dev/dsk/c6t0d0 /dev/rdsk/c6t0d0

A path like

0/4/1/0.76.0.255.0.0.0

with a "255" is usually seen on loops, but it is still different.

On the other hand it would be OK for a controller devices, but your device is a disk!

  In such case you often see more device files than expected, and often no LUN > ID 7.

The path

0/4/1/0.76.5.0.0.0.0

correctly looks like a fabric attached device.

The only case when I have seen this so far is when the LUN presentation settings were wrong.

All have different names for this addressing mode (Volume Set Addressing would probably be the right one), but basically they present the LUN in Windows mode, not in HP-UX mode - this creates (strange) problems.