Strange Device Labeling In 6.3

Home » CentOS » Strange Device Labeling In 6.3
CentOS 13 Comments

I have just installed 6.3 on a machine that was previously running
5.8. Under 5.8 eth0 was eth0. Now with 6.3 /sbin/ifconfig gives me lo, wlan0 and p4p1 (instead of eth0). I would like to make the ethernet a static IP as I intend to for this to be machine used on my LAN only. However, when I do /usr/sbin/setup -> Network Configuration the device is not listed. Can anyone tell me why this is happening and how I can fix it. Or if not how I can set a static and persistent IP address for the ethernet?



13 thoughts on - Strange Device Labeling In 6.3

  • Well……

    I tend to agree with the slashdot commentator who called it overcomplicated and unnecessary. It’s another idea from Fedora, the theory, IIRC, was that this way, devices would always have the same name, whereas under the method that has been used device names could change on a reboot. (Haven’t experienced that myself, but dunno).

    If you google Fedora biosdevname you’ll come across various explanations. To change it back once the thing’s been installed, I’ve always done it by first rpm -e biosdevname, then editing /etc/sysconfig/network-scripts/ifcfg-whatever, changing the device name in there to eth0, changing the name of the file, e.g, ifcfg-p4p1 to ifcfg-eth0 and restarting. I haven’t gotten it working by just restarting networking, but at any rate, if you know you don’t want it during installation, you can add biosdevname=0 to the command line.

  • Scott Robbins wrote:

    Yup. The difference between that, and sticking the MAC address into a simple, existing config file is, oh, that’s right, it’s k3wl.

    I have. Putting the MAC address into ifcfg-eth? fixes it.

    EXCEPT that in 6.x, you really need to edit
    /etc/udev/rules.d/70-persistant-net.rules, too, or take the MAC out of ifcfg-eth?, since it needs to be in 70-blahblah.


  • If it’s as simple as sticking the MAC address into the ifcfg-eth file, I can live with that. But only ifcfg script that exits in
    /etc/sysconfig/network-scripts/ is ifcfg-lo

    I have no idea what k3wl is.

    Thanks for the replies.

    2012/8/9, :

  • Richard Reina wrote:

    Script-kiddie speak. 3 == e. I was being sarcastic (about the fedora developers).

    There should be *something*. Sounds like something’s missing in the network part of your install.


  • The difference _should_ be that you could ship a pre-installed disk to a remote site where it meets up with an freshly shipped server chassis and the on-site person racking it up can know which NIC to put which cable in and have it come up working. But, I think that’s only possible with Dells.

    That assumes that you know the MAC address at the time you’d like to configure the image. That’s rare for me. As are on-site people fluent in linux.

  • try editing


    change p4p1 to eth0 as the value for NAME


    hope this helps


  • this has happened to me a couple of times worst case:

    eth0 = unused realtek onboard eth1 = intel nic used for lan1
    eth2 = intel nic used for lan2
    eth3 = intel nic used for wan

    realtek onboard nic dies during a server reboot

    eth1 -> eth0 = unused eth2 -> eth1 = lan1
    eth3 -> eth2 = lan2

    firewall rules now apply lan2 rules to the wan

    with MAC address pinning, none of the interfaces come up because the addresses do not match the names.

    very lucky that was not off-site


  • +1

    Alternatively, with the biosdevname, you can pin the interface name to the pci(e) slot. That way its a trivial exercise to get ‘remote hands’
    to swap out a dead nic — no need to fiddle with the mac address.


  • And if you don’t…

    Doing remote hands to swap a bad NIC with someone non-Linux qualified in another country, just became the seriously sucky part of your day. BTDT. Got the t-shirt.


  • No, it always has been since the 2.4 kernel days when a deterministic scan order would always give the same name to the same NIC position.
    2.6 has always been a matter of chance if you have more than one card and don’t pin with the MAC address (pairs on cards or the motherboard stay together and keep the order within the set, but the pairs will swap).

  • The idea actually came from Dell. It’s frequently described as a method to prevent the device name from changing during a reboot, but that was already in place. What biosdevname does is make names *predictable* on Dell systems. It shouldn’t be enabled anywhere else.

    As you stated, the documented method of turning the feature off is to add biosdevname=0 to the boot configuration (which means rebooting).