PXE Boot on Ubuntu 16.04 (Part 1)

As I’ve mentioned a few times before, I’m currently building a nice PXE-based platform for testing and imaging machines at work. Building a PXE server is relatively straight-forward, but it takes some understanding of how PXE works.

How PXE booting works

PXE (Preboot eXecution Environment) is a standard way to boot a client device over a standard network connection.  PXE works by following a defined method to send a ‘bootstrap’ to the client machine, which then completes the boot process.

The procedure for PXE is pretty simple when you’re booting Linux:

  1. Compatible device boots, and the option ROM in the NIC attempts to get a DHCP lease.  If it is successful, the DHCP server gives the client device the name of a file to boot from.
  2. The client device connects to a TFTP (Trivial FTP) and attempts to download the file.  If the download is successful, it will begin to boot from the file if it is possible.
  3. The bootable file either contains or refers to a set of parameters to create a bootstrap, frequently initramfs and vmlinuz files, along with some configuration for the root filesystem.
  4. The initramfs and vmlinuz files are downloaded by the client and control is handed off to the bootstrap as it loads the rootfs over the network (usually NFS or HTTP).

In this guide, I’ll be showing you how to make a PXE boot server on Ubuntu 16.04.  The same methods should work on newer versions without much issue, though.

Hardware

PXE booting isn’t terribly hardware intensive, especially if a little bit of a wait is acceptable.  The only real hardware issue is that, since PXE uses DHCP, being able to isolate network ports can be extremely useful.  DHCP can temporarily take down a whole network due to the way it works, so be careful about doing anything involving it without understanding what you’re doing!

Software

The software requirements for PXE are pretty light.  We’ll be using:

  • tftpd-hpa
  • isc-dhcp-server
  • NFS

Yeah, really, only 3 pieces of software are required for a basic PXE server.  Once you get that stuff installed, check out part 2!

Running only specific tests in Memtester

Panucci uses memtester to run a pattern RAM test. All well and good, but some of these tests take forever – unfortunately, time is of the essence here. Fortunately, memtester offers a way to run only certain tests. From the documentation:

-add ability to run only specified tests by setting the environment
variable MEMTESTER_TEST_MASK to a bitmask of the indexes of the tests to be
run. Thanks: Ian Alexander.

This means that you can configure which tests run by adding a simple environment variable.

Things don’t work normally when you run using *sudo*, though, so we need to add it to /etc/environment, like this:

MEMTESTER_TEST_MASK=xxxxx

To generate the mask, look at the list of tests memtester runs:

Stuck Address : ok
Random Value : ok
Compare XOR : ok
Compare SUB : ok
Compare MUL : ok
Compare DIV : ok
Compare OR : ok
Compare AND : ok
Sequential Increment: ok
Solid Bits : ok
Block Sequential : ok
Checkerboard : ok
Bit Spread : ok
Bit Flip : ok
Walking Ones : ok
Walking Zeroes : ok
8-bit Writes : ok
16-bit Writes : ok

Simple create a binary number, with the most significant digit being the bottom of the list (i.e., 16-bit writes) and turning a test on with a 1 or off with a 0, being sure to leave out that “top” test, Stuck Address, since it runs no matter what. Take the full number and convert it to decimal, put it into the environment file, and run memtester again.

Stuck Address : ok
Random Value : ok
Compare XOR : ok
Compare SUB : ok
Compare MUL : ok
Compare DIV : ok
Compare OR : ok
Compare AND : ok
Sequential Increment: ok
Checkerboard : ok
Bit Flip : ok
Walking Ones : ok
8-bit Writes : ok
16-bit Writes : ok

/32 doesn’t do me a bit of good.

So I’m rebuilding my server at work to use a standard PXE boot, rather than the clunky boot method that DRBL provides (which, without documentation-diving, requires me to make changes to the server, essentially). I learned something, uh, vital today. I need to check netmasks more closely.

Wonder what happens when you try to set up NAT on an interface (or set of interfaces…) that your idiotic self set as netmask 255.255.255.255? In other words, a /32?

Yeah, it, uh, refuses to connect to anything, even *the same device that gave it the IP address in the first place*.

Go self.

And I said “Why?”

Fun stupidity from today – I’m rebuilding Farnsworth, the imaging server at work, into a fatter, but more useful, form (i.e., I’m building it out of a 24-bay server with 3.5″ bays and more room to work).

I have 24x 1TB SATA drives (specifically, Seagate ES.2). I’m curious, though, why they have a jumper on them that limits SATA speed. With jumper, it’s set to 1.5gbps SATA, without, it’s set to 3.0gbps SATA. Other than having to remove these little half-height jumpers with tweezers, I’m somewhat amused, honestly. Why would this be there?

The importance of solving the right problem

At my job, I am something of a general problem-solver. I build spreadsheets, tiny web apps, up to imaging servers with custom software.

Our guy in data destruction (responsible for wiping the drives to ensure they’re reasonably secured) was having some problems keeping track of inventory when he counted it up, so I worked with him to make a little inventory clicker application that runs on an iPad we stuck magnets to – the joy of e-recycling!

He said that it works great, it looks great, it does exactly what he needed!

There’s just one problem – he never uses it. As it turns out, he just never remembers to use it, because it’s so far from his routine. Alarms might’ve worked, except the iPad is silent, likely due to a busted speaker.

Still, we solved the wrong problem first; the software doesn’t mean a thing if it doesn’t get used.