Page 1 of 3 123 LastLast
Results 1 to 10 of 25

Thread: eth0 vs eth1 abd enp31s0 and disk UUIDs

  1. #1

    Default eth0 vs eth1 abd enp31s0 and disk UUIDs

    Hi, I noticed, that opensuse 15.1 uses sane network interface names (nice!), but to my surprise, in one system I had eth0, then transferred this very same disk to another system (actually with exactly tha same components, just different MAC), but now I have eth1. Why? From the old good days I remember eth0 was always the first card. To have it more interesting, my tumbleweed desktop uses "insane" (they call it predictable) ethernet names.

    Code:
    [    1.757118] r8169 0000:03:00.0 eth0: RTL8168g/8111g at 0xffffc90001951000, xx:xx:xx:xx:xx:xx, XID 0c000800 IRQ 33
    [    1.757124] r8169 0000:03:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
    [    1.791448] r8169 0000:03:00.0 eth1: renamed from eth0
    [    3.969432] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
    [    4.042152] r8169 0000:03:00.0 eth1: link down
    [    4.042152] r8169 0000:03:00.0 eth1: link down]
    Actually, my first surprise after swapping systems was, that UUID of nvme disk (or partition?) changed (I'm /booting from USB, then from nvme) , so it failed to boot. I had to edit fstab and use volume labels instead. If that would be windows, I'd not be surprised, but linux? I loved that I can run the same disk in every system I get my hands on, but this seems to be no longer truth. I thought UUIDs were meant to be unique for each device, but they are not. Now my first and the only ethernet card in system is eth1 instead of eth0. No big deal with eth1 (still better than enps-whatever-no-one-can-remember) , but different naming between opensuse versions? Could you please explain me, what is going on? I don't mind changes, not even for the worse , but I'm a bit confused. I'm also not very happy with boot by the labels in fstab, they can easily be changed by mistake, so what disk naming should I use in fstab? Thank you.

  2. #2
    Join Date
    Sep 2012
    Posts
    5,230

    Default Re: eth0 vs eth1 abd enp31s0 and disk UUIDs

    Quote Originally Posted by pruda View Post
    transferred this very same disk to another system (actually with exactly tha same components, just different MAC), but now I have eth1. Why?
    Interface names are assigned based on MAC by default. eth0 was already assigned, different MAC means different interface which gets new name.
    my tumbleweed desktop uses "insane" (they call it predictable) ethernet names
    This is technical forum. If you cannot avoid this language, do not post here.
    I thought UUIDs were meant to be unique for each device, but they are not
    UUID has nothing to do with device, it is filesystem property. Show full string that you call "UUID" in both systems.

  3. #3
    Join Date
    Jul 2018
    Location
    Loma Linda, Mo
    Posts
    115

    Default Re: eth0 vs eth1 abd enp31s0 and disk UUIDs

    to fix back to eth0 you need as root to delete the entries in /etc/udev/rules.d/70-persistent-net.rules

    just use vi or leafpad or any editor

    udev justs add entries so the old eth0 is still in the file - reboot after delete the entries will add a new eth0 - here is one with 3 entries

    Code:
    VM1:/etc/udev/rules.d> cat 70-persistent-net.rules
    # This file was automatically generated by the /usr/lib/udev/write_net_rules
    # program,run by the persistent-net-generator.rules rules file.
    #
    # You can modify it,as long as you keep each rule on a single
    # line,and change only the value of the NAME= key.
    #
    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:77:8f:65", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:d2:24:72", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:10:17:45", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
    VM1:/etc/udev/rules.d>
    Opensuse 15.1 with VirtualBox VM's (Windows 98, XP, 7, 8.1, 10 & OpenSUSE 15.0)

    Unix since 1974 (pdp-11 in "B" , Interdata 7/32 in "C") (AT&T, Tandy, Convergent, IBM, NCR, HP flavors)
    Linux since 1995 (mandrake, redhat, fedora, centos, now OpenSUSE)

  4. #4
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    25,387

    Default Re: eth0 vs eth1 abd enp31s0 and disk UUIDs

    Many things can have UUIDs. The UUIDs used by openSUSE as default way of addressing file systems are in fact UUIDs of the file systems, not of the partitions and certainly not of the disk. In GPT partitioning, the partitions also do have UUIDs. So take care.

    The LABELs you mention are also a property of file systems. Feel free to use what you think is the best in your environment. And you can choose a different method for every file system you want to mount, like e.g. by UUID for disks that are always to be present (/, /home, /database. ...) and by LABEL for "walk around and plug in where needed" devices.

    I do not think there is much want for UUIDs for NICs, They already have a unique id: the MAC address.
    Henk van Velden

  5. #5

    Default Re: eth0 vs eth1 abd enp31s0 and disk UUIDs

    Quote Originally Posted by arvidjaar View Post
    If you cannot avoid this language, do not post here.
    Did I really told that much? I was not about to offend anyone. Sorry. I will be even more careful with words next time. And thank you for explaining.

    Quote Originally Posted by larryr View Post
    to fix back to eth0 you need as root to delete the entries in /etc/udev/rules.d/70-persistent-net.rules
    Thank you, the old mac is indeed there. I will edit and fix.

    Quote Originally Posted by hcvv View Post
    Many things can have UUIDs...
    Thank you for your time with very detailed reply, now I understand better.

    Anyone know, why OS15.1 uses traditional ethX, but Tumbleweed uses enp... names? I'm just curious.

  6. #6
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    12,889
    Blog Entries
    3

    Default Re: eth0 vs eth1 abd enp31s0 and disk UUIDs

    Quote Originally Posted by pruda View Post
    Did I really told that much? I was not about to offend anyone.
    I think arvidjaar is not a native English speaker. He may have been confused by your wording.

    Incidentally, the network interface on this Leap 15.1 system is "p4p2". But it is "eth0" on another system that I checked.
    openSUSE Leap 15.1; KDE Plasma 5;
    testing Leap 15.2Alpha

  7. #7
    Join Date
    Jun 2008
    Location
    Auckland, NZ
    Posts
    20,713
    Blog Entries
    1

    Default Re: eth0 vs eth1 abd enp31s0 and disk UUIDs

    Quote Originally Posted by pruda View Post
    Anyone know, why OS15.1 uses traditional ethX, but Tumbleweed uses enp... names? I'm just curious.
    Mailing list discussion about this...

    https://lists.opensuse.org/opensuse-factory/2019-03/msg00089.html


    As I said, Leap 15.1 should be based on SLE-15-SP1. Although we give
    predictable network interface names a try during SLE-15 development as
    you can see in this blog post [1], it finally was not adopted.

    So for Leap 15.X it should be the same, that is the classic naming
    scheme.

    If you want to force the use of predictable network interface names,
    then, giving biosdevname=1 net.ifnames=1 should work.
    Last edited by deano_ferrari; 16-Nov-2019 at 18:27.
    openSUSE Leap 15.1; KDE Plasma 5

  8. #8
    Join Date
    Jul 2018
    Location
    Loma Linda, Mo
    Posts
    115

    Default Re: eth0 vs eth1 abd enp31s0 and disk UUIDs

    This works in Redhat and Centos - not sure about Tumbleweed as I am on 15.1. You should only need the net.ifnames=0 if you run vmware or virtualbox you might need the bios.devname=0 part.

    simply putting or adding to GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0 bios.devname=0" in /etc/default/grub will go back to the old naming convention on the reboot.
    If you change this file, run 'grub2-mkconfig -o /boot/grub2/grub.cfg' afterwards to update
    Opensuse 15.1 with VirtualBox VM's (Windows 98, XP, 7, 8.1, 10 & OpenSUSE 15.0)

    Unix since 1974 (pdp-11 in "B" , Interdata 7/32 in "C") (AT&T, Tandy, Convergent, IBM, NCR, HP flavors)
    Linux since 1995 (mandrake, redhat, fedora, centos, now OpenSUSE)

  9. #9
    Join Date
    Jul 2018
    Location
    Loma Linda, Mo
    Posts
    115

    Default Re: eth0 vs eth1 abd enp31s0 and disk UUIDs

    Code:
    Anyone know, why OS15.1 uses traditional ethX, but Tumbleweed uses enp... names? I'm just curious.
    The enp (the predictable) came about as some BIOS reorder the adapters at boot and without a nice udev file like 70-persistent-net.rules with mac address to name like Opensuse uses that preserve the name assigned to the mac address. The predictable uses the hardware address as that should not change if the BIOS order is different.

    It basically is a solution to solve a bad BIOS design. Ironically it only effects machines with more than 1 Ethernet adapter (hint servers).
    Opensuse 15.1 with VirtualBox VM's (Windows 98, XP, 7, 8.1, 10 & OpenSUSE 15.0)

    Unix since 1974 (pdp-11 in "B" , Interdata 7/32 in "C") (AT&T, Tandy, Convergent, IBM, NCR, HP flavors)
    Linux since 1995 (mandrake, redhat, fedora, centos, now OpenSUSE)

  10. #10
    Join Date
    Sep 2012
    Posts
    5,230

    Default Re: eth0 vs eth1 abd enp31s0 and disk UUIDs

    Quote Originally Posted by larryr View Post
    some BIOS reorder the adapters at boot and without a nice udev file like 70-persistent-net.rules with mac address to name like Opensuse uses that preserve the name assigned to the mac address
    That's incorrect - problem has very little to do with BIOS ordering but is due to non-deterministic order of hardware scan when kernel boots.
    The predictable uses the hardware address as that should not change if the BIOS order is different.
    1. These names (those variants used usually by default) are not "predictable" given any sensible meaning of the word "predictable". Try to guess interface names before installing on new hardware (e.g. to specify them on installer command line). The names may be considered "persistent" in that they rarely change. The only variants that can be considered "predictable" are based on onboard index or PCI hotplug slot number - if you are sure your hardware actually exports this information. I doubt any user on this forum has such hardware.
    2. The names - except based on MAC - are BIOS dependent and will change if BIOS order is different (where "BIOS order" here usually means "PCI enumeration order" on standard x86 platform). It is not uncommon to plug new adapter in your system and to find that all "predictable" interface names have changed. Or after BIOS update which changed enumeration order.


    It basically is a solution to solve a bad BIOS design
    Absolutely wrong. It is solution to avoid maintaining unique interface names database in user space - something that never worked reliably for whatever reasons. So developers "solved" it by effectively relying on BIOS and generating names that are supposed to be unique for current boot and so avoiding need to maintain unique names themselves. Even that fails sometimes - exactly because "uniqueness" depends entirely on BIOS (or in general firmware) implementation.

    What this solution certainly does not do is "solving bad BIOS design". Just try to report any problem associated with "predictable" names - the only upstream answer is "it is your BIOS problem, it does not concern us, contact your vendor".

Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •