"waiting for network configuration" Problem
I decided to go the CLI and Alt+Ctrl+F2 approach so YOU ARE FREE to do that while you are logged in to the GUI - Okay, I will write the general steps so feel free to use whatever approach you like.
-
Edit
/etc/network/interfaces
:sudo nano /etc/network/interfaces
-
If you are typing this from LXTerminal while logged in to the GUI then:
gksudo leafpad /etc/network/interfaces
-
-
Remove whatever written there and just keep this:
auto lo iface lo inet loopback
It is very good idea to keep a backup copy of "interfaces" file just in case so please make sure to save a "interfaces.bak" file before you do anything
Ctrl + O if you are using nano and Ctrl + S (File > Save) if you are using leafpad.
Ctrl + X if you are using nano and Ctrl + Q (File > Quit) if you are using leafpad.
Reboot.
Done.
In every situation that I have run into this it is a problem in /etc/network/interfaces
You should not have to remove everything as suggested in an earlier post, but rather inspect for common problems.
In my case it was defining the gateway parameter for additional ethernet IPS. You only need to define the gateway for the primary interface for each card.
What I mean by this is if your file looks like this:
auto eth0
iface eth0 inet static
address 10.0.0.5
netmask 255.255.255.0
network 10.0.0.0
gateway 10.0.0.1
auto eth0:0
iface eth0:0 inet static
address 10.0.0.6
netmask 255.255.255.0
network 10.0.0.0
#gateway 10.0.0.1
The 2nd gateway param will cause ubuntu to hang for 60+ secs during boot, you only need to define the gateway for the first eth0 section, you DO need to define the gateway for any additional nic cards, IE eth1, wlan0 etc but NOT for additional IPS assigned to the same nic. Earlier version of Ubuntu did not have any issues with this, but Ubuntu 12.04 does not like it... Be nice if it could simply ignore it.
I'm sure there are other "problems" in this file that can cause this, so you should inspect the file and make sure there are no typos etc.
This might help too: http://tech.pedersen-live.com/2012/05/disable-waiting-for-network-configuration-messages-on-ubuntu-boot/
Basically you edit this /etc/init/failsafe.conf
file and disable (comment) the sleep
commands which actually pause the system. Besides accomplishing the job, at least in my case there was no error at all in the network configuration, so everything went fine.
By the way, you solution only allows to configure the loopback interface, something I could not afford in my setup (I had to manually setup the interfaces and bridges).
The real(!) solution to this problem is following command:
sudo sed -i.old-`date +%Y%m%d-%H%M%S` '/^auto lo$/!s/^auto /allow-hotplug /' /etc/network/interfaces
In /etc/network/interfaces
this changes all interfaces (except lo
) from auto
to allow-hotplug
. This way the boot is no more waiting for the interfaces to come up first.
Warning: After this change a permanently connected interface might stay down after boot until
systemd
receives a real plug event. See Notes below.
Example before (look at auto eth0
):
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet dhcp
Example after (look at allow-hotplug eth0
):
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp
Notes:
If you mount network shares in
/etc/fstab
, useauto
and notallow-hotplug
for the interface to the network shares. Else you might see strange things happen on boot process, because network must be available prior to network share mounts.allow-hotplug
does not ensure this.-
If the interfaces are in
auto
mode, you express: "These interfaces are crucial for boot, so we must wait for them to come up before we have booted." Hence, if they do not come up, Ubuntu delays the boot with failsafe, waiting for them to appear for up to 120 seconds. And this is the right thing to do.In contrast, Interfaces which are set to
allow-hotplug
tell Ubuntu, that they are optional. Hence they are not essential to boot. Ubuntu records which interfaces are available at install time, and assumes, that they are important for later operation. This is a conservative choice, in case the interface is later needed because some Service binds to it, as such services fail to start if they miss the interface being up.
There also is a kernel setting which allows processes to bind to nonexistent IPs, so you can always use
allow-hotplug
if you like, without harming the stability of the boot process. However, this is a completely different story.
Notes (update 2018-01-04):
At my side,
allow-auto
does the same asauto
, so it does not help (tried withbr0
).After upgrading one of my systems to Debian Stretch and switching to SystemD, boot became unbearably delayed while waiting for the (permanently connected outside) interface
br0
to come up. However withallow-hotplug
the interfacebr0
stayed down after boot. Perhaps this is caused by SystemD not receiving any real or synthetic plug event on such an interface. I did not dig deeper into this, as some obscurecrontab
entry@reboot /sbin/ifup br0
forroot
fixed it for me. (This works, but probably is something, which better should not be recommended to others. I'd like to hear if somebody has some better idea.)
((Text ends here, the rest is for your entertainment))
And here is a bed time story, inspired by this:
Some crops farmers went on rampage. Their crops dried out! So they investigated why there was not enough water in the irrigation ditch. In the nearer distcance they immediately spotted their culprit. The dam! The damned dam held up all the water!
From this moment on it was clear what to do. "Blow up the dam!" they yelled and started to collect their dynamite. Then they all headed straight for the dam.
The little son of one of the farmers asked his father about what was going on. He told his son: "There's not enough water in the ditch, so we blow up the dam!" Then he immediately left to follow the pack.
"But", the little one tried to shout after his father, "But there is a valve! Just open the valve!" Sadly, his voice was too gentle, and his legs were too short, so this message did not reach anybody.
The boy sat down and cried. Half an hour later he heared the distant "Boom" which destroyed his favorite plaground at the dam, where the valve was located, too.
What happened next?
The Flood swept away all the precious crops. The bank took away the boy's father's farm. His father was unable to pay for a good school. So the boy joined the army to get a higher education. There he learned everything about the phyics of explosives and now tries to invent a blast resitant dam.
What has this story to do with this here?
- The crops farmers are the other answers.
- The little boy is this answer here.
- The dam is the Ubuntu failsafe sleeping.
- The valve is the proper interface setting.
- The water is the boot process.
- The crops is your Ubuntu OS.
- And the filled ditch is, how the boot process should look like.
The setting of the interface, which lives in /etc/network/interfaces
, is blown up with the sleep in failsafe removed, and even if somebody sees the closed valve (auto
), nobody spottet that it could be openend as well!