I had the same problem yesterday on a Maxdata Server. Similar problem you had, that's why I found your question.
My server started and after some time it spilled out many of those IP-Config: no response after xx secs - giving up
messages and lead to a kernel panic after about three minutes.
I spend almost a whole day on trying to solve this issue, but I couldn't find any direct solution.
The problem is that there are two DHCP calls: One at boot time (right before PXE jumps in) which works and another one at the point where our both nodes stopped booting. The second request is shorter than the first one is not answered by dnsmasq for unknown reason.
Basically you can try different approaches:
Use a different network device:
I used a real server having two physical NICs. Switching to the second networking interface immediately solved my problem.
I have to admit that I am no expert in virtual machines, but Oracle VM VirtualBox Manager enables me to install up to 4 distinct networking devices in the VM while one can even change the adapter type. Be sure to play a bit with the settings around since my setup does not allow such a thing to be tested here.
If this does not work, modify your default
config-file to explicitly use DHCP for network configuration:
label ubuntu_12.04.4-desktop-i386
kernel /ubuntu/12.04.4-desktop-i386/vmlinuz nosplash
append boot=nfs root=/dev/nfs nfsroot=192.168.0.99:/path/to/ubuntu-12.04.4-desktop-i386 initrd=/ubuntu/12.04.4-desktop-i386/initrd.lz ip=:<server-ip>::::eth0:dhcp rw live-netdev=eth0 ethdevice-timeout=10
Remember to insert <server-ip>
.
However, if those solutions do not work for you, you can switch to static IP's:
label ubuntu_12.04.4-desktop-i386
kernel /ubuntu/12.04.4-desktop-i386/vmlinuz nosplash
append boot=nfs root=/dev/nfs nfsroot=192.168.0.99:/path/to/ubuntu-12.04.4-desktop-i386 initrd=/ubuntu/12.04.4-desktop-i386/initrd.lz ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:static rw live-netdev=eth0 ethdevice-timeout=10
You will have to create an additional config-file for each client (PXE boot should show which files it is looking for at boot time).
This is an issue that has appeared before: 4 years ago when upgrading from 12.04 LTS (Precise Pangolin) to 14.04.1 LTS (Trusty Tahr):
It looks like a similar issue exists for the upgrade from 14.04 LTS (Trusty Tahr) to 16.04.1 LTS (Xenial Xerus) with the relevant update log not yet updated. There is a choice of two reasonable solutions at the moment:
- Wait a little until this document is updated and then upgrade as normal
Use the following syntax now:
sudo do-release-upgrade --devel-release
Ubuntu documentation speaks on this option of using the --devel-release
or -d
option:
For further stability of a LTS release there is a slight change in
behaviour if you are currently running a LTS version. LTS systems are
only automatically considered for an upgrade to the next LTS via
do-release-upgrade with the first point release. So for example 14.04
will only upgrade once 16.04.1 is released. If you want to update
before, e.g. on a subset of machines to evaluate the LTS upgrade for
your setup the same argument as an upgrade to a dev release has to be
used via the -d switch.
And certainly at the moment this should be a safe course to take. When undertaken on my own Trusty system:
andrew@corinth:~$ sudo do-release-upgrade
[sudo] password for andrew:
Checking for a new Ubuntu release
No new release found
andrew@corinth:~$ sudo do-release-upgrade --devel-release
Checking for a new Ubuntu release
Get:1 Upgrade tool signature [198 B]
Get:2 Upgrade tool [1,265 kB]
Fetched 1,265 kB in 0s (0 B/s)
authenticate 'xenial.tar.gz' against 'xenial.tar.gz.gpg'
extracting 'xenial.tar.gz'
[...]
And the process rolls on installing Xenial by utlising this alternative file. A few hints at upcoming resolution of this issue:
- A few enquiries in IRC (thanks @ThomasWard) indicate imminent fixing of the issue pending the fixing of any bugs in the upgrade path...
- A personal email to myself from a developer has indicated that this should be fixed in the week commencing July 25th
- A Launchpad bug and Feature Request filed on this issue has some interesting comments...
Crossed fingers for a resolution soon!!
Note: The update log altered on July 29th my time, so issue now resolved...
References:
Best Answer
I have upgraded my diskless PXE booting systems in the past using do-release-upgrade.
Install update-manager-core to obtain do-release-upgrade. When you upgrade, don't forget to ensure that your initrd is built for netbooting in /etc/initramfs-tools/initramfs.conf, I have had this file overwritten on upgrade in the past, the option you need is:
You will also need to update your kernel and kernel configuration on your tftp server.
Edit the configuration file in your pxelinux.cfg directory to contain the new entry, on my server I have a host specific file:
You will also need to update the kernel images on the tftp server itself, here's the command I use: