ifup wait at boot

fredg · 2017-10-30 12:36:53

Hello,

I am running Devuan Ascii on a laptop.

The boot process is a little bit long because of ifup.

When I boot with eth0 cable unplugged in the bootup log sequence I get:

Configuring network interfaces...
ifup: waiting for lock on /run/network/interfaces/ifstate.eth0

Then, the boot wait for about 1 min and I got the message:

ifup: interface eth0 already configured

And, boot continues.

f@g:~$ 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).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

Any clue ?

++

fsmithred · 2017-10-30 12:50:50

Replace 'allow-hotplug' with 'auto'.

fredg · 2017-10-30 13:05:30

When done, it hangs a bit on :

DHCPDISCOVER on eth0 to 255?255.255.255....

So, as wicd manage the network on the laptop, I have chosen to remove all eth0 related things on the config file. And, of course, it works
Is it a good way or not ?

++

fredg · 2017-10-30 13:57:02

The interfaces config file sources /etc/network/interfaces.d/*

What files do you have in that directory?

No files.

Ok for the advices. Thank you very much.

++

MiyoLinux · 2017-12-19 00:19:26

I've tried everything in this thread, and none of it helped me with the delay at start-up in Ascii.

As I build all of my systems from a base system, there have been times that I haven't experienced the delay on some Ascii builds, but at other times, I did.

So, I compared a "delay build" with a "no-delay build". I eventually ended up replacing the "network" file in a "delay build" with the one from a "no-delay build" found in /etc/intid.d/networking.

That got rid of the delay, and the boot process flies again to my login screen. However, I now have a "Failure" notification in networking during the boot process. It goes so fast that I can't catch enough of it to write it down. Yet, networking works perfectly after booting into the desktop. Might take some more investigating.

golinux · 2017-12-19 00:41:52

Are you booting without a connection? https://lists.dyne.org/lurker/message/2 … ed.en.html

MiyoLinux · 2017-12-19 00:48:11

golinux wrote:

Are you booting without a connection? https://lists.dyne.org/lurker/message/2 … ed.en.html

Well, on my builds with the delay, the delay only occurred if the Ethernet wasn't plugged in. If I had an Ethernet wire plugged in, there was no delay. Still haven't figured out why some builds have this issue and some don't.

ralph.ronnquist · 2017-12-19 01:40:44

Just a little bit of background:

When '/etc/network/interfaces' (or any one of its sourced files) includes a line "auto eth0", it is a signal to the networking init script, that it should bring up eth0 on boot. That init script has been improved to not consider the cable status, but simply bring up the interface and run dhclient for getting it configured.

When '/etc/network/interfaces' (or any one of its sourced files) includes a line "allow-hotplug eth0", it is a signal to udev, that it should bring up eth0 on boot (and also keep monitoring for later cable events). Its control script has been improved to not consider the cable status, but simply bring up the interface and run dhclient for getting it configured.

Of course, dhclient is only used as part of bringing up the interface if '/etc/network/interfaces' also has the line 'iface eth0 inet dhcp'.

If you are using a network manager, then you should avoid telling the networking init script or udev to bring up eth0, but rather let the network manager daemon deal with it. Whether that induces a boot delay or not depends on whether it has been improved in parity with the scripts.

btw, for the sake of clarity: I write 'improved' but I mean 'destroyed'.

MiyoLinux · 2017-12-19 02:18:56

ralph.ronnquist wrote:

Just a little bit of background:
When '/etc/network/interfaces' (or any one of its sourced files) includes a line "auto eth0", it is a signal to the networking init script, that it should bring up eth0 on boot. That init script has been improved to not consider the cable status, but simply bring up the interface and run dhclient for getting it configured.
When '/etc/network/interfaces' (or any one of its sourced files) includes a line "allow-hotplug eth0", it is a signal to udev, that it should bring up eth0 on boot (and also keep monitoring for later cable events). Its control script has been improved to not consider the cable status, but simply bring up the interface and run dhclient for getting it configured.
Of course, dhclient is only used as part of bringing up the interface if '/etc/network/interfaces' also has the line 'iface eth0 inet dhcp'.
If you are using a network manager, then you should avoid telling the networking init script or udev to bring up eth0, but rather let the network manager daemon deal with it. Whether that induces a boot delay or not depends on whether it has been improved in parity with the scripts.
btw, for the sake of clarity: I write 'improved' but I mean 'destroyed'.

Thank you r.r; I appreciate it sir.

Yet, I'm still confused. Yes, I include a network manager in my builds; however, I follow a guideline in how I build. Therefore, all builds are the same, yet some builds have this delay while others don't. Strange...strange indeed.

greenjeans · 2017-12-20 21:30:01

MiyoLinux wrote:

Thank you r.r; I appreciate it sir.
Yet, I'm still confused. Yes, I include a network manager in my builds; however, I follow a guideline in how I build. Therefore, all builds are the same, yet some builds have this delay while others don't. Strange...strange indeed.

Well now i'm confused. All my Vuu-do builds trace back to the original Miyolinux I started with, and I have never experienced this issue.

Just for clarity though: The builds were started offline completely, from a clean install of Miyolinux (liveCD), and never to this day have I plugged in an ethernet cable to the laptop I build with, all updating is done through wi-fi.

I do delete a LOT of stuff that might otherwise stay in a normal install, especially before I roll an iso, my Refracta-excludes file is relentless.

Last edited by greenjeans (2017-12-20 21:32:49)

dxrobertson · 2018-05-19 21:18:38

I know this is an old thread, but still relevant; I just encountered this problem. Thanks to ralph.ronnquist, that was my very issue.

I had performed an install without desktop and only later did I install NetworkManager along with KDE. My etc/network/interfaces had a allow-hotplug eth0 in it. Removing the config for eth0 fixed the boot delay and the "ifup: waiting for lock on /run/network/interfaces/ifstate.eth0" message is nolonger displayed.

figdev · 2018-05-19 21:33:14

dxrobertson wrote:

Removing the config for eth0 fixed the boot delay and the "ifup: waiting for lock on /run/network/interfaces/ifstate.eth0" message is nolonger displayed.

there is a lot of information in this thread. could you confirm which line you edited in which file?

its easy to try stuff out if youre having this problem and can reboot to tell if its fixed-- its less easy to just try out if youre not having this problem and want to prevent it. hence "which line" and "which file" (and what change) if someone could confirm, thanks.

you changed: allow-hotplug eth0

to: auto eth0

in the file: /etc/network/interfaces ?

thanks.

Last edited by figdev (2018-05-19 21:36:30)

dxrobertson · 2018-05-19 21:46:09

The file is etc/network/interfaces.

The contents before the modification:

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

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

The file contents after the modification (the fix):

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

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

figdev · 2018-05-19 22:52:54

thanks very much!

menuhin · 2018-10-01 12:05:34

Hi Forum members,

This behavior also exhibits in my laptop: a long ifup eth0 wait with the 'allow-hotplug eth0' line in etc/network/interfaces

It seems to be a known Debian bug as well:

https://bugs.debian.org/cgi-bin/bugrepo … bug=838871

Ogis1975 · 2018-10-01 16:28:14

Same bug here.

MiyoLinux · 2018-10-01 22:22:24

This affects only wireless network connections from my experience. Wired isn't affected.

The fix is shown above, and it has worked for me for months and months. I include this fix in MiyoLinux releases also. As root, open the file /etc/network/interfaces

Save a copy of that file (before editing it) somewhere just in case you need to put it back.

You can comment out lines if you prefer, but I personally remove everything in that file and leave only the following two lines...

auto lo
iface lo inet loopback

Save the file. Close it. Then reboot. The delay should be gone,

Ogis1975 · 2018-10-03 17:41:00

MiyoLinux wrote:

This affects only wireless network connections from my experience. Wired isn't affected.

Hello. I am on wired connection. I do not have wireless connection. It is a desktop.

climbingturtle · 2019-03-15 22:20:57

Hi. Just want to say I also had this problem for a long time and can not remember when it appeared. The solution that worked for me was what people here have suggested, commenting out the lines: allow-hotplug eth0,,, iface eth0 inet dhcp

fsmithred · 2019-04-11 21:15:19

The DNG message that golinux linked earlier in this thread is gone. I think I know what it pointed to - there was a patch submitted by Didier Kryn for /etc/init.d/networking that fixes the problem. I have the patch, and I have the message in my mail. Both are copied below.

I don't know if the line numbers in the patch are still correct, but I do know that it works in ascii. I've applied it manually.

Le 22/12/2017 à 08:49, KatolaZ a écrit :
> On Fri, Dec 22, 2017 at 08:40:37AM +0100, Didier Kryn wrote:
>> Hello.
>>
>> I've now switched to ASCII for my personal laptop (amd-64 arch) and I
>> found it working well, better for me than Jessie.
> Hi Didier,
>
> that's pretty good news
>
> [cut]
>
>> A regression with respect to the older releases of Debian and Devuan is
>> the new /etc/init.d/networking script. I have sent on the list a patch to
>> correct this file. I aso had to change /etc/interfaces: previously I had
>> "allow-hotplug wlan0"; now I still have it, plus "auto wlan0", otherwise
>> wlan0 is not always started at boot time. This ifpudown logic is rather
>> convoluted and I fall down to this kind of tricks.
>>
> Could you please send a patch to /etc/init.d/networking (it's very
> difficult to retrieve it from the ML)? I am not looking forward to
> fork ifupdown, to be honest. It would be better maybe to submit the
> patch upstream (i.e., to Debian).
Seems the patch introducing the regression is from the author, not from Debian. It is in the form of a patch in the source of the package, but I didn't find where this patch is applied. Maybe, as suggested by Svante, I should modify the patch so that it changes the behaviour only if systemd is installed, and propose this modification to the author.
Didier

check-link-state.patch

--- networking~	2016-09-16 15:02:20.000000000 +0200
+++ networking	2017-12-18 17:25:49.902781233 +0100
@@ -112,7 +112,12 @@ ifup_hotplug () {
 			    done)
 	    if [ -n "$ifaces" ]
 	    then
-		ifup $ifaces "$@" || true
+		# link detection does not work unless we up the link
+		ip link set "$iface" up || true
+		if [ "$(cat /sys/class/net/$link/operstate)" = up ]
+		then
+		    echo "$iface"
+		fi
 	    fi
     fi
 }

Geoff 42 · 2019-04-24 14:47:55

As I am looking at a simple set-up with no network manager, I was looking at this patch to get past the disconnected eth0.

I am not too good at some of the scoping in some of these languages, but I think that in this patch that $iface and $link are not defined when we get to use them. I think that $ifaces is defined and in my case I only have one interface with allow-hotplug, so putting $ifaces in this patch seems to work for me, although probably not strictly correct.

Geoff

geki · 2019-07-07 10:11:27

JFYI, this looks more sane, as Geoff pointed out. I wonder, if the dependency to iproute2 is acceptable.

--- /etc/init.d/networking	2019-07-07 12:05:57.696076136 +0200
+++ /etc/init.d/networking	2019-07-07 12:11:41.412092526 +0200
@@ -14,6 +14,7 @@
 IFSTATE="$RUN_DIR/ifstate"
 STATEDIR="$RUN_DIR/state"
 
+[ -x /sbin/ip ] || exit 0
 [ -x /sbin/ifup ] || exit 0
 [ -x /sbin/ifdown ] || exit 0
 
@@ -107,7 +108,12 @@
 				    link=${link##.*}
 				    if [ -e "/sys/class/net/$link" ]
 				    then
-					echo "$iface"
+					# link detection does not work unless we up the link
+					ip link set "$iface" up || true
+					if [ "$(cat /sys/class/net/$link/operstate)" = up ]
+					then
+						echo "$iface"
+					fi
 				    fi
 			    done)
 	    if [ -n "$ifaces" ]

Jafa · 2019-08-21 17:33:53

For the primary network interface, changing the interface from using "dhcp" to "manual" solves this ..

Kiergan · 2021-10-11 10:44:50

Hi,
I have this problem when booting for the 1st time after installing the net-install and also the server-install Devuan 3.1.1 Beowulf.
How can I make the needed changes when I can not boot?
Do I need to get a rescue-cd or is it possible to modify the installer?

I have not had this problem before, with older versions.

Edit:

I booted with a rescue-cd and modified the file etc/network/interfaces
Now it boots, but I get no IP, (state DOWN)

This is very inconvenient.

edit:
/sbin/ifconfig eth0 up
dhclient

gave me an IP.

How to fix this, so it will get an IP on boot, like normal?

Last edited by Kiergan (2021-10-11 11:31:17)

ralph.ronnquist · 2021-10-11 12:31:40

It sounds like your /etc/network/interfaces should have the normal configuration setup for eth0 of

auto eth0
iface eth0 inet dhcp

Yes, you can use an installation iso as a (limited) rescue system for an installed system. Just start the installation and use ctrl-alt-f2 at the very first dialog. That brings you to a command line, where you can mount the installed root partition onto /mnt, and then chroot into that for various hands-on.

The officially official Devuan Forum!

#1 2017-10-30 12:36:53

ifup wait at boot

#2 2017-10-30 12:50:50

Re: ifup wait at boot

#3 2017-10-30 13:05:30

Re: ifup wait at boot

#4 2017-10-30 13:57:02

Re: ifup wait at boot

#5 2017-12-19 00:19:26

Re: ifup wait at boot

#6 2017-12-19 00:41:52

Re: ifup wait at boot

#7 2017-12-19 00:48:11

Re: ifup wait at boot

#8 2017-12-19 01:40:44

Re: ifup wait at boot

#9 2017-12-19 02:18:56

Re: ifup wait at boot

#10 2017-12-20 21:30:01

Re: ifup wait at boot

#11 2018-05-19 21:18:38

Re: ifup wait at boot

#12 2018-05-19 21:33:14

Re: ifup wait at boot

#13 2018-05-19 21:46:09

Re: ifup wait at boot

#14 2018-05-19 22:52:54

Re: ifup wait at boot

#15 2018-10-01 12:05:34

Re: ifup wait at boot

#16 2018-10-01 16:28:14

Re: ifup wait at boot

#17 2018-10-01 22:22:24

Re: ifup wait at boot

#18 2018-10-03 17:41:00

Re: ifup wait at boot

#19 2019-03-15 22:20:57

Re: ifup wait at boot

#20 2019-04-11 21:15:19

Re: ifup wait at boot

#21 2019-04-24 14:47:55

Re: ifup wait at boot

#22 2019-07-07 10:11:27

Re: ifup wait at boot

#23 2019-08-21 17:33:53

Re: ifup wait at boot

#24 2021-10-11 10:44:50

Re: ifup wait at boot

#25 2021-10-11 12:31:40

Re: ifup wait at boot

Board footer