Overview

If you are not already using Ubuntu as your number one “go to” for troubleshooting, diagnostics and rescue procedures tool… it will probably replace all of the tools you are currently using. Also, once the machine has booted into the Ubuntu live session, it is possible to perform the OS setup like you normally would. The immediate up shut of using Ubuntu over the network, is that if your already using the CD version, you will never again be looking for the CDs you forgot in the CD drives.

This procedure has been used to make Ubuntu 9.10 (Karmic Koala) up to and including 11.04 (Natty Narwhal) network bootable. It may work for other Ubuntu like distributions (like Linux Mint) but hasn’t been tested.

You will see me use VIM as the editor program, this is just because I’m used to it… you may use any other editor that you’d like.

How does it work?In general the Ubuntu LiveCD boot process that we all know is like so:

You put a CD into the cdrom drive the BIOS knows how to use the cdrom enough to get the boot program on the cdrom (isolinux).

Isolinux is responsible for the menu options. Once you select a boot entry like “Start or install Ubuntu”, it calls the kernal + initrd (initial ram disk) files, copies them into memory and passes parameters to them.

The now in RAM and in control kernel + initrd start the boot process, while using the parameters that where passed to them to determine things like: should the splash screen be shown? should the output be verbose?.

When the inirtrd scripts have finished loading drivers and device information, they look for the Ubuntu liveCD files to continue the boot process. The normal behavior is to look in the local physical cdrom drive.

For network boot:

Instead of a local media such as a CD, the client is booted using it’s network card (PXE) and is supplied with PXElinux over TFTP.

Just like Isolinux, PXElinux is responsible for the menu options. Once you select a boot entry, it calls the Ubuntu kernal + initrd files, copies them into memory and passes parameters to them.

The now in RAM and in control kernel + initrd start the boot process, with our additional information that they should not be looking for the boot files in the client’s local physical cdrom drive, but rather in an NFS share on our FOG server.

This is possible because the Ubuntu creators have enabled networking by integrating, network cards drivers and protocols into the kernel + initrd files. For such an act, we can only say thank you to the Ubuntu team.

Make the Ubuntu files available on the server

The first step is to make the Ubuntu files available on the server. You may opt to simply copy them from the CD drive, or extract them from the ISO, and that will work just fine. With that said, we will make the ISO auto-mounted. While not a must, doing this will enable you to use our “How to Upgrade your Ubuntu ISO Without Re-downloading” guide, to upgrade the Ubuntu version of your network boot without going through all the procedures from scratch or alternatively, replace a single file to update the entire entry.

With the above said, This author likes keeping a couple of past versions around, until the new one has been proven absolutely stable and issues free. That is why we will make a sub-directory and mount point according to version, but know that you could bypass that to have your single point of update.

If all went well, you should be able to list the contents of the ISO by issuing:

ls -lash /tftpboot/howtogeek/linux/ubuntu/11.04/

Create an NFS share

While the boot procedure starts by using PXE, the actual heavy lifting is done by the NFS share on the server. As we are basing this guide on our FOG server, the NFS components and some configurations have already been done for us by the FOG team, and all we have to do is add to them our Ubuntu share.

The above may look messy at first glance but all you have to do is replace *<YOUR-SERVER-IP> with the IP of your server NFS/PXE server.

For a clearer geek understanding, the text above will:

Create a new PXE entry in the“Linux” sub-menu called “Ubuntu 11.04”.

Because of the “MENU DEFAULT” parameter, this entry will be automatically selected when entering the “Linux” sub-menu.

Point the client to take the kernel + initrd files usinf TFTP from the relative path in the “/tftproot” directory of “howtogeek/linux/ubuntu…”

Point the initrd scripts to mount the “root” filesystem from the NFS share on the absolute path of “<YOUR-SERVER-IP>:/tftpboot/howtogeek…”

Note: I have tried (and failed) to use a DNS name instead of an IP for the “<YOUR-SERVER-IP>”, I’m guessing that at that stage of the boot process there simply still isn’t support for DNS… success stories are welcomed.

Possible procedures

You should now be able to boot a client into Ubuntu from PXE (Usually F12).

At this stage we suggest you take the time to review some of the things you can do with this outstanding tool:

I’ve been trying to build a PXE or gPXE server for some time. Your guide and FOG have made the last attempt the best one. Thank you. However, my needs differ a little as I am building it to use in different environments and mostly for use at a Linux Installfest. The biggest distinction is that I must serve a multitude of distros (e.g. ubuntu, Mint, Centos, etc) and versions per distro (32/64 bit, Gnome/KDE/LXCE/etc.). This means a few things:

1. It would be best to put the .ISOs and menus etc in some home partition so they don’t have to be wiped on a system upgrade/clean install. If necessary, maybe they could be put there and linked from the location(s) you are using?
2. Can the variations on s single distro have their .ISOs all in the same directory?
3. It is not totally clear whether this method would result in all .ISOs being mounted, or if they only automount when needed. Also, is there a limit on the number that can BE automounted?

You say you keep several versions of ubuntu but only show doing one. Are you planning to do a third article in this series?

i’m glad to hear of yet another success story :)
while i am planning on a third, fourth and beyond articles in this series, they are not currently planned to go deeper into the Ubuntu liveCD.

so i’ll try to answer your questions in order:
1. you can put the ISOs where ever you want, as long as you make the content available to the NFS share. as in all things Linux, there are no limits on how you can achieve that.

2. sure… as long as they have different file names, there is no limitation on how many distros you can have in the directory or on the PXE server.

3. this guide shows only how to mount the single ISO file and create a single PXE entry, to add additional distros (ISOs) simply rinse and repeat as necessary. as far as i know there is no limit on how many mounts you can do and every mount entry in “fstab” will be auto mounted either at boot or by issuing “mount -a”.
if you would like to temporarily mount an ISO and not have it remain perminent, you can use our earlyer guide here.

You said in your reply to me “if you would like to temporarily mount an ISO and not have it remain perminent, you can use our earlyer guide here.” as if you were going to link to one of your articles or name one, but did not do so. I would like to do this, preferably automatically when a PXE booter requests a particular distro, but even manually if I must.

I don’t know how many I will end up doing so it MAY not be an issue. I just prefer to think ahead rather than having to restructure everything later.

Note: I have tried (and failed) to use a DNS name instead of an IP for the “”, I’m guessing that at that stage of the boot process there simply still isn’t support for DNS… success stories are welcomed.

I have been told by others there is no support for this in any of the xxx.c32 menu systems. By the time any of those are ever used, the server is fully up and should know it’s own IP. My thought is to add some processing to (or following) the network startup script to copy unchanged menu files to the right names and use sed to replace the requisite text in the various menus for the PXE server. I think that could work. You could not do it to the real files because on the second network start they would not contain the original text to replace. Just a thought …

the DNS remark was referring to the fact that i had to change the FOG server’s IP once or twice since initial setup. because the PXE menus are using a “hard coded” address, it meant that i had to go back to the menus and change the IP (which at first i forgot). using a DNS name, would have absolved me from having to do this, but that it is not possible… makes sense?

Thanks for the link. You are correct; it WAS in the word “here” though it did not look like a link until I moused over it. My bad!

I should tell you I have made a royal shambles of this trying to extend it as I was talking about. I had your single .ISO working to net boot, but I wanted more. I tried placing the .ISOs in my home directory tree and mounting 6 of them to 6 directories under /mnt. I changed all the menus and fstab and exports appropriately an now nothing works except the single menu referencing them. But 4 of the six files are not found for no apparent reason. And the two that are just don’t work. The client just returns to the menu after selecting that entry (just like it does for the .ISOs that were not found during the mount. Sigh!

BTW, there are only 8 loop devices so I think some way to automount on use will end up being needed. And perhaps a way to unmount when not needed. Though I suspect I may never see enough activity to demand it, I like to do things where I avoid limits. I am looking forward to reading the other article now that I see the link.

OH, and yes what you say makes sense. What do you think of my sed idea to fix that?

I have it working and serving up 32 and 64 bit flavors of ubuntu 10.04, 10.10, and 11.04.

I’m too tired now but will send you some details tomorrow. It looks like the limits are going to be the number of mounted ISOs since there are normally only 8 loop devices. I also wonder about resource consumption but have not looked at that at all.

Yes, I know. The last two PXE servers I built worked that way which also meant each distro I was serving basically had 2 copies on the server. It also meant that I had to learn where different distros stored certain files in their .ISOs. I don’t know if you want details of what I did, but here they are:

Note the addition of the no-subtree_check to avoid a warning that was coming out in syslog. Also note that I placed all the .ISOs (maybe 100 of them) in a home directory tree so they did not need to be lost if I ever did a fresh install. I would have preferred /tftpboot/ to be there as well as in another PXE server I saw for the same reason but FOG made this so easy and I did not want to dig into there stuff to see what needed to change for them. Probably would not be hard though to move it all under a tftp user.

I was not able to use mount points under .mnt/ or /media/ because syslinux menus apparently make assumptions for the relative location of mount points for PXE usage. Another reason to want these things in user space.

My menu is simply adding to you linux.cfg but to expand the service would probably change that to be multiple menus and I had trouble when I tried that the first time. Anyway, here it is:
MENU INCLUDE /pxelinux.cfg/master.cfg
MENU TITLE Linux Distributions
MENU BACKGROUND howtogeek/pics/fog-sub.jpg
#MENU BACKGROUND fog/bg.png

Next steps:
– try using autofs to dynamically mount and unmount .ISOs as needed and avoid the limit of 8 loop devices
– try using dnsmasq and dnsmasq_proxy to respond to DHCP Requests for a PXE server without having to set that up in the actual DHCP Server (I was shown this working Saturday)
– find a way to not require a static IP to encode into the menus (maybe the sed editing I mentioned before or whatever Brian did Saturday)

Got this working with Mint10, but it’s strange. It loads the live environment fine, everything works… but when I install it, the network doesnt initialize. I had a hell of a time trying to manually enable the network. When I install it (same ISO) from a cd, everything is fine after the install. Would there be a difference on how the network drivers are loaded through a pxe boot?

@Bobby
no difference, its just an Ubuntu bug that popped up somewhere in the 10.04 time-frame. i guess it creeped its way into Mint due to lack of testing/reporting.

to overcome the problem, you can do either one of two things post installation:

1. edit the /etc/network/interfaces file and change the “manual” setting of the network card to DHCP. and then restart networking – this is the dark side of the fix, as in its quicker, faster and more seductive to implement, but has the disadvantage that some networking features don’t work the same as with a normal setup.

2. go into the same file, comment out the network card entry. use ifconfig -a to find the MAC of the NIC and restart networking. then in the GUI go to preferences “network connections” and manually add the NIC with its MAC. – while longer to perform, this will get you up and running just as if you have installed using the CD.

@Larry Thiel
ya, never did get live fedora to work… but didn’t need it that much, so didn’t try that hard. what I did do is get the net installer working from PXE… but if you really need the live version, i can’t help you and i really wish you good luck with that.

as for Puppy, it at least used to have a “humongous” initrd version… so it is possible to send this humongous initrd through PXE to the client and not even use NFS… at least thats what i did back in the day.

regarding the max loop devices, as i said… Linux has many ways to accomplish the same goal… if this one works for you , use it… :)

Trying the Debian 6 net install, this boots fine (although I couldnt get the gtk graphical to work), the install menu comes up and allows me to choose the language, but then it asks for the CD… cant get past it.

Thanks a million for the guides. Been trying to get a PXE server up and running for ages without success. I now have 3 versions of Ubuntu under Linux stuff as well as Parted Magic.

I have a few small issues though changing the backround pictures.

The master.cfg file points to fog/bd.png and the linux.cfg file points to howtogeek/pics/fog-sub.jpg

If the master.cfg file is the global one surely it will always reverts to this image. I’ve placed my own image at howtogeek/pics/fog-sub.jpg but the sub menu always shows the fog/bd.png image.

Also every time I try and point the master.cfg file to another image of the same size as fog/bd.png (both .png and .jpg) I only get a blank backround globally. fog/bd.png seems to be the only one that works. Could this be due to the file permissions? My image is owner = root whereas fog/bd.png’s owner = fog

Sorry, I’m an idiot. I was working on two different PXE boot issues and got them mixed up. LOL

My REAL problem is, I followed your method to the letter, yet everything boots, I got rid of the splash screen so I could watch what was happening, and it seems that it never completes, because it is still looking for the live filesystem on CDROM!

What do I need to change to get it to load the proper one from the nfs share?