This issue has left me scratching my head for a while, but I think I have finally found a solution.
I have been generating virtual machines (VMs) for a client to run on their laptops out in the field. The VMs run a copy of the client’s SugarCRM instance, on top of Ubuntu 12.04 32-bit (to run on a wide range of laptops the client has). The client needs to take these laptops to places where there is no Internet, and I mean no Internet at all, for miles around. Such places on this planet do still exist.
The issue is that Ubuntu runs something called a persistent net generator that creates rules for setting up the network. Each time it detects a new MAC address, i.e. a new network card, it generates a new rule and gives the network interface the next number up. So on first booting, the network card is called “eth0” and all works fine and dandy.
However, move the VM to another machine, and VirtualBox (or VMWare) will give the network card a new MAC address. This network then becomes eth1. Next time, if cloned, the VM will get network card eth2 etc.
Now, the OS is set up to use eth0, and only eth0. Only when eth0 comes up, will the VM be able to use it to access the Internet or local network. This was clearing not happening on cloned copies of the VM due to this persistence of the network rules. The problem manifests itself as the following messages as it boots up:
Waiting for network configuration.Waiting up to 60 seconds for network configuration.
So what to do about it?
The network rules are stored in this file:
The file can simply be deleted or the rules in it commented out. On next boot, a new rule for eth0 will be created and the network will work fine again. Two problems with this: firstly deleting the file is not something I would expect the end users to be messing on with. Secondly, the effect of deleting the file only takes place on the next boot, which is inconvenient.
The better approach is to prevent the OS from writing these persistent rules in the first place. Working out how took some digging, but the solution is actually straight-forward. The rules are generated by a shell script here:
Some sites suggest deleting this script. Don’t do that. It will be back on the next network upgrade. Instead, create an override script, which is like a customised version of that script. If the custom version exists (and it does not by default) then the OS will run that custom version instead. So we create a blank custom script:
sudo touch /etc/udev/rules.d/75-persistent-net-generator.rules
It will also not be touched by any updates to the OS, so it is safe there. Remember to comment out the rules that may already be in /etc/udev/rules.d/70-persistent-net.rules (or delete that file) then reboot, clone, boot again, and the network will be there and ready to use.
The VM I am using can be downloaded from here: http://virtualboximages.com/Ubuntu+12.04+i386+Lamp+Tomcat+Server+Virtual+Computer
It is a great installation that does the job well and simply. It has one web server running by default, under /var/www, making it dead easy to copy the SugarCRM files on. rsync is already installed on it, which many other “appliance” installations don’t have, so pulling a production application to the VM is straight-forward.
It has webmin ready installed, so adding a new virtual server and a database is really easy – no messing around with configuration files needed at all.
It is a 32 bit installation, which is really important when running on a wide variety of laptops. Even some of those laptops with 64-bit processors don’t have the hardware or firmware to support a 64 bit virtualised OS.
I could probably disable Tomcat to save some memory, but I have not bothered as it does not seem to slow things down.