Failed to start LSB :Bring Up down Networking [closed] - centos

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 10 months ago.
Improve this question
I am new to CentOS 7 and I am configuring a static IP on CentOS 7, so I have edited the file /etc/sysconfig/network-scipts/ifcfg-eth0 as following:
TYPE=Ethernet
BOOTPROTO=none
Device=eth0
ONBBOOT=yes
IPADDR=192.168.4.196
NETMASK=255.255.255.0
GATEWAY=192.168.88.254
DNS1=8.8.8.8
USERCTL=no
But when I issue the command
systemctl restart network
I am getting the error
failed to start LSB :/Bring Up down Networking
ip route show gives me no output.
I have applied the solution that stops NetworkManager with the same existing error.
I am able to configure a dynamic DHCP and get a dynamic IP address but not static one.
What can be possible solutions?

Answer 1

Its because of interface issue
Solution worked for me was:
Check the interface available
cp ifcfg-eno16780032 ifcfg-ens192
vi ifcfg-ens192 and change NAME and Device field to ens192
systemctl disable NetworkManager
systemctl status NetworkManager -> inactive
systemctl stop network
systemctl start network
After that check ip a
get the details of IP and able to ping that IP.

Answer 2

You should change BOOTPROTO to static and move your DNS config to your /etc/resolv.conf file, for example:
TYPE=Ethernet
BOOTPROTO=static
PHYSDEV=eth0
ONBBOOT=yes
IPADDR=192.168.4.196
NETMASK=255.255.255.0
GATEWAY=192.168.88.254
USERCTL=no

Answer 3

When facing this issue that derailed proper autossh functionality on my roaming laptop, I decided to rip apart whatever of my MageiaOS code to understand the root cause. I did not have NetworkManager, so knew for sure it was not the obstacle.
The found issue could be described as kind of eventual live-lock between SysV and systemd ways of managing network service. Potentially, many conditions could trigger it (NetworkManager is one of the examples), in my case it was misconfigured vboxnet ifaces from VMWare.
There're two critical blockers in each part of SysV/systemd balance that might start triggering each other in the loop. On SysV side, init.d/network script eventually calls "ifup $device boot", which in response of 'boot' parameter starts ifplugd daemon for pluggable ifaces. The problem with this daemon that despite of '-I' switch (used to ignore errors) it still fails with exit code 4 upon detecting itself in memory. The only proper way to shutdown this daemon from network script is issuing "ifdown $device boot" command, which is supposed to get executed upon stopping network service by 'service' or 'systemctl' commands.
The interesting part of this question: why ifplugd is already in memory before the network service starts? Well, in my case WiFi iface was fired before misconfigured vbox iface but the latter caused entire initscript to fail. So, network was started on boot but service status was recorded as failing. But what prevents us just stopping network service and consequently killing ifplugd from ifdown/boot command? The answer is: systemd in its ingenious ways of handling ExecStop directive in unit file (which is auto-generated on the fly for network service). Basically, "systemctl stop" command just ignores ExecStop directive if it believes that the service is not started. Well, of course it is not because... if previously failed stumbling on unexpected ifplugd instance! So, no way to stop the service, hence no way to get rid of ifplugd, hence no way of (re)starting the service and so on.
Conclusion. There's no single recipe for this sort of trouble because the compatibility balance between network script and systemd approach is very fragile, so many unexpected factors can start interfering. To troubleshoot this scenario, several statuses might be useful:
network service: systemctl status network
ifplugd service: ps ax|grep ifplugd
network link status: ifconfig / iwconfig
autogenerated unit: cat /var/run/systemd/generator.late/network.service
other places running ifup independently: grep -rs ifup /etc
and of course, "bash -x" and debugging "echo Bump" instruction. :-)
Long-term solution is fixing ifplugd to honour '-I' switch in this scenario. Mid-term solution is fixing /etc/sysconfig/network-scripts/ifup-eth for ignoring ifplugd return code. Short-term solution seems to be the most tricky, which is just removing all possible config factors triggering this live-lock. But this is the only one tolerating system autoupdates...

Answer 4

Execute tee /etc/modprobe.d/*blacklist*.conf <- "blacklist ideapad_laptop"
Then reboot. This should unblock your Wi-Fi.

Answer 5

I came here looking for a answer to my case so I'll share, maybe it will help someone else. I'd like to thank cPanel staff for pointing this out to me
As for the reported issues, we have seen the CloudLInux servers running a kernel version lower than "3.10.0-862" and update to Cloudlinux 7.7, they will get an update to the 'iproute' package.
The 'iproute' package needs to wither a newer kernel or to be excluded from updating onto the server initially.
This information has been reported. You can find some more information about it here:
https://www.cloudlinux.com/cloudlinux-os-blog/entry/cloudlinux-os-7-7-released

Answer 6

In my case
journalctl -xe
Shows there was a duplicate interface configuration eth0 & eno1 using the same UUID:
Nov 06 09:35:41 4200-150-137 /etc/sysconfig/network-scripts/ifup-eth[27549]: Device eno1 does not seem to be present, del
Nov 06 09:35:41 4200-150-137 network[27401]: [FAILED]
Nov 06 09:35:41 4200-150-137 network[27401]: Bringing up interface eth0: [ OK ]
removing the unused interface ifcfg file solved the problem for me.

Answer 7

After several trials including restarting of network manager, commenting out the UUID on the interface concerned (mine being ifcfg-eth0), it finally boiled down to a missing file which apparently needs to be included despite the fact that its values can be included directly in the interface file.
vi /etc/sysconfig/network
then add your right values and save:
NETWORKING=yes
HOSTNAME=xxx.xxx.xxx
GATEWAY=x.x.x.x
I hope this helps someone. It is tested on CentOS 7 as a guest VM on Hyper V on Windows 10.

Answer 8

I have VPS with OVH and have been struggling with similar issue.
Just wanna share my solution as it can help some people.
It used to delay boot by 5 minutes, dhclient was checking ipv6 on ifup call.
Set this to no
DHCPV6C=no
inside /etc/sysconfig/network-scripts/ifcfg-eth0

Answer 9

I know this is an old discussion but i had this problem on my bare metal server from ovh after disable NetworkManager service by installing CPanel
This issue solved by adding bellow parameters' in ifcfg-eno1 (or in your case any active interface)
LINKDELAY=31
NM_CONTROLLED=no
ONBOOT=yes
DHCPV6C=no
Also note that you have activated the network service