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. :)
If you ever need to power off an Ultra 10 (this may apply to other models as well) from the OBP, you can issue the power-off command:
ok power-off
While debugging some Solaris patch problems this week, I came across an interesting piece of information. The /usr/sbin/patchadd command that is invoked to apply a patch is actually a binary wrapper for the shell script /usr/lib/patch/patchadd:
$ strings /usr/sbin/patchadd | grep "/usr/lib/patch/patchadd"
/usr/lib/patch/patchadd
/usr/lib/patch/patchadd
/usr/lib/patch/patchadd
If you haven’t looked though /usr/lib/patch/patchadd, I highly recommend doing so. It contains the complete set of patch return codes, and has some useful options for controlling the patch process (setting these will most likely void patch support). Nifty!
While perusing the bash documentation, I came across the PROMPT_COMMAND variable. If PROMPT_COMMAND is set, bash will execute the command assigned to the variable prior to displaying PS1:
$ export PROMPT_COMMAND="echo \"straight pimpin\""
straight pimpin
$ ``
As you can see from this example, this is super useful. ;)
A few years back I developed a script to mirror the primary boot device as part of the jumpstart process. I was amazed that jumpstart didn’t support automated mirroring, and was hopeful that Sun would eventually provide a solution to address this. Someone at Sun was obviously paying attention to the numerous RFEs that were filed, and as of Solaris 9 you can mirror your boot device by adding “mirror” and “metadb” statements to a client profile:
$ egrep '(filesys|metadb)' profile
filesys mirror:d0 c0t0d0s0 c0t1d0s0 free / logging
filesys mirror:d10 c0t0d0s1 c0t1d0s1 1024 swap
metadb c0t0d0s7 size 8192 count 3
metadb c0t1d0s7 size 8192 count 3
I haven’t found a way to use references to disk0 and disk1, but will report back when I do. This is cool!