Ignite LAN boot

[Ruan_3]

Hi guys,

I am trying to test an Ignite LAN boot. I have installed Ignite C.6.10.97 on an N-class server (SAPTST00). I have successfully made a network ignite of a K370 (SAPDEV00), which I now want to recover using an Ignite LAN boot.

The following lines exist in inetd.conf on SAPTST00 (the ignite server)

bootps dgram udp wait root /usr/lbin/bootpd bootpd -d 3
instl_boots dgram udp wait root /opt/ignite/lbin/instl_bootd instl_bootd -d 3

Below are the entries in the bootptab on the ignite server:

sapdev00:\
ht=ethernet:\
ha=0060B083BAE7:\
ip=11.2.16.240:\
hn

instl_boottab contains the following line:

11.2.16.240:0x0060B083BAE7

When I attempt to do a bootpquery (bootpquery 0060B083BAE7 -s saptst00) from SAPDEV00, it reports that it did not receive any replies, even though I can see SAPTST00 sending the replies in the syslog. An ethereal trace on SAPDEV00 also confirms that the replies are reching it, but why it states that it has not recieved any replies I do not know.

When I try and do a bo lan.11.2.16.180 install, the LAN boot also does not complete.

Does anybody please have any pointers for me?

Thanks & regards,
Ruan

[Steven E. Protter]

Shalom Ruan,

On this class of server Ignite will only boot from the built in lan card. A faster add in card will not boot properly.

You can configure the system to transfer the image on the faster add in card but not the boot.

I've run into this back to Ignite 3.x. I keep hoping it will change but have not seen any notes that say so.

SEP

[DCE]

Ignite is very fussy about what LAN cards it will use for installation.

Is the LAN card 0x0060B083BAE7 a bootable device on SAPTST00? Try rebooting the server, and then interupt the boot process when prompted. At this point do a sea command for bootable devices and see if your lan card shows on the list.

[Ruan_3]

Guys,

0060B083BAE7 is the internal NIC, which is the only NIC that can be used for LAN boot. My concern is that the ignite client is not seeing the the bootp replie from the ignite server.

Any thoughts on that?

Thanks

[Ruan_3]

Here is the example of the failing bootpquery on the ignite client:

sapdev00>sudo bootpquery 0060B083BAE7 ether -s saptst00
bootpquery: Bootp servers not responding!

In the syslog I see the following entries on the syslog server (start reading from the bottom):

May 16 08:48:30 bootpd[28581]: sending reply on 11.2.16.240
May 16 08:48:30 bootpd[28581]: sending RFC1048-style reply
May 16 08:48:30 bootpd[28581]: found 11.2.16.240 sapdev00
May 16 08:48:30 bootpd[28581]: rif collection for token ring turned on
May 16 08:48:30 bootpd[28581]: read 0 entries from "/etc/dhcpdeny"
May 16 08:48:30 bootpd[28581]: reading "/etc/dhcpdeny"
May 16 08:48:30 bootpd[28581]: read 2 entries from "/etc/bootptab"
May 16 08:48:30 bootpd[28581]: reading "/etc/bootptab"
May 16 08:48:30 bootpd[28581]: group count: 0
May 16 08:48:30 bootpd[28581]: reading "/etc/dhcptab"
May 16 08:48:30 bootpd[28581]:

As I mentioned earlier when doing an tethereal trace I can see the replies being sent and received on the ignite client:

sapdev00>sudo tethereal -i "lan0" -f "ip host 11.2.16.180 or ip host 11.2.20.180"
Capturing on lan0
0.000000 11.2.16.240 -> 11.2.16.180 BOOTP Boot Request from 00:60:b0:83:ba:e7
0.004464 11.2.16.180 -> 11.2.16.240 BOOTP Boot Reply
1.007010 11.2.16.240 -> 11.2.16.180 BOOTP Boot Request from 00:60:b0:83:ba:e7
1.008378 11.2.16.180 -> 11.2.16.240 BOOTP Boot Reply
4.017188 11.2.16.240 -> 11.2.16.180 BOOTP Boot Request from 00:60:b0:83:ba:e7
4.018583 11.2.16.180 -> 11.2.16.240 BOOTP Boot Reply
10.027056 11.2.16.240 -> 11.2.16.180 BOOTP Boot Request from 00:60:b0:83:ba:e7
10.028965 11.2.16.180 -> 11.2.16.240 BOOTP Boot Reply

Any ideas?

Thanks & regards,
Ruan

[Bob Ingersoll]

bo lan.11.2.16.180 with the "install" option doesn't use the bootps service on ports 67/68 or bootptab. It uses the instl_boots service on ports 1067/1068 and /etc/opt/ignite/instl_boottab. Configure instl_boottab using the Ignite gui.

In the gui select Options -> Server Configuration -> Server Options -> Configure IP Booting Addressesâ ¦

Add a range of IP addresses to be used by clients when installing or recovering images. These addresses will only be used temporarily during installation of images; a permanent client IP addresses will be defined during configuration of the client.

If you have a /var/adm/inetd.sec on the server make certain it contains the following entries:

tftp allow
bootps allow 0.0.0.0
instl_boots allow 0.0.0.0

Replace with the ip address of the Ignite server.

Hope this helps.

[Ruan_3]

Thanks Bob,

I know that instl_bootd is used and not bootp but I was trying to see if there was a way to see if I could test if the ignite client would at least see the bootp/instl_bootd replies from the ignite server (without doing bo lan install)

