network NFS DHCP boot fails on multiple NIC machine

Bug #182940 reported by Jeremy Jackson on 2008-01-14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
initramfs-tools (Ubuntu)
Colin Watson

Bug Description

Binary package hint: initramfs-tools

background: When using initramfs-tools on Gutsy and PXE booting a machine (using dhcpd, tftpd, pxelinux) with multiple network interfaces, the NIC drivers are loaded in some order (influenced by udev) , and by default "ipconfig" chooses eth0 for DHCP/RARP autoconfiguration.

To get initramfs-tools to generate such an initrd, I set BOOT=nfs and MODULES=netboot in /etc/initramfs-tools/initramfs.conf

Assuming only 1 NIC is connected to a network setup for network booting, if the NIC that gets to be eth0 after kernel/initrd is loaded is the same as the one BIOS used to PXE boot, things work alright. If Linux gives that NIC another name, say eth1, then things do not work. ipconfig command is used ( from klibc-tools pkg ), and without any options, it claims to try all interfaces, however it only seems to print:

IP-Config:eth0 hardware addresss 00:01:02:03:04:05 mtu 1500 DHCP RARP
[29.123456] eth0: no link durring initialization

and pauses forever, since there is only 1 cable connected, to what linux calls eth1

Jeremy Jackson (jerj) wrote :

Passing the option "ip=all" to kernel at boot causes /usr/share/initramfs-tools/scripts/nfs to pass the argument "all" to ipconfig, with the following result:

IP-Config:eth0 hardware addresss 00:01:02:03:04:05 mtu 1500 DHCP RARP
[29.123456] eth0: no link durring initialization
IP-Config:eth1 hardware addresss 00:01:02:03:04:06 mtu 1500 DHCP RARP
[29.123456] tg3: eth1: link up 100mbit/s etc

then it displays all the DHCP details, and waits forever

I added the -t timeout flag, and wildcard for picking up the config results, see attached patch.

With the patch and "ip=all" kernel boot argument, booting succeeds.

Daniel Holbach (dholbach) wrote :

To get your fix included in Ubuntu, try transforming it into a debdiff ( and submitting it for review (

Peter Cordes (peter-cordes) wrote :

-t 7 is too short for my setup. -t 60 should be safe.

I was able to netboot the Hardy livecd (which detects my interfaces such that eth1 is the one with the cable plugged in to it). (It does boot=casper, not boot=nfs, so it doesn't normally look at ip= at all.) I booted with break=mount, and started shells on tty2 and tty3, then did ipconfig -t 60 all. I had to kill an ipconfig eth0 /tmp/..., but then the boot worked fully.

Colin Watson (cjwatson) wrote :

It looks to me as if ip=eth1 should do it too?

        case ${IPOPTS} in
                # Do nothing
                # Bring up device
                ipconfig ${DEVICE}
                ipconfig -c ${IPOPTS} -d ${DEVICE}
                ipconfig -d $IPOPTS

                # grab device entry from ip option
                if [ "${NEW_DEVICE}" != "${IPOPTS}" ]; then
                        # wrong parse, possibly only a partial string
                if [ -n "${NEW_DEVICE}" ]; then

It looks like part of this bug was fixed as, but the timeout is still needed.

Colin Watson (cjwatson) on 2008-10-01
Changed in initramfs-tools:
assignee: nobody → kamion
status: New → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package initramfs-tools - 0.92bubuntu14

initramfs-tools (0.92bubuntu14) intrepid; urgency=low

  * scripts/functions: Call ipconfig with a one-minute timeout rather than
    waiting forever (LP: #182940).

 -- Colin Watson <email address hidden> Wed, 01 Oct 2008 14:51:59 +0100

Changed in initramfs-tools:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.