2 Introduction

In previous PXE/BINL application notes (Serva PXE/BINL - AN01: Windows Install & Serva PXE/BINL - AN02: Windows Install Adv & WinPE Boot) we have seen how Serva PXE/BINL services were able to automatically convert into Serva assets Microsoft Windows Install Distributions and Windows PE executives. In those cases the high degree of automation achieved is based on Microsoft's install distributions and PE executives standard format.
When now we have to process non-Windows systems, the lack of a distribution standard forces Serva to use a still very powerful semi-automatic approach:

In a few indicated cases Serva will require you to copy the distribution ISO/IMG file itself without extracting its components.

Inform Serva about the presence of a non-windows distribution by manually creating the corresponding ServaAsset.inf file within the asset's head directory.
i.e. \NWA_PXE\SLED-11-SP1-DVD-i586-GM\ServaAsset.inf

2.3 Making your ServaAsset.inf self-contained and portable.
2.3.1 When creating ServaAsset.inf do not forget to include a correctly populated Description Header; it might look not really important when you deal with one or two non-Windows assets but when that figure grows or you are planning to share your ServaAsset.inf with colleagues or friends the extra effort always pays off.
2.3.2
ServaAsset.inf append variable will surely require some sort of Microsoft share, HTTP server access, or FTP server access. Please always consider Serva's \NWA_PXE\ class directory as the "root" of all those file delivery services. For the sake of consistency when the asset needs a Microsoft share please share the class directory \NWA_PXE\ as NWA_PXE_SHARE.
2.3.2
ServaAsset.inf kernel and append variables will surely require paths, IP addresses, Serva's computer name, etc. All these components are scenario dependant, that's why Serva is able to parse a set of "environment" variables that help you to create portable ServaAsset.inf.

2.4 In cases where an identical ServaAsset.inf is able to boot/install more than one particular asset flavor, architecture, or version, we must consecutively list all the tested distributions in ServaAsset.inf header for reference purposes. Before use, the variables asset and platform must be manually edited accordingly to the particular distribution being booted/installed.

Note

Well written ServaAsset.inf should be:

Format conformant; including its fully populated information header.

Self-contained; not requiring any external additional information for its proper use.

Portable; being able to be copied to different Serva PXE/BINL repositories requiring minimal to none editing.

Please follow these simple rules when creating your own ServaAsset.inf

2.5 ISO-9660 and its Rock Ridge and Joliet extensions.
ISO-9660 (1987) defines how files can be represented on CD/DVD-ROMs. Limitations on the original standard (i.e. file names no longer than 8.3 format) led to the various ISO 9660 extensions used today i.e. Rock Ridge (mostly adopted by the Unix/Linux world) or Joliet (Created by MS; mostly adopted by the Windows world). Most of the Linux distribution ISOs you see today include the original ISO 9660 and both Rock Ridge and Joliet extension encodings. Finally it is always the OS who decides which extension is used at reading time.
Linux file systems use case-sensitive file names, symbolic links, and other features supported by Rock Ridge but not supported by Joliet. Therefore when populating Serva's repository by copying content from those Linux ISO files to our Serva PC the Microsoft OS will always read from the included Joliet extension (remember Microsoft OSs do not include native Rock Ridge support) then we must keep in mind a few points.

While FILE_NAME.TXT and file_name.txt can coexist on a Rock Ridge or Joliet directory, only one of them can exist on a Microsoft FAT32/NTFS based directory.

Rock Ridge soft links are represented as empty files on Joliet.

