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

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