Configuring Intel Solaris is similar to Linux. The low level startup boot process is the same as Windows and Solaris, mainly the use of a PXE loader to start the process, however in order to keep the top level menuing consistent for the client, and to work around a dhcpd configuration issue, it was required to chain together Sun’s version of PXEgrub with PXELinux.

In both the Intel and Sparc cases, a request to boot is dropped on the wire, the dhcpd server accepts the request and issues a reply packet containing the IP address for the PXE client, the IP address of the next server to speak to, and the filename that the PXE client needs to request, still PXELinux for the first stage. For Sparc Solaris, the filename that the bootloader needs to request is not a PXE loader, but instead is the actual Solaris supplied boot file.

The operating system makes use of the PXE Loader configuration. Please go read that post if you have yet to do so as general configuration details are described in that article.

Please take note that a conscious design decision was made at this point to chain the bootloaders to present a mostly unified menu system to the end user. It is possible to create an Intel Solaris stanza in the dhcpd.conf and add the mac addresses of each host that would need to boot off of pxegrub instead of pxelinux. However, this would require the modification of the configuration and restarting of the dhcpd service for each new intel host added.

Since, in the environment, there were an exceptionally small number of Sparc hosts to be installed, and new Sparcs were added intermittently at best, it was considered more desirable to touch the dhcpd files only for the Sparcs rather than the often multiple installs/day required of the Intel machines. This would then allow the scheduling of dhcpd restarts during a maintenance window.

There was one modification made to the dhcpd.conf file which needs to be made regardless of the architecture. The following option statements need to be added to the file somewhere near the PXElinux lines that were added to support PXE booting.

option SUNW.root-mount-options code 1 = text;
option SUNW.root-server-ip-address code 2 = ip-address;
option SUNW.root-server-hostname code 3 = text;
option SUNW.root-path-name code 4 = text;
option SUNW.swap-server-ip-address code 5 = ip-address;
option SUNW.swap-file-path code 6 = text;
option SUNW.boot-file-path code 7 = text;
option SUNW.posix-timezone-string code 8 = text;
option SUNW.boot-read-size code 9 = unsigned integer 16;
option SUNW.install-server-ip-address code 10 = ip-address;
option SUNW.install-server-hostname code 11 = text;
option SUNW.install-path code 12 = text;
option SUNW.sysid-config-file-server code 13 = text;
option SUNW.JumpStart-server code 14 = text;
option SUNW.terminal-name code 15 = text;

These vendor specific lines assign human readable names to the various SUNW codes that are used to set various parameters such as the root path, the swap file, and the like.

The pxelinux menu entry needs to be changed to point to the location of the Sun PXEgrub file placed in the boot tree, and a menu.lst file will need to be created to support that bootloader. The single Solaris entry in my environment looks like this:

label solaris
kernel /boot/grub/pxegrub.0

In my boot directory you can find a grub directory containing the files pxegrub.0 and menu.lst. The menu.lst file is grub’s version of the default entry. It must always be named menu.lst either via the actual filename or through a tftp filename remap. After reading through the Solaris pxegrub source it seems highly likely that this filename cannot be changed via a vendor ID code in the dhcpd.conf file despite what the manpages say.

The three line Solaris 10 entry in my sample menu.lst looks like:

title Solaris 10 Interactive
kernel /images/SOL_10_U3_x86_64/boot/multiboot kernel/unix – install nowin dhcp -B install_media=172.16.32.16:/export/install/images/SOL_10_U3_x86_64
module /images/SOL_10_U3_x86_64/boot/x86.miniroot

The first line is the title as it will appear in the grub menu. The second describes the kernel file to load including all switches passed to the kernel. Given the strange wrapping, please take note that the line ends with the install_media stanza found in the SOL_10_U3_x86_64 directory. Finally, the final line specifies the module the kernel will need to load in order to run properly.

For an Intel installation, the prep work is completed and there remains only the image to prepare. For the sparc image, the dhcpd.conf file will need to be edited each time a new sparc host is added and the following stanza will need to be added and/or updated:

group {
vendor-option-space SUNW;
option SUNW.JumpStart-server “172.16.32.16:/export/JS/sol8/configs”;
option SUNW.install-server-hostname “gorgon”;
option SUNW.install-server-ip-address 172.16.32.16;
option SUNW.install-path “/export/install/images/SOL_9_U8_x86″;
option SUNW.root-server-hostname “gorgon”;
option SUNW.root-server-ip-address 172.16.32.16;
option SUNW.root-path-name “/export/install/images/SOL_9_U8_x86/Solaris_9/Tools/Boot”;
next-server 172.16.32.16;

host solclient01 {
hardware ethernet 00:0c:29:e3:e9:94;
fixed-address 172.16.33.69;
option host-name “solclient01″;
option SUNW.sysid-config-file-server=”172.16.32.16:/export/install/jumpstart”;
}
}