While Rock Ridge supports file names up to 255 chars, Joliet supports file names no longer than 64 chars ("relaxed" Joliet implementations allow longer filenames). Then when copying a file from a Linux ISO to a Microsoft OS (which will be read using ISO's Joliet extension) we "might" end up getting the file with its name truncated to 64 chars.

Points 1 and 2 are not very common. Unfortunately there are some Linux install ISOs today using Rock Ridge longer than 64 char filenames distinctive feature and not using a "relaxed" Joliet extension (i.e. certain Ubuntu/Fedora/CentOS/Mageia flavors). Then serving that kind of distro from Microsoft platforms could lead to problems because of those truncated filename files.
If we serve the distro using Serva's HTTP service there's a workaround by checking the following option located at the HTTP Settings tab:

[x] Truncate GET File names longer than 64 chars

This option (when on) will additionally try looking for a resource with its name truncated if the resource's original name was longer than 64 chars and not found on a first try.
I recommend leaving this option always checked if you are booting/installing Linux or derivatives using Serva's HTTP service.

Note

To Linux producers/distributors:
Please do not use on distribution ISOs Rock Ridge features not present on standard Joliet; they do not really help delivering better Linux boot/install systems but they can make PXE booting/installing from Microsoft platforms unnecessarily more difficult.

Kali 1.0.7 Live requires an MS share NWA_PXE_SHARE user=serva password=avres.
Kali 1.0.7 Live requires a complementary initial ram disk INITRD_N14.GZ (560 Kb) providing additional drivers and a customized init script.
When using Serva as proxyDHCP the external DHCP server must be able to answer to BOOTP requests; if it fails try replacing ipby=bootp by ipby=dhcp.

Jeoss Linux requires Serva's HTTP server offering \NWA_PXE\ as root.
The interactive install will ask you for the HTTP server IP and path to Jeoss components; remember at that moment you have to provide a full url i.e.

http://192.168.20.1/head_dir_name

Jeoss can be installed on head-less systems (no-keyboard/no-monitor) completely controlled by a serial terminal emulator. If you need this feature you can set Serva menu system for simultaneously being displayed through a serial connection by adding

SERIAL 0 115200 0
CONSOLE 1

as the two first lines of Serva's PXE/BINL menu.def. Serva will display a text version of its menu on COM 1 at 115200 bps.

Citrix XenServer requires Serva's HTTP server offering \NWA_PXE\ as root.
The interactive install will ask you for the HTTP server IP and path to XenServer components; remember at that time you have to provide a full url i.e.

http://192.168.20.1/head_dir_name

Citrix XenServer can be installed on head-less systems (no-keyboard/no-monitor) completely controlled by a serial terminal emulator. If you need this feature you can set Serva menu system for simultaneously being displayed through a serial connection by adding

SERIAL 0 115200 0
CONSOLE 1

as the two first lines of Serva's PXE/BINL menu.def. Serva will display a text version of its menu on COM 1 at 115200 bps.

Citrix XenClient Enterprise Engine Installer requires Serva's HTTP server offering \NWA_PXE\ as root.
Copy the XCE-Installer.iso under the head directory.
Copy client.ini under the head directory.
Copy the \boot directory from the XCE-Installer.iso under the head directory.

5 Booting Recovery Tools

Notes

Please consider when the memdisk technique is used here it is only suitable for PXE booting small ISOs and requires the Client's RAM memory > than 2.2 times the ISO file size

8 Advanced

On Serva PXE/BINL - AN02: Windows Install Adv & WinPE Boot we have seen how Serva's repository strategy can be split when booting from Serva other repositories like WDS/MDT/SCCM, etc. In those cases Serva TFTP delivers only a Boot.wim that contains the information to boot and connect to the services/resources offered by WDS/MDT/SCCM own stores.
In the Linux world something very similar happens. Initially Serva TFTP delivers a small Linux executive made of a kernel file and a small file system (ram disk image) usually compressed into a single file. When booting, this executive receives as command line parameters the transfer protocol and the network location of the repository offering the bulk of the boot/install components.
The difference between Microsoft and Linux strategies at this point shows how Microsoft today relies on an image based deployment (i.e. Install.wim) while Linux still uses the conventional multi-file transfer approach.
So far all the presented Linux ServaAsset.inf files on this AN give instructions to the booting kernel for retrieving the rest of files using HTTP or MS share services pointing back to Serva itself. You can easily change this making the kernel to look for the required resources in some other HTTP, NFS, FTP server etc. (including Internet hosted servers). Always remember on these situations Serva repository will still need to keep under its control the corresponding initially TFTP transferred components of the installation.

9 Troubleshooting

9.1 Common errors when creating your ServaAsset.inf:

9.1.1 Variables kernel and append use paths to network retrieved resources. Making mistakes when writing these paths is a very common source of frustration. If you ever get a path that looks like i.e.

kernel = C:/SERVA_ROOT/NWA_PXE/$HEAD_DIR$/images/pxeboot/vmlinuz

you know you are in trouble; the kernel vmlinuz is a file that will always be delivered by TFTP then its path cannot ever begin with "C:". Any time you see a local disk reference on the path of a network transferred resource you surely made a mistake.
Whenever you write a path start thinking of the protocol that will transfer the associated resource (TFTP, HTTP, FTP, CIFS, etc ) and then consider where is the corresponding service root directory pointing at. Surely this way you will make fewer mistakes.

9.1.2 Please consider there are situations where these two paths could produce different results

/NWA_PXE/$HEAD_DIR$/zzzz/xxxx.yyy
NWA_PXE/$HEAD_DIR$/zzzz/xxxx.yyy

While the first one makes an absolute reference to the TFTP root the second one makes a relative reference. This is a common mistake when chain-loading NBPs (Network Boot Programs).

9.1.3 Please consider (specially if you have no much Linux experience) there are situations where one of these two paths could lead to an error.

NWA_PXE\$HEAD_DIR$\zzzz\xxxx.yyy
NWA_PXE/$HEAD_DIR$/zzzz/xxxx.yyy

While the first one is the typical "MS Windows" form of a path the second one is the typical "Unix/Linux" form of a path. Please consider not every piece of code out there is able to handle both forms.

9.1.4 Multi-homed Linux (and derivatives) booting interface.
Multi-homed Linux system are known for sometimes presenting problems on PXE scenarios when choosing the booting network interface. A
ServaAsset.inf working on a single-NIC system might fail on a multi-NIC situation. Most Linux distributions have kernel parameters (i.e. netdevice=bootif) or pxelinux parameters (i.e. ipappend = 2) that help in solving this problem.

9.2 Linux aborted installs because of failed HTTP transfers.
Please see point 2.5

10 Final words

Serva PXE/BINL non-Windows Boot/Install was basically designed as a simple alternative to the conventional Linux based PXE install systems. Users from the MS Windows world sure will find fewer obstacles now when venturing themselves into the non-Windows net boot/install arena.