Itanium bootp/tftp boot error

[Alan Comstock]

I'm attempting to install VMS V8.31h1 Itanuim on a rx2600 via bootp/tftp(PXE) network boot from an Alphaserver1000 that contains the VMS Itanium install DVD(in a DVD drive) with the correct files moved to the correct TFTP directory. It attempts to load but then I get a "unexpected trap". Any ideas as to the problem trap??? Is there a way to get the error that is causing the problem? I'm stuck on this. Output is below.

Please select a boot option

Boot from Bootp

Use ^ and v to change option(s). Use Enter to select an option

Loading.: Bootp

Running LoadFile()
CLIENT MAC ADDR: 00 30 6E 38 19 68
CLIENT IP: 192.168.1.72 MASK: 255.255.255.0 DHCP IP: 0.240.0.0
Running LoadFile()
Starting: Bootp
7 0 0x00006B 0x000000000000000B unexpected trap
7 0 0x000066 0x000000000000000B trap taken, number in ext PE
7 0 0x00003C 0x0000000000002C00 trap taken, offset in ext PE

[Steven Schweda]

I know nothing, but if you define a system
logical name or two, say,
"TCPIP$TFTP_TRACE" = "1"
and, perhaps:
"TCPIP$TFTP_EXTLOG" = "1"
then you might learn something from
SYS$SYSDEVICE:[TCPIP$TFTP]TCPIP$TFTP_RUN.LOG
(or somewhere).


> [...] the correct files [...]

Which are? UNIX-compatible format (Stream_LF
or fixed-512)?

[Alan Comstock]

Files are copied as specified in the Integrity VMS Installation Manual.

[Hoff]

If the files are copied as specified in the Integrity OpenVMS software installation manual and the AlphaServer box is set up per instructions for (I assume) host-based InfoServer, then it's probably time to call HP support and ask for formal help.

The DHCP IP of 0.240.0.0 looks completely bogus. That's potentially a busted DHCP client, or a busted EFI display. There's an IANA reserved range for DHCP client IP activity, 169.254.0.0/16. While not all DHCP clients play well (do any?), I'd not expect to get to get 0.240.0.0 either from a local DHCP server, or as an address if I wasn't able to get an address from the DHCP server.

If the traps are a result of no DHCP client address and if these traps comprise the sole error message(s) for no DHCP address, then the EFI firmware is busted.

If you're not using DHCP and have a static IP enabled (which the 192.168.1.72 address listed could imply), then I'd a: move out of the 192.168.0.0/16 subnet for the sake of the VPNs, and would ignore the above DHCP details. I'd b: ensure there is connectivity within the subnet, as vLANs and LAN-level configurations can potentially derail communications among "new" host addresses. And I'd poke around in the logs.

Do also ensure the EFI firmware is reasonably current. The older firmware for the rx2600 series did have its share of issues and limits. If this is one of the recent crop of US$200 boxes, those definitely had seriously down-revision EFI firmware.

If you're in a hurry, I'd tend to use the EFI path, or a local DVD. If you have access to shared SCSI storage between these two boxes, you can transfer the kit over that way.

If your firmware is down-revision, I'd use the DVD or the EFI-level ftp stuff to transfer over the firmware images and then fix that issue first, and then move along to an InfoServer installation of OpenVMS I64 and such or the SCSI-based transfer of the bits over; the stuff up above.

And even though HP says you can operate without one, it's just a whole lot easier to have a DVD in these boxes.

[Alan Comstock]

The ip's that are echoed are the same as the manual. I'm pretty sure thats not it. I loaded another one this way. Firmware is up to date. I'll look thru the TCP logs for problems. Any other ideas... anyone?

[Alan Comstock]

i feel like a intel robot.. i reboot and reboot; the alpha and itanium. error went away. now I don't get prompted or any confirmation when trying to boot over the net. aarg. i'm repl/enabled and I don't see any requests. I must be stupid still. Here is the DCL I keep using:


$ set nover
$ on sever then cont
$ @sys$STARTUP:ESS$LAD_STARTUP.COM
$ set ver
$ delete TCPIP$TFTP_ROOT:[V831H1]*.*;*
$ delete TCPIP$TFTP_ROOT:[000000]V831H1.dir;*
$
$ creat/dir TCPIP$TFTP_ROOT:[V831H1]
$
$ dismount dka500:/nounload
$ mount/system dka500: I640831H1
$ COPY dka500:[SYS0.SYSCOMMON.SYSEXE]VMS_LOADER.EFI -
TCPIP$TFTP_ROOT:[V831H1]VMS_LOADER.EFI
$ COPY Dka500:[SYS0.SYSCOMMON.SYSEXE]IPB.EXE -
TCPIP$TFTP_ROOT:[V831H1]IPB.EXE
$
$ infoserver:==$ess$infoserver
$ INFOSERVER delete SERVICE I640831H1
$ INFOSERVER CREATE SERVICE I640831H1 Dka500:
$
$ TCPIP SET noHOST node12
$ TCPIP SET noHOST node12a
$ TCPIP SET nobootp node12
$ TCPIP SET nobootp node12a
$
$ TCPIP SET HOST node12/ADDRESS=192.168.1.69
$ TCPIP SET HOST node12a/ADDRESS=192.168.1.70
$
$ TCPIP SET BOOTP node12 /HARDWARE=ADDRESS=00-30-6e-38-19-68 -
/FILE=[V831H1]VMS_LOADER.EFI
$ TCPIP SET BOOTP node12a /HARDWARE=ADDRESS=00-30-6e-38-99-42 -
/FILE=[V831H1]VMS_LOADER.EFI
$

How bad is that(edited)

[Steven Schweda]

> [...] I'll look thru the TCP logs for
> problems. [...]

Well?

Aside from the actual TFTP log file, I
noticed this when I used a loose TFTP client
to fetch a file:

%%%%%%%%%%% OPCOM 23-JAN-2009 09:24:57.00 %%%%%%%%%%%
Message from user INTERnet on ALP
INTERnet ACP TFTP Accept Request from Host: 10.0.0.9 Port: 51283

I haven't tried actually booting anything
this way, however.


> I must be stupid still.

Could be. Not enough evidence yet.

[Alan Comstock]

Bad network cable.

[Alan Comstock]

bad network cable