Feisty boot hangs on "Configuring network interfaces"

Alex, you could've just put the output of those commands in files and attatched them to the bug report instead. But I digress. I can confirm that I'm having these problems too; the difference is that I'm waiting 2-3 minutes at the boot-up screen because of this problem.

Confirmed here too, Dell Insprion 510m.

Not a fix, but a workaround: delete everything in /etc/network/interfaces except the lines defining "lo". As long as NetworkManager can pick up your connection, everything will be fine and your boot delay should disappear.

output of dmesg.

Output of lspci -vv

I can confirm it in Feisty on amd64.

confirm on feisty i386 with intel 2915 and marvell yukon on asus z71vp

Confirm also on feisty i386

can confirm on feisty i386 with intel 945GM and ipw3945

Bug confirmed !!!
Crucial and important bug.

The system now hangs for about 75 secs on "Configuring networks interfaces" during boot up.

My system specs :
Ubuntu 7.04 beta (with latest updates)
HP TC4400 Tablet PC
Core 2 Duo
1.5 GB ram
Intel 945 GM chipset.

uname -a ==> 2.6.20-13-generic #2 SMP Sun Mar 25 00:21:25 UTC 2007 i686 GNU/Linux
dmesg.log and lspci-vvnn.log are attached.

Confirmed here as well (wait of something like 30 seconds at configuring network interfaces).
P$P800 Deluxe main board, built-in ethernet disabled, 2 external 100MBIT ethernet cards
Started after updates of April 4
Worrying how things like this seem to regress so easily just before the RC period of Feisty...

I've played around for a while, did a reinstall and tried the updates bit by bit. It seems that the update to ifupdown is the culprit.

Drats, forgot to add my specs:

HP nx6110
Broadcom 4318 rev2 (using ndiswrapper)

The problem is that the update added a bunch of CRAP to /etc/network/interfaces. I downgraded
module-init-tools
udev, volumeid, dmsetup
ifupdown
m-i-t AND ifupdown

None of those fixed it. None of those packages are the problem. The problem is entirely that a bunch of crap was put in /etc/network/interfaces and it timed out waiting for them when they don't even exist. Just clean out that file, and you're good.

I downgraded this package to 0.6.8ubuntu3, the version it was on 4/3/07, and it didn't fix the problem, so the new version is not the problem.

By the way, I wouldn't say removing everything but lo is a "workaround". My /etc/network/interfaces had nothing but lo until the update (cuz network-manager kinda hates any other configuration), then all of a sudden there was junk in there.

Confirmed on a sony vaio vgn-s4hp with Nvidia 6200 Go and ipw2200 wireless.

could everybody please attach their /etc/network/interfaces files

Confirmed on an Abit KN8 SLI mainboard with onboard network.

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet dhcp

auto eth2
iface eth2 inet dhcp

auto ath0
iface ath0 inet dhcp

auto wlan0
iface wlan0 inet dhcp

iface dsl-provider inet ppp
pre-up /sbin/ifconfig eth0 up # line maintained by pppoeconf
provider dsl-provider

Here's my interfaces attached file.

Here's mine in 3 states: normal (before update), yesterday (after update), today (after cleaning it out)

How it normally looks
auto lo
iface lo inet loopback

#auto eth0
#iface eth0 inet dhcp

#auto eth1
#iface eth1 inet dhcp

How it looked yesterday with the slowness:
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet dhcp

auto eth2
iface eth2 inet dhcp

auto ath0
iface ath0 inet dhcp

auto wlan0
iface wlan0 inet dhcp

How it looks now (fast again):
auto lo
iface lo inet loopback

#auto eth0
#iface eth0 inet dhcp

#auto eth1
#iface eth1 inet dhcp

#auto eth2
#iface eth2 inet dhcp

#auto ath0
#iface ath0 inet dhcp

#auto wlan0
#iface wlan0 inet dhcp

Confirmed on Acer TravelMate C310. Putting the hardwired NIC in roaming mode doesn't help. Can't tell you how long I gotta wait because I generally hit CAD to make it skip the step.

Confirm! My feisty install hands for 90 seconds during "configuring network interfaces" - and that's with a 2GHz Core 2 Duo! Intel PRO/Wireless 3945ABG.
I will try deleting everything but lo and see if that improves it.

Confirmed here. The wait seems longer if I don't have an ethernet cable connected, but that's just my gut feeling - I haven't timed it yet.

Toshiba L30-105 laptop running 32-bit Feisty.

09:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
09:04.0 Ethernet controller: Atheros Communications, Inc. AR5005G 802.11abg NIC (rev 01)

I can also confirm the workaround/fix suggested above works. Thank you!

Here is the interfaces file, both Ethernet controllers (wired and wireless) are Intel.

is that really the fix? to comment out the extra adaptors, or does that just happen to work?

thanks.

same problem here... will try the fix...

confirmed for Feisty on black macboook core duo.

sky2 eth0: enabling interface
[ 37.208000] sky2 eth0: ram buffer 48K
[ 38.356000] NET: Registered protocol family 17
[ 43.636000] applesmc: wait status failed: c != 18
[ 87.148000] CIFS VFS: Error connecting to IPv4 socket. Aborting operation
[ 87.148000] CIFS VFS: cifs_mount failed w/return code = -113
[ 93.156000] CIFS VFS: Error connecting to IPv4 socket. Aborting operation
[ 93.156000] CIFS VFS: cifs_mount failed w/return code = -113
[ 93.200000] NET: Registered protocol family 10
[ 93.200000] lo: Disabled Privacy Extensions
[ 93.200000] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 106.536000] ath0: no IPv6 routers present
[ 338.256000] CIFS VFS: Error connecting to IPv4 socket. Aborting operation
[ 338.256000] CIFS VFS: cifs_mount failed w/return code = -101
[ 338.340000] CIFS VFS: Error connecting to IPv4 socket. Aborting operation
[ 338.340000] CIFS VFS: cifs_mount failed w/return code = -101

it hangs for 3-5 mins during this stage. It eventually drops to text mode and shows "Configuring network interfaces..."

then continues booting normally.

hardyn, since Sokraates said that the problem stars after ifupdown is updated, but rolling that update back doesn't fix it, I think what happened is that when that was installed, it included directions or a script to overwrite the /etc/network/interfaces with what we all have (but rolling back didn't involve an undo script). I don't have an Atheros card/driver, yet ath0 was put in there. Prizrak's are Intel, but he has the Atheros interface as well. If it had just reset it to how it was on install, that wouldn't have added ath0 to mine and Prizrak's because we don't have those cards. I think it overwrote the old file. If you notice, it also has 3 eth's. eth0 = wired, eth1 = wireless, eth2 = well, why would you have 3 network cards (or in this case, it's showing 5, really: eth0, eth1, eth2, ath0, wlan0)? Maybe for bridging and routing, or if one is a modem but that's usually ppp I think. Well if you don't have one of those configurations, there shouldn't be an eth2 or that many interfaces listed in general. By extension, if there are more interfaces listed than you have, it just sits there trying to find them ("It says there's 2 more network cards, where are they? *search* I can't find them! *search more* ") and looks like a hang when you boot. Eventually, it times out on that search and moves on with booting.

Ben, sky2 is a crappy crappy driver. There are a ton of bugs against it. I'm just happy I finally realised that sudo modprobe -r sky2 sudo modprobe sky2 will get it going again without a reboot (I've been rebooting constantly because of it). I really wouldn't be surprised if that was a totally unrelated bug that's simply result of sky2's crap-itude.

Just upgrade Feisty and in my case the boot complety hangs on "Configuring network interfaces".
I waited for more than one hour! I tried Safe mode and the same happened. (I´m in windows XP right now)

I have a Core 2 duo 2.16, 1 Gb RAM, Nvidia Go 7300..
I really don´t know what to do.
Any suggestion? Thanks!

I had that too...
boot with CD and mount your harddrive and then remove the network shares from the fstab file.
worked for me.

that's strange about the sky2 driver. I've never had any problems with it other than this. it's been running the Marvell 88E8053 PCI-E Gigabit Ethernet Controller on this macbook since edgy beta without problems. But watch, now that you said that I'll start having that long endless nightmare.

maco:

I rolled back to Feisty Herd 5 and wont do updates until this resolves. I am looking at my interfaces file right now:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet dhcp

auto eth2
iface eth2 inet dhcp

auto ath0
iface ath0 inet dhcp

auto wlan0
iface wlan0 inet dhcp

I only use lo, eth0 and ath0

But even though the others aren't commented herd 5 still boots normally. I don't think it has to do with the *empty* interfaces being there.

David Rodrigues I had the same problem, to pass the "Configuring Network Interfaces" I pressed Ctrl+Alt+Delete, just once, so it killed the process and proceded with the boot sequence.

Here is my /etc/network/interfaces after the update:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet dhcp

And this is how it boots up fast:

auto lo
iface lo inet loopback

#auto eth0
#iface eth0 inet dhcp

#auto eth1
#iface eth1 inet dhcp

Tough the update didn't add any bogus cards (I have one wired and one wireless) commenting them out helped for me. I didn't do any other changes.

I don't know how the default /etc/network/interfaces looks. That was the one I used before and it worked.

Specs: Kubuntu Feisty Beta + updates on HP nx6110, Broadcom 4318 rev2

Confirming bug with slightly different symptom. After the update, my system hung on the "Configuring Network Interfaces" for at least 5 minutes, I think more like 10. I didn't know to try <ctl><alt><del> as posted above.

This is a Gigabyte GA-965GM-S2, intel 965g chipset , of course with Marvell 88E8056. Only one ethernet adapter. However knoppix detects eth0 and eth1, but I have no idea what the second might be.

/etc/network/interfaces after update, showing problem is shown below. Nothing looks strange. But after commenting out the bottom two lines about eth0, I came up fine. Thanks for the info here!

# 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 dhcp

Oops, forgot to say in above that I'm using feisty x86.

Confirming bug with static IP. After commenting out to boot and setting the static address the interfaces looks as:

auto lo
iface lo inet loopback

#auto eth0
#iface eth0 inet static
#address 192.168.1.100
#netmask 255.255.255.0
#gateway 192.168.1.1

#auto eth1
#iface eth1 inet dhcp

#auto eth2
#iface eth2 inet dhcp

#auto ath0
#iface ath0 inet dhcp

#auto wlan0
#iface wlan0 inet dhcp

iface eth0 inet static
address 192.168.1.100
netmask 255.255.255.0
gateway 192.168.1.1

auto eth0

and both my i386 and amd64 feisty's hang.

The /etc/init.d/networking boot scripts hangs because "ifup -a" tries to start many non-existing or not-connected network devices. For many setups/users this script is not necessary at all, since network adapters are managed by network-manager or by detection events. Another workaround is therefore to disable this script:
sudo update-rc.d -n networking remove
(The loopback interface is started by /etc/init.d/loopback)

Sorry, that should be -f and not -n...

Hello again.

Can someone explain me why, whitout any action from me (meaning I didn't change anything at all) suddenly, after a goodnight sleep, the problem as gone.
That's right, Ubuntu Feisty recently upgraded boot normaly.

Any other case like this? explanation?
If happens again I'll let you know.

Thanks again

Quote: "sudo update-rc.d -f networking remove"

Works great!

THX!

Confirmed. Boot delay seems related to DHCP timeout on eth1 (wireless) for unknown reasons.

Confirmed.

I'm running an HP Pavillion dv1000 laptop with centrino 1.7, 512mb ram, and feisty.

auto lo
iface lo inet loopback

iface eth0 inet dhcp

auto eth1
iface eth1 inet dhcp
wireless-essid Virus Haven
wireless-key 1234567890abcdef1234567890

auto eth2
iface eth2 inet dhcp

auto ath0
iface ath0 inet dhcp

auto wlan0
iface wlan0 inet dhcp

 I just told https://answers.launchpad.net/ubuntu/+ticket/4457 to do what Tormod said (sudo update-rc.d -f networking remove), and seeing his description along with what Thomas just said, and guessing this problem and his are linked, could it be what that question-asker said? Maybe it's trying to find all of the wireless networks. Could also explain why not everyone is having the problem. People without wireless cards or who aren't near a wireless network wouldn't notice it.

I Confirm this bug on my IBM R60 with ubuntu 7.04

and the /etc/network/interfaces fix work for me .

THX

First of all, I can confirm this on Feisty, updated last night, with kernel 2.6.20-14-generic (on x86, of course).

Second of all:

"sudo update-rc.d -f networking remove" == nasty hack.
blanking out /etc/network/interfaces == nasty hack.

These scripts are here for a reason -- so you don't have to manually configure your stuff all the time.

Maybe I'm not understanding how this all works, but here's my /etc/network/interfaces:
[code]
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet dhcp

auto eth2
iface eth2 inet dhcp

auto ath0
iface ath0 inet dhcp
wpa-driver madwifi
wpa-conf /etc/wpa_supplicant.conf

auto wlan0
iface wlan0 inet dhcp
[/code]

Now, for people with wired connections running off of dhcp, this hack will work fine. but for people with a little more under the hood, say, atheros madwifi, or static IPs, or several other scenarios, this isn't going to work for obvious reasons -- if i empty out this file, then i'll have to manually configure wifi each time i need it, i.e. every boot. If I remove the networking script, sure, I don't have hang -- because it's not attempting to do anything with networking.

Maybe I'm being naive. I really don't know how this new NetworkManager deal works, and maybe I'm being obtuse and old-fashioned. But this is not a solution.

Steve K.

I've always considered blanking out /etc/network/interfaces to be a normal configuration. The only way to get WPA support with Network Manager is to do that.

Doing those things doesn't hurt anything if you aren't trying to do anything really weird like bridge a connection or have 2 interfaces going at once. As long as only 1 interface is going to be used at a time, wifi radar/network manager/wicd can configure it anyway.

Steve, these are workarounds and not really solutions, yes. However, in most cases the networking script is not necessary because all network interfaces that are marked as "auto" will be enabled by /etc/udev/rules.d/85-ifupdown.rules as soon as they are detected. This is the modern event-based scheme (think upstart). The networking script is an old-world relique that eventually (no pun intended) will disappear AFAIK.

Well, I guess I spoke out of turn. Cry yer pardon!

I blanked out /etc/network/interfaces as described, leaving just the lo interface.

Then i rebooted (no hang, of course) and logged into gnome. I started nm-applet, and it immediately saw my wireless AP (and a neighbor's). I connected, and it asked me for my WPA-PSK, and here we are! I could never find how to activate wpa in gnome-network-manager...but it was there all along. is this new functionality for feisty?

Guess I should let go of my old ways (like 2 years ago, heh) and see what else I can figure out.

Good work on the workaround, and sorry for my critical tone.

Steve K.

Blanking out /etc/network/interfaces is the only way I've found to get WPA-PSK to work with nm-applet. I spent a day trying to figure out then found some site that said to do that, tried it, and that made it work.

Oh, and when I found the site saying to blank out that file to get WPA to work with nm-applet, I was using Dapper. It's been there all along if you knew to clear that file so that nm-applet has full control.

I have this problem too :( takes very looooonng now to boot

I have this problem too. I would rather see a real fix, despite most of the beta userbase being copasetic with kludges like blanking the interfaces file.

Just in case you have disabled the networking script with "sudo update-rc.d -f networking remove" and for some reason or another want to undo this change, you can re-enable the script again with "sudo update-rc.d networking start 40 S ."

I don't think this has anything to do with the contents of /etc/network/interfaces, since ifup won't bother with devices that don't exist.

This is far more likely to be caused to the recent ifupdown update that adjusted the udev rules to try and stop it altering ppp devices, and has uncovered a udev bug.

Confirmed; it was caused by the udev rules update that attempted to only auto ifup/ifdown interfaces with physical hardware. A slight change to the udev rule to behave as we intended (udev has a strange behaviour with S!= rules) fixes this problem and the original problem

Workaround [decent]:

Move networking further down in the boot process.

I moved networking from rcs.d to rc2.d/rc3.d/... and gave it a priority one lower than GDM.

In otherwords 'mv /etc/rcS.d/@##networking /etc/rc2.d/@14networking'

So now GDM boots, followed immediatley by networking. By time I'm in a usable desktop networking has completed and I'm good to go. I find this to be a very suitable work-around as I don't need networking loading any sooner and I don't noticed the hang time at all now.

This issue only seems to happen when a resource is unavailable.. as in if my NIC isnt jacked in.

I've the same problem.
I've a HP Pavilion dv9271 with a ipw3945 wireless card
My friend when also have a HP with a ipw3945 wireless card (not the same model but it's match old.) have the same problem and now he switch back to Windows and he will not use Linux again he says.
Please fix this problem. It's a high problem!

I've tryed Coon's trick and wov now Ubuntu boots fast.

I try I know why this problem exist.
The Network Manager have it's own network settings with wired or wireless network, but that Upstarter don't know and it's try to set the network interfaces up by the /etc/network/interfaces file? Have I right?

This bug has status "Fix released", but you Louis still seem to have this problem. If so, maybe the bug should be reopened.

It doesn't matter if mine is plugged or unplugged, it still hangs.

On 4/11/07, doobiest <email address hidden> wrote:
>
> Workaround [decent]:
>
> Move networking further down in the boot process.
>
> I moved networking from rcs.d to rc2.d/rc3.d/... and gave it a priority
> one lower than GDM.
>
> In otherwords 'mv /etc/rcS.d/@##networking /etc/rc2.d/@14networking'
>
> So now GDM boots, followed immediatley by networking. By time I'm in a
> usable desktop networking has completed and I'm good to go. I find this
> to be a very suitable work-around as I don't need networking loading any
> sooner and I don't noticed the hang time at all now.
>
> This issue only seems to happen when a resource is unavailable.. as in
> if my NIC isnt jacked in.
>
> --
> Feisty boot hangs on "Configuring network interfaces"
> https://bugs.launchpad.net/bugs/102675
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
_______________________________
D. Robert Trembath
e| <email address hidden>

This bug isn't fixed. Please reopen it!

--
Mvh. Louis
Hjemmeside: www.louis.dk
Mail: <email address hidden>
MSN: <email address hidden>
Jabber: <email address hidden> (ikke en mailadresse)
Registreret Linuxbruger nr.: 405248

Since Louis's problem is not related to the original one and isn't compatible with the original bug description ('after today's upgrades'), I suggest opening a new bug would be more appropriate. Louis, if you do open a new report, be sure to include the particular wireless card in the bug description and preferably in its one-line description (name) as well since this might very well be related to the card. Good luck with your friend...

Ok, I've opened a new bug: https://bugs.launchpad.net/ubuntu/+bug/108152