Solaris

Next Solaris Express build will probably contain one of the long awaited features: Solaris NewBoot architecture for x86 systems. Among other boot architecture improvements, NewBoot introduces GRUB with ufs support, and a pxegrub for PXE booting. Casper Dik describes it here:
The End Of Realmode Boot.
In this entry I'll try and explain how to set up an install server to allow you do a network install of Solaris with PXE.

The procedure described below describes steps necessary for PXE booting and installing
a client with Grub bootloader, which is the default one in Solaris since Nevada b14. Obviously, the very first requirement is that you absolutely must have a PXE-enabled network card installed in the client machine you're about to install.

Here is the full list of server-side components you need to have in order to be able
to PXE-boot and install a client machine over network:

1. DHCP server setup and configured
2. Network install OS image
3. Jumstart configuration files for a given client

I'll go through this list first, and then will give a list of actions you
have to take to configure and PXE-boot a client:

1. DHCP SERVER

1.1. Setup
Start off by doing this:


bash-3.00# dhcpconfig -D -r SUNWbinfiles -p /var/dhcp


This configures your DHCP server: it creates an empty resources table for
its use in /var/dhcp, and creates an /etc/inet/dhcpsvc.conf file with a
contents like this:



Your default DHCP daemon (/usr/lib/inet/in.dhcpd) is started at this stage, and
the above shown dhcpsvc.conf file ensures your dhcp server gets started up automatically upon reboot from /etc/init.d/dhcp script.

1.2. Networks

Here you have to look at your topology and decide, which networks are going to be served by your DHCP server. If you have a DHCP server configured by someone else, here's how you look at the list of networks served:

pntadm -L

It returns you a list, on our server it looks like this:


To create a table for another network, do this:

pntadm -C 192.1.10.0

Make sure you have /etc/netmasks updated, if your network is subnetted.

Update your /etc/inet/dhcpsvc.conf file to include a line with all the
DHCP active interfaces. On our server it looks like this:
INTERFACES=hme1,qfe0,qfe1,qfe3


2. NETWORK INSTALL OS IMAGE

Follow the instructions from this page:
Creating an install server with CD media

In short: create a directory for your netinstall image, and use setup_install_server and add_instll_server
commands to copy necessary files from Solaris_10.1/Tools directory of your install media (CDs or DVD).
Share your netinstall image out.

Checklist:
- make sure the netinstall directory is shared out to your clients
- if you have more than one network, make sure all your networks have
access to this directory.

Share command should return you something like this for your install directory:


- /export/install2 ro=@192.1.1:@192.1.2:@192.1.3:@192.1.4:@192.1.9 ""



3. JumpStart CONFIGURATION

Follow the instructions from this page:
Creating a profile for networked system.

On our server, the JumpStart directory is /export/install/config. Then each machine has a directory there, like /export/install/config/perf-123.

Okay. Assuming you've done everything above, you've got a DHCP server configured, netinstall image ready and JumpStart files created for your client machine.

Now we're ready to reinstall your client. Here's what to do:

1) Generic add_install_client

Go to your netinstall image directory, and go to Solaris_10.1/Tools dir, where you have add_install_script. On our server, for Nevada b14 it's this directory:

/export/install2/nv/snv_14/Solaris_10.1/Tools

Now, do this:

./add_install_client -d SUNW.i86pc i86pc

It's a very important commant. It creates, if necessary, /tftpboot directory, or updates it with generic files for the netinstall OS image we're using. This command will also enable TFTP server on your machine. At last, it will create a /tftboot/pxegrub.I86PC.Solaris_10.1-1 file, which will be used to PXE boot each client you want to install with this build.

2) Client-specific add_install_client

Then, for our client, we have to do this:



It's a line from our script which automates the installation, and it shows clearly what is being passed to the add_install_client command: $ETHER is an MAC-address of the client box. Bear in mind, that for most MAC-addresses you have to add "01" to the beginning of the address. Also, you
have to get rid of the colons usually found in MAC address. So, for instance, if your client has this entry in /etc/ethers file on your server:
00:09:3d:00:68:f3 perf-123

The MAC-address you'll pass to the add_install_client will be this: 0100093D0068F3.

Other parameters are:

$SERVER - IP address of your server's interface on the subnet your client is on
$SYSNAME - a hostname of the client
$SOLARIS_PATH - is a full path to the netinstall image you're using.
$TTY - is an input-output device used during pxegrub boot. You can specify ttya/ttyb here to get an output on a console, connected to your client. You may also not specify this parameter at all for the default device to be used (screen/keyboard).

So, for our client perf-123 the final line looks like this:



This line creates three files in your /tftpboot directory:

menu.lst.0100093D0068F3 - grub menu for your client's PXE boot
rm.0100093D0068F3 - a standard shell script for cleaning up /tftpboot files for your client
0100093D0068F3 - a symbolic link to a build's pxegrub file in /tftpboot

For perf-123, this link looks like this:



If you check now, the grub menu file will look like this:



Unfortunatelly, at this early stage, we have to manually update this file so that the machine not only boots off the network, but starts JumpStart install automatically. To do this, you have to pass a "- install dhcp" as a boot argument to Solaris kernel. So we update one of the menu file lines to look like this:



I'm sure later there will be a command line option, so I'll update this how-to accordingly.


As you can see, most of the add_install_clients parameters end up in this file. A menu file is also a good way to do basic sanity checks, cause it shows you where your client will try to mount a netinstall image from, and where JumpStart will expect to have your client's configuration files to be found.

3) DHCP - IP address and a macro for our client

First, add a fixed IP for your client, which will be issued to it by your server upon DHCP request:


pntadm -f 01 -e 12/31/2010 -A $IPADDR -i $ETHER -m $SYSNAME -s $SERVER $NETWORK.0


Most of the parameters are self-explanatory, and you know most of them from add_install_client command. So I'll mention only the new ones:

$IPADDR is the IP address you want DHCP server to assign to your client
$NETWORK is the network your client belongs to. Obviously, $IPADDR should be in this network as well.
-f 01 means that this IP lease is permanent
-e 12/31/2010 sets the expiration date for this lease (we sure have got some time before 2010)

Now, what this line does apart from assigning an IP address to our client, is that it also assigns the client a DHCP macro. By following the macro specified, your DHCP server will give the client all the additional info the client needs to PXE boot.

Here's the line:

dhtadm -A -m $SYSNAME -d ":BootSrvA=$SERVER:BootFile=$ETHER:"

This line tells the client to try and PXE boot off a specified server with IP $SERVER, and suggests that the bootfile will be $ETHER. This file, as you remember, essentially points to a pxegrub file for the netinstall build.

That's it! Make sure your BIOS points to a PXE-enabled network card on your client, reboot the box, and you should see it downloading the Solaris miniroot onto the client and then booting Solaris. As always, snoop is your friend with network troubleshooting.

When you're writing a DTrace script, often you'd like to pass some parameter in command line. Such an easy task might be really hard unless you read a docs.sun.com section about DTrace scripting, particularly a section about comman line parameters macros.

As with sh or bash, you can access command line parameters via $0..$9 macroses. But there's a catch. Values of these macroses should match a certain definition - a number, an identifier or a string. If there isn't a match here, you'll get an error.

Let's start with a simple script.



If you pass a number as a command line parameter, there will be no error, and you'll get this message:
Your parameter: 123

But if you pass a string instead of number, here's the error you'll get:

bash-3.00# ./args.d a1b2c3
dtrace: failed to compile script ./args.d: line 9: failed to resolve a1b2c3: Unknown variable name

This happens because DTrace tries to find an identifier "a1b2c3". Why does this happen? Because of the way DTrace tries to recognize the type of a command line parameter. The parameter doesn't look like a number, but to make DTrace accept the value as a string, you have to specify it in quotes. Without them, DTrace accepts we've passed an identifier name. And since there isn't one with such a name, we get an error.

To prove this theory, you simply have to create a variable with the same name in your script:


There you go - it works just like I said:

Your parameter: 1979

And if your parameter is definitely a string, you have to change your script (the line with printf, so that it has %s for a string, and not %d for an integer, otherwise you'll get another error)...


... and also put your parameter in quotes, like this:

bash-3.00# ./args.d '"a1b2c3"'
Your parameter: a1b2c3

As you can see, we're getting a string we passed, and not the variable with the same name, which was left in the script intentionally to demonstrate it's not used anymore.

And finally, one more thing. If you want all your command line parameters to be treated as strings by default and even leave the quotes around parameters out, all you have to do is to access the macroses for your parameters with a double $ sign, and then the parameter type definition will be skipped:



And here's how you'd access such a script with the same parameter we've used before:

bash-3.00# ./args.d a1b2c3
Your parameter: a1b2c3

That's it for today! Good luck with your DTrace scripts!