Each new sparc addition will require the addition of a new host substanza in this group. You’ll need to gather the mac address of the new host as well as assign it a static IP address. Once the configuration file has been updated, simply restart dhcpd and the configuration changes are complete. As a side note, installations were done using a small preallocated pool of statics outside the dhcpd range and then the host was reconfigured once the installation was complete.

Now that dhcpd has been setup, we can setup the images. Substitute x86_64 with SPARC as appropriate in the examples. Note that the solaris media comes on DVDs and so there is only a single image to copy.

mkdir /export/install/images/SOL_10_U3_x86_64 # or the path for the real vers.
mkdir -p /mnt/{1,2,3,4…N} # one per ISO
mount -o loop /path/to/iso/SOL_10_U3_x86.iso /mnt/1
…
mount -o loop /path/to/iso/SOL_10_U3_x86.iso /mnt/N
.
tar -C /mnt/1 cpvf – | tar -C /export/install/images/SOL_10_U3_x86_64/ -xpf -

When finished, in /export/install/images/SOL_10_U3_x86/ directory you should have the following directories: boot, Solaris_10, and a Copyright and installer file. Note that there is only a single ISO released from Sun. If the host is 64 bit capable the Solaris OS will boot in 64 bit mode. If the host is only 32 bit capable the OS will boot on its 32 bit kernel. The directory naming of _64 was chosen to remain consistent with the other directory names.

Next confirm that the boot/ directory contains the files you supplied paths to in the grub menu.lst, mainly multiboot and x86.miniroot:

ls -al /export/install/images/SOL_10_U3_x86_64/boot/
grep boot /export/install/boot/menu.lst

And that concludes all of the image prep necessary. The next item to configure is the apache server to ensure it can serve the http content from the /export/install mountpoint. To do so we need to edit the configuration of apache and add a section allowing the webserver to find our content at /images/. Edit the httpd.conf and add the following in an appropriate location, or use this snippet to create a new file uniquely named along the lines of install.conf in the httpd/conf.d directory, if present.

Alias /images/ /export/install/images/
< directory >
Options Indexes FollowSymLinks
AllowOverride Limit
Order allow,deny
Allow from all
< /directory >

Apache needs to then be restarted or HUP’ed for the configuration changes to take effect.

Unless the entire installation is being done over HTTP, Solaris also introduces the need for an NFS server for the image shares. How this is done will be dependent on your operating system, but assuming the nfs software is installed on the machine, in order to nfs export /export/install one needs to try one of the following:

Linux:
edit /etc/exports and add
/export/install *(ro)
service nfsd restart

Solaris:
edit /etc/dfs/dfstab and add
share -F nfs -o ro -d “Image Mounts” /export/install

All that is left now is to test the individual components:

First we need to make sure dhcpd is running:

ps -ef | grep dhcpd

Next we ensure apache is running:

ps -ef | grep httpd

Next ensure that nfsd is running:

ps -ef | grep nfs

Now we make sure that the repository is in proper order:

ls -al /export/install/boot/pxelinux # check for pxelinux
ls -al /export/install/boot/grub/pxegrub # check for pxegrub
ls -al /export/install/boot/grub/menu.lst # check for pxegrub’s menu file
ls -al /export/install/boot/default # check for the default menu file for your entry
ls -ald /export/install/images/SOL_10_U3_x86_64 # ensure the image is there
ls -ald /export/install/images/SOL_10_U3_x86_64/boot # should return 3 files: grub, multiboot, x86.miniroot

Now we make sure that tftp is working as expected (remember that tftp was chrooted to /export/install so everything will be relative to that path):

tftp localhost
cd images/SOL_10_U3_x86_64/boot/
get x86.miniroot

Next we ensure the apache is serving content properly.

wget http://localhost/images/SOL_10_U3_x86_64/boot/x86.miniroot

if, for some reason, you dont have wget on your server you can do it manually using telnet:

telnet localhost 80
HEAD /images/SOL_10_U3_x86_64/boot/x86.miniroot HTTP/1.0

Finally we test the NFS shares. Mount the filesystem on another machine if possible:

mount -o ro yourserver:/export/install /mnt
cd /mnt/images/SOL_10_U3_x86_64/boot
ls -al x86.miniroot

This essentially concludes the work required to net install a Solaris installation.

After finishing the configuration, all that is left is to reboot the machine and netboot using the F12 key, and then select the newly added menu entry from the pxelinux menu when prompted. Grub will then start and present its menu to you. From there select the entry you desire and then just wait until you reach the Solaris blue and green configuration screens.

