Problem Recovering a Ignite Client

[G V R Shankar]

Hello All,

I have a Ignite Server A and Ignite Client B. Both are Itanium Servers. I have updated /etc/bootptab file on Server A with Client information. Using make_net_recovery I took the ignite backup of client B on to the server A.
On Server A. I performed the following

1. In /etc/inetd.conf to make certain bootps and tftp entries have been uncommented.
2. Inetd -c restarted properly. No errors in syslog.log

3. dhcptools -v comes out without any problem.
4 .Checked the tftp line in /etc/inetd.conf to make certain /opt/ignite an /var/opt/ignite directories are listed
5. Nothing has been denied in /var/adm/inetd.sec

Now when I reboot the client B, and at EFI I select Lan to boot. It searches for DHCP server. There is a DHCP server configured and it has PXE images and it responds to this Client B and this defeats my purpose of recovering the client B from Iginte Server A.

How can I bypass this DHCP server and configure my client B to connect to Ignite Server A.

Note: I don't have control over the DHCP server. Server A and Client B are in the same subnet.

Cheers,
Ravi

[Ivan Krastev]

Hi Ravi,

use dbprifile in EFI shell on client - http://docs.hp.com/en/5992-1959/ch06s06.html


regards,
ivan

[Doug O'Leary]

Hey;

I've always considered booting from the console as the dead last resort.

I usually use the bootsys command from the ignite server. My more CLI challenged colleagues use the boot command from the ignite GUI.

The caveat to this is I can't guarantee that'll circumvent the DHCP server as we don't have one on the affected subnets; however, based on the information that's in the INSTALLFS kernel, (instl_adm -d to see), it should work.

The added advantage to running the bootsys command is you don't have to have a boothelper on each subnet to ignite clients on separate netwwork segments.

HTH;

Doug

[Srikanth Arunachalam]

Hi ,

The complete steps for make_net_recovery is given here. Tapir is the client and Koala is the server.

You need to make entry in /etc/opt/ignite/instl_boottab to bypass DHCP.

1) Create mount point :-
lvcreate -n image -L 5120m /dev/vg_appl
newfs -F vxfs /dev/vg_appl/rimage
mkdir -p /var/opt/ignite/recovery
mount /dev/vg_appl/image /var/opt/ignite/recovery

(2) Make entry on respective system /etc/exports as follows :-

/var/opt/ignite/recovery/archives/koala -anon=2
/var/opt/ignite/clients -anon=2

(3) Run exports -av from both the system.

(4) Both on Koala and Tapir, we need to create directory called /var/opt/ignite/recovery/archives/koala
mkdir -p /var/opt/ignite/recovery/archives/koala
chown bin:bin /var/opt/ignite/recovery/archives/koala

(5) Set the umask value to 022

(6) cd /
make_net_recovery -s tapir -x inc_entire=vg00 from Koala system.

(7) Make changes to /etc/inetd.conf such that you remove the comment as given below :-
#bootps dgram udp wait root /usr/lbin/bootpd bootpd

(8) make entry in /etc/opt/ignite/instl_boottab on tapir as follows :-

132.146.22.53:0x0011855F46F6::reserve # koala

(9)restart ientd service as -> "inetd -c"

(10) Step 6 will store image of koala on tapir system under directory of
"/var/opt/ignite/recovery/archives/koala"

(11) reboot koala and invoke the image from tapir system

(12) Do the vice versa on other system and check if the image is appropriate.

Thanks,
Srikanth

[G V R Shankar]

Ivan,

I would love to have DBProfile, but it is not supported on my servers.

Doug,

Completely accept with you, but we cannot boot a crashed system using bootsys. For bootsys to work the system should be available in network.

Srikanth,

I have already taken the ignite backup, but due to the intervention of DHCP server, I am unable to recover the system from Ignite server.

If you are adding the client info to /etc/bootptab, then we don't have to update /etc/opt/ignite/instl_boottab.

I just removed the systems from exsisting n/w and brought them in to a single n/w using a HUB and I am able to recover the client from Ignite Server.

How can I recover the system from Ignite UX bypassing the DHCP that has PXE images.

Cheers,
Ravi

[Tim Nelson · Accepted solution]

In order to use direct lan boot, aka dbprofile, you will need to update the firmware on the IA server(s).

[G V R Shankar]

Tim,

I saw this thread of yours. It is really great. Even my server is rx2620

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1109604

I have updated the firmware of the system
System Firmware Revision : 04.27

Download it from the following URL
http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareIndex.jsp?lang=en&cc=us&prodNameId=441910&prodTypeId=15351&prodSeriesId=447331&swLang=13&taskId=135&swEnvOID=54

In the EFI shell I created a testprofile

dbprofile -dn testprofile -sip 16.138.184.162 -cip 16.138.184.164 -gip 16.138.184.129 -m 255.255.255.192 -b "/opt/ignite/boot/nbp.efi"

Now I am trying to boot from lan

lanboot select -dn test1

I get the following message

PXE-E18: Timeout. Server did not respond.
Exit status code: Invalid Parameter

Both Ignite and Cleint are in the same subnet.

I checked in the Ignite UX server, the tftp services are running.

Cheers,
Ravi

[G V R Shankar]

Can some please help me with this

Cheers,

Ravi

[Ivan Krastev]

Do you have entry in /etc/bootptab for that server ?

Test also with dbprofile with dhcp.


regards,
ivan

[G V R Shankar]

Issue resolved by renaming /var/adm/inetd.sec on ignite UX server.

It contains tftp allow. As per the doc I have in our private archive it says that it should not contain allow or deny for tftp

It would be good if the following points are also taken care.

1/ Please verify that /var/adm/inetd.sec does not contain a tftp entry
of either deny or allow. When you allow one user, you deny all
other users. For troubleshooting purposes you could rename
/var/adm/inetd.sec to /var/adm/inetd.sec.old. inetd.sec is
not needed unless you need tightened security beyond login
verification.

2/ Please verify that a user 'tftp' exists in /etc/passwd. Something like;

tftp:*:510:20:trivial ftp: /home/tftpdir:/usr/bin/false

Note: If UID 510 is not available, use a UID that
is not currently in use.

Note: GID 20 is usually group 'users'. Verify that group
'users' does exist, and match its group ID in this field
in /etc/group.Note: If you have no /etc/passwd entry for the user tftp,
tftpd
has root access to any files or directories that are specified
in the tftp entry in /etc/inetd.conf. HP recommends using a
tftp user in /etc/passwd.


3/ Please verify that inetd is running.

[G V R Shankar]

please read the entire thread

Cheers,

Ravi