Before I start: NO, UNLIKE EVERY OTHER ARTICLE ON THE WEB, PUBLISHED TODAY, THIS IS NOT A JOKE, K?!?

I’ve been looking for a new distro recently. I do this from time to time, principally because I get bored of what I’m currently running. Last time it was Crunchbang which I settled on. This time I wanted to go more advanced, so I started researching Arch Linux.

For those that don’t know, Arch Linux describes itself as:

…a lightweight and flexible Linux® distribution that tries to Keep It Simple.

I’d heard about Arch in the past from several sources and had heard that you basically have to install and configure everything yourself, but that the package manager (awesomely named Pacman!) manages software without having to compile from source (unless you want to!).

The following series of posts will be a record of my experiences installing and configuring Arch on my home desktop machine. This isn’t intended to be an exhaustive installation guide, more just a record of where I tripped up in order to aid those who come next. If you are searching for an installation guide, try the excellent article on the Arch Wiki.

I’ve separated the post out into days. Note: it didn’t actually take me a full day for each part, I work during the day and only really had a couple of hours each evening to spend on this.

Day 1: Backing Up

Before installing I wanted to make sure I didn’t trash my existing Ubuntu system and all my personal data, as I still need to do all the stuff I usually do with my machine. So I made a backup.

I’m not really going to go into how. Suffice to say I used LVM snapshots and rsync, I might write about this in a future post.

This took a while, as I have quite a lot of data. I thought it best to have a beer in the mean time, so I did.

Day 2: Making Space, Starting the Installation and Various Adventures with LVM

The next thing to do was to resize my existing LVM partition containing Ubuntu so that I had space for Arch. I couldn’t work out how to do this at first as none of the partition tools I tried (GParted and Cfdisk) could resize the partition. I eventually worked out how to do it.

First, on my running Ubuntu system I resized the physical volume with:

$ pvresize --setphysicalvolumesize 500G /dev/sda1

This shrank the space used by LVM down to 500GB (from about 1000GB on my machine).

I then rebooted into the Arch live CD (64-bit edition in my case), and ran:

$ fdisk /dev/sda

Now what you have to do next is slightly alarming. You actually have to delete the partition and recreate it in the new size. This works, without destroying your data, because fdisk only manipulates the partition table on the disk, it doesn’t do any formatting of partitions, etc.

I did this through fdisk so that the partition was 501GB (making it a little bigger than the PV just to make sure). I then rebooted back into Ubuntu and ran:

$ pvresize /dev/sda1

To allow it to use all the space. This probably isn’t necessary but I wanted to be safe.

Next, I proceeded to the installation. For some reason the Arch boot CD was really slow to boot and gave me loads of read errors, I think this might have something to do with my drive as I’ve been experiencing the same with other disks. Eventually it booted and dropped my at the default prompt.

From then I basically followed the installation guide for setting up the package source (CD) and the date and time.

I then set about partitioning the disks. The Arch installer uses Cfdisk, which is fine. I just added two partitions to my disk, a small (255Meg) one for my /boot partition and a large LVM one for the rest of the system (I like LVM and wanted to use it again on Arch).

This was fine, but I had some problems setting up the LVM through the installer, even though the user guide seems to think it can do it. Every time I tried, it would just fail on creating the Volume Group, weird.

I gave up for the evening and (you guessed it) went for a beer!

Day 3: Successful Installation

The next day I thought I’d try googling for LVM on Arch, luckily when I got in to work @duffkitty on identi.ca had seen one of my posts complaining about having problems and had given me a link to the LVM article on the Arch Wiki.

This advocated setting up the whole LVM setup manually (and guides you through it) and then just setting the partitions to use in the installer. It also gives you some important things to look out for when configuring the system. Following these instructions worked like a charm and I was able to format everything correctly and install the base system.

I then moved on to configuring the system, following the install guide and taking into account the instructions in the LVM article. Everything went pretty much fine here and I eventually got to installing the bootloader. Here I replaced the Ubuntu Grub version with the one installed by Arch. This left me having to add an entry for Ubuntu, which wasn’t difficult, I just copied the Arch one and changed the partition and file names.

Then it was time to ‘type reboot and pray’ as the Arch installation guide puts it.

So I did.

When I rebooted the bootloader came up with the Arch and Ubuntu entries. I selected Ubuntu just to check everything was OK.

It didn’t work.

Panicking and Swearing Ensued.

I rebooted and selected Arch.

That worked (thankfully).

When it had booted I logged in and opened up the Grub config file again. it turned out I mis-typed the name of the Ubuntu initrd file, that was easily fixed. Rebooting got me safely back to Ubuntu.

So now I have a functioning dual boot between my original Ubuntu install and a very basic Arch install, I think I might need some software there!

But first… beer.

So What’s Next???

Well, firstly I need to get my network connection up and running as I didn’t do that during the install. It’s a Wifi connection over WPA so that’s going to be fun. Then I can start installing software. I’ll probably follow the Beginners Guide on the Wiki (from Part 3). I was also recommended Yaourt by @duffkitty, so I’ll give that a try.

I’ll be continuing to play with Arch over the next few days and reporting my progress in follow up posts here. I’ll also be denting as I go along and you can follow all of these on my #archrob hash tag.

There’ll probably be beer too.

We’ll see how it goes, but eventually I hope to have a system I can use full time.

Bye for now! Happy Easter!

In the Electrical and Computer Engineering Deaprtment of the University of Auckland, where I work we have a little device, internally known as the ‘DonKey’. The purpose of this is to allow easy programming of Atmel AVR based microcontrollers via USB, rather than the simpler serial interface. We also have some internally developed software to program microcontrollers via the device, unfortunately this software is pretty much windows only (we did have a successful attempt to compile it for Linux, but this was quite a while ago, a better solution would be to use a native Linux application).

Internally the DonKey uses an FTDI based USB to UART chip (specifically the FT232R) to communicate with the microcontroller. This presents some problems as, despite being the basis of the programmer on incredibly popular Arduino boards, the main Linux programming tool (AVRdude) has no official FTDI support. I think this is largely due to the use of a bootloader on the Arduino boards, which negates the need of the programming tool to directly flash the board. If however you brick the AVR on the Arduino, you would be out of luck and would need a physical programmer (more on this below).

The DonKey in all it's glory.

In this howto I’ll cover how to get the DonKey working on Linux with AVRdude. Luckily, while researching how I might go about this I found that a large part of the work had been done for me, due to the fact that the Arduino also uses these chips. I found instructions on doswa.com on how to patch and compile AVRdude for just this purpose (so you could flash a bootloader to a new AVR).

These instructions work quite well for the DonKey, up until you get to running the ‘./configure’ command, I replaced this with:

$ ./configure --prefix=$HOME/.local

to setup the code to do a local install in my home directory (as I want this to be my primary version of AVRdude, but not to screw with things on the root filesystem).

Next I followed the instructions on modifiying the makefile and compiling AVRdude via the ‘make’ command. After ‘make’ I also typed:

$ make install

to install into the directory setup earlier. Now AVRdude is installed, the next thing to do is a bit of configuration, firstly you’ll want to make sure it’s on your $PATH so add the following to your ~/.bashrc file:

export PATH=$HOME/.local/bin:$PATH

and run the command:

$ source ~/.bashrc

to re-read the file.

The next issue is that you may wish to remove any copy of AVRdude that is otherwise installed (I found that sometimes my shell would run the wrong one – especially if you use ‘sudo’ to run it):

sudo apt-get remove --purge avrdude

Now, I just mentioned above that you might use ‘sudo’ to run AVRdude, well according to the doswa article you do need to use sudo when using the FTDI based programmers. I’m not sure why this is, but it’s not very useful if you want to be able to call AVRdude from a Makefile or the like.

I solved this by setting a ‘suid root’ on my AVRdude binary. For those that don’t know what this is, the suid bit is a Unix permission setting that makes any program with it run under it’s owning user rather than the user who called it. If the owner happens to be root, the program runs as root even if the user who calls it isn’t. This is probably really insecure if you do it a lot, but you should be OK in this case.

