PXE Puppy Working!

Long time folks here will have familiarity with my “gaggle of old junk” computer farm. Not being fond of tossing out things that work, and from a “family restaurant” background where you have roast turkey one day, turkey sandwiches the next, then “turkey ala king” and finally turkey soup… BTW, the profit is in the soup and the ‘ala king’… I’m loath to toss out a box just because, say, the DVD drive dies (which they do rather more often than I like).

One box, in particular, that I like is the Compaq Evo (Yes, from before HP bought Compaq…) as it has very little fan noise. Nearly none. Fan noise, at 2 am in particular, drives me up a wall… “A fan is an admission of Engineering Failure. -E.M.Smith”. Why on God’s Earth put a fan in a box when simple physics can fix it? A rotating whirring power consuming failure prone mechanical thing. You don’t see fans in high end stereo gear and it runs at hundreds to thousands of watts. The old “Grid Computer Company” made a hand held with a magnesium case and no fan. With heat pipes and aluminum you can passively, and silently, cool just about any hardware that needs it. Or just design for lower power consumption. The Raspberry Pi does that.

In any case, the Evo is a nice, small, quiet and fairly good CPU box with a nice chunk of memory. It also is my Emergency Windoze Box if for some reason I can’t get a thing done on a Linux machine and simply MUST use a Windows box. It has XP on it, wich I like a lot more than anything since. Though the last time I needed that Windows “feature” was a few years back, there are still a fair number of archived things that I’ve not converted away from MS formats, yet. So I keep it.

It also has / had a very nice DVD RW drive in it. That has started to be “sporadic”. Some days fine, some days ‘No Joy’. As booting from CD / DVD releases was my favorite way to get ‘variety linux distros’ to run, that crimps my style. Knoppix, Puppy, SystemRescue CD, Slitaz, and so many more. Nice for doing “financial things” with a known clean OS / Browser. Nice for general browsing without infestation accumulating. Etc. etc. But with the CD / DVD drive dying, not exactly reliable. About 50:50 right now. It being very ancient, not exactly worth putting money into a replacement drive, either. I can get a whole system for less as the local recycle computers shop Weird Stuff. As I noted here:


Though in the process of trying to boot another of my machines I found that SLAX Linux CD does a nice thing, it has a PXE boot server version on the disk… So I might try just booting that on one of them and call it my PXE server, for now. Eventually I want a R.Pi version PXE boot, but the Evo has, once again, stopped talking to the CD drive, and an update of Debian on it did not fix the “occasionally hangs” due to the video driver having issues, so I need a PXE boot target for it, now. As a ‘quick fix’ it would let me get the Evo running (hopefully more stable) and get more experience with the PXE set up process and use. Then that Pi solution can take it’s own time.

Well, without the CD working that SLAX CD didn’t help much. The Antek / ASUS 64 bit box had problems with the disk interface, moving the disk to the second spigot fixed it, for a while… so it’s not a good candidate (and makes noise like a 60 MPH wind tunnel from the fan…) it, too, to become a ‘boot from PXE’ box as that disk is failing.

So I decided to make it a PXE Boot machine. Pre Execution Environment – aka netboot – aka booting over the network.

So I was left with “Then that Pi solution can take it’s own time.” Which time had come. So I set about working on it. A bit more sedately than usual (my motivation was fine, but my ambition was lacking… and some Apple Cider was calling my name, and the TV was teasing me with Mr. Robot and some nice movies on HBO…) Besides, At each step I needed some “think time”. So that’s where I’ve been the last couple of days. Finally deciding to just “push through it” and not do other things until done.

Normally, I’ll just do a web search for folks posting on what they did, ‘gotchas’ they encountered, tricks and methods. Then make up my own recipe if one of them doesn’t stand out as clear and clean. Often there is one stellar example and you can just ‘cook book’ off of it.

Turns out that was a bit more of an adventure than I’d expected. PXE isn’t a service so much as a bag of tools and part of the raw materials you need. Everybody using different parts to build a different structure. Like so many things in the world of people, strongly diverging from the UNIX Way of “do one thing and do it well” (that also means doing it clearly), PXE boot tries to be many things to all people, so “it just growed” into a bit of a mess. At some point I’m going to come back and put up some of the half dozen links to ‘other ways to do it’ that I explored.

For now, I’m just going to “stream of consciousness” put some notes down here. The “Here There Be Dragons” bits.

General Macro Issues

The first thing you run into is the general attitude of postings. PXE boot is something used by SysAdmins in large shops to deploy / configure a hundred machines at a crack. The postings that I found are generally not oriented toward the home gamer with just one box to bring up. So they are terse, leave out a lot of stuff that “the experienced Sys Admin will know”, and revel in offering dozens of options that you might need in a huge shop, but are irrelevant for a shop of a half dozen boxes. Things like how to configure a dozen different architectures of machines with selection of OS to install via MAC address or IP address or HW Class or … Generally NOT just a “get the box working quick”.

Then there is the “go hunt” attitude. For example, you find that you need to put “pxelinux.0” in a particular directory. Where do you get “pxelinux.0”? “Go Fish!”. Eventually you find it is at the SYSLINUX web site. And you can download their tarball and unpack it… and it does have preconfigured binaries for x86 boxes. Somewhere in the file system tree…

Then there are the endless variations of DNS Server,DHCP, TFTP / FTP server, and even HTTP server possible. Originally designed for “Trivial File Transfer Protocol” TFTP, some folks wanted other protocols with higher security or the wiz-bang feature of using a web server to serve their OS. So various reference pages use different DNS configs for different DNS server types. Some Microsoft centric. Some use THE most complicated DNS / DHCP services on the planet. All configured differently and all using somewhat different commands and syntax.

I chose to simplify a lot of that by using “dnsmasq”. It is a ‘lightweight’ DNS, DHCP, TFTP server, but for being “lightweight” has a few hundred levers to pull and settings to set. Now you can ignore 99% of them. But which 99%? Oh, you get to learn about a lot of the others to decide to ignore them…

Lucky for me, I’d already done some dnsmasq setup for my Pi Model B DNS server that blocks ads, so I wasn’t starting from scratch.

Then you get to the PXE Boot part… and again a hundred and one settings. Worse, some can be defaults, some are set in dnsmasq as forced options, or they can be set in various files and flags in the PXE tftp name space. Or some combination of all that. In short, at least 3 places you can set things and they interact. Lord save me from folks adding “feature creep” with multiple places to set ONE configuration. It just cries out “Confusion and conflicts ahead!”… here there be dragons…

So the major part of the workload is just cutting out a lot of that redundant, unnecessary, confounding, weedy crap and finding just what little bit DOES matter and where to get it.

Oh, and most of the path names for directory structure is user configurable so every web page has a different idea of what all the name space ought to be. This can lead to ‘leveling’ issues, and one bit me. Things ‘base’ off of where pxelinux.0 is located, and I got one of the things ‘off by one’ and put files/Puppy in a place that needed /Puppy… that was an hour or two.

So I’m going to leave out a lot of wandering in circles and sorting out useless complications and focus on “what does it take to get PXE up on a Raspberri Pi?” Suited for use with older hardware (i.e. not exploring how to make it ‘go’ with UEFI machines) and with Puppy in particular and direct booting live CD / DVD .iso’s without burning them to a CD.

Syslinux / pxelinux.0

This drove me around the bend for a while. Some pages saying to take it from Their Special Place and others complaining that some releases, like Ubuntu, seemed to have different versions or changed in some way. Others admonishing that all the bits have to match or Bad Things Happen. Since one end goal is to PXE boot some raspberry Pi images too, that they were all using x86 or AMD64 binaries didn’t please me. Since I was running this as server ON a Pi, compiling from source for the PC was not an option I wanted to follow. Many hours pondering and wandering in the desert followed… This is made much much worse by the way SYSLINUX, ISOLINUX and PXELINUX are freely intermingled in most of the pages and docs. All made by the same folks, with the clear dominant use being SYSLINUX as a generic boot loader. PXELINUX a ‘glue on’ afterthought. So you get to wade through dozens of pages of stuff about all sorts of irrelevant SYSLINUX features and options and requirements, only to find out PXELINUX may not need them. Thus the odd .c32 and related files still lying around in my current configuration. Likely not needed and I drug them in when things were NOT working to see if “maybe that will fix it”.

