Klaus Knopper answers your Linux questions
This month's question continues the "Booting via PXE" problem reported in last month's column .
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.
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.)
In this special case, the question/problem concerning the Realtek network card's detection really turned out to be Knoppix-related. To keep the ramdisk small, Knoppix version 7.2 used to store only modules matching the currently running kernel inside the network boot ramdisk. So, if the server boots with
knoppix64, the corresponding 64-bit versions of modules were provided, but the
pxelinux.cfg/default file is still listed in the 32-bit kernel as the one to be loaded. Without an explicit
knoppix64 boot option, the client ended up booting the 32-bit kernel and silently failed to load the 64-bit network card hardware modules.
In Knoppix 7.3, I changed this behavior on the server side by always creating a 32-bit-only network boot ramdisk to go with the 32-bit kernel – to support as many types of hardware as possible. It may be useful to make this a run-time configuration option in the future or create different ramdisks and PXELINUX configurations, so clients could boot as 32- as well as 64-bit systems.
Here is an overview about how Knoppix (and most other network-booting distros) will start over a LAN:
- 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.
- 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.
The bootloader requests to download its configuration file for this client via TFTP. With PXELINUX as bootloader , each client can have its own configuration file, which is named after the assigned IP address and sits inside a directory called
pxelinux.cfgin 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
The content of the configuration file is of the same syntax as
syslinux.cfgfor syslinux or
isolinux.cfgfor isolinux, which makes it easy for Knoppix to adopt the same file from CD or USB booting.
- 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  that allows you to start a PXE environment up to this step by booting from floppy disk or CD.
- 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."
- 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.
- The system root filesystem is being mounted from a server, whose address was typically given as boot
APPENDline in the PXELINUX configuration file. NFS or CIFS (via Samba) are used for this, because they don't require a complex client setup.
- 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.
- 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
- "Ask Klaus" by Klaus Knopper, Linux Magazine, March 2014, issue 160, pg. 40: http://www.linuxpromagazine.com/Issues/2014/160/Ask-Klaus
- PXELINUX: http://www.syslinux.org/pxe.php
- Custom firmware: http://www.rom-o-matic.net
Buy this article as PDF
The company is collaborating with Google and Intel to use Kubernetes as an engine for Fuel
Customers can take a free test drive of SLES for HPC on the Azure Cloud
San Francisco-based chip company announces their first fully open source chip platform.
The whole distro gets rebuilt on glibc 2.3
Ubuntu Vendor tries to solve app packaging and distribution problem across distributions.
Founder of ownCloud launches the Nextcloud project.
Will The Machine change the way future programmers think about memory?
The new Torus distributed storage system is available under an open source license on GitHub
Juries decides Google’s use of Java APIs Was Fair Use