We installed a fresh copy of CentOS on "HP Proliant DL380p Gen8" and the ethernet interfaces are having this Strange, fluctuating connectivity issue where the interfaces either work with no issues and or are completely dead.
Here are some commands outputs:
Systemctl status network
network.service - LSB: Bring up/down networking
Loaded: loaded (/etc/rc.d/init.d/network; bad; vendor preset: disabled)
Active: failed (Result: exit-code) since Mon 2019-04-15 03:38:16 EDT; 3min 18s ago
Docs: man:systemd-sysv-generator(8)
Process: 6557 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=1/FAILURE)
Apr 15 03:38:14 localhost.localdomain systemd[1]: Starting LSB: Bring up/down networking...
Apr 15 03:38:15 localhost.localdomain network[6557]: Bringing up loopback interface: [ OK ]
Apr 15 03:38:15 localhost.localdomain network[6557]: Bringing up interface eno1: ERROR : [/etc/sysconfig/network-scripts/ifup-eth] Device eno1 does not seem to be present, delaying initialization.
Apr 15 03:38:15 localhost.localdomain network[6557]: [FAILED]
Apr 15 03:38:16 localhost.localdomain systemd[1]: network.service: control process exited, code=exited status=1
Apr 15 03:38:16 localhost.localdomain systemd[1]: Failed to start LSB: Bring up/down networking.
Apr 15 03:38:16 localhost.localdomain systemd[1]: Unit network.service entered failed state.
Apr 15 03:38:16 localhost.localdomain systemd[1]: network.service failed.
ifconfg -a
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
lspci -nn|grep net
03:00.0 Ethernet controller [0200]: Broadcom Inc. and subsidiaries NetXtreme BCM5719 Gigabit Ethernet PCIe [14e4:1657] (rev 01)
03:00.1 Ethernet controller [0200]: Broadcom Inc. and subsidiaries NetXtreme BCM5719 Gigabit Ethernet PCIe [14e4:1657] (rev 01)
03:00.2 Ethernet controller [0200]: Broadcom Inc. and subsidiaries NetXtreme BCM5719 Gigabit Ethernet PCIe [14e4:1657] (rev 01)
03:00.3 Ethernet controller [0200]: Broadcom Inc. and subsidiaries NetXtreme BCM5719 Gigabit Ethernet PCIe [14e4:1657] (rev 01)
Ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
nmcli c
NAME UUID TYPE DEVICE
eno1 2c3315f0-9a56-4c6f-9cab-a55e3a0f7f2d ethernet --
eno2 657324ea-5e27-4d31-a6ce-314227330869 ethernet --
eno3 6c53e522-01ce-4807-bfe1-46266cb45e29 ethernet --
eno4 e7cebe37-3d20-4e34-b951-ea5901c36a1c ethernet --
/etc/sysconfig/network-scripts/ifcfg-eno1
TYPE="Ethernet"
PROXY_METHOD="none"
BROWSER_ONLY="no"
BOOTPROTO="dhcp"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"
IPV6_ADDR_GEN_MODE="stable-privacy"
NAME="eno1"
UUID="2c3315f0-9a56-4c6f-9cab-a55e3a0f7f2d"
DEVICE="eno1"
ONBOOT=yes
HWADDR=2c:76:8a:5d:ea:b8
nmcli device status
DEVICE TYPE STATE CONNECTION
lo loopback unmanaged --
nmcli device status
GENERAL.DEVICE: lo
GENERAL.TYPE: loopback
GENERAL.HWADDR: 00:00:00:00:00:00
GENERAL.MTU: 65536
GENERAL.STATE: 10 (unmanaged)
GENERAL.CONNECTION: --
GENERAL.CON-PATH: --
IP4.ADDRESS[1]: 127.0.0.1/8
IP4.GATEWAY: --
IP6.ADDRESS[1]: ::1/128
IP6.GATEWAY: --
lspci -vv
journalctl -b 0 | grep devices
journalctl -b 0 | grep kernel
journalctl -b 0 | grep module
lspci -vv
(which drivers/modules are in use? There may be known issues with them),nmcli device status
and/ornmcli device show
(there may be recognized but not configured devices) andjournalctl -b 0 | grep <devices' kernel module>
to see if your devices are being renamed on boot. – fra-san Apr 15 '19 at 12:24journalctl
command so I ran devices, kernel and module separately. I also updated the question with new logs, you can check. Thanks! – FS5 Apr 16 '19 at 9:44lspci
you posted has no references to network interfaces, contrasting with the output oflspci -nn|grep net
. Also, no mention of network interfaces injournalctl -b 0 | grep kernel
(nor of bus/device numbers03:00.
) may suggest that the hardware is not properly seen/recognized. – fra-san Apr 16 '19 at 11:1203.00.x
(parts of) PCI addresses should be injournalctl -b 0 | grep kernel
regardless of any driver, since the kernel logs them even before the proper drivers kick in. And since they are not there, we may be seeing a hardware issue (or a hardware configuration issue). – fra-san Apr 16 '19 at 11:41