Klaus Knopper answers your Linux questions

Ask Klaus!

Article from Issue 161/2014
Author(s):

 

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.)

Matching Modules

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:

  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.

Infos

  1. "Ask Klaus" by Klaus Knopper, Linux Magazine, March 2014, issue 160, pg. 40: http://www.linuxpromagazine.com/Issues/2014/160/Ask-Klaus
  2. PXELINUX: http://www.syslinux.org/pxe.php
  3. Custom firmware: http://www.rom-o-matic.net

The Author

Klaus Knopper is the creator of Knoppix and co-founder of LinuxTag expo. He currently is a Professor, Dipl. Ing., at the University of Applied Sciences Kaiserslautern. If you have a configuration problem, or if you just want to learn more about how Linux works, send your questions to: mailto:klaus@linux-magazine.com.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Ask Klaus!

    Klaus Knopper answers your Linux questions.

  • Knoppix 6.3 Exclusive!

    Knoppix creator (and Q&A mastermind) Klaus Knopper shares some insights on the latest release.

  • Ask Klaus!
  • Interview: Klaus Knopper

    Ten is a fair age for a Linux distribution that doesn’t have massive staff resources to back it up. Klaus Knopper looks back with a sense of satisfaction after just having compiled version 6.4. As a tribute to the community, this version includes only free software.

  • ASK KLAUS!

    Klaus Knopper is the creator of Knoppix and co-founder of the LinuxTag expo. He currently works as a teacher, programmer, and consultant. If you have a configuration problem, or if you just want to learn more about how Linux works, send your questions to: klaus@linux-magazine. com

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More

News