3

I've been having trouble with recent Ubuntu live CDs trying to boot off of them via PXE. My ultimate goal is to rebuild an old Ubuntu 9.04 diskless box using the newer Ubuntu 12.04.4 build.

When trying to boot what I believe is a good configuration, I'm getting output similar to the following:

Loading .../vmlinuz......

// --- lotsa good boot-up stuff ---

Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/casper-premount     ...
 [    6.336295] pcnet32 0000:02:01.0: eth0: link up
done.
done.
IP-Config: eth0 hardware address xx:xx:xx:xx:xx:xx mtu 1500 DHCP RARP
IP-Config: no response after 2 secs - giving up
IP-Config: eth0 hardware address xx:xx:xx:xx:xx:xx mtu 1500 DHCP RARP
IP-Config: no response after 3 secs - giving up
IP-Config: eth0 hardware address xx:xx:xx:xx:xx:xx mtu 1500 DHCP RARP
IP-Config: no response after 4 secs - giving up
IP-Config: eth0 hardware address xx:xx:xx:xx:xx:xx mtu 1500 DHCP RARP
IP-Config: no response after 6 secs - giving up
IP-Config: eth0 hardware address xx:xx:xx:xx:xx:xx mtu 1500 DHCP RARP
IP-Config: no response after 9 secs - giving up
IP-Config: eth0 hardware address xx:xx:xx:xx:xx:xx mtu 1500 DHCP RARP
IP-Config: no response after 16 secs - giving up
IP-Config: eth0 hardware address xx:xx:xx:xx:xx:xx mtu 1500 DHCP RARP
IP-Config: no response after 25 secs - giving up
IP-Config: eth0 hardware address xx:xx:xx:xx:xx:xx mtu 1500 DHCP RARP
IP-Config: no response after 36 secs - giving up
IP-Config: eth0 hardware address xx:xx:xx:xx:xx:xx mtu 1500 DHCP RARP
IP-Config: no response after 64 secs - giving up
IP-Config: eth0 hardware address xx:xx:xx:xx:xx:xx mtu 1500 DHCP RARP

I originally followed the steps here. I currently have the following:

  • A router running Tomato 1.21 (yes, I know it's old)
  • A box containing the TFTP server and the files from the live CD (IP address 192.168.x.y)

The router has a Dnsmasq custom configuration containing the following lines shown below:

dhcp-no-override
dhcp-boot=pxelinux.0,,192.168.x.y

With these set up, when I want to add something new to my PXE collection, I put some files in certain places, add lines to certain config files, and then I'm ready to boot my target box.

I've done this in the past for several boot situations including:

  • Backtrack 4r2 i386
  • Debian Lenny, Squeeze, and Wheezy
  • Damn Small Linux
  • Fedora 18
  • Several older Ubuntu live CDs
  • Several older Ubuntu installations

My current process to add a new Ubuntu live CD into the mix is as follows:

  1. Mount the live CD as an ISO image.
  2. Copy all files out of the ISO image onto the hard drive.
  3. Copy the vmlinuz and initrd.lz files from the ISO contents to area accessible by the TFTP server.
  4. Rebuild the initrd.lz to support PXE booting by modifying initramfs.conf and then running update-initramfs inside chroot:
    • MODULES=netboot
    • BOOT=nfs
    • NFSROOT=192.168.x.y:/path/to/extracted/iso/contents
    • DEVICE=eth0 // didn't do this before, trying now as described here due to trouble but still no dice; only have single NIC anyway
  5. Add item to boot.txt in TFTP server.
  6. Add lines to file under pxelinux.cfg directory.

Once I do these, I can reboot. To try it out, I've been using a basic VMware Player virtual machine with no hard drive, no CD-ROM drive, and no floppy drive. All it does is boot from PXE.

In the past, this has worked wonderfully, and then I can power it down and boot my desired physical box via PXE the same way.

I haven't been able to boot the last couple Ubuntu live CDs this way because I get the message as shown above:

no response after xx secs - giving up` message

Finally, I mounted the ISO directly under my VMware VM and installed Ubuntu directly onto a VM. Once I had that, I made it a diskless image by mounting the hard drive and copying the contents out similar to Steps 1 and 2 above, and then trying to PXE-boot from there.

This has worked before; however, when I try to do this with my 12.04 installation, I see the same symptom as my 12.04 live CD:

no response after xx secs - giving up

I tried this; it didn't work. Here are my old and new pxelinux.cfg/default lines:

label ubuntu_12.04.4-desktop-i386
         kernel /ubuntu/12.04.4-desktop-i386/vmlinuz nosplash
#         append boot=casper netboot=nfs nfsroot=192.168.0.99:/path/to/ubuntu-12.04.4-desktop-i386 initrd=/ubuntu/12.04.4-desktop-i386/initrd.lz
         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

I would appreciate any insight anyone has.

Thanks.

4 Answers 4

2

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).

4
  • Thanks for the info. Please clarify switching to another network device. My VM currently has only one network adapter set up as bridged. What can I do for a second network interface, and how to make it different? Regarding the first solution, I can't even boot into the environment in order to get to the network settings; should I be able to change the configuration my editing the root partition files directly?
    – jia103
    Commented Mar 30, 2014 at 5:20
  • Yes, you ca edit the files on the root partition directly from your host system. Nevertheless, there is the possibility to add information at booting time (I will update my answer).
    – MrD
    Commented Mar 30, 2014 at 9:53
  • I'm afraid the only solution that seemed to work for me is the static IP, but not the way described above. Instead, I had to modify the /etc/network/interfaces and /etc/resolv.conf file. I would prefer staying with dynamic, but oh well. This should work. I'm now having trouble reaching the Internet from it because my putting the gateway directly in the resolv.conf file didn't help; I probably need to find what generates it and specify it there, but this is progress. Thanks!
    – jia103
    Commented Mar 30, 2014 at 16:06
  • I got the answer from here about updating resolv.conf in Ubuntu: askubuntu.com/questions/157154/….
    – jia103
    Commented Mar 30, 2014 at 21:18
0

This is a bug on ipconfig not implementing the DHCP standard correctly

quick solution see/get Serva made INITRD_N11.GZ which includes an already fixed ipconfig (I'm related to serva development)

http://vercot.com/~serva/an/NonWindowsPXE3.html

0

I know this is an old question, but it just bit me as well.

If you have multiple NICs, this can be caused by Linux choosing one that isn't connected. Network device naming has been reworked, and that probably took effect between the version you were using and the one you switched to.

However, I'm not sure whether the renaming could have affected you since you apparently didn't boot with

ip=nicname

0

This issue seems to be reproducible on devices with several network interfaces As a workaround try to add 'IPAPPEND 2' to your 'default' configuration file in pxelinux.cfg folder

http://www.syslinux.org/wiki/index.php?title=SYSLINUX#IPAPPEND_flag_val_.5BPXELINUX_only.5D

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .