Anyone who has jumpstarted a Sun box using Solaris anytime in the last 13 years has relied on the add_install_client script to do all the hard bits, like setting up the inetboot file in /tftpboot, and adding entries to the /etc/ethers and /etc/bootpararms. The add_install_script took a fair amount of the complexity that you might have to do by hand and did it for you, despite the fact that the parameters required to drive add_install_client can give the typing fingers a real workout.

Ever really looked at /etc/bootparams?

There's about a paragraph worth of stuff in there for each system that will get built describing to the client what things it needs to boot and install Solaris. I remember having to setup multiple servers and all the typing that entailed. I seem to recall building a table of systems and using a while; do loop to call add_install_client repeatedly. Not that I'm a bad typist, but why should I type all that crud out manually? I can't recall the number of times I couldn't get a system net-booting because I fat-fingered something like the ether address or path or something. And how would I really know, unless I had been using a command line shell with history features to see what I had really called add_install_client with?

However, bootp is not a great protocol for booting unless it's contained to a single subnet. The BOOTP requests don't pass through routers, and therefore, you needed to have a boot server on each subnet, so that a net-booting client could get it's initial boot load. Once the intial boot load happened, it could then talk to an install server on a different subnet. Not terrible, but it further complicates the issue by requiring a setup for the install server as well as the boot server.

As it turns out, since DHCP configurations can be passed through routers, you no longer need a boot server on each network to PXE or DHCP boot a Solaris system. This allows you to keep all your jumpstart configurations in one place, even if you have multiple jumpstart servers, as is done in large installations or like some of the factories in Sun.

Dawn of DHCP support for jumpstarting

I don't know exactly when this happened. It's only been in the last four or five years because an old Ultra-AXe box I have in the lab won't dhcp boot. (boot net:dhcp - install) The support for DHCP in add_install_client then fundamentally changed the behavior of add_install_client. Now, when you call add_install_client with the appropriate parameters to do a DHCP/PXE jumpstart, what you get is a list of DHCP macros that you have to plug into your local DHCP server, along with the requisite files in /tftpboot to get your client netbooting. If you thought /etc/bootparams was bad, configuring the DHCP macros is substantially worse, especially if you've never configured a DHCP server before. Not to mention, each different DHCP server has it's own syntax (SUN, ISC, Microsoft, etc et al). And it's not just a set of information that you have to configure, but there's also this concept of "supported architectures". Assuming you've been DHCP booting a bunch of V240's and the boss brings a new V440 up to the lab for you to jumpstart. You configure the add_install_client, punch boot net:dhcp - install and *nothing* happens. Well, not in the way you expect. You'll see things like timeouts and fallbacks to bootp perhaps, but it won't boot.

Whiskey-Tango-Foxtrot? Turns out that you have to inform the DHCP server, and all the SYMBOL macros that you now support the V240 and the V440, which requires approximately X lines of macro changes, based on the number of SYMBOL macros you have defined in your DHCP server which supports jumpstarting. A minimum number will be something like 8 and could be as high as 16. You go back and you fix your DHCP tables, and maybe you just go ahead a pre-populate any of the architectures for systems you might be DHCP jumpstarting, remembering to transform the "," to a "." so you dont' have to fool with the SYMBOL macros again. ( uname -i | sed 's/,/./' )

DHCP Macros for jumpstarting

/etc/bootparams looks really good right now, especially if you're fighting the DHCP server and trying to get things working. If you think the pain is not worth the effort, let me suggest the Jumpstart Enterprise Toolkit, aka JET which takes the complexity of jumpstart and put's all the typing and configuration into a single file. Make a typo? Review your template and remake the client. Need to tweak something, modify the template and remake the client. For some people, this is just *too* hard, but if you're like me and you want to figure out how you jumpstarted a system from 6 months ago, this is the tool to use. Do you have to care about DHCP servers when using JET? Nope. Well, unless you aren't running a Sun DHCP server. Do you have to worry about parsing the output of add_install_client? Nope. So where's the rub? Do you really want to become a DHCP/PXE macro guru? Do you think it's more important that you have really cool and complicated macros, or do you want a tool which sets up the client for you? If you fall into the first category, have at it. If all you really want is a framework to help you jumpstart your systems, then JET is the tool for you.

PXE Booting and how it relates to DHCP

When you call add_install_client (either manually or using a front end like JET) for a DHCP configuration, add_install_client sets up the information in /tftpboot, like you would expect to see. However, instead of populating /etc/bootparams, it nows gives you a list of DHCP macros, with values that you need to populate. JET does all the population of the DHCP macros for you (and if you run remove_client, will take them out of the DHCP tables).

The two DHCP macros that are required to PXE boot a system are the BootSrvA and BootFile. add_install_client tells you to put the BootSrvA macro in the PXE macro (PXEClient:Arch:00000:UNDI:002001). For the most part, we have figured out that this is kind of problem. If you happen to have a multihomed jumpstart server, having the BootSrvA macro in the PXE macro means that you can only have one network you boot from. Unless you then populate other macros with a BootSrvA macro, such as a network or client macro. So what's the point? Why bother with the PXE macro??? I think it just complicates the issue and by putting the BootSrvA in the client macro, you control that client. Some folks like to do anonymous jumpstarts where you can come in and plug your laptop and install it without having to do anything else than pinch a network port. From a security perspective, this is a bad idea. This means that at any time, a user could take one of your PC's and install an OS from the network and you don't have any control over it. The second macro required to PXE boot is BootFile, which is the Network Boot Program (nbp). It is currently a real mode binary which is responsible for collecting the rest of the client configuration information from the DHCP server, checking for a custom bootenv.rc file (usually named /tftpboot/01<MAC address>.bootenv.rc) on the tftpboot server and the inetboot file specified by the SbootURI macro. It starts the inetboot binary which then starts the kernel and you are on your way to PXE booting a Solaris X86/X64 system.

Per node bootenv.rc file

In Solaris 9, U6 (04/04), the concept of a per-node bootenv.rc was introduced. This file is created when you pass add_install_client a "-b variable=parameter" construct. If add_install_client sees that flag, it generates a custom bootenv.rc taken from the net-boot image, and applies the changes you specified with the -b flags. In this case, you can do things like disable acpi for the install, set the serial port to be the console, or set the boot-args to "- install nowin" like:

add_install_client [bunch of jumpstart variables] -b acpi-user-options=0x2

or

add_install_client [bunch of jumpstart variables] -b input-device=ttya -b output-device=ttya

or

add_install_client [bunch of jumpstart variables] -b boot-args=\"- install nowin\"

The last variable sets up the boot-args so that when the system boots, you no longer have to hit "2" to do a customized jumpstart, such that an Solaris X86/X64 jumpstart can be completely hands off (at in Solaris 10).