So, you get syslinux from here:


but only for the recent development version.

The latest official version of Syslinux can be downloaded in .tar.gz, .tar.bz2, .tar.xz, and .zip formats from kernel.org. This download includes both the source and official pre-compiled binaries that should work for most users (See also Official Binaries). Version changes are available in the .LSM files.

The Syslinux download includes PXELINUX, ISOLINUX and MEMDISK as well.

Official Testing versions (aka pre-release), when available, can be downloaded from:

It does have the helpful note:


At least SuSE, Mandriva, and Ubuntu use a version of SYSLINUX modified with a patch called “gfxboot”. This is a highly invasive and unsupported modification of SYSLINUX. Please avoid these versions if possible.

As of 2010-10-19, Ubuntu 10.10 (Maverick Meerkat) uses Syslinux 4.01 with GFXBoot.c32 (now officially included) and includes several special patches to allow gfxboot to use some configuration directives that were originally intended to be used only with the Simple Menu modules (menu.c32/vesamenu.c32). Some patches are upstreamed, but some of them might not.

So Ubuntu will be later in my PXE boot additions…

Then it sends you off to a different link to actually get the download you most likely want:


This kind of “wade through three things and four links to get to the actual place you wanted” is pervasive in the whole SYSLINUX / PXELINUX design and web pages and more. Royal PITA and clearly a difference between “bootloader people” and “UNIX guys”…

FWIW, there is a watershed at about 5.0 release. That’s where the whole UEFI extension was added. SYSLINUX breaks up into several different forks then and the files multiply like rabbits. Then you must pick the RIGHT version for your system. BIOS vs UEFI vs… and 32 vs 64 bit hardware. This, then, reflects into the PXELINUX area…

Despite that, I chose a recent 6.x release and and odd number (even are often ‘feature releases’ in the land of *nix and the odd releases ‘bug fixes’ for those features…) then download it. Copy it to the working directory for syslinux and unpack it. I chose the .gz compression version just because the .xz is not as easy to type… I also snagged a slightly older one, just in case. Unpacked with something like “tar -xvzf syslinux-6.03.tar.gz” it makes it’s own directory.

root@RaPiM2:/WD2/ext/pxelinux# cd syslinux
root@RaPiM2:/WD2/ext/pxelinux/syslinux# l

syslinux-5.10  syslinux-5.10.tar.gz  syslinux-6.03  syslinux-6.03.tar.gz

root@RaPiM2:/WD2/ext/pxelinux/syslinux# ls -l
total 19496
drwxrwsr-x 29 11341510     501     4096 Jun  4  2013 syslinux-5.10
-rw-r--r--  1 chiefio  chiefio  8281150 Jul 14 01:31 syslinux-5.10.tar.gz
drwxrwxr-x 33     1026    1026     4096 Jul 14 00:18 syslinux-6.03
-rw-r--r--  1 chiefio  chiefio 11671940 Jul 13 22:53 syslinux-6.03.tar.gz

Once you go inside, you find a nice dense forest of all sorts of stuff, almost all of it not what you wanted. Where’s pxelinux.0? Nobody seems to tell you…

root@RaPiM2:/WD2/ext/pxelinux/syslinux# cd syslinux-6.03
root@RaPiM2:/WD2/ext/pxelinux/syslinux/syslinux-6.03# l

bios	  core	 dos	  efi32      gnu-efi	   linux     mbr      mtools  sample	     version	 win64
codepage  devel  dosutil  efi64      gpxe	   lzo	     memdisk  NEWS    syslinux.spec  version.pl
com32	  diag	 dummy.c  extlinux   libfat	   Makefile  mime     now.pl  txt	     win6
COPYING   doc	 efi	  gen-id.sh  libinstaller  man	     mk       README  utils	     win32

Now if you happen to be an experienced sys admin, which is their target audience, no worries. But for the home gamer, it’s opaque. I poked around for about 5 minutes thinking I’d have good intuition about where it ought to be. No joy. Why? “Because a find is a terrible thing to waste!” of course! ;-)

root@RaPiM2:/WD2/ext/pxelinux/syslinux/syslinux-6.03# find . -name pxelinux.0 -print

Now in the world of Unix, naming ANY file “core” is a Very Bad Idea. IF you are running a program, and it crashes, it dumps a file named “core” in your present working directory. It is just asking for that file to be nuked. Here, they have a whole directory named “core”. Sigh. Any experienced sys admin or sys prog would generally presume that ‘core’ was a left over core file and ignore it. (I have no idea what happens if I’m running a program as ‘root’ and it core dumps AND there is a directory named ‘core’ in that space…)

Yet there it is. OK, snag a copy and put it in your PXEboot root tree…

Now at one time I thought I might need the lslinux.c32 file. Why? Because when attempting to PXEboot I’d get the DHCP done, and then the prompt menu, and then it would crap out saying it didn’t find ‘ldlinux.c32’. So I added it. And that didn’t fix it. I suspect a SYSLINUX error message from the boot process. I’ll be removing it later to see if it is really needed… BUT, in case anyone wants to know where to find it… My guess is that pxelinux.0 has that inside of it, but that the error message doesn’t know that. at any rate, changing the place where pxelinux.0 was located in the file system name space made boot work and the error message go away.

root@RaPiM2:/WD2/ext/pxelinux/syslinux/syslinux-6.03# find . -name ldlinux.c32 -print

The “elf’ is one “object file format” for assembler language. Others are a.out and more. They make several versions of ldlinux and you need the one for your object format, which they then name with the .c32 suffix and put in a com32 directory…

Similar find commands can be used to find any other bits you might need for whatever you choose to do…

The key take away here is just that you need to download this tarball and compile to get the one for the Raspberry Pi chip, or do a find to get the one for the right Intel chip and assembler combo for your PC hardware. (Learning that cost me about 4 hours…)


Originally I’d thought of setting up the Pi with a WiFi dongle and having it be the router to my WiFi network as well. Due to some bad behaviour at boot time with my WiFi dongle, I scrubbed that (at a cost of 1/2 a day…) All the more frustrating as this particular SD chip had been working as my emergency router to the hotspot… I suspect maybe a different dongle has confused it, or the wifi software was not happy booting without the hotspot in existence. At any rate, it was taking 1/2 hour or so to boot, so I just started turning things off. Unplugging the dongle, I got to where I could config it (and another few hours gone…) and took the easy way out. The old D-Link spare WiFi router from the parts box. I shut off DHCP on it, and use the Pi for DHCP. It also provides a “hub” function so the stand alone ethernet hub went into the parts box. (Who knows how much time saved… yeay!!)

Many of the ‘how to’ pages go out of their way to explore the intricacies of leaving your present router as your DHCP source via indirection configuration. As I wanted a very private network behind its own router, that didn’t interest me… but did keep getting in my face…

FWIW, this site has a nice write up for dnsmasq with ubuntu:


For the dnsmasq config, I’m just going to ‘diff’ the old and new. Realize that I’m still playing with “menus”. I’ve shut off the ones from dnsmasq, but not yet got the ones from files in the pxe-root working as desired. Oddly, this results in a boot prompt on the EVO where just typing “Puppy” works, as the pxelinux.cfg is ‘correct’ for Puppy.

This may have some artifacts and junk in it, but is still illustrative. The actual file has a LOT more lines in it (678) and most of them are comments or command commented out. Since dnsmasq handles all of DNS, DHCP, TFTP and PXE stuff, showing all that in one go is likely best. This is NOT an ideal layout, but is a test / working layout. Final production gets a cleaning and preening pass and the ‘pxe root’ will end up on a USB dongle as something like /PXE/boot_files.

For those unfamiliar with ‘diff’ output, it gives the line number of the change, then gives the ‘out’ and ‘in’ as angle brackets. Since wordpress will try to steal anything between those as HTML, Im changing them to O and I. This is showing what changed between the old basic dnsmasq config, and the one working now as a DNS, DHCP, TFTP and PXE boot server.

I MAKE NO REPRESENTATION THAT THIS IS IDEAL, OR EVEN VERY GOOD. It was “hacked together on the fly” as the base router when AT&T service suddenly died. I just “got it to work” and moved on. I’m sure there is plenty of tuning and preening that could be done.

This first batch mostly protects against some odds and ends of bad practice. Like not forwarding partial domain names for resolution (i.e. don’t do a DNS lookup ‘forward’ out of your network on ‘servername’ without a .foo.bar part) and don’t forward 192 and 172 and 10. block addresses) Lines with a # at the start, like “#resolv-file=/etc/resolv.dnsmasq” are commented out. This one shows where I was testing using an external file for my resolver listing of hosts names to kill, then changed my mind and went to ‘in line’ (see down below). Note that there is copious description of all of these in the dnsmasq.conf file, so I’m not going to explain them all here.

diff dnsmasq.old.conf dnsmasq.conf
O #domain-needed
I domain-needed
O #bogus-priv
I bogus-priv
O #filterwin2k
I filterwin2k
O #resolv-file=
I #resolv-file=/etc/resolv.dnsmasq
O #no-resolv
I no-resolv
O #no-poll
I no-poll

Here is my list of name servers. The old router had been, but that changed when it died. It looks like I need to take that out. is my Pi filtering DNS, while .254 is the AT&T box (that I likely ought to deprecate at this level). IF it gets stuck, it can go looking in The Big Bad World on the other servers. Due to Google being “Less Than Trustworthy”, I’ve commented out their server.

O #server=/localnet/
I #server=
I server=
I server=
I server=
I server=
I #server=
I server=
I #server=

Then, after a couple of ‘junk lines’ we get into the list of domains to ‘ground’ to my own local web server that just says “It Worked!” instead of a load of ads and tracking… This is a partial list…

I #server=/localnet/
O #address=/double-click.net/
I address=/website-error.com/
I address=/double-click.net/
I address=/.chartbeat.com/
I address=/packages-seo.com/
I address=/.doubleclick.net/
I address=/doubleclick.ads.com/
I address=/.pixel.quantserve.com/
I address=/.bluekai.com/
I address=/.ubertags.com/
I address=/.google-analytics.com/
I address=/.googlesyndication.com/
I address=/googleusercontent.com/
I address=/l.google.com/
I address=/.l.google.com/
I address=/.ads.google.com/
I address=/.googleapis.com/
I address=/.googletagservices.com/
I address=/.facebook.com/
I address=/.twitter.com/
I address=/amazonaws.com/
I address=/.amazonaws.com/
I address=/.moatads/
I address=/.microsoft.com/
I address=/.bing.com/
I address=/.medianetadvertizing.com/
I address=/.doubleverify.com/
I address=/.akadnds.net/
I address=/.gravatar.com/
I address=/.adnxs.com/
I address=/.advertizing.com/
I address=/.godaddy.com/
I address=/.adadvisor.net/
I address=/.adtechus.com/
I address=/.simpli.fi/
I address=/.amazon-adsystem.com/
I address=/.criteo.com/
I address=/.mathtag.com/
I address=/.adform.net/
I address=/.asdrvr.org/
I address=/.adsymptotic.com/
I address=/.chango.com/
I address=/.rfihub.com/
I address=/.sitescout.com/
I address=/.akadns.net/

Customize to my own domain name inside the office, and use the ethernet port for DNS DHCP.

O #interface=
I interface=eth0
O #expand-hosts
I expand-hosts
O #domain=thekelleys.org.uk
I domain=chiefio.global

This part starts DHCP services, sets up default routers and assigns address ranges. Numbers to be changed to whatever you use.

O #dhcp-range=,,12h
I dhcp-range=,,48h
O #dhcp-option=option:router,
I dhcp-option=option:router,
O #dhcp-option=42,
I dhcp-option=42,
O #dhcp-option=252,"\n"
I dhcp-option=252,"\n"
O #dhcp-option-force=208,f1:00:74:7e
I dhcp-option-force=208,f1:00:74:7e
O #dhcp-option-force=209,configs/common
I dhcp-option-force=209,configs/common

Here, DHCP starts to interact with PXE. I played with forcing the PXE root directory, but decided to leave it alone for now. Letting it default to the TFTP root (see below). The “pxe-service” lines force PXE menu lines for boxes of the type “x86PC”. They worked, but I’ve commented them out as I’m working on that files based menu config. For a first bring up, using lines like them is fine.

O #dhcp-option-force=210,/tftpboot/pxelinux/files/
I #dhcp-option-force=210,/WD2/ext/pxelinux/files
O #dhcp-boot=pxelinux.0
I dhcp-boot=pxelinux.0
O #pxe-service=x86PC, "Install Linux", pxelinux
I pxe-service=x86PC, "Run / Install Linux", pxelinux

Here we turn on TFTP service. “Someday” it will become shorter on that USB dongle…

O #enable-tftp
I enable-tftp
I tftp-root=/WD2/ext/pxelinux/files

I made cache size and timeouts bigger as I wanted more persistent DNS caching. Especially when it was routing over the WiFi Hotspot…

O #cache-size=150
I cache-size=10000
O # Normally responses which come form /etc/hosts and the DHCP lease
I # Normally responses which come from /etc/hosts and the DHCP lease
O #local-ttl=
I local-ttl=10000
O #bogus-nxdomain=
I bogus-nxdomain=

You might be wondering what that last line is about. I’m just going to quote the comments in the dnsmasq.conf file. It is a good exmple of their stuff anyway:

# If you want dnsmasq to detect attempts by Verisign to send queries
# to unregistered .com and .net hosts to its sitefinder service and
# have dnsmasq instead return the correct NXDOMAIN response, uncomment
# this line. You can add similar lines to do the same for other
# registries which have implemented wildcard A records.


Just shutting of yet another data leak…

Puppy In Particular

For Puppy, there is an added complication. Puppy uses an ‘odd’ structure where it writes out information to a .sfs file AND reads it in at startup. So when you get the kernel to boot, it still wants that file. It then proceeds to hunt for it on any disk it can find. To stop this, you must bundle it into the initial RAMdisk in memory. This page had a decent formula for it, but there may well be better. I followed a slightly different path, that also worked.


root@RaPiM2:/WD2/ext/pxelinux/files# pwd

Note that my prompt includes a listing of what directory I am in. I’m running as root (superuser) and the # shows that too. It saves a LOT of typing “sudo blah“.

root@RaPiM2:/WD2/ext/pxelinux/files# ls
ldlinux.c32  memdisk  Puppy  pxelinux.0  pxelinux.cfg

So I stuck a ldlinux.c32 here at one point, thinking it was the problem. It wasn’t, so likely needs to be removed. My ‘tftp’ directory is “/WD/ext/pxelinux/files” and that is where pxelinux.0 goes. In here is also the pxelinux.cfg directory where you put the directions for PXE to follow. I made a directory named ‘memdisk’ preparatory to the bring up of an iso image boot (later) and a Puppy directory for my particular Puppy release.

After editing the dnsmasq settings “this time for sure” you must restart it. This is a SystemV Init box, not Systemd. If running systemd, you are on your own for the service starting.

root@RaPiM2:/WD2/ext/pxelinux/files# service dnsmasq restart
[ ok ] Restarting DNS forwarder and DHCP server: dnsmasq.

Here’s what my owenership and permissions look like at present. They can likely be tightened up considerably, later. Perhaps via a PXEboot user who owns things…

root@RaPiM2:/WD2/ext/pxelinux/files# ls -ld .
drwxr-xr-x 4 root root 4096 Jul 14 01:34 .
root@RaPiM2:/WD2/ext/pxelinux/files# ls -l *
-rwxr-xr-x 1 root root 122308 Jul 14 01:34 ldlinux.c32
-rw-r--r-- 1 root root  26140 Jul 14 01:12 memdisk
-rw-r--r-- 1 root root  46909 Jul 14 00:09 pxelinux.0

total 2852
-rw-r--r-- 1 root root 1287530 Jul 13 16:45 initrd.gz
-rw-r--r-- 1 root root 1627180 Jul 13 16:45 vmlinuz

total 8
-rw-r--r-- 1 root root 257 Jul 14 01:14 default
-rw-r--r-- 1 root root 234 Jul 14 01:13 old.default