Again, If you have any problems or questions, drop me a line and I’ll see what I can do to help. If there is interest in the topic, moving from an interactive installation to the configuring of jumpstart may be discussed in a later article should there be interest in the topic. If this article sounds familiar it is because I followed the guidelines I established in the Linux article. ;)

>>> Karl

Configuring Linux is nowhere near as complex as the Windows environment. The low level Linux boot process is the same as Windows and Solaris, mainly a PXE request is dropped onto the wire. The dhcpd server accepts the request and issues a reply packet containing the IP address for the PXE client, the IP address of the next server to speak to, and the filename that the PXE client needs to request. The filename passed to the client used is the pxelinux bootloader which has been described in detail elsewhere.

The operating system makes use of the PXE Loader configuration. Please go read that post if you have yet to do so as general configuration details are described in that article.

The pxelinux menu entry needs to be updated to point to the linux kernel and an appropriate initrd stanza needs to be added to the menu entry as well. Substitute your own directory name for all instances of RHEL_4_U5_x86_32. That said, a sample entry in my environment looks like this:

label rhel4_32
kernel /images/RHEL_4_U5_x86_32/install/images/pxeboot/vmlinuz
append initrd=/images/RHEL_4_U5_x86_32/install/images/pxeboot/initrd.img nofb text noipv6 method=http://install/images/RHEL_4_U5_x86_32/install ksdevice=eth0

Remember that the tftpd server is chrooted to /export/install, so on the filesystem, the kernel resides in the base directory /export/install/images/RHEL_4_U5_x86_32/. The nomenclature used at the customer site allows multiple variants of RHEL 4 32 and 64 bit to live in the tree concurrently. Menu entries need only be added for each desired variant to install other versions.

Once the PXE menu entries have been added, the image can be prepared. This is nowhere near as complex as windows and requires only a few steps:

mkdir /export/install/images/RHEL_4_U5_x86_32 # or the path for the real vers.
mkdir -p /mnt/{1,2,3,4…N} # one per ISO
mount -o loop /path/to/iso/RHEL4-U5-i386-AS-disc1.iso /mnt/1
…
mount -o loop /path/to/iso/RHEL4-U5-i386-AS-discN.iso /mnt/N
# note, if you run out of loopback devices, add “options loop max_loop=256”
# to /etc/modprobe.conf and reboot.
tar -C /mnt/1 cpvf – | tar -C /export/install/images/RHEL_4_U5_x86_32/ -xpf -
…
tar -C /mnt/N cpvf – | tar -C /export/install/images/RHEL_4_U5_x86_32/ -xpf -

When finished, in /export/install/images/RHEL_4_U5_x86_32/ directory you should have the following directories: RedHat, SRPMS, install, images, isolinux, and a large number of README html files.

Confirm that the install/images/pxeboot directory contains a file called vmlinuz and the path matches what was indicated in the pxelinux menu entry and that the initrd.img is present in the same directory and that the paths to the images match:

ls -al /export/install/images/RHEL_4_U5_x86_32/install/images/pxeboot
grep RHEL_4_U5_86_32 /export/install/default

And that concludes all of the image prep necessary. The next item to configure is the apache server to ensure it can serve the http content as requested by the method= line of the menu entry. To do so we need to edit the configuration of apache and add a section allowing the webserver to find our content at /images/. Edit the httpd.conf and add the following in an appropriate location, or use this snippet to create a new file uniquely named along the lines of install.conf in the httpd/conf.d directory, if present.

Alias /images/ /export/install/images/
< directory >
Options Indexes FollowSymLinks
AllowOverride Limit
Order allow,deny
Allow from all
< /directory >

Apache needs to then be restarted or HUP’ed for the configuration changes to take effect.

All that is left now is to test the individual components:

First we need to make sure dhcpd is running:

ps -ef | grep dhcpd

Next we ensure apache is running;

ps -ef | grep httpd

Now we make sure that the repository is in proper order:

ls -al /export/install/boot/pxelinux # check for pxelinux
ls -al /export/install/boot/default # check for the default menu file for your entry
ls -ald /export/install/images/RHEL_4_U5_x86_32/ # make sure the RedHat dir is there
ls -ald /export/install/images/RHEL_4_U5_x86_32/install/images/pxeboot # should return 4 files: initrd.img, README, TRANS.TBL, vmlinuz

Now we make sure that tftp is working as expected (remember that tftp was chrooted to /export/install so everything will be relative to that path):

tftp localhost
cd images/RHEL_4_U5_x86_32/install/images/pxeboot
get vmlinuz

Next we ensure the apache is serving content properly.

wget http://localhost/images/RHEL_4_U5_x86_32/install/images/pxeboot/vmlinuz

if for some reason you dont have wget on your server you can do it manually using telnet:

