update: boot-image from network-boot server does not apply netmask on V440, doesn't contact gateway to NFS-mount from

From: rob.de.langhe@belgacom.be
Date: Wed Apr 06 2005 - 09:31:37 EDT


Update since I got a few replies that relate to the mini-Solaris (which
has then already been loaded via NFS from the Jumpstart server) that
starts up, but then sets an incorrect netmask and thus fails to proceed
getting the rest of the Jumpstart information.

My problem is one step before that : the client simlpy tries to find
that installation server on the local subnet, hence its ARP requests on
the local subnet to find the Ethernet address of him.
The reason seems to be that this boot-image is not using any specific
netmask information of the boot-server, so that it would know that the
remote Jumpstart/NFS-server must be reached via the gateway(router).

By the way: the local boot-server correctly has its /etc/netmasks
populated with
45.217.2.0 255.255.254.0

The Jumpstart-server contains the "sysidcfg" file, but this file is
accessed via NFS, and -again- no connectivity is possible by the
boot-image accross subnet boundaries to do such NFS communications.

Hopeless Rob...

-----Original Message-----
From: sunmanagers-bounces@sunmanagers.org
[mailto:sunmanagers-bounces@sunmanagers.org] On Behalf Of
rob.de.langhe@belgacom.be
Sent: 06 April 2005 13:13
To: sunmanagers@sunmanagers.org
Subject: URGENT: boot-image from network-boot server does not apply
netmask on V440, doesn't contact gateway to NFS-mount from

Hi,

we have an urgent problem that I can't get resolved:

a V440 on a new network segment needs to be Jumpstarted with Solaris-9,
it gets (using TFTP) correctly the very initial boot image from a
boot-server (RARP, BOOTP) on the same segment, does some BOOTP requests
to that same boot-server which returns properly the gateway's IP-address
and the NFS-server's IP-address plus directory path on it where the
initial Solaris must be retrieved from.

Then it hangs, sending out ARP requests to 255.255.255.255 to find out
the MAC-address for the NFS-server's IP-address :

This machine's subnet is 45.217.2.0/23, so the range is from 45.217.2.0
till 45.217.3.255 The boot-server in this subnet is 45.217.2.49 This
server gets IP-address 45.217.2.110 The gateway for this subnet is
45.217.2.33 The NFS-server has IP-address 45.216.114.42 {1} ok boot
/pci@1c,600000/network@2:speed=100,duplex=full - install Boot device:
/pci@1c,600000/network@2:speed=100,duplex=full File and
args: - install

/pci@1c,600000/network@2: 100 Mbps full duplex link up Timeout waiting
for ARP/RARP packet Timeout waiting for ARP/RARP packet 4000
/pci@1c,600000/network@2: 100 Mbps full duplex link up

Requesting Ethernet address for: 45.216.114.42 panic - boot: Could not
mount filesystem.
Program terminated
{1} ok boot /pci@1c,600000/network@2:speed=100,duplex=full - install

A network sniffer has captured the packets that are sent out during
"Requesting Ethernet address for: 45.216.114.42", and they are not
directed to the gateway, but generic ARP requests.

This indicates to me that the boot-image is not using the netmask (which
it receives from the local boot server, i.e. 255.255.254.0) to determine
if that NFS-server is on a remote subnet or if it belongs to this same
subnet. It is maybe not using any netmask, and defaulting to the
RFC-category for the 45.*.*.* ranges, being a class-A subnet (mask
255.0.0.0)

There is a separate discussion that happened (including by myself a few
weeks ago) about the initial Solaris O/S which incorrectly gets the
netmask of the NFS-server.
This server is not yet in that stage. Here it is the boot-image itself
that fails to use a proper netmask.

On another subnet, we have exactly the same boot-image sitting on a
boot-server, and there a 280R uses correctly the local gateway to
contact this same NFS-server accross it subnet boundaries.

Is there something different in behaviour of 280R compared to V440 ?

The bootimage is "inetboot.SUN4U.Solaris_9-1", 152376 bytes, "sum" on
this file returns 3662 and 298.

Searched the web for 2 days, found nothing about this particular
problem...

Rob

**** DISCLAIMER ****
http://www.belgacom.be/maildisclaimer
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers

**** DISCLAIMER ****
http://www.belgacom.be/maildisclaimer
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers



This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:30:29 EDT