The “default” file in pxelinux.cfg directory is where you put your recipe of what is to be done. You can make dozens of layers of other recipes, too. Complicaions on complications. Just ignore them.

root@RaPiM2:/WD2/ext/pxelinux/files/pxelinux.cfg# df
Filesystem      1K-blocks       Used Available Use% Mounted on
/dev/loop0         103422     103422         0 100% /WD2/ext/pxelinux/Puppy
/dev/loop1         713980     713980         0 100% /WD2/ext/pxelinux/Knoppix
/dev/loop2         660480     660480         0 100% /WD2/ext/pxelinux/Debian
/dev/loop3         164418     164418         0 100% /WD2/ext/pxelinux/Slacko

To make things easier, I’ve mounted several CD .iso images as file systems. Lets me root around inside them if I like. You can also see what else is going into my PXE Boot server over the next few days ;-)

Here’s the /etc/fstab entries for those mounts:

# Mount ISO Images as disk                <<<<<<<<<>>>>>>>>>

/WD2/ext/pxelinux/isos/puppy-4.2.1-MULTIUSER-r3.iso /WD2/ext/pxelinux/Puppy udf,iso9660 ro,user,loop 0 0

/WD2/ext/pxelinux/isos/debian-7.8.0-i386-xfce-CD-1.iso /WD2/ext/pxelinux/Debian udf,iso9660 ro,user,loop 0 0

/WD2/ext/pxelinux/isos/slacko-5.7-NO-pae.iso /WD2/ext/pxelinux/Slacko udf,iso9660 ro,user,loop 0 0

/WD2/ext/pxelinux/isos/KNOPPIX_V7.0.5CD-2012-12-21-EN.iso /WD2/ext/pxelinux/Knoppix udf,iso9660 ro,user,loop 0 0

One must also make the directories as mount points, so here’s what the name space looked like after that:

root@RaPiM2:/WD2/ext/pxelinux# ls
Debian	files  isos  Knoppix  pup_421.sfs   Puppy  Slacko  syslinux  TESTING_menus

The iso images are in ‘isos’ and they get mounted on a directory with their name in it. The directory “files” is where I finally landed the start point for PXE boot (and likely needs to be ‘up leveled’ to a shorter path name in the final version). The directory ‘syslinux’ was where I unpacked the syslinux download to extract the needed file(s?). I’m still working on the whole menus thing, so they are set aside at the moment with the TESTING prefeix… That whole interaction of “menus from files” vs menus from dnsmasq… That “pup_421.sfs” file is just ‘passsing through’ on its way from the iso image to the ‘final initial ram disk’ that is accurate in an oxymoronic kind of way…

Essentially, this shows my workspace layout. Syslinux unpacked in one directory. Isos as isos in another. Mounted where it’s easy to rummage around in them AND they are inside the tftp export space if for some reason I need that. All the actual PXE working bits in the ‘files’ space as I whacked on it to to get it to go.

Here is where I went into the CD image and pulled out that .sfs file and moved it ‘up one’:

root@RaPiM2:/WD2/ext/pxelinux/files/pxelinux.cfg# cd /WD2/ext/pxelinux/Puppy/
root@RaPiM2:/WD2/ext/pxelinux/Puppy# l

boot.cat  boot.msg  help.msg  initrd.gz  isolinux.bin  isolinux.cfg  logo.16  pup_421.sfs  vmlinuz

root@RaPiM2:/WD2/ext/pxelinux/Puppy# ls /WD2/ext/pxelinux
Debian	files  isos  Knoppix  Puppy  Slacko  syslinux  TESTING_menus
root@RaPiM2:/WD2/ext/pxelinux/Puppy# cp pup_421.sfs ..
ls ..
root@RaPiM2:/WD2/ext/pxelinux/Puppy# ls ..
Debian	files  isos  Knoppix  pup_421.sfs  Puppy  Slacko  syslinux  TESTING_menus
root@RaPiM2:/WD2/ext/pxelinux/Puppy# cd ..

That way I’m not at risk of messing up anything. Yes, the iso is read only and mounted read only, but paranoia knows no bounds… so I made a copy (later to be deleted… scratch disk is free).

Next we go into that PXE files Puppy directory where you can see that I’ve already got a copy of the vmlinuz kernel and the initrd.gz initial RAM disk. Now we need to glue onto it that .sfs file…

root@RaPiM2:/WD2/ext/pxelinux# cd files
root@RaPiM2:/WD2/ext/pxelinux/files# ls
files  ldlinux.c32  memdisk  Puppy  pxelinux.0	pxelinux.cfg
root@RaPiM2:/WD2/ext/pxelinux/files# cd Puppy
root@RaPiM2:/WD2/ext/pxelinux/files/Puppy# ls
initrd.gz  vmlinuz

I’m going to do the work in /tmp. That’s on the SD card. It would likley be better to do it on the hard disk, but habit is comforted by the /tmp path name…

First we look around to make sure we are not doing to step on anything. Then make a working directory and do the “unpack merge repack’ on the intird.gz file. Again, I’m making copies so the original copies are intact. I’ll delete them later.

root@RaPiM2:/WD2/ext/pxelinux/files/Puppy# ls /tmp
cKpNC8hq.part  serverauth.J6jRRzXQn0  ssh-fmlNhwZBCwcw
root@RaPiM2:/WD2/ext/pxelinux/files/Puppy# mkdir /tmp/Puppy
root@RaPiM2:/WD2/ext/pxelinux/files/Puppy# pwd
root@RaPiM2:/WD2/ext/pxelinux/files/Puppy# ls
initrd.gz  vmlinuz
root@RaPiM2:/WD2/ext/pxelinux/files/Puppy# cp initrd.gz /tmp/Puppy
root@RaPiM2:/WD2/ext/pxelinux/files/Puppy# ls ..
files  ldlinux.c32  memdisk  Puppy  pxelinux.0	pxelinux.cfg
root@RaPiM2:/WD2/ext/pxelinux/files/Puppy# ls ../..
Debian	files  isos  Knoppix  pup_421.sfs  Puppy  Slacko  syslinux  TESTING_menus
root@RaPiM2:/WD2/ext/pxelinux/files/Puppy# cp ../../pup_421.sfs /tmp/Puppy
root@RaPiM2:/WD2/ext/pxelinux/files/Puppy# cd /tmp/Puppy
root@RaPiM2:/tmp/Puppy# ls
initrd.gz  pup_421.sfs

So this puts the two files that need a merge in one temp directory where I can play with them. We then make a working directory inside that one. Yes, you could cut out half of these copies and moves and still be fine. The original originals are still on the CD iso. But my habit of always flowing away from the pure source was set in Chem Class… you never back contaminate…

The process is pretty simple. The initrd.gz file is a compressed cpio archive. We uncompress it, take it out of cpio format, add the .sfs file, then put it back in a cpio archive.

root@RaPiM2:/tmp/Puppy# mkdir working
root@RaPiM2:/tmp/Puppy# ls -ld working
drwxr-xr-x 2 root root 4096 Jul 14 18:07 working
root@RaPiM2:/tmp/Puppy# chmod 777 working
root@RaPiM2:/tmp/Puppy# cd working
root@RaPiM2:/tmp/Puppy/working# mv ../initrd.gz ../initrd.gz_old
root@RaPiM2:/tmp/Puppy/working# zcat ../initrd.gz_old | cpio -i
3754 blocks
root@RaPiM2:/tmp/Puppy/working# l

bin  init  proc		 pup_ro1   pup_ro12  pup_ro15  pup_ro18  pup_ro20  pup_ro3  pup_ro6  pup_ro9  README.txt  tmp
dev  lib   pup_new	 pup_ro10  pup_ro13  pup_ro16  pup_ro19  pup_ro21  pup_ro4  pup_ro7  pup_rw   sbin	  var
etc  mnt   PUPPYVERSION  pup_ro11  pup_ro14  pup_ro17  pup_ro2	 pup_ro22  pup_ro5  pup_ro8  pup_z    sys

root@RaPiM2:/tmp/Puppy/working# cp ../pup_421.sfs .
root@RaPiM2:/tmp/Puppy/working# find . | cpio -o -H newc | gzip -9 > ../initrd.gz 
203970 blocks