telnet localhost 80
HEAD /images/RHEL_4_U5_x86_32/install/images/pxeboot/vmlinuz HTTP/1.0

This essentially concludes the work required to netboot a RHEL installer to the point where the user can make their desired selections to complete the installation.

After finishing the configuration, all that is left is to reboot the machine and netboot using the F12 key, and then select the newly added menu entry from the pxelinux menu when prompted. When the installer loads and begins the interactive installation you will need to walk through the installer options and answer any question.

If you have any problems or questions, drop me a line and I’ll see what I can do to help. If there is interest in the topic, moving from an interactive installation to the configuring of kickstart may be discussed in a later article should there be interest in the topic.

>>> Karl

So, there are a few things left to do before we can attempt a network boot. Primarily we need to add/create the winnt.sif configuration file, update the binl daemon files and restart the daemon, and then we need to test the components to make sure that everything is in order.

An absolute minimal winnt.sif created by the addnewos.sh script looks like the following:

[data]
floppyless = "1"
msdosinitiated = "1"
; Needed for second stage
Orisrc="\\\\172.16.32.16\REMINST\\W50AA\i386"
OriTyp = "4"
LocalSourceOnCD = 1
;DisableAdminAccountOnDomainJoin = 1
[SetupData]
OsLoadOptions = "/fastdetect"
; Needed for first stage
SetupSourceDevice = "\Device\LanmanRedirector\172.16.32.16\REMINST\\W50AA"
[UserData]
ComputerName = *
FullName = *
OrgName = *
ProductID = *

Briefly, the [data] section specifies where the media will be coming from and what type it is. The [SetupData] stanza contains any arguments to be passed to the kernel, as well as establishing the source device from which setup is to pull the additional datafiles. The listed path corresponds to the samba share that was setup earlier.

Finally, the [UserData] section allows for the customization of the computer name, the user name, and the company name, as well as provide a slot to prefill the appropriate license key obtained from Microsoft.

This sif file will allow setup to execute in a fully interrogative mode, asking the user performing the install the same series of questions as if they’d used the CD media for the installation. There are quite a few options available for the sif file allowing for the full unattended installation of windows. If there is an interest I can expand on it in a future piece.

Once the w50aa.sif file is in place, we can go refresh the binlsrv.py database. Assuming the copies of binlsrv.py, infparser.py, and windirs.conf.sample were obtained from this site, this is accomplished by doing the following:

• edit windirs.conf and add the new directory name, i.e. W50AA
• run infparser.py
• run binlsrv.py

With the binlsrv.py script running, we can begin to do the testing on the system. Of course you could at this point simply reboot the box you wish to install, cross your fingers, and hit F12 to netboot while hoping for the best. Those of you willing to use some methodology in their testing, please read on. Please note: I’m assuming the path to your install tree is /export/install/ and you have the windows image in images/W50AA. You’ll need to adjust it for your environment otherwise.

First we need to make sure dhcpd is running:

ps -ef | grep dhcpd

Next we ensure binlsrv.py is running;

ps -ef | grep binl

Now we make sure that the repository is in proper order:

ls -al /export/install/pxelinux	   # check for pxelinux
ls -al /export/install/default     # check for the default menu file for pxelinux
ls -ald /export/install/images/W50AA/i386 # make sure the i386 dir is there
ls -ald /export/install/images/W50AA/w50aa* # we should get 3 files back, w50aa, w50aa.0, w50aa.sif.

Now we make sure that tftp is working as expected (remember that tftp was chrooted to /export/install so everything will be relative to that path):

tftp localhost
cd images/W50AA/boot
get w50aa.sif

Now we ensure that the rewriting rules for the tfpd map files worked properly

grep W50AA /var/log/messages  # on linux
grep W50AA /var/adm/messages  # on solaris

You should have seen several log lines spit out as a match to the grep statement. If not, there is the possibility that the mapping isn’t working. Try a tail -f on the logfile and run a few tftp fetches by hand looking for the matches.

At this point the only thing left to do is the actual boot of the computer. So, reboot the test machine, netboot it, and if all goes well you will be greeted by the pxelinux menu. From there pick the entry you created for the windows installation and you will soon be greeted by the windows setup program.

Hopefully there is enough in here to allow you to troubleshoot any issues which you may run into. If this is not the case, please post in the comments and I’ll do what I can to assist you.

>>> Karl

The configuration of the PXE environment requires several components:

• dhcpd server
• tftpd server
• PXE bootloader

Each of these items has customized configuration files which will be described below.

At the lowest level there is a dhcpd server listening for initial boot requests. ISC’s dhcpd server, specifically version 3.0.6 which was the current version at the time. On the production RHEL machine, version 3.0.5 from the RPM was used.

