Thanks to Louis-Philippe Reid who pointed me in the direction of running in.dhcpd with the -d and -v flags. This produced a stack of debugging output, and I could see it wasn't listening on the correct interface, so I manually added this with the -i flag. This however didn't quite work - I,ve listed my steps below both so I remember exactly what I did, and also in case anyone else has this problem. Original post attached below. My jumpstart server has a bunch of different subnets on it, and one of these which I've been using for SPARC jumpstarts is on ipge0:2, EG not a "real" NIC. After running /usr/lib/inet/in.dhcpd -dv -i ipge0:2 I could see the dhcp server binding, and requests coming in, but it never offered a response : Dhcpagent in debug mode on the client, here's what it says : /sbin/dhcpagent: debug: dhcp_selecting: DF_REQUEST_HOSTNAME /sbin/dhcpagent: debug: select_best: no valid OFFER/BOOTP reply /sbin/dhcpagent: debug: select_best: no valid OFFER/BOOTP reply /sbin/dhcpagent: debug: select_best: no valid OFFER/BOOTP reply : And here's the server : 45cc497d: Datagram received on network device: ipge0:2(limited broadcast) 45cc497d: Client: 0100144F785C90 has DYNAMIC 192.168.3.4 owned by server: 192.168.3.1. 45cc4981: Datagram received on network device: ipge0:2(limited broadcast) 45cc4981: Client: 0100144F785C90 has DYNAMIC 192.168.3.4 owned by server: 192.168.3.1. And there it sat. A snoop also reveals that the jumpstart/DHCP server was seeing the request, but it never responded. I then hit on the idea that although the jumpstart server has a virtual NIC of 192.168.3.1, maybe it didn't "know" that was itself - the debug output showed it received a valid response, but it just sat there. So, I then bound in.dhcpd to the real NIC as well as the virtual NIC : /usr/lib/inet/in.dhcpd -dv -i ipge0:2,ipge0 And then re-configured the pntadm command, telling it that that lease was owned by the "real" NICs IP address, 10.63.252.21. It looks a bit odd in the pntadm output, but here it is : $ pntadm -P 192.168.3.1 Client ID Flags Client IP Server IP Lease Expiration Macro Comment 0100144F785C90 01 192.168.3.4 10.63.252.21 Forever 0100144F785C90 Sure enough, debug shows it working : 45cc4e9f: Datagram received on network device: ipge0(limited broadcast) 45cc4e9f: Datagram received on network device: ipge0:2(limited broadcast) 45cc4e9f: ipge0(limited broadcast): There is no 10.63.252.0 dhcp-network table for DHCP client's network. 45cc4ea0: Unicasting datagram to 192.168.3.4 address. 45cc4ea0: Adding ARP entry: 192.168.3.4 == 00144F785C90 45cc4ea0: Added offer: 192.168.3.4 Woot! So the moral of the story is that in.dhcpd doesn't seem to know about any other IP addresses other than it's primary one. You don't need to jumpstart and provide DHCP leases on that subnet, you just need to use that address when configuring it through pntadm. Hope this helps :) -Mark -----Original Message----- From: sunmanagers-bounces@sunmanagers.org [mailto:sunmanagers-bounces@sunmanagers.org] On Behalf Of Round, Mark - CALM Technical <Mark_Round@ipcmedia.com> Sent: 08 February 2007 19:47 To: sunmanagers@sunmanagers.org Subject: PXE boot from X4100 - Solaris 10 11/06 Hi all, I am having real problems getting Solaris 10 11/06 x64 booting from PXE on a X4100. Any advice would be much appreciated, as I suspect I'm just doing something really stupid here and messing up some syntax... I will of course summarise and post here with any updates. Jumpstart Server : T2000, Solaris 10, 01/06 Jumpstart Client : X4100, Solaris 10, 11/06 (version of Solaris added to jumpstart server) Systems are connected together via a 1GB switch. If I boot as normal from the X4100 and configure a NIC, I can verify I can ping and "see" the T2000. The only thing complicating issues as far as I can see is that the T2000 jumpstart server is on several different networks, but the network set aside for jumpstarting clients (192.168.3.0) has been succesfully used to jumpstart SPARC systems before so it appears this is purely a DHCP/PXE issue. Here's the set of steps I follow : # Start off by initialising DHCP (previously unconfigured with -U) $ dhcpconfig -D -r SUNWbinfiles -p /var/dhcp # Add the clients host name and MAC to /etc/hosts and /etc/ethers # Add the install client, MAC address obtained by watching POST. # 192.168.3.1 is the T2000s' IP address $ ./add_install_client -d -e 00:14:4F:78:5C:90 -s 192.168.3.1:/export/software/jumpstart_x86 i86pc If not already configured, enable PXE boot by creating a macro named 0100144F785C90 with: Boot server IP (BootSrvA) : 10.63.252.21 Boot file (BootFile) : 0100144F785C90 # I ignore what it's telling me about the BootSrvA address, and use the 192.168.3.x range instead # Create the table $ pntadm -C 192.168.3.0 # Now I add the DHCP lease $ pntadm -A 192.168.3.4 -f 01 -e 12/31/2010 -i 0100144F785C90 -m 0100144F785C90 -s 192.168.3.1 192.168.3.0 # Now add the macro $ dhtadm -A -m 0100144F785C90 -d ":BootSrvA=192.168.3.1:BootFile=0100144F785C90:" # Restart the DHCP server, and then try to boot from the X4100's PXE boot # PXE boot on the X4100 spits this out : CLIENT MAC ADDR: 00 14 4F 78 5C 90 GUID: 00000000 0000 0000 0000 00144F6B8E3F PXE-E51: No DHCP or proxyDHCP offers were received. # This is what snoop shows me on the T2000 $ snoop ether 0:14:4f:78:5c:90 Using device /dev/ipge (promiscuous mode) OLD-BROADCAST -> BROADCAST DHCP/BOOTP DHCPDISCOVER OLD-BROADCAST -> BROADCAST DHCP/BOOTP DHCPDISCOVER OLD-BROADCAST -> BROADCAST DHCP/BOOTP DHCPDISCOVER OLD-BROADCAST -> BROADCAST DHCP/BOOTP DHCPDISCOVER And I can also verify that UDP port 67 is listening on all interfaces : $ netstat -na -P udp | grep 67 *.67 Idle What am I doing wrong ? Why is my DHCP server not responding to it's requests ? Thanks in advance, -Mark ----------------------------------------------------------------------- This E-mail is from IPC Media Ltd, a company registered in England and Wales, whose registered office is at Kings Reach Tower, Stamford Street, London SE1 9LS, registered number 53626, VAT number 646150645. The contents and any attachments to it include information that is private and confidential and should only be read by those persons to whom they are addressed. IPC Media accepts no liability for any loss or damage suffered by any person arising from the use of this e-mail. Neither IPC Media nor the sender accepts any responsibility for viruses and it is your responsibility to check the email and attachments (if any). No contracts may be concluded on behalf of IPC Media by means of e-mail communications. If you have received this e-mail in error, please destroy and delete the message from your computer. For unbeatable savings on magazine subscriptions and great gift ideas visit www.giftmags.co.uk * IPC Media's head office moves to new headquarters from 2nd April, 2007. The new address will be The Blue Fin Building, 110 Southwark Street, London, SE1 0SU. The new telephone and fax numbers will be available during February. _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagers ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Fri Feb 9 06:04:35 2007
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:44:04 EST