That’s it. Now we swap that initrd.gz in for the old one. (At this point, I’d already gotten the PXE boot to try booting Puppy, but it failed on that missing .sfs file, so this whole process was after hitting that wall…) Again, my usual overly careful “move to the side don’t delete until the end” so I end up with two “old” copies (in addition to the one on the iso…), verfy all the files are where I think they are, then make the move. All this could be shortend to one move command.

root@RaPiM2:/tmp/Puppy/working# cd ..
root@RaPiM2:/tmp/Puppy# ls
initrd.gz  initrd.gz_old  pup_421.sfs  working
root@RaPiM2:/tmp/Puppy# ls /WD2/ext/pxelinux/files/Puppy
initrd.gz  vmlinuz
root@RaPiM2:/tmp/Puppy# mv /WD2/ext/pxelinux/files/Puppy/initrd.gz /WD2/ext/pxelinux/files/Puppy/Old_initrd.gz
root@RaPiM2:/tmp/Puppy# ls -l initrd.gz_old /WD2/ext/pxelinux/files/Puppy/Old_initrd.gz 
-rw-r--r-- 1 root root 1287530 Jul 14 18:03 initrd.gz_old
-rw-r--r-- 1 root root 1287530 Jul 13 16:45 /WD2/ext/pxelinux/files/Puppy/Old_initrd.gz
root@RaPiM2:/tmp/Puppy# ls -l
total 201716
-rw-r--r--  1 root root 102749687 Jul 14 18:13 initrd.gz
-rw-r--r--  1 root root   1287530 Jul 14 18:03 initrd.gz_old
-rwxr--r--  1 root root 102510592 Jul 14 18:04 pup_421.sfs
drwxrwxrwx 37 root root      4096 Jul 14 18:12 working

the actual move…

root@RaPiM2:/tmp/Puppy# mv initrd.gz /WD2/ext/pxelinux/files/Puppy/
root@RaPiM2:/tmp/Puppy# ls /WD2/ext/pxelinux/files/Puppy/
initrd.gz  Old_initrd.gz  vmlinuz
root@RaPiM2:/tmp/Puppy# ls /WD2/ext/pxelinux/Puppy/
boot.cat  boot.msg  help.msg  initrd.gz  isolinux.bin  isolinux.cfg  logo.16  pup_421.sfs  vmlinuz

Then I clean up by removing the stuff in /tmp.

root@RaPiM2:/tmp/Puppy# pwd
root@RaPiM2:/tmp/Puppy# ls
initrd.gz_old  pup_421.sfs  working
root@RaPiM2:/tmp/Puppy# rm -rf working/
root@RaPiM2:/tmp/Puppy# rm *
root@RaPiM2:/tmp/Puppy# ls
root@RaPiM2:/tmp/Puppy# cd ..
root@RaPiM2:/tmp# pwd
root@RaPiM2:/tmp# ls
cKpNC8hq.part  Puppy  serverauth.J6jRRzXQn0  ssh-fmlNhwZBCwcw
root@RaPiM2:/tmp# rmdir Puppy/

Again, all that could be shortened to “rm -rf /tmp/Puppy” in the blind… but I don’t like flying blind…

Then I clean up those excess “old” copies (after the PXE boot actually worked ;-)

root@RaPiM2:/tmp# cd /WD2/ext/pxelinux/files/Puppy
root@RaPiM2:/WD2/ext/pxelinux/files/Puppy# ls
initrd.gz  Old_initrd.gz  vmlinuz
root@RaPiM2:/WD2/ext/pxelinux/files/Puppy# rm Old_initrd.gz 
root@RaPiM2:/WD2/ext/pxelinux/files/Puppy# ls
initrd.gz  vmlinuz
root@RaPiM2:/WD2/ext/pxelinux/files/Puppy# ls -l
total 101936
-rw-r--r-- 1 root root 102749687 Jul 14 18:13 initrd.gz
-rw-r--r-- 1 root root   1627180 Jul 13 16:45 vmlinuz

CD .iso images for Live CDs

The next step will be getting a “Live CD” image to boot. I’m basically going to follow the guide here:


as it looks like a well written and clean process.

In the file /var/lib/tftpboot/pxelinux.cfg/default, add this menu entry. Replace the ISO and menu labels accordingly.

label wde
menu label WDE Recovery
root (hd0,0)
kernel other/memdisk
append iso initrd=other/SymantecEncryptionDesktop10.3.0MP1Win32_WDE_Recovery.iso raw

I’ve already got the memdisk part done, and it does boot memdisk, so all I need to do now is add the iso file in the append line.

Here’s my pxelinux.config file as of right now (note short on menu stuff…)

root@RaPiM2:/WD2/ext/pxelinux/files# cd pxelinux.cfg
root@RaPiM2:/WD2/ext/pxelinux/files/pxelinux.cfg# ls
default  old.default
root@RaPiM2:/WD2/ext/pxelinux/files/pxelinux.cfg# cat default
menu title PXE Boot Menu by EMS

label Puppy
	menu label Puppy
	kernel Puppy/vmlinuz
		append initrd=Puppy/initrd.gz method=nfs: lang=us keymap=us ip=dhcp noipv6

label memdisk
	menu label memdisk
	kernel memdisk

I’m not sure that “method -nfs” is actually doing anything at this time… it was another debugging attempt…

Still To Do

Clean it up. I’ve left all sorts of non-harmful but untidy bits laying around.

Get better files based menus working right.

Move the TFTP directory onto a USB Stick (so it doesn’t need a USB Hub to power the hard disk). For this, I need to empty one of my USB sticks… Most likely the PNY that isn’t too swift on writes, but is OK on reads. It presently holds a Centos copy that I was using with a Plop boot CD to run on the EVO, but that now I can’t get to reliably via that CD… So a prime candidate for PXE boot instead.

Assure it boots headless correctly so I can just power up and go without moving my monitor, keyboard, mouse etc. from my desktop Pi onto it. This will be my second “infrastructure Pi”, but one that doesn’t need to be “up” all the time so will need to take power on cycles in the blind.

Then write a script to rebuild one from scratch (and test it) without all the fumbling and drama. MUCH easier now that I’ve got a working copy. Oh, and I need to clone the Chip to disk as a backup while I’m at it…

But for now, I’m just going to “pop a cool one” (home brew cider ;-) and catch up on some web page reading and comments … maybe from that new Puppy running on the Evo ;-)

Subscribe to feed


About E.M.Smith

A technical managerial sort interested in things from Stonehenge to computer science. My present "hot buttons' are the mythology of Climate Change and ancient metrology; but things change...
This entry was posted in Tech Bits and tagged , , , , , , , . Bookmark the permalink.

16 Responses to PXE Puppy Working!

  1. E.M.Smith says:

    Well, I got menus to work. Seems there are a couple of binaries you need to have in the PXE-root area:

    root@RaPiM2:/WD2/ext/pxelinux/files# ls
    Debian	 ldlinux.c32  memdisk	menus  pxelinux.0
    Knoppix  libutil.c32  menu.c32	Puppy  pxelinux.cfg

    Those libutil.c32 and menu.c32 bits.

    Still haven’t tested if ldlinux.c32 is absolutely needed, but given that the others were, it likely is also…

    I got Knoppix to boot a kernel, but it goes looking for the rest of it’s brain on the hard disk and USB, not via the network. A bit more work there… Also Debian ISO booted, but it isn’t a live iso so didn’t give me a session, just an “Install?” question. Nice for large deployments, not very useful for headless thin client… As of now my pxelinux.cfg/default looks like:

    root@RaPiM2:/WD2/ext/pxelinux/files# cat pxelinux.cfg/default 
    DEFAULT menu.c32
    menu title PXE Boot Menu by EMS
    label Puppy
    	menu label Puppy
    	kernel Puppy/vmlinuz
    		append initrd=Puppy/initrd.gz lang=us keymap=us ip=dhcp noipv6
    label Debian
    	menu label Debian
    	kernel memdisk
    	append iso initrd=Debian/debian-7.8.0-i386-xfce-CD-1.iso
    label Knoppix
    	menu label Knoppix
    	kernel memdisk
    	append iso initrd=Knoppix/KNOPPIX_V7.0.5CD-2012-12-21-EN.iso method=nfs: lang=us keymap=us ip=dhcp noipv6
    label memdisk
    	menu label memdisk
    	kernel memdisk

    That “method=nfs” on Knoppix also seeming to do nothing… I’ve taken the similar bit out of the Puppy entry and it still works fine. Despite the keymap=us it still prompts me for keymap at Puppy boot… Clearly some OSs take options better than others…

    Note the “DEFAULT” line at the top. That tells the system to use that bit of code (menu.c32) for making the menu. It then goes looking for it “in the usual place” that seems to be the top of the tftp root / pxeboot_root area which I have set to /WD2/ext/pxelinux/files at the moment (but to become once on USB stick something like /PXE_boot

    At any rate, the menu now works, I’ve booted a few different images, and it’s down to working out the quirks of any given iso image behaviours (like that Knoppix thing… I don’t think I’m going to fit 700 MB into the initrd.gz like for Puppy, but it might work ;-)

    FWIW, where I found things in syslinux:

    root@RaPiM2:/WD2/ext/pxelinux/syslinux/syslinux-6.03# find . -name libutil.c32 -print
    root@RaPiM2:/WD2/ext/pxelinux/syslinux/syslinux-6.03# find . -name menu.c32 -print

    I used the ‘bios’ versions as I’m not running UEFI…

  2. p.g.sharrow says:

    @EMSmith; Not sure about how cute your “puppy” is. ;-) That menu looks like something I put on my 8088 PC-XT back in the early days of DOS. Kind of brought a chuckle…pg

  3. beng135 says:

    I nslookuped & got:


    Since you’re using it, I assume it has some particular asset?

  4. E.M.Smith says:


    Well, I think your dog is fat and your cat has fleas too! ;-)

    Yes, the menu is simplistic. First step is just to get something, anything, to work. I’ve now got a nice blue background and many more options. By end of tomorrow I’ll likely have a photo as my background and foreground graphics too… Now that I’ve learned that Fedora Live is a “no go” I’m going to be making nested menus for things that work vs don’t, with all the ‘do not go’ in one submenu. Development… it’s a process…


    The ad blocking DNS servers do what they say, take DNS requests for any ad sites they know of and nullify them to block ads. Essentially the same thing I do with my “black hole” list on my R.Pi server, and what “PiHole” does. Just a question of how far upstream the DNS request gets before it gets nuked. I nuke a bunch of very common ones on my own DNS server so they never hit the internet at all. (That mattered a lot more when running from the “pay by the byte” Hot Spot…)


    IFF I don’t have one in my list, it goes “upstream” and those ad block sites can block it. IF all else fails, I can let the DNS request go to a more “normal” server…

    I’ll likely, eventually, cut this particular list down to just the PXE server itself, and the Pi DNS server with filters (as it has the upstream servers in its config anyway, and would then cache that item for other users / other times that day).

    This list is significantly longer than needed, and has some systems that only work on some networks, as I had been moving this Pi around. On the AT&T network, on the 10.x.x.x lab network (now commented out), on the WiFi HotSpot, now on the 17.x.x.x PXEboot experimental network… Once it ‘has a single home’ I’ll prune out the other entries. For now, it’s nice to have it “just work” wherever it is with a way too long list of things to try…


    OK, a bit later… I was inspired to audit my list of DNS servers… Looks like one of the ad block servers is down (it is still listed on their web site, but nslookup didn’t find it…) so I’ve commented it out too:

    UPDATE: I discovered I’d “typoed” the address for the second adblock DNS. It starts with 198 not 192… so I’ve fixed it in the below text:

    # Add other name servers here, with domain specs if they are for
    # non-public domains.
    #server=  add block server, but down at the moment I'd miss typed 192 when it is 198
  5. E.M.Smith says:


    I had to put menu.c32 into the PXE boot directory to get menus to work. Here’s my present “default”. Like I said, “it’s a process”…

    root@RaPiM2:/WD2/ext/pxelinux/files/pxelinux.cfg# cat default 
    DEFAULT menu.c32
    menu title PXE Boot Menu from PiM2
    label Puppy
    	menu label Puppy
    	kernel Puppy/vmlinuz
    		append initrd=Puppy/initrd.gz 
    label DSL
    	menu label DSL
    	kernel memdisk
    	append iso initrd=DSL/dsl-4.4.10-initrd.iso
    label Debian
    	menu label Debian INSTALL
    	kernel memdisk
    	append iso initrd=Debian/debian-7.8.0-i386-xfce-CD-1.iso
    label Tails
    	menu label Tails NOT WORKING yet
    	kernel memdisk
    	append iso initrd=Tails/tails-i386-1.4.1.iso
    label Knoppix
    	menu label Knoppix NOT WORKING yet
    	kernel memdisk
    	append iso initrd=Knoppix/KNOPPIX_V7.0.5CD-2012-12-21-EN.iso method=nfs: lang=us keymap=us ip=dhcp noipv6
    label Privatix
    	menu label Privatix - Boot fails post initramfs
    	kernel memdisk
    	append iso initrd=Privatix/privatix_11.04.11_xfce_en.iso
    label Cryptonas
    	menu label Cryptonas - Boots, gives disk errors
    	kernel memdisk
    	append iso initrd=Cryptonas/cryptonas_0.3.5.iso
    label Fedora 
    	menu label Fedora NOT WORKING web site says won't work either.
    	kernel Fedora/vmlinuz0
    	append method=nfs: lang=us keymap=us ip=dhcp ksdevice=eth0 noipv6 initrd=Centos/intrd0.img 
    label Centos
    	menu label Centos - Not going to work per Fedora
    	kernel Centos/vmlinuz0
    	append method=nfs: lang=us keymap=us ip=dhcp ksdevice=eth0 noipv6 initrd=Centos/intrd0.img ramdisk_size=10000

    Note that Fedora says the way they do their LiveCD won’t work via PXE and I presume that CentOS, as a Fedora repackage, will have the same reason why it doesn’t work. I need to explore “other ways” to make them go… (unpack the files into a NFS disk etc etc.)



    The current LiveCD’s have no easy way to PXE/NFS boot a LiveCD.
    Currently the Fedora LiveCD’s pick up the file system from the squashfs image on the CD. It would be nice to have a feature that allowed us to load that image from NFS rather than the CD. That way we can easily PXE Boot the LiveCD without having to modify the LiveCD

    I know, I know, you would much rather this was all done clean and THEN I do a posting… but where’s the fun in that? At least this way you get to see that even well experienced guys have to run into a few walls, start over a few times, back off, learn something new, try again, then polish polish polish once it actually goes! ;-)

  6. E.M.Smith says:

    Oh, and one other nice use of a PXE boot server:

    You can have a ‘vanilla boring nothing done with it at all’ Windowz install on your desktop box, and at boot time hit the right Function Key (for your bios.. it varies) and tell it to PXE boot instead. Then, off in a closet or under a box in the garage, have your little Raspberry Pi PXE server that sends the OS to the box and has the NFS space where you keep files.

    Now somebody breaks in and steals your computer (in uniform or not…) they get a useless bit of fluff that is entirely innocent. With no evidence that it actually booted from somewhere else…

    “Yes officer, that is my computer. Yes, it is the one I use to browse the internet” is a true statement. They didn’t ask about the OS used… or the boot method…

    When traveling, or just when wanting to leave the house for a longish time, the Pi can be powered down and the USB / SD chip stuck in your backpack… so even a complete search has “nothing much” at risk. (Just don’t lose the backpack!)

    While this is substantially the same as using a Live CD / Live DVD release and putting your files on a USB dongle, it has the advantage of being remote and having nothing ‘near’ the machine to indicate that. IF there is a ‘surprise knock on the door’, a simple power-down makes all nice…

    One could make the USB / SD card encrypted, too, but then bringup can’t be headless… But you could have that rig in your office and on the same switched power strip as the desktop. Hit that switch, everything goes dark. (Though it might be found and the encription key demanded… which is part of why I like the ‘remote’ option… Oh, and “wireless network extenders” can bridge the gap between two wired segments of network, if you don’t want a ‘wire trail’…)

    Yes, this is all, still, part of my reaction to when Tallbloke got raided… But for a single choice by the “perp” as to whom he wanted to use to release information, I could have been the target of said raid… Since Tallbloke’s stuff was hauled away, and not given back for a loooong time, and then might be “buggered”, I’ve been moving my “stuff” onto disposible / remote / secure and just hard to spot or figure out gizmos and distributing the data stores to non-traditional places / methods. So go ahead, take my Pi, I can have a new one from Amazon next day. Take the SD chips. Have fun sorting out the dozen of them with 5 operating systems each (almost all vanilla, some encrypted, some with encrypted wads of data inside the file system). I have remote copies when needed, and anything I care about isn’t on them anyway… Or on the 2 desktop PCs.

    Frankly, I don’t really have anything of interest. Mostly a vast cannonical collection of Linux releases and more copies of temperature data of different eras than anyone sane would keep. Plus some backups of machines that died a decade+ ago… so anyone need a really really old copy of Windows 95 from a Toshiba Laptop? Yeah, like I said… But it’s MY collection of fine garbage bits! ;-) In a way, it would be kinda fun to be raided… I’d be very smug and snickery as I’d now their Forensics IT guy would be busy for months digging through piles of innocent trash. AND they could not just assume that a “Fedora.x.x.x.liveCD” file was in fact that, since some bits are in fact file systems in a file… so every file would need to be inspected. There are millions of them… My favorites being the encrpted boxes that inside contain “Congratulations! You’ve broken encryption on this container and know the password is: {Whatever it is}.” Nothing like spending a few days and a few $Thousand of computer time to break encryption only to find you’ve been played…

    What bored I.T. Security Guys do when stuck at home with nothing to protect… (Yes, I miss being in the game sometimes… catching Russian Hackers, placing calls to the F.B.I…. those were the days… Hey, Kid! Get off the lawn!! 9-)

  7. E.M.Smith says:

    Well, I moved everything in /WD2/ext/pxelinux onto the PNY usb stick, and it is mounted as /PXE so all the paths are much shorter. I then removed the hard disk, and the keyboard and mouse and anything else external and booted it headless. All is good.

    (I did have to change the path names in /etc/dnsmasq.conf and pxelinux.cfg/default…)

    It has now also booted up on a lower power (i.e. cheap) USB charger type power supply and is running fine.

    So at this point I’ll be doing any maintenance on it via a remote login. Essentially, now, it is “in production” for 3 different OSs and I’ve got some work to do to get the others to go right.

    It’s kinda cool to have a “tin of Altoids” sized computer as my boot server ;-) Now I just need to find a nice place to put it so I can get some desk real estate back …

    For the ‘reluctant’ LiveCD boots, I think they likely fall into two sorts.

    A) Need to stuff the squashfs into the initrd (hopefully…) like Puppy.

    B) Need to take an installed image from a disk “somewhere” and put that up via NFS, with the initrd and vmlinuz extracted to the server. (For those that are recalcitrant for non-squashfs reasons)

    For some, like that Cryptonas release, it quite likely is expecting me to have given it a disk to serve up and is confused by the environment at boot time. I didn’t really expect it to run “out of the box” and likely needs some SysAdmin TLC even in a normal install.

    At any rate, enough for now. From this point forward, it’s just “maintenance” to put up any given distribution of an OS and make it “go”. The multi-user version of Puppy has a very nice look and feel to it, so I’m pretty happy with it as the “boot and browse” or “boot and do secure stuff” system.

  8. E.M.Smith says:

    BTW, you can get ad block hosts files from several places, including sourceforge…



    so you put that in /etc/hosts and turn on use of /etc/hosts in /etc/dnsmasq.conf file.

    That is easier than converting 15000 lines of hosts file to dnsmasq formay/syntax.

    You can also get Windows versions (random site, not vetted)

    This one has an interesting listing of a Pi version… I’ve not read it yet


  9. E.M.Smith says:

    It helps to test the basics before you depend on them…

    This SD chip had been used for NFS before, so I figured it was working. It isn’t. Attempts to do a simple NFS mount from it to Puppy on a client fail.

    This is likely due to some iptables setting that doesn’t like the new network address range.

    This is also likely why various attempts to boot things using NFS configs that ought to work, failed. (Some of those marked ‘fail’ in my present menu…)


    OK, so I get to play with iptables and settings until a simple NFS mount works, and THEN come back to the issue of getting some of those iso systems to run…

    Note to self: Test basic service function and security settings before using…

  10. E.M.Smith says:

    Well, there was more to it than that…

    I actually discovered these bits in reverse of the below order, but this is the order in which they though ought to be done…

    Due to the particular way Raspbian starts and what it runs, portmap isn’t right. You have to make it right and then restart nfs-kernel-server… Turns out “I knew that once” likely about a year ago (a 2015 date stamp on the file), as I’d put a script on that chip to deal with it:

    root@RaPiM2# cat /usr/local/bin/nfsstart
    service rpcbind start
    /etc/init.d/nfs-kernel-server start

    But I’d not made it happen automagically at boot time. Now added to /etc/rc.local

    echo "Starting NFS Services from /etc/rc.local "

    Since it is now a fundamental service of the chip, not just a sometimes thing…

    But Wait! There’s More!

    Turns out “Puppy” Linux is “special” when it comes to NFS… rather than have “mount nfs” work, they have a Very Special Way…


    Now Puppy is slightly different from now on,

    – it has replaced the standard linux command set with one supplied by BusyBox. Busybox is smaller than the standard command set but has sacrificed some command functionality. One of the crippled commands delivered by Busybox is the ‘mount’ command; you can’t use it to mount a NFS share.

    – to over come this the Puppy developers have supplied a command called mount-FULL which is capable of mounting NFS shares.

    There are two ways to mount a NFS share in Puppy,

    – one off using the command mount-FULL from a command line or terminal window
    – permanently so that the share is available at every boot automatically.


    The ‘mount-FULL’ command looks like this for a nfs mount

    mount-FULL -t nfs /root/HBW


    -t specifies the type of mount, in this case nfs shared/directory on the server = the server IP and the directory to mount, something like /home/yourname/MyMusic
    /root/HBW = the directory on the client that maps to the server. When mounted if you use roxx and point it to this directory you actually see the contents of the server and you can treat it as if it was on your local machine.

    Which sometimes doesn’t work…

    Thanks for the great tutorial! Have set up My Ubuntu box as the server, and am trying to network my puppy laptop to it…

    Here is my command:
    mount-FULL -t nfs /root/Desktop/share

    I’m getting this error message:
    mount: unknown filesystem type ‘nfs’

    Any idea what I’m doing wrong? I’m running eeetiger, which is based on Puppy 3.01. Cheers!
    I find dinky’s problem described above very odd – I uninstalled my Dingo that got the successful mount script described above, so I couldn’t check it out, but now when I again installed Dingo on another machine (frugal and pupsave file), I get the same error message although I just repeated the command above (after adding /mnt/public in the file structure). I just don’t get what I did to get it working last time…

    BUT: in my research I found a thread about similar issues
    and after analyzing this I went to my bootmanager and added the kernel module ‘nfs’ to the list of modules to start. This didn’t solve the problem, but an icon called ‘File-sharing’ suddenly showed up in the home folder… when clicking on this, a little network scanner similar to pnethood showed up, scanned my network, found the share and I logged into it and got it mounted – and it is still there after reboot too… Very nice tool, but the question remains; why doesn’t the mount-FULL command work any longer? Very strange indeed… I somewhat wonder if I am watched by some sort of Update Manager… Wink
    Puppy 4.10 Dingo – no sugar added – but maybe a little piece of fat-free…?
    Back to top
    View user’s profile Send private message

    Joined: 19 Jan 2008
    Posts: 699

    PostPosted: Sun 05 Oct 2008, 19:38 Post subject:
    Echo above post… would also like to sort out the mount-FULL command, but more interested in getting the share going. Sould someone help me? Using Puppy 4 I found the same thing… once nfs was loaded, lovely little tool available as dscribed above. I think I’m having problems networking my Ubuntu server… have set up everything as above, and as described here: http://ubuntuforums.org/showthread.php?t=249889

    Using this command:
    mount-FULL -t nfs /root/Desktop/share

    Gives me this back:
    mount: RPC: Program not registered

    So that didn’t work. I think the above gui tool would have, but unfortunately I think my Ubuntu server isn’t configured correctly, I can’t see my share at all. Thanks.
    Can someone please give me a hand? Thanks

    At that point I just gave up on Puppy as my “test instrument” for NFS success and booted the EVO to Debian. Luckily, this time the video driver didn’t hang (it is sporadic when it locks up video…) so I was able to go ahead and debug NFS. In short, the mount worked. (Now I can go back and turn iptables back on and see if the rules I shut off were really the issue, or not…)

    I also moved the Arch Pi3 onto the same network for an easier debugging platform “Head station” for the headless P2…

    In doing an NFS mount to it, that ought to have been trivial, I kept getting “bad mount option” errors. As I’d copied the particular option list from a working mount to a different system, this jiggled a memory of when I was trying to get that old Version 2 NFS box to mount for data draining… The “New Improved!” NFS V 4 claims to do a handshake starting with V4, then V3 and then V2, but some boxes don’t seem to use the same hand for the shake…

    I had to add nfsvers=3 or nfsvers=4 or even nfsvers=2 to the NFS Mount line in /etc/fstab. That’s right, ANY of them work. But it just had to have one of them…. Something between Debian / Raspbian and the Arch box is not quite aligned on the handshaking…

    Like so:   /PXE    nfs    nfsvers=4,rw,defaults,nolock,noauto,noatime  0 0

    THEN I got the nfs mount to work…  30666880 10802176  18283776  38% /PXE

    So now I can use THIS headful box to do things like put iso images onto the PXE server, edit the menu and cfg files, etc. etc. AND I know that NFS is working at a glance, so can get back to that whole process of making NFS based PXE services work at PXE boot time… (hopefully without the PXE booting client running into a vers= issue…)

    I’d complain more, except it’s progress… Things are actually working better at each iteration. It just makes me a bit cranky when folks can’t follow (or write a decent…) RFCs and have backwards compatibility that works and have interoperable protocols that actually inter-operate or provide a decent debugging tool instead of having you “go fish!” at each level and test and retest every single basic part of a long long chain…


    Is it time to open an Apple Cider yet? Somehow a cold apple cider while laying in the sun in the garden is sounding a LOT better than whacking this keyboard…

    Back later… (how much depending on what’s cold in the ‘fridge ;-)

  11. E.M.Smith says:

    Strange how sometimes nostalgia has a run-in with change…

    I’ve been using the EVO as a target for “variety OS” things for a while now. I’m using it for this posting. It was my “Fast enough to like and quiet enough to not bother” box of choice for several years. The Pi, and even the Pi Model 2, were just not quite up to the task of replacing it.

    Now, booted into Debian (and past the ‘glitch’ point where the video driver sometimes locks it up) I’m using it as a “daily driver” for today… and finding it just a touch slower and less pleasant than the Pi Model 3, and with a less liquid video experience (to be expected, as ‘past the glitch’ the graphics are processed in the CPU instead of the GPU as that is the fallback…) and that ‘barely a whisper’ from the fan a tiny bit distracting…

    It seems that the Pi 3 has put me over the edge into “Pi Preference” land… and I’m no longer willing to accept the “compromise” of “almost” quiet… and 4 x 64 bit x 1.2 GHz cores beat one old 32 bit core even at IIRC about 2.4 GHz… something like that. Let’s check:

    chiefio@EVOdebian:~$ cat /proc/cpuinfo
    processor       : 0
    vendor_id       : GenuineIntel
    cpu family      : 15
    model           : 2
    model name      : Intel(R) Pentium(R) 4 CPU 2.40GHz
    stepping        : 7
    microcode       : 0x1d
    cpu MHz         : 2399.544
    cache size      : 512 KB
    fdiv_bug        : no
    hlt_bug         : no
    f00f_bug        : no
    coma_bug        : no
    fpu             : yes
    fpu_exception   : yes
    cpuid level     : 2
    wp              : yes
    flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up pebs bts
    bogomips        : 4799.08
    clflush size    : 64
    cache_alignment : 128
    address sizes   : 36 bits physical, 32 bits virtual
    power management:

    Yes, 2.4 GHz.

    Given that I’d done a speed test of the Model 2 against the ASUS / ANTEK that came up a wash on CPU intensive things, and now subjectively the EVO is “relatively slow”, it is an interesting realization moment for me. I no longer like the Intel based desktop machines…

    Big, noisy (Antek sounds like a room fan…), and with nothing “extra” to offer over a Pi Model 3 desktop…

    Yes, I know, I could go out and buy a SuperD-Duper New Giant Game Station Intel Wiz-Box!! and have a whole lot faster… but why? What I have does everything I need… Once you have: Browser, Email, Graphics Edit, Word / Calc / Office Stuff, Video and Music… I’m running out of things I need and don’t have.

    I suspect this portends “problems ahead” for Intel and Microsoft…

    For a “small company” I could set up all their core services on a dog-bone case stack of Pi boards and the hardware cost would be about $800. ( I know because I used rack mount generic PCs of about that same power to set up a 200 person company’s infrastructure using Linux a dozen or so years back… but now instead of $1000 a box it would be $40 / card…)

    Desktops for most folks would be fine with this level of computes. For doing email and editing documents, it’s fine, and that is all that most folks really need to do at work.

    Makes a fellow go “Hmmmm……”

  12. p.g.sharrow says:

    It appears that the Pi might be the new IBM-PC paradigm. A little computer that can be used for everything. The firmware/software is the tool and the Pi is the handle. Just change the SD card and a different tool is the result…pg

  13. E.M.Smith says:

    Oh, and to assure cache action that commented out “#server=” ought to have the # removed and have it made active to look to itself for lookups first. Also, if you dhcp to get the address for your Pi server (probably a bad idea unless you have a few interfaces…) the dhcp interface ought to have prepended:

    root@RaPiM2:/etc/dhcp# cat dhclient.conf 
    # Configuration file for /sbin/dhclient, which is included in Debian's
    #       dhcp3-client package.
    # This is a sample configuration file for dhclient. See dhclient.conf's
    #       man page for more information about the syntax of this file
    #       and a more comprehensive list of the parameters understood by
    #       dhclient.
    # Normally, if the DHCP server provides reasonable information and does
    #       not leave anything out (like the domain name, for example), then
    #       few changes must be made to this file, if any.
    prepend domain-name-servers;

    Which likely only matters if you are, say, using the ethernet for DNS serving and the WiFi on a Pi Model 3 for upstream connection or similar “more than one network” activity…

    I’ve not noticed any difference myself, and was playing with it, but the “how to” pages say you ought to have set up that way…

    Then again, I’ve got two levels of DNS cache on my Pi 3 desktop. Self, and Pi B to the world. Three levels on the PXE network: Self, PXE server, Pi B to the world. So the odds of any address being cached on the LAN is quite high in any case (once used one time…)

    Useful page here: https://wiki.debian.org/HowTo/dnsmasq

    But, for completion, now you know ;-)

  14. E.M.Smith says:


    Interesting metaphor…

    Rather like those portable power tools where the battery / motor is one chunk, and you change the head to be a drill, saw, whatever… The Pi is the motor kit, the grip / head is the SD card…

  15. Pingback: Windowz PC Sales Drop, Apple Rises – Linux? | Musings from the Chiefio

  16. E.M.Smith says:

    The second ad-block DNS server was mis-typed. I’d had “192” where it ought to have been “198” like this:


    I’ve fixed it in the comment above, and in the original article. And verified it:

    [root@ARCH_pi_64 chiefio]# nslookup
    Non-authoritative answer:	name = dns1.alternate-dns.com.
    Authoritative answers can be found from:
    242.101.198.in-addr.arpa	nameserver = ns2.rackspace.com.
    242.101.198.in-addr.arpa	nameserver = ns.rackspace.com.
    ns.rackspace.com	internet address =
    ns2.rackspace.com	internet address =

    It’s the little things that take the longest to spot…

Comments are closed.