The full intricacies of configuring the dhcpd file can be found in the manpage, however at a minimum one needs to specify the following pxelinux entries and create a single subnet stanza for basic functionality.

# pxelinux settings
option space pxelinux;
option pxelinux.magic code 208 = string;
option pxelinux.configfile code 209 = text;
option pxelinux.pathprefix code 210 = text;
option pxelinux.reboottime code 211 = unsigned integer 32;

#and

# Servers subnet
subnet 172.16.32.0 netmask 255.255.254.0 {
authoritative;
option routers 172.16.32.1;
option subnet-mask 255.255.254.0;
option broadcast-address 172.16.33.255;
option domain-name “dhcp.karlmajer.com karlmajer.com”;
range dynamic-bootp 172.16.33.201 172.16.33.251;

ddns-domainname “dhcp.karlmajer.com”;
ddns-rev-domainname “dhcp.33.30.172.in-addr.arpa.”;

next-server 172.16.32.16;

filename “boot/pxelinux.0″;
site-option-space “pxelinux”;
option pxelinux.magic f1:00:74:7e;
option pxelinux.configfile “pxelinux.cfg”;
option pxelinux.pathprefix “/tftpboot/pxelinux/files/”;
option pxelinux.reboottime 30;
}

Several assumptions are made by that configuration snippet that will need updating:

1. *There is no other dhcpd server on the network*
2. The tftpd server is at 172.16.32.16
3. The default router is at 172.16.32.1
4. You’ve placed your pxelinux and configuration files in $TFTPROOT/boot directory
5. Your network spans 2 class Cs, i.e. the 255.255.254 (/23) netmask and 33.255 broadcast.

After making these changes in the dhcpd.conf file, start up the daemon using the method of your choice, i.e., service dhcpd start, svcadm enable dhcpd, or even simply ‘dhcpd’ from the command line.

At this point there should be a functioning dhcpd server on the network. The next thing to configure is the tftpd server. Tftp-hpa version 0.42 was chosen as the tftp server of choice as it supported the remapping of file paths in requests, and offered tcp wrappers as an added bonus. Edit the tftpd.map file, often sought by tftpd at /etc/tftpd.map, and add the following lines to it:

rgi ^pxelinux.0 /boot/pxelinux.0
rgi ^pxelinux.cfg/ /boot/
rgi ^boot/pxelinux.cfg/ /boot/
rgi ^boot// /

This sets up the location of the boot files relative to the tftpd root which is specified on startup. In the environment that was built, all provisioning related items were placed in /export/install and the tftpd daemon was chrooted to this path. Therefore the pxelinux related files were in /export/install/boot, the menu files were in /export/install/hostmenu.

Now the tftpd server can be run from either inetd or as a standalone. Given the low usage of the install system, it was decided that tftpd would run from xinetd on RHEL ignoring the startup/shutdown costs of the daemon which may be noticeable were the install frequency several installs per hour rather than week.

Configuration of the inetd process will differ depending on the flavor of unix employed. On RHEL one need simply add a service definition to the xinetd.d directory and the xinetd daemon will pick it up on the next invocation. A sample RHEL stanza looks as follows:

# default: off
# description: The tftp server serves files using the trivial file transfer \
# protocol. The tftp protocol is often used to boot diskless \
# workstations, download configuration files to network-aware printers, \
# and to start the installation process for some operating systems. service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -m /etc/tftpd.map -v -v -v -s /export/install -t 10
disable = no
per_source = 11
cps = 100 2
flags = IPv4
}

Note the explicit paths to the tftpd.map as well as the chroot to /export/install.

At this point we have a daemon to respond to our PXE requests, and we have a daemon to serve the content using the tftp protocol for the PXE requests. Now we need to supply the file to be served.

PXELinux from http://syslinux.zytor.com/pxe.php was used as the bootloader. The files were unbundled and placed into /export/install/boot. A menu file was created for pxelinux, the contents of which look like:

#Note, this menu starts the local disk, a memtest utility, and a Windows 2000 RIS #Installation.
default local
prompt 1
timeout 0
display /boot/install.msg
F1 /boot/install.msg

label local
localboot 0

label w50aa
kernel /images/W50AA/boot/w50aa.0

label memtest
kernel /boot/memtest
append -

For safety the default configuration chosen is to always favor the internal drives and only attempt to boot from the w50aa stanza on request. Now copy the menu containing the described data into the /export/install/boot/ (adjusted appropriately for your filesystem layout) and either name the file default, or name the file something else and symlink it to default.

At this point you should have the basic workings of a PXE loader environment. To test it first make sure that dhcpd is running:

ps -ef | grep dhcpd

Next use tftp to connect to localhost and request the file pxelinux:

tftp localhost
get pxelinux

Finally, reboot a host with a PXEboot capable network adapter and hit F12 to netboot.

Please let me know if you have any questions or comments.

>>> Karl

boot/ – the collection of bootloader files and the sif file.

inf/ – the driver information files. The contents of this dir is read by the python RIS implementation processes.

sys/ – the drivers themselves

i386/ – the cab files and other files found on the i386 directory on the media

amd64/ – on 64 bit OSes, this contains 64b versions of the i386 files.

The boot directory is populated as follows. Modifications need to be made to the actual windows binaries using your binary editor of choice. There are several strings, such as “winnt”, prevalent throughout all of the binaries and they each need to be replaced with a new string. This is done to create uniqueness across all of the windows install variants all of which request the same files such as winnt.sif, ntdetect.com, and whatnot. Using your binary or hex editor of choice, and substitute the following strings:

• startrom.n12 – NTDLR to w50aa
  • rename this file to w50aa.0
• setupldr.exe – winnt.sif to w50aa.sif; ntdetect to ntdw50aa;
  • rename this file to w50aa
• ntdetect.com – no string replacement
  • rename this file to ntw50aa.com

Alternatively, the following script snippet can be adopted to use. In the example below let ${Lwhich}=”w50aa”. The full script can be found at http://www.karlmajer.com/files/addnewos/addnewos.sh. Note, if using the script, the script assumes you’ve created the directory w50aa/i386 and/or w50aa/amd64 depending on the bitness of the OS and copied the files from the install media to those locations.

echo “Preparing boot directory.”
echo “…cabextracting files…”
cabextract -d boot/ i386/startrom.n1_
cabextract -d boot/ i386/setupldr.ex_

echo “…copying files…”
cp i386/ntdetect.com boot/

echo “…editing binaries…”
echo “…..startrom.n12…”

cat > /tmp/${Lwhich}.startrom.$$ << EOF
:%s/NTLDR/${Lwhich}/g
:wq!
EOF
vim -b -s /tmp/${Lwhich}.startrom.$$ boot/startrom.n12

echo “…..setupldr.exe…”

cat > /tmp/${Lwhich}.setupldr.$$ << EOF
:%s/winnt.sif/${Lwhich}.sif/g
:%s/ntdetect/ntd${Lwhich}/g
:wq!
EOF
vim -b -s /tmp/$Lwhich.setupldr.$$ boot/setupldr.exe

echo “…renaming binaries…”
mv boot/ntdetect.com boot/ntd${Lwhich}.com
mv boot/setupldr.exe boot/${Lwhich}
mv boot/startrom.n12 boot/${Lwhich}.0

You’ll note the vim is being used in binary mode (-b) in order to do the edits. The stubfiles simply create regex expressions for vim that are used to handle the search and replace. The script also handles the renames for you as well.

When it is all said and done, you will have the following files in the boot directory: w50aa, w50aa.0, and ntdw50aa.com. If you’re using the full version of the script then a w50aa.sif configuration file will have been created also. Those files map to the old ntldr, ntdetect, and then the setup specific files, setupldr.exe and the winnt.sif file.

To populate the i386 directory all that is required is to copy the i386 directory off the media directly into the tree.

For the inf and sys directories, the following needs to be done. Note that ${BIT} denotes 32 or 64 bit and pulls files from the appropriate directories accordingly. Again, this is included in the script linked above.

echo “Preparing inf and sys directories.”

if [ ${BIT} ];
then
echo “…extracting inf files…”
cabextract -d inf amd64/[Nn][Ee][Tt]*.[Ii][Nn]_
echo “…extracting sys files…”
cabextract -d sys -F *.sys amd64/driver.cab
else
echo “…extracting inf files…”
cabextract -d inf i386/[Nn][Ee][Tt]*.[Ii][Nn]_
echo “…extracting sys files…”
cabextract -d sys -F *.sys i386/driver.cab
fi

echo “Complete.”

That takes care of the directories. The only remaining things to do are to update the tftpd.map file and to create a few symlinks to fix bizarre windows naming conventions as well as update the windirs.conf which is the binl parser configuration file and update it to include this new OS we’ve added. Both of these are covered in detail in the script.

That concludes the preparation of the windows image. The next section will discuss setting up the low level boot and PXE environment.

>>> Karl

First a bit of background on the windows boot process. As a windows machine starts the boot process, the following things happen approximately in this order (1):

1. The MBR is queried for the boot sector, and Ntldr is read.
2. Ntldr is loaded into memory. Its reads the Boot.ini file to present the menu and loads the kernel.
   1. Ntldr will eventually load Ntoskernl.exe, Bootvid.dll Hal.dll and the boot-start device drivers.
3. Ntdetect.com then runs and performs a basic hardware detection for Ntldr.
4. Ntbootdd.sys is loaded for I/O.
5. Ntoskrnl.exe is initialized and starts the system-start device drivers then kicks off smss.exe
6. Hall.dll is loaded and is used to speak to the hardware in the machine.
7. Smss starts the windows subsystem.
8. Winlogon is started.
9. SCM (service control manager) is started for windows services/drivers.

The boot process across the network is somewhat similar:

1. The pxeclient on the network interface in computer drops a boot request onto the wire.
2. The dhcp server catches this request and gives the pxeclient an IP address, the IP address of the next server in the process, and the name of the file to fetch. .
   1. pxelinux was used for the windows installs.
3. The pxeclient then fetches pxlinux via tftp from the bootserver and presents the menu to the user and waits for entry.

Up until this point the pxe boot procedure is the same regardless of what OS is being loaded.

1. The user selects the desired windows installation and pxelinux tftps back to the server and asks for the appropriate file, typically startrom.n12, the network bootloader for the MS boot process.
2. startrom.n12 then calls for setupldr.exe
3. setupldr.exe, actually named ntldr on the filesystem, is the pre-installation setup loader for windows.
4. as before ntldr calls ntdetect.com for hardware detection,
5. similarly, ntdetect.com handles hardware detection for the ntldr process as for the disk based boot
6. finally the file winnt.sif is loaded which contains the instructions for the setup/RIS based installation.

Now, in order to make this all work a bit of filename manipulation magic needs to be undertaken. This is accomplished in the tftpd.map file which is loaded by the tftp server and additionally by making a few changes to both the names of the binaries and to the binaries themselves.

The naming convention chosen at the site was based on the fact that NTLDR is five characters. A method to encode OS names/types into the five characters was devised such that any OS/SP level could be encoded. The first letter was either W for 32 bit or X for 64 bit. The next two characters were the Microsoft OS version number, W50 for Windows 2000 32bit, X51 for Windows XP Pro 64 Bit. Finally the last two characters were used to denote patch level and any other desired information. For example, at the client site, X51AA was an unpatched XP Pro 64 Bit. While X51BA was SP2.

The path used on the filesystem to contain the filesystem images was /export/install/images. The tftp root is /export/install. The mapfile contained:

# windows to unix pathing
rgi \\ /

# anything asking for /IMAGES is broken and likely a Microsoft client.
rge ^/IMAGES/ /images/

# rehome 32 and 64 2k and 2k3 to /images
rgi ^/X5.* /images\0
rgi ^/W5.* /images\0
# Windows 2000 32 bit – W50AA

rgi ^/boot/pxelinux.0ntdw50aa.com /images/W50AA/boot/ntdw50aa.com
rgi ^boot/pxelinux.0ntdw50aa.com /images/W50AA/boot/ntdw50aa.com
rgi ^/boot/pxelinux.0w50aa.sif /images/W50AA/boot/w50aa.sif
rgi ^boot/pxelinux.0w50aa.sif /images/W50AA/boot/w50aa.sif
rgi ^w50aa /images/W50AA/boot/w50aa
rgi ^/images/W50AA/i386/W50AA/sys/(.*) /images/W50AA/sys/\1

# Windows XP Professional 64bit – X51AA
rgi ^x51aa /images/X51AA/boot/x51aa
rgi ^ntdx51aa.com /images/X51AA/boot/\0
rgi ^x51aa.sif /images/X51AA/boot/\0
rgi X51AA/i386 X51AA/amd64
rgi ^/images/X51AA/amd64/X51AA/sys/(.*) /images/X51AA/sys/\1
rgi ^/images/X51AA/i386/X51AA/sys/(.*) /images/X51AA/sys/\1

First off we need to rewrite dos paths to unix paths. Next we need to send anything asking for just /[WX]5 to /images. That allows the client to find the files its going to request next. The next section addresses some bugs in windows 2000 in which it tacks on the file its looking for onto the file it loaded previously, ie the pxelinux bootloader. Thankfully XP lacks this bug. You’ll notice that the filenames are not those mentioned in the process flow earlier, but are instead files based on the new naming convention. Any additional OSes based on 2000 need to simply copy the 2000 stanza and adjust the w50aa to the new 5 digit code. The same holds true for XP. These mappings allow the pxeclient to find the contents of the appropriate boot directory.

Configuring the directories in the W51AA tree will be covered in the next post.

>>> Karl

(1. This disk based bootup process was adapted from “Table 5-1, Microsoft Windows Internals, Fourth Edition, p252″. Any typos are mine. I’d recommend the original version of this from the text if possible. Its one of the few windows reference books on my shelf.)

The system built for the client, however, made use of both a single box running tftp, samba, and the python RIS implementation from http://oss.netfarm.it/guides/pxe.php. The basic setup is as follows:

TFTP – tftp-hpa 0.42 – With remap and with tcpwrappers was chosen as the tftp server to be used. The using of tcpwrappers is generally a good practice, but the remap function was the desired functionality in this version of tftpd. RHEL 5 ships with this binary as an rpm. The map file will be explained in further detail in when the image preparation is discussed.

SAMBA – samba 3.023c-2 – Was selected as the version of samba to run. Again, this was available as an rpm on RHEL 5 and made the selection easy. The following lines were added to the smb.conf configuration file to support the RIS installation environment:

encrypt passwords = yes
null passwords = yes
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
idmap uid = 16777216-33554431
idmap gid = 16777216-33554431
template shell = /bin/false
winbind use default domain = no
guest account = nobody
map to guest = Bad User

The last line allows any user that fails authentication to map to the guest account. If the samba server is setup on a different domain than the rest of the organization, as it was in the case on this network, the desktop computers will have access to the CIFS shares to pull cabs, or other files, from the CD images available on the shares. Note: While testing on unix using smbclient, the share name is \\\\HOST\\SERVICE. If you happen to add a trailing \\ on the end, the service name wont match and the connection will fail with a “tree connect failed: NT_STATUS_BAD_NETWORK_NAME.”

RIS – The UDA v 1.4 provided the foundation binlsrv.py and infparser.py files that were used to initialize the 32 bit OSes. As written, the core binl code needed to be refactored and extended for the intelligent inclusion of additional operating systems, both 32 and 64 bit. The biggest change was made to the infparser and allows it to read the list of operating systems to be parse from a text file. A link to my updated versions of the files can be found here: binlsrv.py, infparser.py, and windirs.conf.sample.

Once the requisite software has been installed, the image will need to be prepared. This will be covered in the next section entitled “Multi-OS Installation: Configuring the Windows Image.”

Unless otherwise specified, the Solaris installation was built from the source tarball, whereas the Linux installation came from an official RedHat RPM. This typically accounts for any version differences found between the two operating systems.

The network services required to fully netboot and install a machine are as follows:

• At the lowest level there is a dhcp server listening for initial boot requests. ISC’s dhcpd server, specifically version 3.0.6 which was the current version at the time. On the RHEL machine, version 3.0.5, was used.
• A tftp server is required to make the necessary files available. The files in question could be either pxe bootloaders for Linux and Solaris 10, the actual boot files in the case of Solaris 9, and the WINNT bootloader in the case of Windows. Tftp-hpa version 0.42 was chosen as the tftp server of choice as it supported the remapping of file paths in requests, and offered tcp wrappers as an added bonus.
• An HTTP server is made available on the network to support Solaris jumpstart and Linux kickstart. The server offers media for both of the installation processes. The Apache that shipped with Solaris 10, Apache/2.0.58, and the Apache that shipped with RHEL 5, Apache/2.2.3, worked without a problem.
• An NFS server is made available on the network to support Solaris installations including jumpstart. The server offers the entire media tree to any client that may desire it. Linux NFS servers may have problems with Solaris clients on anything other than NFSv2. The converse is not true.
• To support windows, a CIFS needed to be offered. Samba was picked as it is the primary software of choice. Version 3.023c-2 was used on RHEL, 3.025c on Solaris.
• RIS Services are required to properly net install a Windows machine. The software used was a python implementation of the binl server and is covered in greater detail in the Windows section.
• Additionally, OS ISOs for every operating system to be installed must be obtained for both the Windows and Unix environments. This must be done in accordance to appropriate licensing for each respective OS.

The delivered product was capable of installing: Linux RHEL 3,4,5 32 and 64 bit variants, Solaris 9, 10, both intel and sparc at multiple releases, Windows 200[03], XP, both 32 and 64 bit including the unpatched and last two service pack levels. All in all a total of 27 windows offerings, 6 Solaris offerings, and 6 Linux offerings were available to any server or desktop that supported pxe booting.

More to come…

>>> Karl

After a bit of research I decided to use a combination of the theory behind the Ultimate Deployment Appliance (UDA) VM, available from http://www.vmware.com/appliances/directory/232 , VMWare’s appliances directory, as well as the information found on the RIS for Linux site located at http://oss.netfarm.it/guides/pxe.php around which the UDA is built.UDA v1.4 was already capable of booting a considerable variety of 32 bit windows images, however it lacked the ability to easily add 64 bit images. Additionally, there was no need for the pretty HTML GUI that the package offered and so they were omitted in favor of a pxelinux and pxegrub menu system.

This series of articles will describe how the system was built as well as provide examples on how to build your own. It will be written in several parts, at least one for each of Solaris, Linux, and Windows, and the Windows article may be further subdivided into several more.

More will follow as time permits.

>>> Karl