1

This doesn't occur very frequently. It did used to happen about 30% of the time, and then I opened the computer and found that the wifi PCI card wasn't screwed in properly. I did the screw up, and now it works correctly almost always (about 95% of the time). It annoys me when the computer starts without network capability, because I can't use it and it means I have to sit through another 103 seconds of reboot, like I did this afternoon.

I got a couple of photos today - the first one "Waiting for network configuration..." that lets me know that I'll have to wait for the process to end and then reboot the computer when it's finished, and the second one "Waiting up to 60 more seconds for network configuration...".

Waiting for network configuration...

Waiting up to 60 more seconds for network configuration...

7
  • "...because I can't use it and it means I have to sit through another 103 seconds..." You can't just manually restart networking or dhclient instead of rebooting? sudo service networking restart ? Aug 9, 2016 at 9:54
  • do you have network mounts in your /etc/fstab
    – Mr.Gosh
    Aug 9, 2016 at 10:43
  • @user4556274 I will try sudo service networking restart the next time it happens. Thanks. Aug 10, 2016 at 4:08
  • My /etc/fstab: # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sda1 during installation UUID=c520dfe7-a7ac-4aa1-a1d4-f6c3f0c55165 / ext4 errors=remount-ro 0 1 (1/2) Aug 10, 2016 at 4:10
  • # swap was on /dev/sda5 during installation UUID=be80b30a-cddf-484d-821a-312a71d7027a none swap sw 0 0 # mount 4f721fc0-8072-453f-b48f-ca686bd89549=sdb1=InternalHDD at boot UUID=4f721fc0-8072-453f-b48f-ca686bd89549 /mnt/InternalHDD ext4 defaults 0 2 (2/2) Aug 10, 2016 at 4:10

3 Answers 3

3

These messages appear while waiting for all interfaces marked as 'auto' in /etc/network/interfaces to come up. On most Ubuntu systems, that's only loopback (127.0.0.1); everything else is done later, via NetworkManager.

This usually happens if you've added something marked as both 'auto' and 'dhcp' in that file, and the DHCP server doesn't immediately respond. You'll see this screen until it does.

It might also happen if the device is "missing," for instance if the PCI card isn't seated properly and isn't recognized, or is defective.

So first, look in /etc/network/interfaces and determine what, aside from lo, is marked as auto (alternatively, use this command to print all the auto interfaces: ifquery --list --allow auto)

Probably, it'll just be your "wifi PCI card," but maybe it's another leftover device you're not using anymore? A wired Ethernet card with no cable plugged in? Remove the 'auto' from anything you don't want to come up at boot (and have to wait for).

If it is just your wireless card, did you mean to configure it this way instead of using NetworkManager? If not, I'd suggest the latter, especially for a wifi interface. Remove the 'auto' and reboot (or just run ifdown [interface] or even ifdown -a), log into the graphical desktop, and use the applet in your panel to set up the connection.

If you don't want to use NM for whatever reason, you probably still don't want to wait for the wireless at boot. In this case you'd remove the 'auto' again, and use the ifup [interface] command to bring it up later. To still do it automatically at boot (but not wait for it), ideally you would create your own upstart script in /etc/init that runs right after static-network-up. If you don't want to figure out how to do that, you could always just slap that command in /etc/rc.local, however.

[interface], by the way, is probably going to be wlan0, but you should verify this by looking at the output of ifconfig -a, when it's working.

On to the actual failure, the next time it happens you're going to have to look at /var/log/syslog to find out exactly why. Since you say it works after you reboot, it's probably not going to be a DHCP server issue. More likely, it's an issue with the device. You might see lines like this:

Aug 13 18:45:44 ubuntu dhclient: Error getting hardware address for "wlan0": No such device

Check to see whether the device even appears in the output of ifconfig -a. If it does, you can manually retry ifup [interface] (or just ifup -a if you never removed the autos) to see if it works without rebooting. If not, start looking at the kernel boot messages (dmesg | less) for anything relevant. Normally there's something printed when the device is first detected, for example:

[ 25.770930] Intel(R) Wireless WiFi driver for Linux
[ 25.770933] Copyright(c) 2003- 2015 Intel Corporation
[ 25.773887] iwlwifi 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control ...
[ 26.110349] iwlwifi 0000:03:00.0: loaded firmware version 18.168.6.1 op_mode iwldvm

Look at your own when it's working to see what it should look like. Then, compare to when it's broken. Are there any errors? Or, is the wireless stuff missing altogether? That, to me, just screams poorly seated or defective card. Make very sure it is fully and firmly in the PCI slot.

If you found other kinds of errors, in syslog or in dmesg, you should probably file a bug. Save everything relevant you found in these logs and output of commands. When you are able to connect, run the command ubuntu-bug networking to create the bug, then attach whatever you saved.

4
  • Thanks @Nathan. I'll start to work through what you say at my earliest opportunity. I might have a chance to start later today. Aug 16, 2016 at 0:39
  • I couldn't work out any way to leave a comment with legible formatting here, so I've written my comments into a pastebin. pastebin.com/A9Ttz2i9 Aug 16, 2016 at 1:28
  • The error happened this morning when I booted, so I took the opportunity to dmesg | less pastebin.com/LXj4y0is and to get /var/log/syslog after the error message pastebin.com/RNx2Rsxu. Aug 18, 2016 at 0:20
  • I compared a "successful boot" version of syslog with a "No network boot", and the same for two versions of dmesg | less output, and I'm none the wiser. I think it's time to give up. Thanks for your time and suggestions. Aug 20, 2016 at 3:02
3
+50

The fact that tightening a screw has an impact on the frequency of the problem indicates (at least to me) that this is a hardware connectivity issue. I would remove the card, carefully clean the contacts on the card and replace it. If this doesn't resolve the problem It doesn't automatically indicate that the card is bad. Try the card in a different slot (or different system) as the slot could be defective, not the card.

8
  • Yes it seems that way to me, too @elder-geek. I re-seated the card yesterday after my post, and it hasn't made any difference (I had another “Waiting for network configuration” episode when I booted this morning). That indicates to me that it is time to move it to another PCI slot. I'll do that later today if I get an opportunity. Aug 18, 2016 at 0:14
  • I've just taken the card out from one PCI slot and installed in another. I have only booted once so far, and it has worked so far (which is not conclusive either way). Aug 18, 2016 at 2:11
  • @el_gallo_azul Best of luck. Thank you for keeping us posted! :)
    – Elder Geek
    Aug 18, 2016 at 17:02
  • Sadly, it did the old "Waiting for network configuration..." routine, followed by no network, when I booted the computer this morning (about 7 hours ago). It's normal for "Waiting for network configuration..." to appear during boot, but it usually disappears after a second or less. I took a copy of syslog and dmesg | less again this morning when it failed, so if I get a chance I'll compare them to each other, and to these outputs from a successful boot (eg. the current one). Aug 19, 2016 at 3:59
  • 1
    i would be suspicious of this card , if at all possible swap out for another identical card to isolate hardware issues. Paritial connection could have blown part of the electronics and occasional failure is good indicator of this. If the frequency of failure increases then bin the card , its dying.
    – Amias
    Aug 19, 2016 at 10:42
0

This problem has never occurred again since I upgraded from Ubuntu 14.04 to Ubuntu 16.04 ten days ago.

This is the first time that such an upgrade has worked successfully for me. Previous upgrade attempts, from 10.04 to 12.04, and 13.04 to 14.04, didn't work, and had to be followed up with installing from a freshly downloaded image, and then several hours of configuration of the system.

2
  • That would certainly be nice. Yes, one would think that: (a) initially tightening the screw; or (b) successfully upgrading the operating system; would either be 100% or 0% successful, but they both seem to have contributed a little bit. Sep 7, 2016 at 7:32
  • Yes. The intermittent nature of this error also led me to believe that it must be hardware-related. I hope it has ended forever. Sep 8, 2016 at 0:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .