Ignite-UX, tftp timeout issues while trying to recover a VPAR

[Mel Burslan]

Hello fellow HPUX enthusiats,

After about 6 years of (almost) no HP-UX. I have fouind myself on the hot seat. In the past I used Ignite UX and did not have any major issues other than one firewall here or there blocking my traffic. They were mundane. Now I am facing a doozy.

My setup

Ignite-UX Server rx2660 running HP-UX 11.31

Client to be recovered:

-Running HP-UX 11.11

-Running as a VPAR on one of the 2 cells of RP-8420 hardware

-On the same cell, there are 2 more HP-UX 11.23 servers running.

-If push comes to the shove I can boot this server I am trying to recover, to an image, contained on one of the disks but the OS will be less than ideal and can not be used for the long term. Plus, this recovery needs to succeed as a proof of concept as a bare metal restore process.

Current situation:

I can boot the VPAR using 

vparboot -p <vparname> -I <IP_address_of_ignite_server>,/opt/ignite/boot/Rel_B.11.11/WINSTALL

I get the the ignite-UX gui on the console.

Select "Install HP-UX" option 

Hangs for a few minutes and cmes back saying "tftp> Transfer timed out."

while it is soinning and waiting for tftp to respond, I am on the ignite server and ran these commands:

# tcpdump -l port 69
08:35:42.862846 IP <temporary_IP_address_here>.49152 > ignite.domain.net.tftp: 35 RRQ "/var/opt/ignite/data/INDEX" octet

and this line keeps repeating every second or two until tftp times out

# tail -f /var/adm/syslog/syslog.log                     # on a separate window

Mar 21 09:35:45 ignite tftpd[21361]: send_file: recv: Can't assign requested address

again, this repeats many many times.

lan0 of the client is on the same network segment of the IP address of the ignite server, although in physucal world they are seprated by some switches and routers. linkloop between the two interfaces is giving successful results.

The file /var/opt/ignite/data/INDEX, is there and it heas read permissions open for everyone

I am stumped here since late last week. I'm all ears if anyone can suggest a solution or at least something I can attempt.

As usual, thanks in advance.

[Torsten.]

A handy document that can help a lot:

http://h20565.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c02018871&lang=en-us&cc=us

(useful not only for golden images)

[Mel Burslan]

I was aware of this document and glanced through it recently. My problem is between steps 4 and 5 on page 10 of this dcoument. I can specify the network informatin and click on OK to proceed and I am looking at this 

* Bringing up Network (lan0)
add net default: gateway 129.228.244.1
* Reading configuration information from server...

for about 3 minutes, which is followed by the dreaded 

tftp> Transfer timed out.

message

[Torsten.]

TFTP configured in inetd.conf?

tftp dgram udp wait root /usr/lbin/tftpd\
tftpd /opt/ignite /var/opt/ignite

if you use

# tftp dgram udp wait root /usr/lbin/tftpd tftpd \
-l /opt/ignite /var/opt/ignite
# bootps dgram udp wait root /usr/lbin/bootpd bootpd -d 9

they will log into syslog.

A possible test:

# bootpquery 0011855F549E
Received BOOTREPLY from hpignite.xyzco.com (10.1.1.11)
Hardware Address: 00:11:85:5f:54:9e
Hardware Type: Ethernet
IP Address: 10.1.1.110
Boot file: /opt/ignite/boot/nbp.efi
RFC 1048 Vendor Information:
Subnet Mask: 255.255.255.0
Gateway: 10.1.1.1
Bootfile Size: 24576 512 byte blocks

Domain Name Server: 10.1.1.1
Host Name: hpuxsys1
Domain Name: xyzco.com

The ignite admin guide has a chapter about replacing TFTP with NFS, worth to try.

[Mel Burslan]

Here are my inetd.conf contents:

tftp dgram udp wait root /usr/lbin/tftpd tftpd -s -r blksize\
/opt/ignite\
/var/opt/ignite
bootps dgram udp wait root /usr/lbin/bootpd bootpd -d3

also I don't have any issues booting from the ignite server over the network. Problem is just the tftp part. NFS is the Pandora's box, which I really do not want to open. I am hoping I can get the tftp working for what I need

[Torsten.]

What gives

instl_adm -T

Not sure what "tftpd -s -r blksize" does, the example is without -s -r.

Did you check bootptab?

Looks like the client cannot get the IP?

[Mel Burslan]

# >instl_adm -T
* Checking file: /opt/ignite/data/Rel_B.11.11/config
* Checking file: /opt/ignite/data/Rel_B.11.11/hw_patches_cfg
* Checking file: /var/opt/ignite/data/Rel_B.11.11/apps
* Checking file: /var/opt/ignite/config.local
* Checking file: /opt/ignite/data/Rel_B.11.23/config
* Checking file: /opt/ignite/data/Rel_B.11.23/hw_patches_cfg
* Checking file: /var/opt/ignite/depots/HPUX_VPARS_11.23/vpar.cfg
* Checking file: /var/opt/ignite/data/Rel_B.11.23/core.cfg
* Checking file: /var/opt/ignite/data/Rel_B.11.23/vpar.cfg
* Checking file: /var/opt/ignite/data/Rel_B.11.23/QPK_11.23.cfg
* Checking file: /opt/ignite/data/Rel_B.11.31/config
* Checking file: /opt/ignite/data/Rel_B.11.31/hw_patches_cfg
* Checking file: /var/opt/ignite/data/Rel_B.11.31/core_cfg

-r blksize came from anothe ITRC post having a similar issue, but not the same. Before it was present, situation was exactly the same. It was a hail-mary attempt on my end, sometime last week.

bootptab is nothing more than the boilerplate to my eye. Someone in the past tried a couple of single server installs and left the artifacts behind. 

IP address I am providing manually on the console of the client. It doesn't have to use DHCP. I know that IP Address is not being used by anyone else, because I shut down the interface with the same IP address myself.

[Torsten.]

It is at least 6 years or more ago since I installed vPars ... Maybe 10 years ago I installed on RISC servers ...

However, did you restart inetd after making changes?

inetd -c

I assume lan0 (lan0 of the vpar) is working, since you get the first GUI. Next step would be to load the mini system and the ignite GUI.

what gives

# instl_adm -d

expected results?

[Mel Burslan]

instl_adm -d shows the right network information and the hostname etc. 

And yes, lan0 is working since I can get the WINSTALL image via bootp over it. 

Yes I have restarted inetd after the modifications.

The only thing I didn't do is to reboot the ignite server which is up for 600+ days and we had been thru a few power outages, and other catastrophic events, which tooks parts of the network down for a brief period of time. I am willing to give it a kick, just to see if it helps anything, as I am pretty much out of ammunition here.

[Torsten.]

sometimes it is tricky.
we hit a similar problem some time ago. another client was getting the dhcp address - it was a blade oa - from our ignite server, so we had a duplicated ip address and a similar result. we also assigned the ip address manually during restore. we found this out because there was a ping responde while the server was off. i would increase the loglevel and have a look into syslog while starting the client.