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: Message type = DHCPDISCOVER
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 = 192.168.1.3
DHCP: IP Address Lease Time = -1 seconds
DHCP: Subnet Mask = 255.255.255.0
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=192.168.1.3:SinstPTH="/media/solaris/11_sparc/current":SrootNM="tigger":SrootIP4=192.168.1.3:SrootPTH="/media/solaris/11_sparc/current/Solaris_11/Tools/Boot":BootFile="SUNW.sun4u":SsysidCF="192.168.1.3:/media/solaris/11_sparc/":SjumpsCF="192.168.1.3:/media/solaris/":BootSrvA=192.168.1.3:
Solaris10x86 Macro :SinstNM="tigger":SinstIP4=192.168.1.3:SinstPTH="/media/solaris/10_x86/current":SrootNM="tigger":SrootIP4=192.168.1.3:SrootPTH="/media/solaris/10_x86/current/Solaris_10/Tools/Boot":BootFile="SUNW.sun4u":SsysidCF="192.168.1.3:/media/solaris/10_x86/":SjumpsCF="192.168.1.3:/media/solaris/":BootSrvA=192.168.1.3:
Solaris10SPARC Macro :SinstNM="tigger":SinstIP4=192.168.1.3:SinstPTH="/media/solaris/10_sparc/current":SrootNM="tigger":SrootIP4=192.168.1.3:SrootPTH="/media/solaris/10_sparc/current/Solaris_10/Tools/Boot":BootFile="SUNW.sun4u":SsysidCF="192.168.1.3:/media/solaris/10_sparc/":SjumpsCF="192.168.1.3:/media/solaris/":BootSrvA=192.168.1.3:
FedoraCore5 Macro :BootFile="fedora5/pxelinux.0":BootSrvA=192.168.1.3:
PXEClient:Arch:00000:UNDI:002001 Macro :BootSrvA=192.168.1.3:
tigger Macro :Include=Locale:Timeserv=192.168.1.3:LeaseTim=86400:LeaseNeg:DNSdmain="foo.com":DNSserv=192.168.1.1:
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. :)