WARNING: Despite what I say, it might not be OK. Allowing any program unrestricted root access has the potential to hose your system and scatter all your data to the winds. FOLLOW THESE INSTRUCTIONS AT YOUR OWN RISK!!

So here we go:

$ sudo chown root:root ~/.local/bin/avrdude
$ sudo chmod u+s ~/.local/bin/avrdude

Now you should be able to successfully run AVRdude on FTDI based devices without resorting to using sudo every time.

But, what of the DonKey I hear you cry! Well all we have to do to support the DonKey is give AVRdude a little bit of configuration which tells it what the DonKey actually is. This can go in ~/.avrduderc, and looks a bit (well exactly) like this:

programmer
id = "donkey";
desc = "University of Auckland ECE DonKey";
type = ft245r;
miso = 1; # D1
sck = 2; # D2
mosi = 3; # D3
reset = 4; # D4
;

OK, now you should be able to successfully use the DonKey with AVRdude, using a command similar to this:

avrdude -c donkey -p m8 -P ft0 -U myawesomeavrproject.hex

Note: this command is for the ATMega8 as denoted by the ‘-p m8′, check the AVRdude manual page for the correct -p option if you are using a different type of AVR.

OK, well that’s pretty much it, I’ll post back soon regarding my other progress with some microcontroller stuff. Bye for now!

The main piece of software you will need is dnsmasq, which you can install with the command:

sudo apt-get install dnsmasq

I already had this installed as I’m using it as a DNS cache for my network (which is also pretty useful). It turns out that dnsmasq is a bit of a ‘swiss army knife’, it can do DHCP, DNS and TFTP all together and very easily. You should edit the config file:

sudo nano /etc/dnsmasq.conf

And add/uncomment/edit the following lines:

dhcp-range=192.168.1.3,192.168.1.50,12h # sets the ip address range and update frequency for the network
dhcp-boot=pxelinux.0 # set up network booting to boot the pxelinux bootloader
enable-tftp # enable built in tftp server
tftp-root=/var/tftpd # set tftp directory

Basically this sets up dnsmasq to be both the DHCP server for the network and push the PXE boot options out over the network. It also enables the built in TFTP server in dnsmasq and sets the directory to serve files from.

The next step is to get some files to serve, I got the PXE/netboot image from the Ubuntu cdimages site, and untarred the files to the correct directory:

wget http://archive.ubuntu.com/ubuntu/dists/jaunty/main/installer-i386/current/images/netboot/netboot.tar.gz
sudo mkdir -p /var/tftp
tar -xvzf netboot.tar.gz -C /var/tftp/
chown -R nobody:nogroup /var/tftp

The tar file of course is basically just the minimal install CD, set up for netbooting, so when you install you will need to download all the packages, for a simple cli install this doesn’t take very long, and you can use a package cache or something to help with future installs.

OK, now restart dnsmasq:

sudo /etc/init.d/dnsmasq restart

…and you should be good to go (make sure that your machine is the only DHCP server on the network). For tips on booting clients see my original article – btw, since I used the new version of Ubuntu I can now boot my Eee PC 901 over the network!

If you have any questions or problems with this I’d be happy to answer them, just post them below.

Bye for now!

A while ago my boss came to me with an idea. He wanted to purchase a number of netbooks and install LimeSurvey on each of them to be used as a mobile survey unit, that could be taken to schools, colleges, workplaces, etc. and used to collect data for research projects. I pointed out that if we were to install LimeSurvey on all the netbooks each would need an individual webserver and MySQL server, which apart from being a lot of effort would fragment the dataset and make it much more difficult to collect the data together.

Hence, I suggested that we setup one of the machines as the server and set it’s built-in Wifi to work as an access point for the others so they could access the server. This means that no external network access is required, you carry the server with you!

Well, today the netbooks arrived (we ended up with Acer Aspire Ones in the end). So I set about configuring one to be our server. This model came with Windows XP pre-installed (not sure if you can get a Linux version), but also had a 160GB hard drive. My instinct was to install Ubuntu Server as it has an option to deploy a LAMP server out of the box (which is awesome and would have saved me loads of time). So I downloaded it from our local mirror and flashed the iso to my usbstick with Unetbootin, which I hadn’t used before. I booted from the usbstick and everything went well until I got to the ‘detect CDROM drives’ bit – which usually detects the usbstick as containing the files from the iso. Not so here, no matter what I tried it wouldn’t be convinced that the usbstick was a CDROM!

So, I fell back to what I have previously used, Isotostick, a nice little shell script thats always done this well for me. Same problem.

Turns out the problem is with the server and alternate isos of Ubuntu, which don’t contain the correct FAT driver for loading the installation packages from a usbstick. There is a workaround for this, here, but I couldn’t get it to work. So, I decided to use the Ubuntu Desktop version (thank God our mirror is internal to the university!). I realised later that this had the advantage that the server could also be used as a client and the server software would be invisible to the user.

So I installed that. Which went fine as you’d expect. When I rebooted after the install I found that the wifi didn’t work. A quick google turned up a page which gave instructions on how to install the latest madwifi driver from source, which I did, though I had to manually dig up build-essential (and dependancies) from the /pool folder on my usbstick and install them with dpkg as I couldn’t get it to recognise the usbstick as an apt repository. I wouldn’t have had this problem if I’d have had a wired connection on the machine though.

Then I set about installing the packages required to turn it into a server:

$ sudo apt-get install apache2 phpmyadmin mysql-server dhcp3-server bridge-utils

I’m not sure whether the bridge-utils package is strictly required, but I installed it anyway. It doesn’t do any harm as it’s only a few kB to download. If you are following this as a howto and are only using the Wifi as your net connection (as I was), make sure you install all of this now as later on you’ll lose your connection when we setup the Wifi to be an access point. If you’re on ethernet, you’ll be able to keep your connection (but see later).

Installing those packages took a while over the Wifi, so while it was going on I downloaded and installed LimeSurvey. I don’t really need to say how to do that as it’s all documented on their site. I unpacked it to /var/www/survey on the server and configured it as per the instructions. Once I had all the packages above installed I was able to create a database and user through phpmyadmin and run the LimeSurvey installation script. Pretty much the same as installing any other PHP app.

Next came the wifi setup, I played around for a while trying to get this working, but I think the following is probably the best course to take in setting this up. You need to start by putting the wireless adapter into access point/master mode, you do this (for the atheros card used in the Aspire One) by editing/creating the /etc/modprobe.d/madwifi file (documented here):

$ sudo nano /etc/modprobe.d/madwifi

The file contents should be:

options ath_pci autocreate=ap

Then reload the kernel module:

$ sudo modprobe ath_pci

You’re then ready to reconfigure the network interfaces, if you type iwconfig, you should see that the ath0 device now has the capability to act as an access point. To setup the access point you need to edit the network interfaces file:

$ sudo nano /etc/network/interfaces

The contents of my file were as follows:

auto lo

iface lo inet loopback

# uncomment the following two lines if you’re on ethernet and you want to still have a connection once you restart the networking!

#auto eth0

#iface eth0 inet dhcp

auto ath0

iface ath0 inet static

wireless-mode master

wireless-essid my-access-point

address 192.168.1.1

network 192.168.1.0

netmask 255.255.255.0

broadcast 192.168.1.255

This sets up the network interface acting as an access point with name ‘my-access-point’ and assigns the local machine a static address of 192.168.1.1 on the network. To reload the configuration, do this:

$ sudo /etc/init.d/networking restart

Note: at this point you will lose ‘outgoing’ wifi connectivity as your adapter is now acting as an access point!

Now, if you boot up another machine with Wifi, you should be able to see the ‘my-access-point’ network in the list of available networks. However, connecting to it won’t currently work as you won’t be able to get an IP address, this is where the DHCP server, which we installed earlier, comes in.

In order to set this up we first need to tell it to listen for DHCP requests on the correct interface, in our case ath0. We do this by editing the /etc/default/dhcp3-server file to look like this:

# Defaults for dhcp initscript

# sourced by /etc/init.d/dhcp

# installed at /etc/default/dhcp3-server by the maintainer scripts

#

# This is a POSIX shell fragment

#

# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?

# Separate multiple interfaces with spaces, e.g. “eth0 eth1″.

INTERFACES=”ath0″

Next we setup the DHCP server to dish out addresses to the clients on out network, edit the file /etc/dhcp3/dhcpd.conf to have an entry like the following:

subnet 192.168.1.0 netmask 255.255.255.0 {

range 192.168.1.100 192.168.1.200;

option domain-name-servers 192.168.1.1;

option domain-name “mynetwork.local”;

option routers 192.168.1.1;

option broadcast-address 192.168.1.255;

default-lease-time 600;

max-lease-time 7200;

}

I don’t know whether all those options are definitely needed, but this configuration works. I think you could probably get away without the routers and name servers, as these won’t exist on this small standalone network.

OK, now start up the DHCP server and you should be in business:

$ sudo /etc/init.d/dhcp3 start

Assuming that works OK, try connecting to the ‘my-access-point’ network from another machine, it should work (if it doesn’t or you can’t see the network, try rebooting the server machine).

Once you’ve successfully connected you should be able to browse pages hosted on the server at http://192.168.1.1, so my LimeSurvey install would be at http://192.168.1.1/survey. Now you have a portable server that you can take round to serve web apps to machines in the vicinity! Awesome!

That just covers the server part of what I have planned for these small netbooks, my ultimate aim is to set them all up running Ubuntu with a lightweight desktop and Firefox started automatically in Kiosk mode (thanks to the R-Kiosk addon). This will give us ten little survey machines which will just ‘boot’ into Firefox and go to the LimeSurvey page. I’ll post details of that setup once I’ve done it, but for now that’s all! Bye!

Well, I promised something technical and here it is. It’s turned into a bit of a mammoth post, but the end result is pretty cool!

The idea of being able to install your favourite Linux distro over the network and so do away with burning CD’s (which ultimately get used once and then thrown away) is tantalizing. Not to mention the serious geek points for anyone who has a boot server on their network.

I started out using this article as a reference, as the process seemed relatively simple. However, I soon found out that this article wasn’t strictly accurate and didn’t explain some things too brilliantly! So I decided to see if I could do better.

The following is my account of setting up my own boot server on a spare box I had lying around (though you can just as easily do it on your main computer). I started from a base install of Ubuntu Server 8.10 (Intrepid Ibex) which I installed in the normal way (i.e. from a CD).

Prerequisites

Once my server was up and running and I could ssh into it, the fun really started. The article I linked to above tells you what you need, namely:

1. A dhcp server (sudo apt-get install dhcp3-server)
2. An Ubuntu CD image (the alternate CD not the live CD one, though presumably the server version works too).
3. A TFTP server (more on this below)
4. A web server, such as apache (sudo apt-get install apache2)

Out of those, only the TFTP server caused me problems, I dutifully installed the suggested package (tftpd), only to find much later that it didn’t support one of the options needed by the bootloader.  To avoid this use the tftpd-hpa package instead (sudo apt-get install tftpd-hpa).

What happens…

At this stage, it might help if I run through the actual netbooting process as this will give you a general understanding of what we need to configure:

1. When you choose the netboot option on the machine you want to boot (usually in the boot order settings in the bios), the bios will run a small program stored in on the motherboard (PXE-ROM). This program is essentially a DHCP client, which sends out broadcasts on the network looking for someone to provide it with an IP address and information on what to do next.
2. The DHCP server on your network respond to the broadcast and dishes out an IP address to the client. It also passes it the IP address of a boot server and the name of the bootloader file to request.
3. The client contacts the boot server (which can actually be the same machine as the DHCP server) and requests the bootloader file and executes it.
4. The bootloader loads it’s configuration from the server and displays a menu of the boot options.
5. When the user selects an option, the bootloader requests the kernel and initrd images from the server and boots the kernel.

Our kernel will run the Ubuntu installer so that we can install an Ubuntu system on the client machine, but to get the packages we will use apache to serve them out for us across the network.

Let’s get down to it

OK, let’s configure some stuff, first up is the DHCP server. Here’s my configuration:

default-lease-time 600;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.3;
option domain-name-servers <ns1>, <ns2>;
option domain-name "mydomain.com";
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.2 192.168.1.51;
}
next-server 192.168.1.5;
filename "pxelinux.0";

This goes in /etc/dhcp3/dhcpd.conf (sudo nano /etc/dhcp3/dhcpd.conf). I’m actually only going to expalin the last two lines (the rest is pretty standard DHCP stuff which you can find out about somewhere else. The last two lines are expalined below:

1. next-server 192.168.1.5; – gives the client the address of your boot server, in most cases this will be the same as your DHCP server address (I’m running all this on my one server box). Change the address to the address of the machine you want to use.
2. filename “pxelinux.0″; – the bootloader file to use, just leave this as it is.

Once you’ve done that, restart the DHCP server with ‘sudo /etc/init.d/dhcp3-server restart’. Also if you’re running a commercial (wireless) router, you’ll need to disable the DHCP server on the router from it’s control panel.

TFTP or not TFTP

The TFTP server needs very little configuration. All I did was create directory in the root of my filesystem to serve from:

sudo mkdir /tftpboot

Then you just need to make sure that tftpd serves from that directory (I spent ages wondering why mine wasn’t working because of this!), by changing the ftpd line in /etc/inetd.conf to:

tftp           dgram   udp     wait    root  /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /tftpboot

(I basically changed the path at the end). Then restart the inetd service (sudo /etc/init.d/openbsd-inetd restart).

Serving the iso files from Apache

Now we’re going to copy everything out of the iso image to somewhere that Apache can find it:

sudo mkdir -p /var/www/netinstall/ubuntu8.10-alternate
sudo mount -o loop ubuntu-8.10-alternate.iso /mnt
sudo cp -a /mnt/* /var/www/netinstall/ubuntu8.10-alternate/
sudo umount /mnt

First, we made the required directories to serve our files from. Structuring the directories like this allows us to serve other versions out from the same server if we want to. Secondly, we mounted the iso file on the /mnt directory, then we copied all the files from that to our server directory and finally unmounted the iso image.

If you now go to http://<serveraddress>/netinstall/ubuntu8.10-alternate, you should see a listing of the files that were on the CD. That was easy, let’s move on.

The elusive pxelinux.0

You should recognise ‘pxelinux.o’ from the filename perameter in the DHCP config above, this is the bootloader that loads our kernel. Unfortunately, I couldn’t find it (and the other article gave me no clue!).  I eventually found it in the files I copied from the iso (I’ve since learned that you can also get it from the ‘syslinux’ package). To copy it to the correct place use:

sudo cp /var/www/netinstall/ubuntu8.10-alternate/install/netboot/pxelinux.0 /tftpboot/

Next we need a kernel and initrd image we’ll also get these from the files we just copied:

sudo mkdir /tftpboot/ubuntu8.10-alternate
sudo cp /var/www/netinstall/ubuntu8.10-alternate/install/netboot/ubuntu-installer/i386/linux /tftpboot/ubuntu8.10-alternate/
sudo cp /var/www/netinstall/ubuntu8.10-alternate/install/netboot/ubuntu-installer/i386/initrd.gz /tftpboot/ubuntu8.10-alternate/

Now we need to configure pxelinux to find our kernel, the configuration goes in /tftpboot/pxelinux.cfg/default:

default 1
timeout 200
prompt 1
display pxelinux.cfg/msgs/boot.msg
# begin list of available boot options
# Local hard disk boot
label 1
localboot 0
# Ubuntu 8.10 Alternate install CD
label 2
kernel ubuntu8.10-alternate/linux
append initrd=ubuntu8.10-alternate/initrd.gz

The first two lines select the default boot entry (see below) to use and give us a timeout of 20 seconds after which that option will be selected (the timout value is measure in tenths of a second). The next two display a menu of the available kernels (which goes in /tftpboot/pxelinux.cfg/msgs/boot.msg).

Next we have our boot entries. Each of  these have a label line which enables us to identify the listing later. The first listing just has a directive telling pxelinux to boot from the local hard disk. As this option is selected as the default (above) the computer will attempt to boot from it’s hard disk once the timout has occured.

The second listing is more interesting, we have the kernel directive with the path relative to the /tftpboot/ directory, this tells  pxelinux what kernel should be booted if this option is selected (duh!). We have the append line, which adds options to the kernel, in this case we tell it to use our initrd  image, but you can add any valid kernel option. Obviously this file can have as many listing as you want to give boot options, there’s also support for multiple different menu’s and help screen, but I’m keeping it at this for now.

OK, now all we need is our display message. I put mine in the msgs directory (mkdir /tftpboot/pxelinux.o/msgs) and put this in the  file  (boot.msg):

^Y^L                  ^O0fNETWORK BOOT OPTIONS^O07
Select one of the options below, or press enter for the default:
1 - Local Hard disk boot [Default]
2 - Install Ubuntu 8.10 'Intrepid Ibex'
NB: Default will be selected after 20 seconds

That’s it! Just make sure the bit before the hyphen matches the label field we used above, so that the user knows what to type at the prompt. The funny characters in the file correspond to specially interpreted charaters for clearing the screen, etc. I just copied them from another file!

Booting Clients

The first client I tried to boot was my ASUS EeePC 901. I succesfully configured the bios to boot from the network and got to the menu screen. Booting the Ubuntu kernel worked and I was able to get into the installer, however a few steps in it told me that my ethernet adaptor was unsupported so it was unable to get packages for installation. Apparently, the next version of Ubuntu (Jaunty) is going to have the driver included by default in it’s kernel, so maybe that’ll work (I’ll try it at some point and report back).

Next I decided it would be cool to try and boot a virtual machine from my network. Having done some research I found that if I used VirtualBox with host networking I should be able to get an IP address from my network (rather than VirtualBox’s build in DHCP) and so boot from the network. I currently had the Open Source edition of VirtualBox installed, which is an older version (2.04) which doesn’t support host based networking without a lot of fiddling around.

I decided to take the easy way out and upgraded to version 2.1 via the VirtualBox repository. Once this was installed I was able to select ‘Host Network Interface’ in the virtual machine network settings and then select eth0 as my interface. In the advanced settings I set network as the first boot device and then booted the machine:

Network boot screen, as seen in VirtualBox

As  you can see from the screenshot, this worked just fine, as did proceeding to the installer. When I reached the step in the install which asked me to select a mirror I scrolled up and selected ”. On the next few screens I had to enter information about the server I was using, namely the IP address (192.168.1.5) and the path to the repository (/netinstall/ubuntu8.10-alternate/). See the screenshots below for details:

Select 'enter information manually' on the repository selection screen.

Enter the IP address of the webserver where you copied the files from the ISO

Enther the path of the directory which you copied the files to, relative to the web server root.

The rest of the install proceeded just fine, with the packages being retrieved and installed from the network. I ended up with a functional desktop system (in a virtual machine) just as I would get if I had used a CD.

Next Steps…

Wow, that turned out to be pretty long. Hopefully you’ve made it this far and I’ve managed to help you get to grips with this. I still have a few things I want to try to setup with this and I’ll report back if I make any progress:

• It would be really great to have Clonezilla and/or some kind of rescue toolkit distribution available for booting over the network, that way I can just plug in a machine and boot up whatever I need.
• I eventually want to have a go at making a completely diskless system, which doesn’t look that difficult as I seem to have done most of the work. Ideally it would be nice to be able to install/design a system in a virtual machine on my desktop and then deploy it across the network when it’s ready!

I hope you’ve enjoyed this How-To and have found it informative, if you have any problems, corrections or just want to say thanks, feel free to post a comment. Bye for now!