Ignite client hangs when booting INSTALL kernel

[Shaun Clark]

Configuration (Ignite clients and server):
C180 Visualize (with built in ethernet)
Interphase 5511 PCI FDDI
HP-UX 10.20
Ignite-UX A.2.4.307

- Ethernet and FDDI network are parallel networks. Ethernet is only
being used for Ignite.

The ignite server has been configured with the IP address corresponding
to the ethernet. We are not using DHCP so entries have been added
to /etc/bootptab mapping hardware addresses of ethernet cards to
permanent IP addresses. INSTALLFS has been set with correct
server IP, netmask and disable_dhcp=TRUE.

When we invoke 'bootsys -w -v host:IP' (where IP is the ethernet address),
we see the expected information on the server and the client starts rebooting
and tries to start the INSTALL kernel. After the checksum (or whatever those
numbers represent) appears, nothing else is output to the console.
Using tcpdump we see what appears to be a loopback test on the
ethernet card of the client but after this, no additional network traffic..

We have tried disabling the FDDI card (i.e. leaving it unconfigured) on the
client but this doesn't change the behaviour.

Only when we physically remove the FDDI card does the client correctly
boot the INSTALL kernel (after which things seem to proceed as expected
for Ignite). We need to Ignite 100 machines and DO NOT want to have to
physically remove the FDDI cards from each one and then replace them
after the Ignite. Is there anyone who knows why our client hangs when
the FDDI card is installed? Is there a workaround that doesn't involve
removing the FDDI cards?

[CHRIS_ANORUO]

Use "ifconfig lan0 down" on the client and try Ignite again

[Shaun Clark]

The suggestion to use 'ifconfig lan0 down' on client seems counter-intuitive...
Ignite uses ethernet and this command would disable ethernet on the client.
Assuming 'ifconfig ifi1 down' is what is meant, how is this different from
not configuring the FDDI card in the first place? And how does this
impact how the INSTALL kernel behaves at boot-up? (I'm assuming that
the INSTALL kernel is making it's own decisions about what interfaces
are available/configured without any knowledge of how the client was
previously configured).

[Thomas G. Tudrej]

hi,

try setting the following in /var/opt/ignite/config.local:

_hp_default_cur_lan_dev="lanx"

where "x" is the number for your ethernet interface.

[Patrick Wessel]

Shaun,

I don't know much about Workstations, but on a 9000/800 server I would try to cache any kind of chassis code to figure out what the system is doing when the install process hangs. Is there a way to get any 4 digit hex code from the box?
My idea is, that the install kernel isn't able to handle the FDDI interface. When the kernel tries to configure the IO subsystem, it meets the FDDI card, has no idea how to configure it? you know what I mean?
The chassis code when the kernel configures the IO subsystem is CEF2.

[Shaun Clark]

Since the INSTALL kernel isn't even reaching the point at which the config.local data comes into play, I can't see how the suggestion to add the entry to config.local will help.
I haven't found a way to determine what the kernel is doing when it hangs but it seems likely that it is trying to do something with the FDDI card but doesn't have the required functionality compiled in. How do we fix this?