[Info-vax] Integrity rx2800 i2 trying to boot from MSA2050
Tom Wade
nospam at void.blackhole.mx
Fri Jul 28 12:18:09 EDT 2023
Hi,
Thanks for all the responses to my query. Just to summarize:
The rx2800 i2 with the MSA2050 and the B9F24A(R) HBAs is a supported
combination, and should be able to boot from the SAN, once Update 1.0 is
installed with 8.4-2L1.
Tech support believe it to be a hardware problem, even though the SAN
disks work fine once VMS has booted.
The extensive document referred to in the link below, describes the
various steps required to get VMS to boot over those HBAs (by default it
can't). Unfortunately one of the early steps is to activate the Device
Manager ('d' during the pre boot sequence), then selecting the HBA, and
the HBAs don't appear at this point.
The suggestion that looks most likely to me at this stage is that a UEFI
driver for the relatively new HBAs is missing from the Integrity.
Since I am only providing the VMS expertise for this project, I'm
letting the hardware purveyors take this issue up with HP.
Customer is running from the internal RAID disk and using the SAN as
application to get up and running. If we find a subsequent solution, I
will post it here.
Regards, and again thanks to all.
> Hoping to hear from anyone who has got an rx2800 i2 booting from an MSA
> SAN using 16 Gb/s fiber HBAs. I am trying to clone a system disk from
> another rx2800 booting from an EVA SAN.
>
> Hardware Details.
>
> HP Integrity rx2800 i2 1.60GHz/6.0MB 8 CPU
> B9F24AR Fiber HBA
> MSA-2050 SAN
>
> Software
> VSI OpenVMS 8.4-2L1.
> Update 1.0 installed.
> Unclustered.
>
> ---
> OpenVMS installed on internal SCSI drive from VSI DVD OK.
> When booted from the internal drive, VMS can see the SAN $1$DGA disks,
> and perform I/O to them.
>
> I restored an /IMAGE saveset of the source machine (same hardware type
> and O/S version) onto one of the fiber disks. I then added a boot entry
> using SYS$MANAGER:BOOT_OPTIONS.COM for this disk and added it to
> position 1.
>
> efi$bcfg: $1$dga3021: (Boot000A) Option successfully added
> efi$bcfg: $1$dga3021: (Boot000B) Option successfully added
>
> Option 2 (List) shows
>
> Entry Description Options
> ----- ----------------------------------------------------------
>
> -------------
> 1 OpenVMS 8.4 on SAN $1$DGA3021 FGA0.2070-00C0-FF52-E296
> $1$DGA3021 PCI(0|a|0|0) Fibre(207000C0FF52E296,LunF000000000000)
> 2 OpenVMS 8.4 on SAN $1$DGA3021 FGA0.2470-00C0-FF52-E296
> $1$DGA3021 PCI(0|a|0|0) Fibre(247000C0FF52E296,LunF000000000000)
> 3 OpenVMS on DKA0: PKA0.0
> DKA0 PCI(0|1|0|0) Scsi(Pun0,Lun0)
>
> When I try to boot from the SAN device, I get
>
> Booting OpenVMS 8.4 SAN disk $1$DGA3021 FGA0.2470-00C0-FF52-E296
> Boot Failed. OpenVMS 8.4 SAN disk $1$DGA3021 FGA0.2470-00C0-FF52-E296
> Booting OpenVMS 8.4 SAN disk $1$DGA3021 FGA0.2070-00C0-FF52-E296
> Boot Failed. OpenVMS 8.4 SAN disk $1$DGA3021 FGA0.2070-00C0-FF52-E296
>
> I originally tried it with the unpatched DVD installed operating system.
>
> When that failed, I removed the boot entries, applied Update 1.0 to VMS
> on the internal SCSI drive, rebooted (from the internal drive), and
> re-added the SAN boot options. I did this because of information
> contained in a PDF document on the DVD, which suggested Update 1.0 was
> required. A link to the document on the VSI web site is
>
> https://docs.vmssoftware.com/docs/ENABLING_16GB_FC_HBAS_FOR_BOOT.pdf
>
> This made no difference.
>
> I then did an /IMAGE copy of the patched SCSI system disk onto another
> SAN drive, created new boot entries for this, and attempted to boot from
> that drive. I did this to make sure the version of OpenVMS on the SAN
> was fully patched to Update 1.0.
>
> Again, the same boot failure.
>
> The document describes booting into the EFI shell and the device
> manager, which I also did. The EFI shell was unable to see any file
> systems on fiber SAN:
>
> > EFI Shell list (fs entries)
> >
> > fs0 :Removable HardDisk - Alias hd9a0b blk0
> > PcieRoot(0x30304352)/Pci(0x1,0x0)/Pci(0x0,0x0)/Scsi
>
> (0x0,0x0)/HD(1,GPT,291986A1-20CC-11EE-A1D6-AA000400FEFF)
> > fs1 :Removable HardDisk - Alias hd9a0d blk1
> > PcieRoot(0x30304352)/Pci(0x1,0x0)/Pci(0x0,0x0)/Scsi
>
> (0x0,0x0)/HD(3,GPT,291986A0-20CC-11EE-A1D7-AA000400FEFF)
> >
> > VMS_SHOW EFI output
> >
> > fs0:\> \EFI\VMS\VMS_SHOW
> >
> > Searching 6 NET Device entries...
> > Searching 7 UEFI Device entries...
> > Searching 66 PCI Device entries...
> > Searching 65 VMS Device entries...
> >
> > VMS: DKA0 EFI: fs0 Vol: V8_4_2L1 DevInfo: HP LOGICAL
>
> VOLUME 6.64
> > fs0:\>
>
> No files found on fs1:
>
> The Device Manager was also unable to see the SAN adapters
> Device Manager output
> /--------------------------------------------------------------------------
>
> ----\
> | Device Manager
>
> |
> \--------------------------------------------------------------------------
>
> ----/
>
> Devices List Configure the iSCSI
> iSCSI Configuration parameters.
> Emulex 10G NIC: Bus:Dev:Func 09:0:0 -
> E4:11:5B:62:80:8A
> Emulex 10G NIC: Bus:Dev:Func 09:0:1 -
> E4:11:5B:62:80:8C
>
> The various scenarios described in the document refer to i4 or i6
> servers (this server is an i2). The only scenario mentioned using i2
> servers, was an example ("Use Case 2") whereby the customer was
> attempting to replace i2 servers by i4 or i6. The inference from this
> is either that i2 servers don't need any such special steps, or that i2
> servers cannot boot from an MSA 2050 SAN using an B9F24AR HBA.
>
> Customer opened a support call, and apparently the i2 is compatible, but
> since the HBA can't be seen from the EFI environment, it must be a
> hardware fault, despite the fact that once booted, VMS can see the drives.
>
> Any suggestions/experiences/comments gratefully received.
>
> ---
> Tom Wade
> OpenVMS Consultant and Enthusiast
> tom dot wade at tomwade dot eu
More information about the Info-vax
mailing list