Network startup stalls boot

(In reply to comment #0)
> 1- when you have no link, it should fail immediatly (if it's possible to detect).

Here's a (probably non-ideal) workaround for item #1, which I use on my Thinkpad
T42p (Intel 82540EP ethernet controller). It looks like it should work with
most other wired interfaces as well.

Edit /etc/network/interfaces, and make the following changes (I'll attach my
modified version):

1) Find the "mapping hotplug" stanza, and comment out the "map eth0" line.

2) Add "auto eth0" just above the "iface eth0" stanza.

3) Add the following line (replace "[TAB]" with it's namesake) to the end of the
"iface eth0" stanza.

   [TAB]pre-up /usr/sbin/ethtool -t "${IFACE:-eth0}" online | egrep -iq '^link
test.+[^0-9]0$'

This causes ethtool to check the interface status, and aborts bringing it online
if the Link Test portion fails. This seems to work fine as long as the
interface isn't managed by hotplug... the pre-up command is apparently run too
early in that case, and fails because the driver hasn't completed it's
initialization. Hence removing eth0 from the "mapping" clause.

I don't remember if the ethtool package was present by default... I think that I
probably installed it manually.

Created an attachment (id=2317)
modified /etc/network/interfaces file

As promised, here's my mangled /etc/network/interfaces file.

Somebody should really deal with this. When you have a laptop, it's annoying as
shit; if you reboot, you have to wait about 2-3 minutes before you can log in.
I thought vanilla Debian used to just background it after 3 seconds.

(In reply to comment #3)
> Somebody should really deal with this. When you have a laptop, it's annoying as
> shit; if you reboot, you have to wait about 2-3 minutes before you can log in.
> I thought vanilla Debian used to just background it after 3 seconds.

Nope. This is exactly the same in Debian and upstream, and always has been.

This will be addressed in a different way for Dapper, via NetworkMagic.

(In reply to comment #3)
> Somebody should really deal with this. When you have a laptop, it's annoying as
> shit; if you reboot, you have to wait about 2-3 minutes before you can log in.
> I thought vanilla Debian used to just background it after 3 seconds.

When dhcp is waiting, you can just type "Ctrl-C" to stop the network
configuration and continue boot process...
I think this is not a "real" problem !?

DHCP of your hardware network interfaces is no longer in the critical path of the boot process, so it doesn't matter how long the timeout is.

I'm reopening this as unconfirmed without assignee, because it's in feisty again. The default dhclient.conf has a "timeout 30" line and makes the boot process stall for a long time. I just wonder if there is a good reason for such a high timeout?

I've tested this a bit and I have no idea where that boot stall is really coming from. When booting without "quiet" and "splash" I get the timeout when starting the network devices, but even if they have been enabled or the timeout lowered, it takes a long time to boot. Any hints?

I did some more debugging and found out that if I remove all lines from /etc/network/interfaces, the boot is *much* faster. The dhclient.conf timeout doesn't improve the situation at all, but the boot is stalled because Ubuntu puts a couple of interfaces in the network config. I'm using networkmanager, so I don't need this config anyway.

Still, the original problem is not fixed in feisty: Starting the network is in the critical boot path and thus stalls the boot.

This bug not only stalls boot, but also adds delays to suspend/hibernate. I added gnome-power-manager to the list of affected packages.

Having the same problem in Feisty Fawn on my laptop. Using network-manager-gnome, so for me, trying to connect to my lan during boot is really unnessesary. And when network-manager is installed by default in Feisty, I really don't understand how this is happening?

Two bootcharts from my laptop - one with network cable attached, one without.

With cable (1:20)
http://img147.imagevenue.com/view.php?image=30835_feisty_20070206_9_122_262lo.jpg

Without cable: (1:56)
http://img9.imagevenue.com/img.php?image=31456_feisty_20070206_8_122_25lo.JPG

Is there a way to disable this bootup network check? Seems kinda redundant when Feisty is running Network-manager as default.

I found a solution - for me anyways:

sudo cp /etc/init.d/networking /etc/networking.old
sudo rm /etc/init.d/networking

Just removed the S40 networking service from the /init.d folder. Startup time in Feisty Fawn is now 31 seconds:
http://img143.imagevenue.com/view.php?image=69652_feisty_20070207_3_122_179lo.jpg

Is this still an issue for somebody? Since feisty herd-3, we got NetworkManager as default and my bootup isn't slow anymore. But it might have been a different problem on my laptop altogether...

Gnome packages are not related at all to the boot sequence (neither to hibernate/resume; they just trigger it, but not control it)

Likewise.

In Feisty, the DHCP timeout has been lowered to 30 seconds, which is a good balance between working with slow DHCP servers and not getting too annoyed.

Also, if you have a non-permanent internet connection, then you should just use network manager and use the Gnome network tool to disable the static configuration.

I consider this not a problem any more. Please shout out if I misunderstood and you still think that something needs to be changed. Thank you!

I went from 1:22 to :25 in Feisty by adding a sleep 15 to S40networking ~ line 17

case "$1" in
        sleep 15;
start)