The internet is not short of tutorials about how to boot your Linux computer through the network, you will find links to some of these in the following. This is my own howto about that, with a focus on lightweight tools; the case for a diskless workstation will not be covered. You will be interested in this method for installing on a set of servers, as it doesn't involve moving a CD reader or USB stick around. The network method is useful also for a laptop or notebook, which may not have a CD reader. The network boot method is also fine for recovery, in case your boot sector is messed up and you can't use a CD reader. What about booting with USB, which is today present everywhere? See next section. # Booting using USB: maybe not so universal Probably the easiest for an individual installation... when it works! Three different ways to organize a USB key for booting seem to exist, and not all are always recognized by your BIOS. See for instance these references: 1. [General information about bootable USB sticks](http://www.rm.com/Support/TechnicalArticle.asp?cref=TEC818956) 1. ["Universal" USB key builder](http://advancemame.sourceforge.net/boot-readme.html) 1. [About USB-ZIP](http://lime-technology.com/forum/index.php?topic=2407.0) 1. [Debian USB install from hybrid iso](http://kitenet.net/~joey/blog/entry/Debian_USB_install_from_hybrid_iso/) 1. [Boot Debian from an USB device](http://www.debian-administration.org/article/Boot_Debian_from_an_USB_device) Despite the above information, I was never able to boot using USB with one of my motherboard. This was actually one of the reason I wrote this: it's expensive to change a motherboard which doesn't cooperate, but cheap to get an ethernet card accepting network boot. # Network booting in a few simple steps ## Configuring your BIOS You have to setup your BIOS to boot first through the network. The option label for this can be quite different between BIOSes, your motherboard manual can be handy here. If your motherboard doesn't have the option, you are screwed, but it's unlikely if it is from the [present millenium](http://www.kegel.com/linux/pxe.html). It can happen that even if the motherboard has the option, your network card doesn't have the ROM for network boot in the right specification (which is [PXE](http://en.wikipedia.org/wiki/Preboot_Execution_Environment)). Trying a more recent network card will help here. Reboot after BIOS change. You will get a message like "Intel UNDI, PXE...", and a few lines below the MAC address of your network card. Write it down somewhere, it will be useful later. These messages are sent by a program running on the network card ROM, which the BIOS has called because you selected "network boot". After a few seconds, an error message will appear, as no host on your LAN has replied to the bootp protocol requests that the ROM program has sent. Next step is then to setup such a host. ## Setting up a bootp and tftp server The bootp server will be configured to send back after receiving a bootp request from a booting host: 1. an IP address for the booting host 1. the IP address of a tftp server 1. pathname on that tftp server of a first stage bootloader After the bootp transaction finishes, the booting host will start downloading the first stage bootloader from the tfpt server, and pass control to it. In the simplest scenario, the first stage bootloader will in turn load kernel image and initrd from the tftp server. In a more complex scenario, an OS installer will be downloaded from the tftp server; it is how Debian does network installations. More details about all that later. For simplicity, I will give the configuration where bootp and tftp servers are the same. In the case you want separate servers, notice that the bootp server must be on the same ethernet link as the booting machine; the tftp server can be any IP reachable host. You have several options for a bootp and tftp servers, I use udhcpd (from [BusyBox](http://busybox.net/)) and [tftpd-hpa](ftp://ftp.kernel.org/pub/software/network/tftp/), which are lightweight compared to the competition. On Debian, this is a minimal /etc/udhcpd.conf configuration file: start 192.168.0.22 end 192.168.0.22 interface eth0 max_leases 1 siaddr 192.168.0.99 boot_file pxelinux.0 option subnet 255.255.255.0 option lease 600 option router 192.168.0.254 option dns 8.8.8.8 start and end bound the range of the addresses allocated by the server. Here there is only one possible address, as this example is for a recovery setup. Notice that the range must not be already allocated on your LAN, and the address allocated to the booting host can be limited to the time of the kernel download; after that you can change it. This allows for that configuration to be universal for network booting on your LAN. siaddr is the address of the tftp server. In case the tftp server is outside your subnet, you have to give a router option and a dns option. boot_file is the pathname of the first stage bootloader. The pathname is relative to the root directory of the tftp server, see below. For Debian, the tftpd-hpa configuration file is called /etc/default/tftpd-hpa and contains arguments to the daemon called in.tfpd: RUN_DAEMON="yes" OPTIONS="-v -l -a 192.168.0.99 -s /var/lib/tftpboot" Option -a must be consistent with siaddr above. Argument -s is the root directory of the files to be downloaded. So file pxelinux.0 is located at /var/lib/tftpboot/pxelinux.0 ## Putting in place files to be downloaded by tftp: OS installation I will be a bit Debian specific here, as I don't use regularly other distros. Have a look at [the Debian network installation manual](http://www.debian.org/releases/stable/i386/ch04s05.html.en), which gives the project blessed method for network installation. You will find reference to a file netboot/netboot.tar.gz at the end of that page, it's what you have to untar in /var/lib/tftpboot/. That's all! Notice: when the Debian installer asks for a network address through DHCP, and you let it go ahead with udhcpd, you will need a router and a dns option in /etc/udhcpd.conf, so as to be able to reach the internet and download packages. ## Putting in place files to be downloaded by tftp: recovery For recovery, you can use the pxelibux.0 from Debian package syslinux-common, part of the [syslinux project software](http://www.syslinux.org/wiki/index.php/The_Syslinux_Project). Here is how the /var/lib/tftpboot looks like: /var/lib/tftpboot/: total 7545 drwxr-xr-x 63 root root 2048 Jun 10 22:06 .. drwxr-xr-x 2 root root 1024 Oct 4 2010 pxelinux.cfg -rw-r--r-- 1 root root 6165406 Oct 4 2010 initrd.img-2.6.26-1-686 drwxr-xr-x 3 root root 1024 Oct 4 2010 . -rw-r--r-- 1 root root 1505936 Oct 4 2010 vmlinuz-2.6.26-1-686 -rwxr-xr-x 1 root root 15820 Oct 4 2010 pxelinux.0 /var/lib/tftpboot/pxelinux.cfg: total 3 drwxr-xr-x 2 root root 1024 Oct 4 2010 . -rw-r--r-- 1 root root 230 Oct 4 2010 01-aa-bb-cc-dd-ee-ff drwxr-xr-x 3 root root 1024 Oct 4 2010 .. Notice the 01-aa-bb-cc-dd-ee-ff file: it's a syslinux configuration file, whose name is a network MAC address, prefixed with 01-. This a simple authorization mechanism: pxelinux.0 will look for a syslinux configuration file in pxelinux.cfg/ whose name matches the MAC address of the host doing the tftp request: if none is found, booting stops. So you can use a specific kernel and initrd for every host you want to boot through the network. Now the content of a syslinux config file fit for the above listing: totaltimeout 50 timeout 50 ontimeout /vmlinuz-2.6.26-1-686 append root=/dev/sda1 ro quiet initrd=/initrd.img-2.6.26-1-686 label single kernel /vmlinuz-2.6.26-1-686 append root=/dev/sda1 ro single initrd=/initrd.img-2.6.26-1-686 More info about the MAC authorization mechanism and other configuration options can be found at the [syslinux project](http://www.syslinux.org/wiki/index.php/The_Syslinux_Project). ## Final remarks You will experience that downloading the kernel and especially the initrd is quite slow, due to tftp using UDP packets of 512 bytes only. So it is a method to recommend only in case of problems, or for a first installation. It can be noticed that a tftp download is sent in clear and so is not secure. Information in this page should remain valid for [EFI](http://en.wikipedia.org/wiki/Extensible_Firmware_Interface) motherboards and architecture derived IA-32, but I have no direct experience of these. However, mobile computers like smartphones and tablets are mostly not covered.