 |
After having a problem that "ip a add" command did not get executing in /etc/rc.local on sytem bootup (see also https://bugzilla.redhat.com/show_bug.cgi?id=843735), I found out that after 'systemctl enable NetworkManager-wait-online.service' the network.service did not fail on bootup anymore. |
 |
Should we close the bug then? |
|
|
Same problem for me. (CentOS-7 with all updates up to Feb 24 2015) févr. 24 16:27:37 is148389 NetworkManager[2171]: <info> startup complete févr. 24 16:27:37 is148389 systemd[1]: Started Network Manager Wait Online. févr. 24 16:27:37 is148389 systemd[1]: Starting LSB: Bring up/down networking... févr. 24 16:27:37 is148389 NetworkManager[2171]: <info> NetworkManager state is now CONNECTED_GLOBAL févr. 24 16:27:37 is148389 NetworkManager[2171]: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-lo ... févr. 24 16:27:37 is148389 network[2571]: Activation de l'interface loopback : Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo' févr. 24 16:27:37 is148389 NetworkManager[2171]: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-lo ... févr. 24 16:27:37 is148389 network[2571]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo' févr. 24 16:27:37 is148389 NetworkManager[2171]: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-lo ... févr. 24 16:27:37 is148389 network[2571]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo' févr. 24 16:27:37 is148389 NetworkManager[2171]: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-lo ... févr. 24 16:27:37 is148389 network[2571]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo' févr. 24 16:27:37 is148389 network[2571]: [ OK ] févr. 24 16:27:37 is148389 network[2571]: Activation de l'interface bond0 : Erreur : aucun périphérique trouvé pour la connexion « bond0 ». févr. 24 16:27:37 is148389 network[2571]: [ÉCHOUÉ] févr. 24 16:27:38 is148389 network[2571]: Activation de l'interface eno1 : Erreur : aucun périphérique trouvé pour la connexion « eno1 ». févr. 24 16:27:38 is148389 network[2571]: [ÉCHOUÉ] févr. 24 16:27:38 is148389 systemd[1]: network.service: control process exited, code=exited status=1 févr. 24 16:27:38 is148389 systemd[1]: Failed to start LSB: Bring up/down networking. |
|
|
CentOS_Bug.JPG (74,050 bytes) |
|
|
CentOS_Bug1.JPG (73,493 bytes) |
|
|
7.1 has been released in the mean. Please update and check if your issue is fixed. |
|
|
The problem still exists with CentOS 7.1 updated 2015-04-29. Motherboard is Supermicro X10DRi with Intel i350 ethernet controller. With NetworkManager-wait-online.service disabled (the default): # journalctl -u network.service Apr 29 14:03:42 ps2 systemd[1]: Starting LSB: Bring up/down networking... Apr 29 14:03:42 ps2 network[1381]: Bringing up loopback interface: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo' Apr 29 14:03:43 ps2 network[1381]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo' Apr 29 14:03:43 ps2 network[1381]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo' Apr 29 14:03:43 ps2 network[1381]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo' Apr 29 14:03:43 ps2 network[1381]: [ OK ] Apr 29 14:03:43 ps2 network[1381]: Bringing up interface enp4s0f0: Error: Connection activation failed: Connection 'enp4s0f0' is not available on the device enp4s0f0 at this time. Apr 29 14:03:43 ps2 network[1381]: [FAILED] Apr 29 14:03:43 ps2 network[1381]: Bringing up interface enp4s0f1: Error: Connection activation failed: Connection 'enp4s0f1' is not available on the device enp4s0f1 at this time. Apr 29 14:03:43 ps2 network[1381]: [FAILED] Apr 29 14:03:43 ps2 systemd[1]: Started LSB: Bring up/down networking. With NetworkManager-wait-online.service enabled (and a small delay added to bootup): # journalctl -u network.service Apr 29 14:19:24 ps2 systemd[1]: Starting LSB: Bring up/down networking... Apr 29 14:19:24 ps2 network[1872]: Bringing up loopback interface: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo' Apr 29 14:19:25 ps2 network[1872]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo' Apr 29 14:19:25 ps2 network[1872]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo' Apr 29 14:19:25 ps2 network[1872]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo' Apr 29 14:19:25 ps2 network[1872]: [ OK ] Apr 29 14:19:25 ps2 network[1872]: Bringing up interface enp4s0f0: [ OK ] Apr 29 14:19:25 ps2 network[1872]: Bringing up interface enp4s0f1: [ OK ] Apr 29 14:19:25 ps2 systemd[1]: Started LSB: Bring up/down networking. An alternative to using NetworkManager-wait-online.service is to edit /usr/sbin/ifup and add sleep 5 before nmcli con up uuid "$UUID" This makes me think there is a race condition between NetworkManager.service and network.service and maybe rhel-import-state.service. |
|
|
I have the same issue. systemctl restart network.service My computer just hung. I start NetworkManager-wait-online.service which doesn't help. Has anybody got a solution yet? |
|
|
I have the same issue on 2 VMs. Other 2 VMs have no problem at all. I also noticed that if I reboot the 2 VMs with the problem, the 2 interfaces will load the wrong configuration while if I shut them down and then start them up again, they will load the correct configuration. |
|
|
I have solved my problem by changing /etc/nsswitch.conf automount: from "nis files" to "files nis". |
|
|
not to me unfortunately :( |
|
|
I actually managed to fix my issue. My configuration files did not have HWADDR set. Once I set it it works fine! Hope it helps! |
|
|
I reported the same issue a while back in case 0007473. I already had HWADDR set in my interface files... so, that was not it. However, I've changed /etc/nsswitch.conf automount: from "files" to "files nis" and that seem to do the trick. |
|
|
I think there are two issues here: 1. Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo' This is generated by command 'nmcli con load /etc/sysconfig/network-scripts/ifcfg-lo' executed by 'ifup' The cause is that NetWorkManager ifcfg-rh plugin does not support loopback interface at all. It expects that ifcfg-* files would all have TYPE variable set, which a default ifcfg-lo does not have. I've managed to work-around this by adding "TYPE=Loopback" there. This would make NetworkManager ifcfg-rh plugin to ignore a file because of unknown type: May 25 15:14:43 batyskaftest.batory.org.pl NetworkManager[751]: <info> parsing /etc/sysconfig/network-scripts/ifcfg-lo ... May 25 15:14:43 batyskaftest.batory.org.pl NetworkManager[751]: <info> read connection 'loopback' May 25 15:14:43 batyskaftest.batory.org.pl NetworkManager[751]: <warn> Ignoring connection 'loopback' of unrecognized type. Loopback would be started anyway - I think by kernel automatically. 2. Failed to activate 'eno1': Connection 'eno1' is not available on the device eno1 at this time. NetworkManager tries to configure a device before it's ready: May 25 15:14:43 batyskaftest.batory.org.pl NetworkManager[751]: <info> (eno1): preparing device May 25 15:14:44 batyskaftest.batory.org.pl NetworkManager[751]: <warn> Failed to activate 'eno1': Connection 'eno1' is not available on the device eno1 at this time. [3 seconds later] May 25 15:14:47 batyskaftest.batory.org.pl NetworkManager[751]: <info> (eno1): link connected May 25 15:14:47 batyskaftest.batory.org.pl NetworkManager[751]: <info> (eno1): device state change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40] May 25 15:14:47 batyskaftest.batory.org.pl NetworkManager[751]: <info> Auto-activating connection 'eno1'. May 25 15:14:47 batyskaftest.batory.org.pl NetworkManager[751]: <info> (eno1): Activation: starting connection 'eno1' This is perfectly normal for an interface to be up only after some seconds, for example because of spanning-tree protocol run. I couldn't find any info on how to force NetworkManager to configure interface ignoring it's hardware connection status though. |
|
|
I have the same issue. I install centOS7 with CentOS-7-x86_64-DVD-1503-01.iso. My network card is Realtek PCIe GBE Family Controller and Broadcom 802.11n network adapter. I check BOOTPROTO in ifcfg-enp14s0 and its value is dhcp. I modified the value of yes to ONBOOT. I use the command service network restart or systemctl restart network,but the result show that is Restarting network (via systemctl): Job for network.service failed. See 'systemctl status network.service' and 'journalctl -xn' for details. I can't connect to a wireless network now under centOS7, but I can switch to windows7 to connect with a wireless network on the same machine. |
|
|
I've solved the problem. |
|
|
My issue was, there were two network files, ifcfg-ens160 and ifcfg-ether. I removed the incorrect one and it fixed part of it. I still have the "RTNETLINK answers: File exists" when restart the network. I wondered if it's because when I clone it in VMWare that I told the clone to add the IP, Subnet Mask, Gateway, and DNS. I will try to clone one w/o adding this in the clone. |
|
|
I had both the "Bringing up loopback interface: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo'" error and the "Failed to activate 'X': Connection 'eno1' is not available on the device X at this time" error. Luckily, I was able to solve both. The first was solved with tometzky's suggestion - adding the line "TYPE=loopback" to the file /etc/sysconfig/network-scripts/ifcfg-lo. The second was more difficult to diagnose. It turned out that the wrong Realtek NIC driver was being used. The clue was in /var/log/messages, where NetworkManager mentioned loading "r8169" for the interface I was having trouble with. The motherboard I was using (an ASUS AM1I-A) had an NIC that required the "r8168" driver instead. I found that driver here: http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3. Once the driver was built and installed, I had to blacklist "r8169" and "mii" to get things working (after a reboot). |
|
|
@brinsky: The r8169 driver from the CentOS kernel is an umbrella which covers all modern Realtek chipsets ( at least r8101, r8168 and r8169 ). Since your chipset was not supported, please file a bug at bugzilla.redhat.com against RHEL 7 ( the kernel component) and mention the information you included in the last paragraph of your comment here, as well as the output of lspci -nn | grep Ethernet |
 |
@brinsky ... and you do not need to build the driver yourself. Use the kmod-r8168 package from ELRepo ( http://elrepo.org/tiki/kmod-r8168 ). |
|
|
@wolfy: Done, thanks (https://bugzilla.redhat.com/show_bug.cgi?id=1247149) @toracat: Good to know, thanks. |
|
|
what is the progress of this bug on the RedHat side? it seems I'm not authorized to view the bug 1247149 |
|
|
#for ifcfg-xxxxx NM_CONTROLLED=yes #for ifcfg-lo TYPE=loopback #using nmtui to edit nic , set automatically connect & activate it. |
|
|
@wpy1971, thank you, it works fine |
|
|
Install rpm package net-tools for resolve this issue. Package net-tools is missing in minimal install for Centos7. |
|
|
Installing net-tools has no effect on the loopback issue on a minimal install. |
|
|
Just to mention that redhat document: https://access.redhat.com/solutions/1549693 is probably the same one. |
|
|
I just ran into this. In my case, manual configuration of network during install. NetworkManager didn't successfully start the interface. We still don't use it or nm-cli, we disable it and use the network.service. Doing that, although I could bring up the interface with ifup ifcfg-em1, the systemctl network.service still failed with the ifcfg-lo error. I fixed it by using tometzsky's suggestion, adding TYPE=loopback (there is a NAME=loopback already there which I left alone.) So, the issue still exists, and, although I didn't investigate thoroughly, exists with NetworkManager left at default after an install where the only defaults changed were configuring a manual address during installation. |
|
|
The upstream article referenced by @elico does describe the issue reported by the OP and it was apparently resolved in RHEL 7.3. |
|
|
Was this issue resolved? It's very simple to find out what the solution for this issue is. |
|
|
The solution consists in adding "TYPE=loopback" to the file /etc/sysconfig/network-scripts/ifcfg-lo , and restarting service. |
- Anonymous
