Having been sick as a dog for nearly two weeks, I had the opportunity to kill some time setting up a PXE boot server for my network.
It’s working nicely now, so I can connect devices to my network & immediately boot via PXE to install media for Fedora, CentOS or Ubuntu. It’s also handy for virtual machines, connect them to a virtual network with dnsmasq dhcp setup to provide the pxe boot server address, and your VMs can PXE boot too.
Setting up a PXE boot server is a pretty well-documented process, with many good online guides, eg: Ubuntu and CentOS 7.
Those guides all cover the setup of basic PXE boot infrastructure (dhcp, tftp, dnsmasq, pxelinux, nfs, apache/httpd, firewall). Once that’s all done, you’ll need to do more research on which boot parameters are required by the particular installation sources you have. This is where things are less well-documented, as over the years, different Linux distributions/versions have used a frustrating variety of poorly-documented methods & kernel parameters to boot their installers. Getting these details right can require some detective work.
If, however, you need to PXE boot:
-
– Fedora 27 (server & live workstation iso media)
– CentOS 7.4
– Ubuntu 16.04 LTS (server & live desktop iso media)
– Ubuntu 17.04 (server & live desktop iso media)
then read on – because the arcane details you need, painstakingly collected from diverse sources spanning the interweb, are here.
You’re also welcome to take a look at the files in my GitHub:
-
– dnsmasq configuration
– pxelinux.cfg directory – containing the whole menu configuration.
Before I go into the boot parameters required for each distro, I do have a couple of tips/comments on the basic setup:
1) On a modern linux distro like Fedora 27, the dhcp/tftp is very easy. If you’re using NetworkManager you’ve already got dnsmasq running, so just drop a suitable dnsmasq configuration file into /etc/NetworkManager/dnsmasq.d/ and restart NetworkManager – and your dhcp/tftp is sorted.
2) There’s one dnsmasq config tweak which is particularly handy. It ensures your new boot server only provides DHCP to clients also requesting PXE. This prevents your new PXE server from getting in the way of any other (non-PXE) DHCP server already on your network (ie your router):
# Set a tag if it's a PXE client
dhcp-match=set:IsPXEClient,60,"PXEClient"
# Ignore non-PXE requests, to allow any existing DHCP server to handle them instead.
dhcp-ignore=tag:!IsPXEClient
3) When setting up virtual networks in libvirt, you can use the bootp parameter to specify the address of your PXE boot server, so your VMs can PXE boot.
Unfortunately, you can’t use “virsh net-update” to easily script this modification, you’ll have to use “virsh net-edit” or some other method to manually update the network configuration.
Below is an excerpt from the config file for one of my virtual networks, at /etc/libvirt/qemu/networks/soe.vorpal.xml, illustrating the usage of the “bootp” parameter (inside the dhcp block):
You should also be aware of localOnly=’yes’, used inside a domain block:
If you use something like “server=/soe.vorpal/192.168.125.1” to configure your host dnsmasq to forward dns queries for soe.vorpal to the dnsmasq handling this virtual network, you should configure the libvirt dnsmasq handling soe.vorpal with the localOnly=’yes’ directive. Otherwise you’ll cripple your dns with a never-ending DNS storm caused by the soe.vorpal dnsmasq forwarding queries back to your host, forming a loop.
Now, on to a summary & quick explanation of boot parameters for each distro:
DETAILS TO FOLLOW SHORTLY. (In the meantime, you can check details in the files on GitHub).
To whet your appetite, here’s a shot of the main boot menu. The sub-menus look much the same:
