Hi,
I've done my fair share of CentOS 7 installations, but this is the first time I have this kind of weird problem. Here goes.
In my office I have a battered Dell Optiplex 320 PC with two NICs that I'm using as a bare metal sandbox server for testing purposes.
The CentOS 7 installer sees the connected network card as eth0. But after the first reboot, the interface comes up as eth1.
My first reflex was to rename ifcfg-eth0 to ifcfg-eth1 and edit it accordingly. Weirdly enough, on the subsequent reboot the interface comes back as eth0.
I took a peek in /etc/udev/rules.d to see if there was any persistent interface definition, but the directory is empty.
On a side note, I installed Ubuntu Server 16.04 LTS on that same machine and got the exact same problem. Debian installer sees the main network interface as eth0, but on the first reboot the interface comes back as eth1.
Any suggestions ?
Niki
Very strange and as you suggested delete the ifcfg-eth0 file and recreate, specify your settings. I suspect your wireless device and or systemboard is faulty. Is there a BIOS hardware self-test you could perform to check the integrity of your hardware?
On Sun, Feb 9, 2020, at 8:10 AM, Nicolas Kovacs wrote:
Hi,
I've done my fair share of CentOS 7 installations, but this is the first time I have this kind of weird problem. Here goes.
In my office I have a battered Dell Optiplex 320 PC with two NICs that I'm using as a bare metal sandbox server for testing purposes.
The CentOS 7 installer sees the connected network card as eth0. But after the first reboot, the interface comes up as eth1.
My first reflex was to rename ifcfg-eth0 to ifcfg-eth1 and edit it accordingly. Weirdly enough, on the subsequent reboot the interface comes back as eth0.
I took a peek in /etc/udev/rules.d to see if there was any persistent interface definition, but the directory is empty.
On a side note, I installed Ubuntu Server 16.04 LTS on that same machine and got the exact same problem. Debian installer sees the main network interface as eth0, but on the first reboot the interface comes back as eth1.
Any suggestions ?
Niki
-- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12 _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Salim
Le 09/02/2020 à 14:52, Salim Shaw a écrit :
Very strange and as you suggested delete the ifcfg-eth0 file and recreate, specify your settings. I suspect your wireless device and or systemboard is faulty. Is there a BIOS hardware self-test you could perform to check the integrity of your hardware?
There is no wireless device on this PC.
Just an onboard NIC and then an additional PCI NIC.
Hello, Am Sonntag, 9. Februar 2020, 14:10:44 CET schrieb Nicolas Kovacs:
Hi,
I've done my fair share of CentOS 7 installations, but this is the first time I have this kind of weird problem. Here goes.
In my office I have a battered Dell Optiplex 320 PC with two NICs that I'm using as a bare metal sandbox server for testing purposes.
The CentOS 7 installer sees the connected network card as eth0. But after the first reboot, the interface comes up as eth1.
My first reflex was to rename ifcfg-eth0 to ifcfg-eth1 and edit it accordingly. Weirdly enough, on the subsequent reboot the interface comes back as eth0.
I took a peek in /etc/udev/rules.d to see if there was any persistent interface definition, but the directory is empty.
On a side note, I installed Ubuntu Server 16.04 LTS on that same machine and got the exact same problem. Debian installer sees the main network interface as eth0, but on the first reboot the interface comes back as eth1.
Any suggestions ?
this is coming from The NetworkManager?
I set in my config *-eth0 the HWADDR=XXXXXXXXXXXX and NM_CONTROLLED=no
Le 09/02/2020 à 15:15, Günther J. Niederwimmer a écrit :
this is coming from The NetworkManager?
I set in my config *-eth0 the HWADDR=XXXXXXXXXXXX and NM_CONTROLLED=no
I forgot to add : I removed NetworkManager as I do on all my servers.
Le 09/02/2020 à 14:10, Nicolas Kovacs a écrit :
Any suggestions ?
I forgot to add. The onboard NIC is a Broadcom card.
$ lspci | grep -i net 02:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 10) 02:09.0 Ethernet controller: Broadcom Inc. and subsidiaries BCM4401-B0 100Base-TX (rev 02)
This card gets randomly renamed to either eth0 or eth1 after every reboot.
This is weird.
Am 09.02.2020 um 16:14 schrieb Nicolas Kovacs:
Le 09/02/2020 à 14:10, Nicolas Kovacs a écrit :
Any suggestions ?
I forgot to add. The onboard NIC is a Broadcom card.
$ lspci | grep -i net 02:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 10) 02:09.0 Ethernet controller: Broadcom Inc. and subsidiaries BCM4401-B0 100Base-TX (rev 02)
This card gets randomly renamed to either eth0 or eth1 after every reboot.
This is weird.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...
Example 11.4
"Kernel always uses the ethX naming convention at boot when it enumerates network devices. Due to parallelization, the order of the kernel interface enumeration is expected to vary across reboots."
Alexander
Le 09/02/2020 à 16:54, Alexander Dalloz a écrit :
"Kernel always uses the ethX naming convention at boot when it enumerates network devices. Due to parallelization, the order of the kernel interface enumeration is expected to vary across reboots."
Thanks for the heads up.
I experimented quite a bit, and found some surprising behavior. So I documented everything in a little blog article.
* https://www.microlinux.fr/interfaces-reseau-persistantes/
Cheers,
Niki
On Sun, 9 Feb 2020 at 13:51, Nicolas Kovacs info@microlinux.fr wrote:
Le 09/02/2020 à 16:54, Alexander Dalloz a écrit :
"Kernel always uses the ethX naming convention at boot when it
enumerates
network devices. Due to parallelization, the order of the kernel
interface
enumeration is expected to vary across reboots."
Thanks for the heads up.
I experimented quite a bit, and found some surprising behavior. So I documented everything in a little blog article.
Cheers,
So yeah if there are certain cards, certain bios firmware, the eth? are not guarenteed. The upstream kernel will say it is not a bug as everything is doing what it is doing, and will point out various things where eth? is really an internal kernel representation which is only accurate by luck. What you are supposed to do is rename the interface (I think the docs I found said net0 or whatever you want) and link the two via udev or similar rules. That way the udev sets up and sees 'this pci/network is blah.. alias it to net0 and pass that so the scripts work. Then network-scripts or networkmanager or whatever sets up and down net0 versus a 'semi-random' eth interface. [For kernels beyond 4.?? and beyond I am expecting that this will be a more stringent requirement]
There may be ways to force NIC naming, I've done so but only on Ubuntu so you'll need to do the research if it's important to you. Things to look for based on my experience: 70-persistent-net.rules, net.ifnames=0, biosdevname=0.
________________________________ From: CentOS centos-bounces@centos.org on behalf of Nicolas Kovacs info@microlinux.fr Sent: Sunday, February 9, 2020 12:51 PM To: centos@centos.org centos@centos.org Subject: [EXTERNAL] Re: [CentOS] CentOS 7 : network interface renamed from eth0 to eth1 after reboot
Le 09/02/2020 à 16:54, Alexander Dalloz a écrit :
"Kernel always uses the ethX naming convention at boot when it enumerates network devices. Due to parallelization, the order of the kernel interface enumeration is expected to vary across reboots."
Thanks for the heads up.
I experimented quite a bit, and found some surprising behavior. So I documented everything in a little blog article.
* https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.microlinux.fr%2finte...
Cheers,
Niki
-- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.microlinux.fr&c=... Mail : info@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12 _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Harriscomputer
Leroy Tennison Network Information/Cyber Security Specialist E: leroy@datavoiceint.com
[cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG]
2220 Bush Dr McKinney, Texas 75070 www.datavoiceint.comhttp://www..com
This message has been sent on behalf of a company that is part of the Harris Operating Group of Constellation Software Inc.
If you prefer not to be contacted by Harris Operating Group please notify ushttp://subscribe.harriscomputer.com/.
This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message.
On Mon, Feb 10, 2020 at 03:12:11PM +0000, Leroy Tennison wrote:
There may be ways to force NIC naming, I've done so but only on Ubuntu so you'll need to do the research if it's important to you. Things to look for based on my experience: 70-persistent-net.rules, net.ifnames=0, biosdevname=0.
I cheated; I use NIC teaming, and before starting networking, run a script that iterates over NICs, picking up their current device names, and scripting the if-cfg* files.
I had to do this when a few years ago, Dell was getting clever about renaming NICs aggressively, and nothing could trust 'eth0' anymore. Now, I always get a 'bond0'.
(Oh, and I also disabled NetworkManager, because, like systemd, it tries to be Too Clever for it's own good.)
Overkill for most, I admit, but it make my installation media much more portable.
Le 10/02/2020 à 16:12, Leroy Tennison a écrit :
There may be ways to force NIC naming, I've done so but only on Ubuntu so you'll need to do the research if it's important to you. Things to look for based on my experience: 70-persistent-net.rules, net.ifnames=0, biosdevname=0.
That's exactly the solution I described in detail in my blog article.
:o)
On 2020-02-11 00:09, Nicolas Kovacs wrote:
Le 10/02/2020 à 16:12, Leroy Tennison a écrit :
There may be ways to force NIC naming, I've done so but only on Ubuntu so you'll need to do the research if it's important to you. Things to look for based on my experience: 70-persistent-net.rules, net.ifnames=0, biosdevname=0.
That's exactly the solution I described in detail in my blog article.
Having messed a lot with this renaming issue in the past, I can tell you there is only one thing that you have to do for stable ethernet naming, just have "HWADDR=" in your ifcfg-* scripts.
See
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...
(you can stop reading at rule 1)
Regards.
-
Alexander Dalloz -
Brian Reichert -
Günther J. Niederwimmer -
Leroy Tennison -
Nicolas Kovacs -
Roberto Ragusa -
Salim Shaw -
Stephen John Smoogen