Debugging problems with Solaris in.dhcpd vendor options

While attempting to jumpstart my Sun Ultra 10 this week, I encountered the following error:

ok boot net:dhcp – install
Boot device: /pci@1f,0/pci@1,1/network@1,1:dhcp File and args: – install
38800 panic – boot: Could not mount filesystem.
Program terminated

The machine was getting a kernel, but for some reason was unable to mount the Solaris miniroot. Since DHCP was used to jumpstart the client, the location of the miniroot should have been provided as a DHCP option. To begin debugging the problem, I fired up snoop on the jumpstart server to see which options (options are used to pass custom items such as the boot server to the client) were sent to the client:

$ snoop -vv -d hme0 ether 0:3:ba:9:62:f8 | grep DHCP

DHCP: Client Class Identifier = "SUNW.Ultra-5_10"
DHCP: Requested Options:
DHCP:    1 (Subnet Mask)
DHCP:    3 (Router)
DHCP:   12 (Client Hostname)
DHCP:   43 (Vendor Specific Options)
DHCP: Maximum DHCP Message Size = 1472 bytes

[ ..... ]

DHCP: Message type = DHCPOFFER
DHCP: DHCP Server Identifier =
DHCP: IP Address Lease Time = -1 seconds
DHCP: Subnet Mask =
DHCP: Boot File Name = SUNW.sun4u

Well this is odd, the server is returning just the basic options (i.e. boot file name, IP address, netmask, etc.). Since the jumpstart-specific options weren’t returned, I ran the dhtadm utility with the “-P” (print the contents of DHCP tables) option to print the symbols and macros in the DHCP tables:

$ dhtadm -P

Name                    Type            Value
Solaris11SPARC          Macro           :SinstNM="tigger":SinstIP4="/media/solaris/11_sparc/current":SrootNM="tigger":SrootIP4="/media/solaris/11_sparc/current/Solaris_11/Tools/Boot":BootFile="SUNW.sun4u":SsysidCF="":SjumpsCF="":BootSrvA=
Solaris10x86            Macro           :SinstNM="tigger":SinstIP4="/media/solaris/10_x86/current":SrootNM="tigger":SrootIP4="/media/solaris/10_x86/current/Solaris_10/Tools/Boot":BootFile="SUNW.sun4u":SsysidCF="":SjumpsCF="":BootSrvA=
Solaris10SPARC          Macro           :SinstNM="tigger":SinstIP4="/media/solaris/10_sparc/current":SrootNM="tigger":SrootIP4="/media/solaris/10_sparc/current/Solaris_10/Tools/Boot":BootFile="SUNW.sun4u":SsysidCF="":SjumpsCF="":BootSrvA=
FedoraCore5             Macro           :BootFile="fedora5/pxelinux.0":BootSrvA=
PXEClient:Arch:00000:UNDI:002001        Macro           :BootSrvA=
tigger                  Macro           :Include=Locale:Timeserv="":DNSserv=
Locale                  Macro           :UTCoffst=-18000:
Sterm                   Symbol          Vendor=SUNW.Ultra-10 SUNW.i86pc,15,ASCII,1,0
SjumpsCF                Symbol          Vendor=SUNW.Ultra-10 SUNW.i86pc,14,ASCII,1,0
SsysidCF                Symbol          Vendor=SUNW.Ultra-10 SUNW.i86pc,13,ASCII,1,0
SinstPTH                Symbol          Vendor=SUNW.Ultra-10 SUNW.i86pc,12,ASCII,1,0
SinstNM                 Symbol          Vendor=SUNW.Ultra-10 SUNW.i86pc,11,ASCII,1,0
SinstIP4                Symbol          Vendor=SUNW.Ultra-10 SUNW.i86pc,10,IP,1,1
SbootRS                 Symbol          Vendor=SUNW.Ultra-10 SUNW.i86pc,9,NUMBER,2,1
Stz                     Symbol          Vendor=SUNW.Ultra-10 SUNW.i86pc,8,ASCII,1,0   
SbootFIL                Symbol          Vendor=SUNW.Ultra-10 SUNW.i86pc,7,ASCII,1,0
SswapPTH                Symbol          Vendor=SUNW.Ultra-10 SUNW.i86pc,6,ASCII,1,0
SswapIP4                Symbol          Vendor=SUNW.Ultra-10 SUNW.i86pc,5,IP,1,0
SrootPTH                Symbol          Vendor=SUNW.Ultra-10 SUNW.i86pc,4,ASCII,1,0
SrootNM                 Symbol          Vendor=SUNW.Ultra-10 SUNW.i86pc,3,ASCII,1,0
SrootIP4                Symbol          Vendor=SUNW.Ultra-10 SUNW.i86pc,2,IP,1,1
SrootOpt                Symbol          Vendor=SUNW.Ultra-10 SUNW.i86pc,1,ASCII,1,0

At first glance, the DHCP vendor options looked fine, so I started to think through how a DHCP jumpstart installation works. After pondering this for a few minutes, it dawned on me that in.dhcpd uses the Client Class Identifier (e.g., SUNW.Ultra-30) to identify the client and return the options specific to that client. To see what my Ultra 10 was reporting itself as, I fired up snoop:

$ snoop -vv -d hme0 ether 0:3:ba:9:62:f8 | grep DHCP

[ ….. ]

DHCP: Client Class Identifier = “SUNW.Ultra-5_10”

Bingo! The client reported itself as a SUNW.Ultra-5_10, but I had specified SUNW.Ultra-10 when creating the symbols. To fix the issue, I updated the pertinent symbols, restarted in.dhcpd, and low and behold the jumpstart worked flawlessly! The moral of this story: there is none. :)

7 thoughts on “Debugging problems with Solaris in.dhcpd vendor options”

  1. Thanks for your helpful information regarding Solaris 10 Net install on Sparc based Systems. However where can I find DHCP vendor Parameter Codes ? Because, T1000′ take the parameter codes, it can’t handle the name of parameters from DHCP macro.

  2. Thanks a lot, I had the same problem with T5140, which SUN claims as SUNW.SPARC-Enterprise-T5140 but CCI is SUNW.T5140.
    You just made my day man. MANY THANKS !!!

  3. Thanks heaps for posting this! While I was well familiar with setting up non-DHCP jumpstarts, I’m now managing DHCP jumpstarts from a setup built by a contractor. So far, I’d only needed to jumpstart Ultra 45 workstations (without any problems), and was stumped why I couldn’t similarly jumpstart a SunBlade 2500 with Solaris 10 from the same jumpstart server. After all, Client Class Identifiers didn’t require specifying under non-DHCP jumpstart, and the need to do so under DHCP isn’t particularly obvious from a quick glance at the DHCP GUI’s tabbed pages.

    This help turned an otherwise mediocre day at work into a good day! :-)

  4. Thank you for this very useful blog entry. So i find out a problem with the identifier of the new T3-1. The command uname -i says sun4v, but with snoop i see the real name ORCL.SPARC-T3-1.

Leave a Reply

Your email address will not be published. Required fields are marked *