Any way I can test instl_bootd? I have made the entries in instl_boottab (as you can see earlier in this thread). Do I have to make any changes to hosts.allow?

Thanks,
Ruan

[Ruan_3]

Bob,

I have made the changes to /var/adm/inetd.sec, but still the bootp reply is not recognised by the ignite client. Am I flogging a dead horse?

Cheers,
Ruan

[Uday_S_Ankolekar]

Try with ipaddress followed by three colons (:::) in instl_boottab file on ignite server
ex:
11.2.16.1:::

-USA.

[Bob Ingersoll]

If you have confirmed that the server is sending the bootp/instl_bootp response then the only thing I can think of that might prevent the client from seeing it (assuming the server and client are on the same network) is a duplex mismatch. To eliminate this possibility ensure that the switch port that SAPDEV00 is connected to is set to autonegotiate.

[Ruan_3]

Hi Bob,

The ignite client and server are on the same subnet. As you can see for the ethereal trace on the client, the traffic is arriving at the client, but for some reason it does not recognize it as a valid reply.

Before I performed the initial lan boot test, the bootpquery worked. I don't know what has happened which is now causing it to fail.

Thanks,
Ruan

[Bob Ingersoll]

Hi Ruan,

I suggest that you chose one protocol, either bootp or instl_bootd (preferably the latter) to focus on.

The bootp response is getting back to the client but have you verified the instl_bootd response is getting back?

You have debugging on (-d 3) for instl_bootd - do you see any debug entries in syslog? Do you have inetd logging (inetd -l) on? Is inetd calling instl_bootd?

If you don't see instl_bootd getting run then move hosts.deny out of the way temporarily.

Another way to see if intl_bootd is processing the client request is to look at instl_boottab. Make certain that only the ip address is specified; when instl_bootd assigns the address to a client he will update the ip address in instl_boottab with the client MAC and a time stamp.

Once an address from instl_boottab is assigned to a client instl_bootd wont reuse that address for 5 minutes. This could be interfering with your testing. You may want to specify multiple addresses for this reason.

[Tor-Arne Nostdal]

There could also be other servers that answers you're bootp reply... check syslog's on other servers on same LAN.

You might also need a boothelper as I've seen that some servers simply don't handle bo lan.x.x.x.x install if it's on another subnet.

If you find a failed bootp request on another server, you might put this as the boothelper to relay the bootp request to your Ignite server.

See Ignite-UX documentation and search for "boot helper"

/Tor-Arne

[IT_2007]

Did you ever get passed this phase? I am also having same problem, escalated to HP and still waiting to hear from them.

I am trying to boot a vpar on Itanium dome, both vpars: client and Ignite lies on the same Npar but Ignite is not responding to client queries.

thanks.

[Ruan_3]

Hi Guys,

I have managed to get the Ignite client to boot off the ignite server!

There is a host-based firewall (IPFilter) installed on the ignite client and server. Broadcast traffic on 11.2.16.255 and 11.2.20.255 was being blocked without the log option, so I never saw these blocks in the syslog (when doing the bootpquery tests).

Disabled IPF by inserting a pass all rule at the top of the file and was then able to do a successful lan boot. I will now create a rule to allow bootp/instl_bootd traffic through the firewall.

I have not completed the ignite test yet. I just went as far as the Ignite TUI. I am doing the ignite lan boot to test a backout procedure, not to recover the client per se.

How can I split the mirrored root disk, restore the ignite image to one of the non-mirrored root disk and then revert to the previous OS?

In the past I had HP come and yank the root disks and insert a loan drive for the recovery. Anyone have any other ideas?

Also, during a test on a different ignite server with an older version of ignite, the loading of the image took an immense amount of time. Up to 1 hour just to load 10%. This is not feasable when one's recovery window is very small.

I have found the following link indicating that you can use _hp_lanadmin_args="-X 100FD" to set the speed and duplexing settings. Does this indeed work? Below is a copy of the instl_adm config on the server:

# instl_adm defaults:
# NOTE: Manual additions between the lines containing "instl_adm defaults"
# and "end instl_adm defaults" will not be preserved.
server="11.2.16.180"
netmask[]="255.255.255.0"
route_gateway[0]="11.2.20.254"
route_destination[0]="default"
# end instl_adm defaults.
( lan[].driver == "btlan" )
{
_hp_lanadmin_args="-X 100FD"
}

The route gateway listed in a different VLAN. Does this pose a problem? The default gateway is also 11.2.20.240.

Thanks & regards,
Ruan

[Ruan_3]

Hi Guys,

This thread is now moving out of the ignite forums' focus area.

Can I lvsplit vg00 and then do an lvmerge after doing a successful recovery? If I want to install Support Plus patches can I follow the same procedure to recover to the previous system state or to the patched state depending on the source and destination lvols for lvsync?

Thanks & regards,
Ruan

[IT_2007]

You can't install if it is different VLAN. Ignite won't support on it. Ignite and client should be on same VLAN.

Once you meet the above requirement then do this way to test it out on one of the mirror disks.

On client:

1. Note down hardware paths for both disks for vg00: mirror and original disk.
2. Break the mirror.

On Ignite server:

1. Boot client.
2. Once you get gui to install then select mirror disk and remove other disks as part of vg00 so that you would affect only mirror disk.

For some reason, if the test fails, you always have original copy of client to boot off.

Hope this helps.