Entries tagged pxe

Related tags: birthday, dnsmasq, eee pc, eepc, gargoyle, gpxe, lenny, linksys, router, wrt54gl.

My router serves Debian installer via gPXE

Sunday, 25 July 2010

My Linksys router now serves the LAN with netboot images, allowing the simple installation of Debian GNU/Linux.

I updated /etc/dnsmasq.conf on the router itself to read:

# gPXE sends a 175 option.
dhcp-match=gpxe,175

# serve the "undionly.kpxe" file by default.
dhcp-boot=net:#gpxe,undionly.kpxe

# which will then pull the config via HTTP
dhcp-boot=http://static.steve.org.uk/netboot/gpxe.cfg

Then placed /tftproot/undionly.kpxe in place on the router. This combination of files causes:

  • The machine to netboot via undionly.kpxe (think of this like pxelinux.0.)
  • The file gpxe.cfg to be fetched via HTTP
  • Which in turn loads a simple menu.conf file, again via HTTP
  • At this point the user can select the flavour of Debian installer to run.

I have only one problem - it seems that adding the expected entry to boot locally fails:

MENU TITLE Netboot

LABEL Local.Disk
   bootlocal 0

Update: After a fresh sleep and more trial and error I discovered this works:

LABEL Local.Boot
   KERNEL local/chain.c32
   APPEND -

It gives a temporary warning about invalid sector number - but actually does boot locally by default, on both my EEEPC and my desktop machine.

If you want to snarf my netboot environment you are welcome to mirror :

Why did I do this in the first place? I wanted to install Squeeze upon my EEEPC (now done.)

ObQuote: Nice Cross. How'd you get the blood off?

- Dead Like Me

| No comments

 

My Linksys router now runs Linux and almost provides PXE.

Thursday, 22 July 2010

I've been interesting in running Linux upon my router for a long time, but I never had a really compelling reason to do so. The potential for brickage was always too high to make me want to experiment for the sake of it.

However last night I installed Gargoyle upon my Linksys WRT53GL. Although I have no single compelling reason to do so there were a few things on my mind which made me risk it:

Syslog

I thought it would be nice to log things to my desktop machine.

QoS

I often run rsync to mirror my photographs, videos, and files, to off-site locations. These are then replicated via chironfs.

Being able to use QoS to prioritise SSH traffic, which is the transport I use for rsync, means I don't suffer from laggy connections.

Graphing & Statistics

Having statistics and traffic information is interesting.

Since I've only just installed it I've not had too much opportunity to experiment with it - and my initial forays were not so productive. For example "opkg install tcpdump" failed as the root filesystem wasn't big enough.

However which was to update the router to function as PXE server. I installed the tftpd server:

opkg install tftpd-hpa

Then I added this to /etc/dnsmasq.conf:

dhcp-boot=pxelinux.0,router.my.flat,192.168.1.1

Only after I'd done this did I realise two things:

  • I don't have the space on the router to host the pxelinux.0 file, and the associated Debian netboot installer.
  • Chances are I could just use the built-in TFTP support of dnsmasq. ("enable-tftp" + "tftp-root=/tmp/tftproot".)

Tomorrow, (after visiting the dentist. Uggh) I will experiment with this further. Right now it looks like I have two options:

  • NFS mount the TFTP root, but keep both DHCP+TFTPD running upon the router.
  • Configure the router to load the files from another machine, by updating dnsmasq.conf to read: dhcp-boot=pxelinux.0,random.host.name,192.168.1.xx.

Either way I have to store the files upon another host, due to the constrained space on the router's filsystem. So the question becomes "Which service should I run externally: TFPTD or NFS?".

Running TFTPD, upon my desktop, seems smaller, less of a security risk, and neater. Running TFTPD also avoids issues if I reboot both the router and my desktop at the same time as a stalling NFS mount could prevent a timely router-boot.

ObQuote: Looking for a secret door. Places like this always have a secret door.

- St Trinian's 2: The Legend of Fritton's Gold

| 8 comments.

 

Oh my God, someone ate my entire pie!

Wednesday, 11 March 2009

Yesterday was my birthday, and it was full of cookies, pies, magical pixie dust and things made entirely of sugar and spice!

The remainder of the day was spent re-installing Debian Lenny upon my EEE PC - Somehow I managed to completely screw the system.

Because the EEE PC is one of those ultra-portable machines I mostly used it when I was travelling, or outdoors. That mean I was generally receiving poor connectivity and the system packages weren't up to date.

While I was in bed I figured I'd dist-upgrade it to the recently released Lenny. Unfortunately I started the dist-upgrade inside X.org, once I realised this I figured I'd cancel the operation via Ctrl-c.

Bad news everbody: I think I was unlucky enough to interrupt an upgrade of libc, or something equally critical. Every single application gave segfaults afterward.

I had two open root terminals and I could navigate around via cd .., and "echo *", but all other commands such as sudo, dpkg, strace just gave segfaults. (Even static commands gave errors - so it might have been the dynamic loader that was borked, I admit I didn't look too closely.)

I figured reinstalling would be a good solution since the machine has a 4Gb root partition and /home was stored on a separate 16Gb volume. Unfortunately I managed to misjudge the installer's partitioning step and nuke the partition table on the external volume so I ended up losing the whole system.

Happily reinstallation was a breeze as my home network is setup to allow installation via PXE network booting (at some point I should document NFS-root PXE-booting). It took me longer to fiddle with the BIOS on the EEE PC to allow network booting than it did to complete a minimal install. Which I guess is good.

I still need to restore my backup of /home/, but that can wait a few days. Right now I'm loathe to touch the machine at all - although I did distract myself by getting KVM to PXE boot:

# create 4gb disk image
dd if=/dev/zero of=/tmp/img.img bs=1024 count=4096k

# launch KVM
sudo kvm -no-acpi
  -boot n -tftp /var/lib/tftpboot/ -bootp /pxelinux.0
  -hda /tmp/img.img
  -net nic,macaddr=00:0E:35:be:de:ad  -net user

It seems that KVM wants to have access to the local TFTP root directory so I just pointed it at that. Since my desktop machine is also my TFTP + DHCP host that works out nicely. (A quick scan of the manual suggests that QEMU/KVM has funky built-in TFTP code, so it doesn't actually forward TFTP requests over the network.)

DHCP requests were certainly passed around as expected though and were answered via my local dnsmasq installation. I did see errors at every DHCP request in syslog, but they seemed harmleess enough:

gold dnsmasq[29241]: no address range available for DHCP request via qemu0

*shrugs*

ObFilm: Never Been Kissed.

| 1 comment.

 

Recent Posts

Recent Tags