netboot install of live CD results in unconfigured network interface

Bug #388060 reported by Marc Tardif on 2009-06-16
This bug affects 9 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)

Bug Description

Binary package hint: casper

When netbooting the live CD over NFS, the network connection must be preserved throughout the live session so that the filesystem remains accessible. Currently, this is achieved by adding the following lines to /etc/network/interfaces which prevents network manager from attempting to reestablish a connection once the desktop finally appears:

  auto eth0
  iface eth0 inet manual

These lines are added by casper in a script called 23networking. Here are a few relevant lines from the script:

    if [ -z "${NETBOOT}" ]; then method="dhcp"; else method="manual"; fi
    if [ "$method" != dhcp ] || [ ! -x /root/usr/sbin/NetworkManager ]; then
        # ...
        cat >> "$IFFILE" <<EOF
auto $i
iface $i inet $method


So, this at least enables the live cd environment to be loaded over NFS. However, the problem is that this later gets propagated to the installed environment if ubiquity is called. This is done by the script and here are the relevant lines from the script:

        for path in ('/etc/network/interfaces', '/etc/resolv.conf'):
            if os.path.exists(path):
                shutil.copy2(path, os.path.join(, path[1:]))

In the most common general case, this is the desired behavior so that the user's network configuration is propagated from the live to the installed environment. However, in the case of netbooting the live cd, this is not necessarily the case because this environment needs to make assumptions about the network which might not apply anymore once the system boots from a drive rather than from the network.

I suspect the behavior should be that a best effort should be done when attempting to propagate the network configuration from the live environment when netbooting. This would mean preserving the configurations for all the network interfaces except the one used to mount the filesystem over NFS. The reasoning is that some assumptions were made about that interface which were only relevant in this context, so all bets are off about preserving that configuration.

In order to achieve this desired behavior, I would suspect that casper would need to communicate somehow to ubiquity that a particular part of the network configuration should not be propagated to the installed environment. This could probably be accomplished by using the configuration file as the communication interface. For example, the interfaces file could look something like:

  auto eth0
  iface eth0 inet manual

Then, ubiquity could easily parse that out when propagating the network configuration from the live to the installed environment.

Marc Tardif (cr3) on 2009-06-16
description: updated

I can confirm this. When installing via PXE boot using a Karmic Desktop Install CD, the installed system does not properly connect to the network automatically the way the live environment did. Running "sudo dhclient" gets an address, and it then connects fine, but when you reboot it is back to the improper configuration.


auto eth0
iface eth0 inet manual

from /etc/network/interfaces and rebooting solves the problem. Deleting the file also seems to work, though it isn't regenerated after doing so. This seems in keeping with what I've read suggesting that Network Manager doesn't need this file anymore (though perhaps it uses it if it is there?).

In any case, this should be fixed, as it poses a significant barrier towards network based installs using the livecd.

dalesyk (dale-czexan) wrote :

I noticed the same problem on both karmic and lucid. If you PXE boot the live cd, the eth0 interface works as expected. If you then run the installer from the live cd and reboot, the network does not come up. If I change "iface eth0 inet manual" in /etc/network/interfaces to "iface eth0 inet dhcp" and restart the network or reboot, everything works again. This should happen automatically IMHO.

Magnus Ihse Bursie (ihse) wrote :

I can confirm that this bug is still present in Maverick.

To clarify the end user impact: When installing from PXE, this means that network is not working at the very first boot of the newly installed system, even though it worked during installation. This looks like quite a serious issue to me. According to, I think this means that this bug's importance should be classified as "High":
"High: A bug which fulfills one of the following criteria:

    * Has a severe impact on a small portion of Ubuntu users (estimated)
    * Makes a default Ubuntu installation generally unusable for some users
          o For example, if the system fails to boot, or X fails to start, on a certain make and model of computer
    * A problem with an essential hardware component (disk controller, laptop built-in wireless, video card, keyboard, mouse) "

Looking at this following triaging bug 678450:

casper's logic in 23networking seems broken. At that point in the install NetworkManager would not be installed. Would it be sufficient to just skip adding the "manual" method interfaces to /etc/network/interfaces, since omitting them would make their use manual? This at least shouldn't break servers, since they don't run NetworkManager, and would probably be reasonable for most users.

Larry G. Wapnitsky (lwapnitsky) wrote :

I can also confirm that this issue still exists in casper as of 2.04.2011. I am working with the BitDefender LiveCD (which uses casper) and have found that a PXE boot of the LiveCD does not update the /etc/resolv.conf.

I move, additionally, to excise the "manual" method from /etc/network/interfaces to avoid this issue moving forward.

Changed in casper (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
tags: added: netboot
Thomas Hood (jdthood) wrote :

I have linked bug #1013843 to this one but I'd like to point out a few differences.

* Bug #1013843 was filed against Quantal. The bug didn't affect Precise.
* Quantal has resolvconf. So does the Quantal Desktop live CD. So did Precise. Earlier Ubuntus didn't.
* The problem is observed at the late_command stage rather than after reboot.

Nevertheless I think it's useful to address that bug along with this one (#388060): both reports lead to the conclusion that the handling of network configuration and nameserver information from stage to stage needs to be debugged such that it is correct in all scenarios, including that of netbooting a live CD to install Ubuntu to a local disk, running late_command, and rebooting into the installed system.

Thomas Hood (jdthood) on 2012-06-20
summary: - netboot insall of live cd results in a manual network interface
- configuration
+ netboot install of live CD results in unconfigured network interface
Thomas Hood (jdthood) wrote :

Mathieu wrote:
> Would it be sufficient to just skip adding the "manual" method interfaces to /etc/network/interfaces

I am guessing that the interface was once defined as "inet manual" in order to prevent both ifup and NM from messing with it.

Omitting the stanza entirely will prevent ifup from messing with the interface.

In casper version 1.316 a snippet was added to 23networking which appears to deactivate NM in another way.

    if [ -n "${NETBOOT}" ] && [ -x /root/usr/sbin/NetworkManager ]; then
        # Disable Network Manager on netboot to avoid loosing connectivity to the media
        echo "manual" > /root/etc/init/network-manager.override

Thomas Hood (jdthood) wrote :

Relevant earlier report: bug #946215:

> Tracked it down to 23networking in casper writting
> /etc/resolv.conf in the target which obviously won't
> quite work because of resolvconf.>
> I'll do some copy/pasting of the code I wrote for LTSP in a similar use case.

Stéphane Graber (stgraber) wrote :

Moving bug to ubiquity as that's where we should be checking for that kind of scenario and fallback to copying /rofs/etc/network/interfaces if the interface is marked as manual (static should still be copied).

no longer affects: ubiquity
affects: casper (Ubuntu) → ubiquity (Ubuntu)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers