Ask Klaus!

This month's question continues the "Booting via PXE" problem reported in last month's column  [1].

PXE Booting Knoppix (and Other Distros)

Dear Klaus! I have checked out [my setup] again now. First of all, the terminal server does recognize the network card of my client to be a Realtek 8111D/8168 PCI Gigabit Ethernet controller. (I had started a Live Knoppix on exactly the client that later I want to PXE boot.) I have selected ALL the available NIS drivers (RTL 8168 is not there, however, so I hope the RTL 8169 will do), because I want a system which can not only PXE this particular client. I have set up the PXE environment with the miniroot created from the terminal server. It fails to boot. It gets stuck with a message:

Loading network device module(s)
   Probing network device(s) handled by nfsv4.ko.sh: can't access tty;
job control turned off
/ # [ ....."

Seems there is a bug.

I do not understand why I need to create a ramdisk file with the terminal server. Others bring a ramdisk file on their distribution media which PXE boots fine on any NIS adapter.

Best regards,

Friedrich Hotz

Hello Friedrich: Let me first clear up some possible misunderstandings before I go into detail on how Knoppix and other distributions boot and run over the network. :-)

The Realtek 8168 network card is supported by the rtl8169.ko module, which is part of the standard Linux kernel. If you are not happy with performance (I noticed that in some cases bandwidth is slowed down with this module), you can get the r8168-dkms package from Debian, which will compile and install a replacement module during installation. This, however, is not the cause of a problem concerning network boot; the rtl8169 driver is still fine for that.

Each network card chipset needs its own driver module; there is no "generic ramdisk" that will work for each and every card. Only the computer's BIOS in real mode can successfully do network broadcasts and download a kernel+ramdisk via TFTP, using the onboard firmware of the card, before any operating system or drivers are loaded. You can compile various network card driver modules inside the static kernel, or you can put individual modules in a ramdisk, one module per chipset, which is more flexible and keeps the static kernel part smaller.

Because not all network cards are capable of booting via PXE, it is sufficient to add the modules for cards known to work, which are most modern PCI/PCIE cards. This is why they are preselected in the choice menu of knoppix-terminalserver. They add up to about 10MB of compressed driver data. Cards that require special firmware in order to function, such as some Broadcom network cards, need additional files that are not provided automatically.

After the client computer has loaded kernel and ramdisk, the /init script contained inside the ramdisk is executed and, in the case of Knoppix, will try to load each and every module until the right network card is found. Because the Linux kernel is loaded before the modules located on the ramdisk, you have to make sure that kernel modules and the kernel actually match in version and compile-time options; otherwise, loading modules will fail. This is the most likely cause of failure to detect or support a network card! (See the "Matching Modules" box.)

Here is an overview about how Knoppix (and most other network-booting distros) will start over a LAN:

1. The network client, connected to the LAN, boots in PXE mode (PXE = pre-execution environment) and sends a DHCP (dynamic host configuration protocol) broadcast to all computers in the same network segment, requesting an IP address.
2. After obtaining and setting its client IP address assigned by the DHCP server to the network card, the client now downloads a bootloader via TFTP (trivial file transfer protocol). It's the DHCP server's obligation to tell which address to use for this. The TFTP server providing files for download can be located on the same computer running the DHCP server (which is the case with knoppix-terminalserver) or on a different computer.

3. The bootloader requests to download its configuration file for this client via TFTP. With PXELINUX as bootloader [2], each client can have its own configuration file, which is named after the assigned IP address and sits inside a directory called pxelinux.cfg in the TFTP server, named after the IP address in hex. So, for example, IP address 192.168.168.1 becomes pxelinux.cfg/c0a8a801. (Using

   printf "%02x%02x%02x%02x\n" 192 168 168 1

   will show you the correct file name). If not found, PXELINUX will fall back to pxelinux.cfg/default.

   The content of the configuration file is of the same syntax as syslinux.cfg for syslinux or isolinux.cfg for isolinux, which makes it easy for Knoppix to adopt the same file from CD or USB booting.

4. Based on the content of the configuration file, PXELINUX (to stay with this popular bootloader) will now download the Linux kernel and the initial ramdisk via TFTP to RAM. I'm still in firmware mode here – no operating system yet – everything is done by BIOS routines and drivers provided by the network card's firmware. For older computers that don't support PXE booting, custom firmware is available [3] that allows you to start a PXE environment up to this step by booting from floppy disk or CD.
5. Linux kernel and compressed ramdisk are being decompressed to RAM, and control is transferred to the Linux kernel. From now on, an operating system (Linux) is running, and because Linux leaves from (firmware) real mode to protected mode, the network card is "forgotten."
6. Linux, with the help of supporting modules from the ramdisk, now needs to (re)gain control over the hardware, especially the network card. The matching kernel module activates the network card again, and another DHCP broadcast is sent to the LAN to get another (or the same) IP address.
7. The system root filesystem is being mounted from a server, whose address was typically given as boot APPEND line in the PXELINUX configuration file. NFS or CIFS (via Samba) are used for this, because they don't require a complex client setup.
8. The read-only mounted network filesystem is being overlayed with a writable ramdisk. Thus, it behaves like a hard disk, and configuration files are writable.
9. From here, the system continues to start up all services as it would have done in a regular hard disk installation.

In Knoppix, steps 6 to 8 are done by the initial ramdisks /init script, which contains all necessary commands and procedures. The server part, DHCP, TFTP, NFS, and optionally a nameserver and web cache (BIND and Squid) are configured and started from the /usr/bin/knoppix-terminalserver script. On failure of a critical step, the client will be dropped to a shell from where the technically skilled user can find out what went wrong. After fixing errors, the user can continue to boot by leaving the shell with exit.