PXE booting the desktop image fails to configure network

Bug #602273 reported by Mathieu Trudel-Lapierre on 2010-07-06
This bug affects 2 people
Affects Status Importance Assigned to Milestone
casper (Ubuntu)
Colin Watson
Colin Watson

Bug Description

Binary package hint: initramfs-tools

BOOTIF appears to not be set after going through today's iso image for maverick-desktop-i386 (20100706) and the accompanying pxelinux.0 file. This in turn causes DEVICE not to be set in casper, which causes the PXE-booted installation to fail to mount the NFS root and end.

Related branches

Attaching casper.log with the boot started with the debug= parameter.

Attaching the contents of /proc/cmdline.

Attaching the contents of dmesg.

Ameet Paranjape (ameetp) on 2010-07-06
Changed in initramfs-tools (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Ameet Paranjape (ameetp) wrote :


What type of system is this?

Changed in initramfs-tools (Ubuntu):
status: Triaged → Incomplete

I've been able to test this on two different Vostro V13, however, it seems to be the case on all the systems in the lab, so Toshibas, Dells, netbooks, etc.

Ameet Paranjape (ameetp) on 2010-07-06
Changed in initramfs-tools (Ubuntu):
importance: Medium → High
Changed in initramfs-tools (Ubuntu):
assignee: nobody → Canonical Platform QA Team (canonical-platform-qa)
Ameet Paranjape (ameetp) on 2010-07-06
Changed in initramfs-tools (Ubuntu):
status: Incomplete → Triaged
Colin Watson (cjwatson) on 2010-07-06
Changed in initramfs-tools (Ubuntu):
assignee: Canonical Platform QA Team (canonical-platform-qa) → Colin Watson (cjwatson)
Colin Watson (cjwatson) wrote :

I'd like to sync up the relevant function in casper with live-initramfs in order to fix this, but on examination I found that the code in live-initramfs doesn't make sense - the relevant section of code is provably unreachable. I've filed a Debian bug about this.

affects: initramfs-tools (Ubuntu) → casper (Ubuntu)
Changed in casper (Ubuntu):
assignee: Colin Watson (cjwatson) → nobody
Colin Watson (cjwatson) on 2010-07-07
Changed in casper (Ubuntu):
assignee: nobody → Colin Watson (cjwatson)
Ameet Paranjape (ameetp) wrote :

This is blocking installs in the lab marking as critical.

Changed in casper (Ubuntu):
importance: High → Critical

Wrote a (quick) patch that seems to correct the issue. That said, it's making use of a function that is sourced from /init inside the initrd, and apparently not in casper itself, which seems far from optimal. Perhaps it would be a good idea to re-copy this function in casper-functions or casper-helpers instead.

Note also: apparently the IPAPPEND 2 option is now required for pxelinux to include BOOTIF in cmdline since casper doesn't just configure the interface specified in initramfs.conf.

Robbie Williamson (robbiew) wrote :

Lowering to "High" based on comment #8, i.e. installs in our lab are unblocked.

Changed in casper (Ubuntu Maverick):
importance: Critical → High
Colin Watson (cjwatson) wrote :

configure_networking is fine - it's in /scripts/functions which is sourced by /scripts/casper-functions which is sourced by /scripts/casper.

Thanks for your patch, which largely looks fine. I made a few more corrections - configure_networking calls ipconfig several times, and so /netboot.config was ending up with lots of duplicate stuff in it and things were breaking. A better approach seems to be to read the machine-readable file that ipconfig emits.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package casper - 1.241

casper (1.241) maverick; urgency=low

  [ Mathieu Trudel-Lapierre ]
  * Use configure_networking at do_netmount; it's at least more resilient
    than a simple ipconfig call since it retries, and it properly parses
    BOOTIF to know which devices to configure. (LP: #602273)

  [ Colin Watson ]
  * Parse the machine-readable file written out by ipconfig rather than
    trying to parse its human-readable output.
 -- Colin Watson <email address hidden> Fri, 20 Aug 2010 13:37:56 +0100

Changed in casper (Ubuntu Maverick):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers