networking.service fails to start (times out after 5 minutes) when both IPv4 and IPv6 are enabled for an interface about openmediavault HOT 15 CLOSED

The following fix worked for me:

in your /etc/network/interfaces, change this:

# The primary network interface
auto eth0
iface eth0 inet dhcp

to this:

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

Substitute eth0 for all of your ethernet adapter names.

This will start interface eth0 when the kernel detects a hotplug event from the interface (i.e. when you plug a cable in), instead of starting it at boot.

from openmediavault.

This fixed it for me until it gets patched out by omv updates. The gui wil omv first aid will generate good interface configuration files now which won't error out.

Edit:
/usr/share/openmediavault/mkconf/interfaces.d/20ethernet

Remove the line:
-v "concat('auto ',devicename)" -n \

from openmediavault.

I have the same issue after I changed my motherboard and had to reconfigure (enp4s0 changed to enp2s0).

But removing auto (as in refferenced) will propably dissable autostart of the network interface and make the machine after restart not available over network (if I understand correctly what auto does, it autostarts the interface on bootup?).

Before the system also needed some time to boot up but maybe I have never typed:
systemctl status networking.service.
I just looked at ifconfig or similar outputs.

If I disable ipv6 with omv-firstaid all works properly.

I chose both auto (dhcpv6 and slaac?) ways for IPv6 both didn´t work.

The system gets ipv6 (fd55..., fe80..., 2003...) and can ping6 ipv6.google.com and also an ipv6 (2003) of another device in my network.

So all seems to work. But still the networking.service failed. I don´t believe this is good.

from openmediavault.

The same problem didn't occur on Debian prior to installation of OMV

Does this apply to the same machines your using to test OMV? If yes, does the /etc/network/interfaces file looks exact the same? I'm wondering because OMV does not do any special things to the userland network stack.

The only thing that comes into mind is the systemd unit openmediavault-issue. Can you give it a try and disable this unit. Maybe this will fix the boot issue.

from openmediavault.

to this:

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

This is strange because this is exacly what OMV does when it creates the configuration file.

from openmediavault.

Let me clarify, I had to remove auto eth0 line and just have the hotplug line. OMV added it back though, so back to square one.

from openmediavault.

Same Here.

Changed

# enp2s0 network interface                                               
auto enp2s0                                                             
allow-hotplug enp2s0                                                     
iface enp2s0 inet static
(And so on)

To:

# enp2s0 network interface                                               
#auto enp2s0                                                             
allow-hotplug enp2s0                                                     
iface enp2s0 inet static
(And so on)

(I commented auto enps20 Out)
And restarted the status was active and not failed:

root@MyServer:~# systemctl status networking
● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
   Active: active (exited) since Thu 2019-04-18 16:36:03 CEST; 4min 5s ago
     Docs: man:interfaces(5)
  Process: 12972 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=0/SUCCESS)
  Process: 12968 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --read-environment --list --exclude=lo)" ] 
&& udevadm settle (code=exited, status=1/FAILURE)
 Main PID: 12972 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/networking.service

Apr 18 16:36:03 MyServer systemd[1]: Starting Raise network interfaces...
Apr 18 16:36:03 MyServer systemd[1]: Started Raise network interfaces.

@amezin your Problem should be solved.
Is OMV patched to not include "Auto " anymore in the omv-firstaid

But why does it only fail with Auto on when ipv6 is also enabled (haven't tried only ipv6 to see If it fails when both are enabled or if the Problem is in ipv6).

from openmediavault.

#116 (comment)
But it also does put auto in there (Look one Line above in the Code)

from openmediavault.

I just wanted to add that this fixed the issue for me. I was stuck with the UI telling me to save my changes, it was only by having the interfaces file open and constantly saving it as it ran the save changes that I was able to get past this point.

from openmediavault.

Have the same problem with Renegade roc-rk3328-cc arm soc. Tried many hack found at many places. Used last Armbian Buster headless built with latest OMV built. Did everything as in the manual. Re-installed twice just to be sure. Armbian on itself works right (before OMV install). Unfortunately, all fixes I've found are for RPI ot x86 installs, and do no apply here.

So, upon reboot of the device, eth0 is lost. Spends 5 mins trying to boot.

omv-firstaid fixes it, temporarily, until next reboot. Tried dhcp and fixed ip with same results.

Only fix so far: never reboot, always on scenario.

This problem seems to happen for some time, to quite many people, across losts of different platforms. It there a cure? Hope let live they say.

from openmediavault.

So, upon reboot of the device, eth0 is lost. Spends 5 mins trying to boot.

This sounds to me that predictable device names are not enabled, right? Maybe it would help to find this out.

from openmediavault.

Update on my issue I thought was a bug in OMV ended up being that I had accidentally assigned a gateway address to more than one interface, and that was causing the issues. Only setting the gateway for the primary interface fixed my issues.

from openmediavault.

@shbatm I can cross that out, only one interface here - once I've got through omv-firstaid scheme to create it.

@votdev Thanks for the answer. How can I find out? I've read some pages about it, then this https://wiki.debian.org/NetworkInterfaceNames - but I'm kinda lost and over my head.

So please, how and where to look for predictable device names enabling?

Thanks

from openmediavault.

@8jef please use the OMV forum at https://forum.openmediavault.org/ to get support.

@ALL others, from reading this thru my conclusion is that this specific issue has been fixed in 5.x.
In case I got it wrong please reply and provide your OMV version via command "dpkg -l | grep openmediavault"

from openmediavault.

no feedback received, closing

from openmediavault.