installer writes a permanent ethernet entry in interfaces file

[Leo Milano]

If Ubiquity (the installer) is ran while connected to the internet via ethernet, writes an "auto ethX" line in /etc/network/interfaces. This means that the boot up process, including bringing up the X system by upstart, will be delayed for whatever timeout is defined in /etc/init/failsafe.conf (see bug 839595). This is currently 120 seconds.

So far, it seems like the best solution would be for the installer to give the user the option to choose what to do with the interfaces file after finishing installation. This will also be an issue with upgrades to Oneiric, so the upgrade tool should probably offer the user to "fix" the interfaces file. In all cases, the user should be offered a sane default behavior.

Please see bug #839595 for more information

[Scott Moser (smoser)]

From my perspective, it makes sense for Ubiquity to write the 'auto eth0' (or more generically 'auto ethX') for a non-wireless device that it did the install over.

The difficulty is in determining if the user was just doing an install over that interface or would generally expect it to be permenant. If the user is expecting to keep that system plugged in, then adding an 'auto' entry is the right behavior, and *not* adding that entry may well mean the user cannot reach their machine after install.

[Leo Milano (lmilano)]

Scott: it seems clear that a permanent connection in a machine needs to be there, yes. However, it is assuming that any user who has ethernet plugged in needs that. This seems dangerous, particularly because it makes people have subsequent 3 minute boot up times. Why not just ask the user? (and want the user about possible large delays in boot up if they choose permanent for something that isn't)

[Clint Byrum (clint-fewbar)]

It seems to me that this is actually quite safe, sane behavior for the installer to exhibit, since it can't be sure that you don't want the machine connected via the install interface after first reboot. Without the guaranteed presence of NetworkManager to tie it to (one picks mini/alt installer because they want to customize, right?) , what choice does the installer have but to keep the configuration given.

What might be a more interesting way to go would be to change NetworkManager so that when it is installed, it can offer to disable these auto interfaces at a medium priority, with its default being not to (its more annoying but safer to leave them in /etc/network/interfaces).

Anyway, I believe this behavior (right or wrong) is all coming from debian-installer, not ubiquity, so redirecting as such, and marking the importance Medium since this only affects users who are switching off their install interface, not all users.

[Leo Milano (lmilano)]

Clint: good point about annoying vs safer.

Overall, I don't think we know, at installation time, what the user intends to do. In my case, for instance, I never intended to create any static connection. Actually, I configured a DHCP ethernet connection. I really had no intention of persisting the connection, and such is the case of other folks commenting in the related bug reports. Of course, other people will be setting up servers in some large institutions/corporation, and they deserve to be

So, yes, I think the best way to handle this is by explicitly asking the user before leaving the installation. The simpler installer doesn't hardcode ethernet connections, so the bulk of the users are not a concern. And the folks doing a custom install won't mind an extra question.

Should I update the bug description along these?

[Robert Hooker (sarvatt)]

I don't know if you want to edit the description for this or not, but I only do full live installer installs (not netinstall or alternate) and it is a very common situation for wifi to not be supported on the livecd so I have to plug my laptops in via ethernet and am hitting the 3 minute timeout once its done every time.

[Leo Milano (lmilano)]

Thanks, Robert!

I will update the description, since this is very relevant. Basically, the installer is always adding "auto ethX" to the interfaces file, provided there is an ethernet connection at install time. This means the problem will be much more widespread than we had thought. I think the severity of this bug is higher than Medium, but I can't change that.

So, all the installers should address this. And I think the upgrade tool should address this, as well. Many people who have never used the command line but had an ethernet connection in their first install, will have 3 minutes boot delays until/unless they learn how to modify a text file in sudo mode.

[Chris Van Hoof (vanhoof)]

Based on the testing and comments we have on the scenarios which can add an entry to /etc/network/interfaces this certainly feels like something that might have a bit more exposure to users beyond netinstall and/or alternate.

[Colin Watson (cjwatson)]

Surely the alternative to adding an 'auto' line is that the interface won't automatically be brought up on the first reboot after installation? Without NetworkManager, I think it's more likely that the same interface is going to be in use before and after installation.

With NetworkManager, the installer *already* calls /usr/lib/NetworkManager/ifblacklist_migrate.sh, which is supposed to disable 'auto' lines in favour of NM. Thus, I think Clint's comment #3 is based on some mistaken assumptions, or else is mistakenly ascribing a network-manager bug to d-i.

I'm more than happy for this bug to remain open for discussion, but I don't think simply removing the 'auto' line is the solution, nor do I think that simply punting and asking the user what to do is a good approach; and I'm going to mark this Won't Fix for oneiric as we could easily do more harm than good by changing behaviour at this late stage. I rather suspect that fixing this in a way that makes everyone happy will require changes outside the installer; having to predict what reality will be at some later point in the installer never works well.

[Clint Byrum (clint-fewbar)]

Thanks for the new info Colin.

In light of all the info here, I think the right way to go is to update the failsafe.conf to inform the user that the system boot is delayed waiting for network configuration. This will give the user a chance to inspect their network configuration, and will allow support people to quickly ascertain the status of /etc/network/interfaces and fix it.

I believe the way to do this is with a plymouth message after 20 seconds. This will ensure that any plugged in system sees no message, but anybody waiting an unreasonable amount of time is informed quickly. Opening a task against upstart since that is where failsafe.conf lives.

[Leo Milano (lmilano)]

Clint: something to consider. How would people (except for advanced users) fix their interfaces files? Can we provide a bash script installed by default, that will allow people to quickly install a vanilla interfaces files? It could also save a backup, and optionally restore it with another script. Or a simple debian package that can be installed, etc.

One way or the other, I think we need to provide an easy fix for the average user hit by this (and having the typical home networking connection, which doesn't need any customization of the interfaces file). Otherwise, we'll be one step further from fixing bug #1 :)

[Clint Byrum (clint-fewbar)]

Excerpts from Leo Milano's message of Tue Sep 13 19:43:36 UTC 2011:
> Clint: something to consider. How would people (except for advanced
> users) fix their interfaces files? Can we provide a bash script
> installed by default, that will allow people to quickly install a
> vanilla interfaces files? It could also save a backup, and optionally
> restore it with another script. Or a simple debian package that can be
> installed, etc.
>

That script is already installed with network-manager as:

/usr/lib/NetworkManager/ifblacklist_migrate.sh

Not the most discoverable thing, but it does the job.

> One way or the other, I think we need to provide an easy fix for the
> average user hit by this (and having the typical home networking
> connection, which doesn't need any customization of the interfaces
> file). Otherwise, we'll be one step further from fixing bug #1 :)

More important is making sure people understand that this is the reason
things are booting slow for them. I'm not convinced that normal installs
lead to 'auto ethX' in /etc/network/interfaces. Only installs that
started life without network-manager will have it, which is certainly
not the norm.

[Launchpad Janitor (janitor)]

This bug was fixed in the package upstart - 1.3-0ubuntu8

---------------
upstart (1.3-0ubuntu8) oneiric; urgency=low

  * debian/conf/failsafe.conf: Add plymouth messages to help users
    understand why the system boot takes longer when they have
    static network interfaces defined. (LP: #847782)
 -- Clint Byrum <email address hidden> Wed, 14 Sep 2011 18:53:10 -0700

[Damian Christey (damian-christey)]

Possibly related:
My boot times had been really following some Oneric updates last week. Today I saw the "Waiting for network configuration..." message, and found this bug. I looked in my /etc/network/interfaces and found an "auto ppp0" line. This is really strange, because I have never even used the modem on this laptop. Also this was an upgrade to Oneric, not a fresh install.

[Damian Christey (damian-christey)]

Sorry, I meant to say "My boot times had been really long..."

[Leo Milano (lmilano)]

Yes, Damian, this is the same bug. To double check, you can temporarily edit that file (using sudo), and add a "#" character in from of the ppp0 related lines. This should bring your boot time back to normal.

So, a couple questions, mostly because it's not clear who is affected: 1) have you ever used an alternative network manager? (such as wicd, etc) 2) what installation procedure have you used, originally? (regular cd, alternate cd, etc)

Thanks for reporting!

[Clint Byrum (clint-fewbar)]

I should also point out that bug #838968 was fixed yesterday. That should help reduce the cases of this problem. It seems that sometimes the installer removes just the 'iface' line, and not the 'auto' line. We were incorrectly waiting on interfaces that could never be brought up, because they had no definition, but did have an auto line.

Damian, did you have just 'auto ppp0' or also 'iface ppp0 ....' ? If you only had auto ppp0, then you were affected by 838968, and should make sure you have the latest ifupdown package.

[Leo Milano (lmilano)]

Hi Clint

Thanks for the changes in failsafe.conf, neat work! A ten second countdown would probably give slightly better feedback to the user (but it isn't essential or anything):

 $PLYMOUTH message --text="Waiting up to 60 more seconds for network configuration..." || :
 sleep 10

 $PLYMOUTH message --text="Waiting up to 50 more seconds for network configuration..." || :
 sleep 10

 $PLYMOUTH message --text="Waiting up to 40 more seconds for network configuration..." || :
 sleep 10

         [etc]

I also tested removing the "iface eth0" and there is no delay, so the fix to bug #838968 seems to be working ok, which will alleviate the situation here

> I'm not convinced that normal installs
> lead to 'auto ethX' in /etc/network/interfaces. Only installs that
> started life without network-manager will have it, which is certainly
> not the norm.

Yes, that was the initial understanding. However, comment #5 by Robert Hooker seemed to indicate that this is not the case (wouldn't the normal live CD always initiate NetworkManager). But I downloaded the Beta 1 live CD, burned a USB image and I still couldn't reproduce Robert's observation. I was using a DHCP connection.

@Robert: could you please give a little more details on how to reproduce what you see? Maybe show your interfaces file?

[Janne Snabb (snabb)]

I wonder if the fix to this bug is causing the bug #856810 ?

[Dave L (westy3)]

My /etc/network/interfaces consists only of

auto lo
iface lo inet loopback

Yet I now have this problem since doing dist-upgrade to 11.10-beta2. Should I file a separate bug? I can't seem to find a bug report that fits exactly.

[Clint Byrum (clint-fewbar)]

Excerpts from Dave L's message of Thu Sep 29 08:50:37 UTC 2011:
> My /etc/network/interfaces consists only of
>
> auto lo
> iface lo inet loopback
>
> Yet I now have this problem since doing dist-upgrade to 11.10-beta2.
> Should I file a separate bug? I can't seem to find a bug report that
> fits exactly.
>

Dave, that does sound odd. I'd recommend filing a new bug against the ifupdown
package with this:

apport-bug ifupdown

Can you verify that you have this md5sum:

$ md5sum /etc/network/if-up.d/upstart
2869783d5379a5acfaff5da1fc428718 /etc/network/if-up.d/upstart

Also if you do choose to open a new bug, please comment here with the
new bug # so we can take a look right away.

[PeterPall (peterpall)]

I understand that the first time after installation it makes sense for the system to wait for a network connection before booting. If the installer removes the line in /etc/network/interfaces telling the system about networks most users won't ever find out about this. But -
What happens if somebody just needs a line in /etc/network/interfaces. Or - as I did - added a static network communication to avoid problems with the router or because it was needed to get the system in a sane state again after one updates from one ubuntu alpha to another?

Since the user won't know the reason why the system is waiting for a network and other OSes have strange boot delays that seem to have been introduced intentionally chances aren't 100% that he will eventually end up here and know what to do to fix the problem.

[Clint Byrum (clint-fewbar)]

Excerpts from PeterPall's message of Sat Oct 08 11:16:29 UTC 2011:
> I understand that the first time after installation it makes sense for the system to wait for a network connection before booting. If the installer removes the line in /etc/network/interfaces telling the system about networks most users won't ever find out about this. But -
> What happens if somebody just needs a line in /etc/network/interfaces. Or - as I did - added a static network communication to avoid problems with the router or because it was needed to get the system in a sane state again after one updates from one ubuntu alpha to another?
>
> Since the user won't know the reason why the system is waiting for a
> network and other OSes have strange boot delays that seem to have been
> introduced intentionally chances aren't 100% that he will eventually end
> up here and know what to do to fix the problem.

Its my hope that the user would report this message and those who are
supporting that user would know immediately what the problem is and help
them solve it. Since it only happens once one has deliberately modified
the network configuration of the machine, it seems like a good idea to
direct the user to the machine's network configuration as the source of
the boot up wait.

[Mark - Syminet (mark-syminet)]

We have servers which are all automatically configured by adding simple static entries to /etc/network/interfaces. Upon reboot, it's network reachable within about ten seconds while the monitor is hung saying, "Waiting 60 more seconds for network configuration..." - but it is pingable and accepting ssh connections with no problems.

Commenting out the sleep stanzas worked here also, but it would be far better if the test checked properly and didn't start sleeping when everything was up. Either that or maybe something in /etc/default to tell it not to check period, I will maintain my own interfaces file. Here's an example interfaces file, I think this is all syntactically correct?:

root@19r8s12:/etc# cat /etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.1.181
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1

root@19r8s12:/etc#