Aerospace



Home

Company Information

Information Request

Linux How-to Guides

ADSP 21xx
Digital Signal Processing
Tutorials

SW Utilities

On-line Order Form

Aerospace Projects

Commercial Projects

Circuit Boards

Server Support


Bonk

Have you found this site useful? Did we save you time? Did we cure your head-ache? Is your hair growing back now?

Please make a donation to help with maintenance.


Linux, Windows Remote Installation Server Howto

For Mandriva 10.2LE

Copyright 2005, Aeropspace Software Ltd, GPL.


Scope

I was recently faced with a Windows XP notebook PC that was completely destroyed by malware and this machine didn't have any removable media that it could boot from. It could not boot from USB either! The only solution was to do a network install and to do that, I needed a network install server.

This guide explains how to configure a Linux Remote Installation Server for Windows XP and use it to load a WinPE recovery version of XP over a network. It is based on my experience with this very brief howto of Gianluigi Tiesi at http://oss.netfarm.it/guides/pxe.php. Go there and download his python scripts. If you read everything there and everything here, you should be able to get a RIS going in much less time than I.

The RIS process is weird and far more complicated than doing a Linux network install. First, the machine uses DHCP to get an address and find the file to boot. It then downloads this boot file via tftp. Finally, it starts up Windows SMB networking and installs over the network from a Samba share. Therefore, you need dhcp, tftp and samba running on the RIS server, plus Gianluigi's binl server application to handle the RIS process.

Once you managed to get a WinPE recovery version of XP booted and running in RAM, you can use that to install a full version of XP over the network from a Samba shared CDROM drive.

Clearly, one would only go through all this hassle for a very good friend, or as a pure mental exercise, but the upshot is that once you have it done, you can make neat Bootable Windows XP recovery CDs - much like Knoppix and the next time anyone brings you a messed up machine, you can save yourself many hours of grief by starting with a netboot.

Oh, well, what the hell! - Yosarian, Catch 22 by Joseph Heller.


Setup

I used my notebook machine to do this. This machine is dual booting, so I could use WindowsXP to run Bart's PE Builder to prepare the WinPE install files. It has a built in ethernet adaptor eth0 and a WiFi adaptor eth1. I normally use WiFi eth1 for a connection to the internet, so that left eth0 for the RIS function. My router dishes out IP addresses starting at .100, and there are some servers between .1 and .15, so I used a .20 address for eth0 and set up a DHCP server just above that, for the machine in repair.

Configure an ethernet port on your RIS machine with a fixed address, eg.:

ifconfig eth0 192.168.1.20 netmask 255.255.255.0

Run a cross-over cable to the machine in repair that you want to install via PXE.


DHCPD

Install dhcpd from CDROM if you haven't got it already. Setup DHCPD with the following configuration in file /etc/dhcpd.conf:

ddns-update-style none;
authoritative;

subnet 192.168.1.0 netmask 255.255.255.0 
{        
  option subnet-mask 255.255.255.0;
  option domain-name "aerospacesoftware.com";
  server-name "plato.aeronetworks.ca";
  next-server plato.aeronetworks.ca;
  range dynamic-bootp 192.168.1.21 192.168.1.30;
  default-lease-time 86400;
  max-lease-time 604800;
  filename "startrom.o";
}

Start DHCPD on eth0 with the following command:

# dhcpd eth0

Now, if you start up the Windows PC and select PXE Netboot, it should ask for an address and you should see something like this in /var/log/messages:

Jun 18 14:27:36 plato kernel: e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
Jun 18 14:27:36 plato ifplugd(eth0)[19251]: Link beat detected.
Jun 18 14:27:37 plato ifplugd(eth0)[19251]: Executing '/etc/ifplugd/ifplugd.action eth0 up'.
Jun 18 14:27:41 plato ifplugd(eth0)[19251]: Program executed successfully.
Jun 18 14:27:48 plato dhcpd: DHCPDISCOVER from 00:08:0d:ad:23:0a via eth0
Jun 18 14:27:49 plato dhcpd: DHCPOFFER on 192.168.1.30 to 00:08:0d:ad:23:0a via eth0
Jun 18 14:27:50 plato dhcpd: DHCPREQUEST for 192.168.1.30 (192.168.1.20) from 00:08:0d:ad:23:0a via eth0
Jun 18 14:27:50 plato dhcpd: DHCPACK on 192.168.1.30 to 00:08:0d:ad:23:0a via eth0
Jun 18 14:28:06 plato kernel: e100: eth0: e100_watchdog: link down
Jun 18 14:28:06 plato ifplugd(eth0)[19251]: Link beat lost.
Jun 18 14:28:08 plato kernel: e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
Jun 18 14:28:10 plato kernel: e100: eth0: e100_watchdog: link down
Jun 18 14:28:12 plato ifplugd(eth0)[19251]: Executing '/etc/ifplugd/ifplugd.action eth0 down'.
Jun 18 14:28:12 plato dhcpd: receive_packet failed on eth0: Network is down
Jun 18 14:28:12 plato ifplugd(eth0)[19251]: Program executed successfully.

On the machine in repair, you will probably see the DHCP results on screen - the IP Address, Gateway, Netmask and so on, therefore you should immediately know whether dhcpd works properly.


TFTP

Mandriva 10.2 uses the hpa tftp server. Install tftpd from CDROM if you haven't gotten it already.

If you check the version of tftpd it should say something like this:

# in.tftpd -V
tftp-hpa 0.40, with remap, with tcpwrappers

The server is supposed to be launched via xinetd and the configuration file is /etc/xinetd.d/tftp, but it may not work in all versions of Linux. It does work in Mandriva 10.2LE.

Here is the manual method:

Create file /etc/thcpd.rules containing the following line:

rg \\ / # Convert backslashes to slashes

Open a console and run in.tftpd manually:

/usr/sbin/in.tftpd -s /var/ftp/windows -m /etc/tftpd.rules

Check /var/log/messages and ensure that you don't see any tftpd errors.

Here is the xinetd method:

The tftp control file is /etc/xinetd.d/tftp. Create the file tftpd.rules as explained above and modify /etc/xinetd.d/tftp as below, to add the backslash conversion rule:

##############################
# Start of /etc/xinetd.d/tftp
##############################
# 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             =  -s /var/ftp/windows/ -m /etc/tftpd.rules
        disable                 = no
}

Then restart xinetd. This is very important, else the changes to tftp won't take effect:

service xinetd restart

Test Tftpd:

Test tftpd from a console by transferring a file:

Create a file in /var/ftp/windows to test with:

cd /var/ftp/windows
cat >test
test test test
ctrl-D
In one console, watch the messages log:
# tail -f /var/log/messages

and in another, do a get:
$ tftp
tftp> get test

You should not get any error messages in the messages log and tftp should report that the get action worked - something like:

getting from plato.aeronetworks.ca:startrom.0 to startrom.0 [netascii]
Received 22642 bytes in 0.8 seconds [213440 bit/s]

Now two parts of the puzzle should be working.


Create a BartsPE CDROM

The actual installation is done from a SMB share. The tftp server doesn't follow symbolic links, therefore, the SMB share must be in the tftp root.

You have to take a WinXP CD and convert it into a Preinstalled Executable (PE) system to use with RIS. This best done with Bart's PE Builder, available at http://www.nu2.nu/pebuilder. The PEBuilder is easy to use, but in addition to the WinXP CD, you also need to get the MS Windows Service Pack 2 from the MS web site. Bart's has the ability to slipstream the service pack into the installation files and write the whole thing to a bootable CD - something similar to a Knoppix CD, but it won't run on a large variety of hardware, the screen configuration is 800x600, it will reboot every 24 hours and the number of concurrent processes is limited to six - a useful debug tool nonetheless.

Once you are done with Bart's and has a CD, copy the contents of the CD to the Samba share /var/ftp/windows/winpe. The directory structure MUST be ...winpe/i386...

cd /var/ftp/windows
mkdir winpe
cd winpe
cp -a /mnt/cdrom/* .

Delete the following from the root of the folder:

AUTORUN.INF
README.HTM
SETUP.EXE
WIN51
WIN51IP
spnotes.htm
win51ip.SP1

These files are not needed.

You have to flatten out the directory tree somewhat. Copy the contents of the inf, drivers and system32 directories to the i386 directory, otherwise you will get File Not Found errors when ntldr executes on the machine in repair.


Configure Samba

Configure the Samba share with the following parameters in /etc/samba/smb.conf. Note that the share name [REMINST] is required and that the directory is the same as the tftp root directory:

[REMINST]
     path = /var/ftp/windows
     browsable = true
     read only = No
     guest ok = Yes

You must set null passwords = true in smb.conf. Restart samba with 'service smb restart'. Test Samba with smbclient:

smbclient -L //localhost -N

That should list the shares. Now try to log into the ris share and look around:

smbclient //localhost/reminst
smb:\> ls

You should see something like this:

[herman@plato ~]$ smbclient //localhost/reminst
Password:
Anonymous login successful
Domain=[MSRIS] OS=[Unix] Server=[Samba 3.0.13]
smb: \> ls
  .                                   D        0  Sat Jun 18 22:35:05 2005
  ..                                  D        0  Fri Jun 17 22:43:13 2005
  winpe                               D        0  Sat Jun 18 22:35:05 2005

                63943 blocks of size 131072. 61448 blocks available
smb: \>

Note that if samba doesn't work on this machine, there is no way that it will work from a distant machine. So if it won't work, then you have some more debugging to do first...


Fix the Filenames in the RIS Repository

You also need to modify the server name and path in SetupSourceDevice option of winnt.sif file. Edit the path in fixup-repository.sh and launch it to fix the case of the files in the repository.

Find and change this line in fixup-repository.sh:

REP=/var/ftp/windows/winpe

Then run it:

./fixup-repository.sh

If you get a page full of 'cannot stat' errors, then the path is wrong.


TFTP Windows Startup Files

You need to copy a few files from your original WindowsXP CD to the tpftp root directory, which must be the same as the Samba share directory:

cd /var/ftp
mkdir windows

You need to expand one file. On your Windows PC, expand startrom.n1_:

c:>expand startrom.n1_ startrom.o

This filename is passed to the PXE machine by the DHCP server.

Copy the expanded file back to the /var/ftp/windows directory. Then copy the files of Gianluigi Tiesi to /var/ftp/windows and also copy setupldr.bin, ntdetect.com from the i386 directory to here - the root of the tftp server.

You need to do one more fix. Rename setupldr.bin to ntldr and run fixloader.py ntldr:

mv setupldr.bin ntldr
./fixloader.py ntldr

It should come back with the message "Loader fixed".


RIS Command Files

These command files are used by the machine in repair, to find the Samba RIS repository. Therefore they need to have the relevant Samba paths:

File winnt-ris.sif

Rename this file to winnt.sif, then change the paths below. The syntax for the paths is:

\Device\LanmanRedirector\%servername%\RemInst\%RelativePathToWinpe%

If the paths are wrong, then the setup system in startrom.0 will start, give a welcome message and then stop with "INF file txtsetup.sif is missing or corrupt". It took me a loooooooong time to get past that point...

[data]
floppyless = "1"
msdosinitiated = "1"
; Needed for second stage
OriSrc = "\\192.168.1.20\RemInst\i386"
OriTyp = "4"
LocalSourceOnCD = 1
DisableAdminAccountOnDomainJoin = 1

[SetupData]
OsLoadOptions = "/fastdetect"
; Needed for first stage
SetupSourceDevice = "\Device\LanmanRedirector\192.168.1.20\RemInst\"

[UserData]
ComputerName = *
ProductID=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

Binl Server

First you need to build device driver cache using infparser.py to create devlist.cache file that must be in same directory as binlsrv.py.

cd /var/ftp/windows
./infparser.py /var/ftp/windows/winpe/i386/inf

Now you can launch binlsrv.py, it will load the driver cache and will reply to client requests.

./binlsrv.py

You should see something like this:

Succesfully loaded 955 devices
Binlserver started... pid 1841

Put a tail on the messages file so that you can get some idea of what is going on, start up the machine in repair and let the fun begin...

tail -f /var/log/messages

Install and Test

At this point, when I started the machine in repair again, things proceeded through dhcp and tftp, I got a message saying that Setup is starting and then it hung with: "INF file txtsetup.sif is corrupt or missing, status 21. Setup cannot continue. Press any key to exit." This was due to a bad path specification in winnt.sif. Lots of experimentation was required to fix that. I eventually found the LanmanRedirector path syntax on the Microsoft site and with some more trial and terror, eventually got it to continue.

The next failure was a missing ethernet driver. It always amazes me how a system can start up quite happily over ethernet, then complain that it doesn't have a driver - can't it just fall back to the basic default that has been working a moment ago? Sigh...

The binl server gave the following message:

Recv NCQ len = 48
NCQ Driver request
[R] Vid: 0x8086
[R] Pid: 0x1059
[R] rev_u1 = 0x2
[R] rev_u2 = 0x0
[R] rev_u3 = 0x0
[R] rev    = 0x10
[R] rev2   = 0x50
[R] subsys = 0x11179
Checking PCI\VEN_8086&DEV_1059&SUBSYS_00011179
Checking PCI\VEN_8086&DEV_1059
Driver not found

To fix this, hunt down the driver at the manufacturer web site, make sure the name is in lower case and add it to /var/ftp/windows/winpe/i386/inf, then run infparser.py, restart binl and try again.

This time, it found the ethernet driver and got stuck with: "File \\i386\KDCOM.DLL could not be loaded." The problem being that this file was in i386/system32, while the ntldr program looked for it in i386. To fix this, I had to do some directory flattening till these errors went away, as explained above in the Samba section.

Eventually, after many trials and tribulations, I had BartsPE running in RAM on the machine in repair. I could then share the CDROM drive on the server with Samba and copy the whole Windows XP Pro CD to the hard disk of the machine in repair, then execute setup.exe to do a proper install of Windows.


What a way to waste a whole long weekend - and then people ask me why I don't like MS Windows. Sigh... ;-)

Have fun!
Herman



Copyright © 2005-2008, Aerospace Software Ltd., GPL.