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. :\

    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.

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.

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

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"

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.

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.

Thank you, the old mac is indeed there. I will edit and fix.

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.

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.

Mailing list discussion about this…

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

If you want to force the use of predictable network interface names,
then, giving biosdevname=1 net.ifnames=1 should work.

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

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).

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. 1. 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”.

Users may list current naming scheme:

erlangen:~ # udevadm test-builtin net_id /sys/class/net/enp0s31f6
Load module index
Parsed configuration file /usr/lib/systemd/network/
Created link configuration context.
Using default interface naming scheme 'v243'.
Unload module index
Unloaded link configuration context.
erlangen:~ # 

See also the fine documentation:

Users may override using /etc/udev/rules.d/70-persistent-net.rules.

Kernel command line settings override all of the above: net.ifnames=0,1

See also:—useage-examples

erlangen:~ # udevadm test /block/sdb
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.

Load module index
Parsed configuration file /usr/lib/systemd/network/
Created link configuration context.
Reading rules file: /usr/lib/udev/rules.d/00-dont-del-part-nodes.rules
Reading rules file: /usr/lib/udev/rules.d/01-md-raid-creating.rules
Reading rules file: /usr/lib/udev/rules.d/10-dm.rules
Reading rules file: /usr/lib/udev/rules.d/11-dm-mpath.rules
Unload module index
Unloaded link configuration context.
erlangen:~ # 

My system has:

erlangen:~ # lsblk -o NAME,UUID,PARTUUID,PTUUID
NAME        UUID                                 PARTUUID                             PTUUID
sda                                                                                   27c8c52a-8091-403c-adf1-e9c791667d40
├─sda1      **fad3604b-5a61-4653-8c14-518d850400ba** 2c0e640c-3df5-470a-a17c-89b17eba59d8 
├─sda2      3760cc8d-f468-4654-855b-afcd31071075 410b7947-08ad-4fb7-93ea-854f63a3bf78 
└─sda4      f5177cae-4082-44ed-9471-b99030f06866 1f1100a4-325e-4d9e-84a3-bc119b98a449 
sdb                                                                                   90c1973b-4a41-4e96-85ba-b7358ea77ccc
├─sdb1      **4A24-B10D**                            2fe6b58a-379a-4f6e-899b-8be22ef6e885 
├─sdb2      690b51d7-7034-4585-b362-615f8056be45 f1379b6c-304b-4606-98b8-5cec4f3dd678 
├─sdb3      492c5d5e-5d9b-4a99-9d34-e1f9cee09fe9 1e7b0509-97cf-4a62-b7fc-db46be72335b 
├─sdb4      f4c5463f-f43d-420a-a0ea-4456cfbc54fa ced907e6-2af7-42d8-8643-31a61479352b 
└─sdb5      204f7d0f-979a-41e1-a483-a597d0357e0b f4880da8-3641-499b-81b6-4432b106f8ff 
nvme0n1                                                                               a84f222e-0177-499b-a7ea-bda6f31e2196
├─nvme0n1p1 047d4d83-a9a7-482e-8d15-a1c855a637ea 6c573fc1-08a3-4a7c-94bb-5488c8a0ba91 
├─nvme0n1p2 8b190950-c141-4351-9198-7a9592b4fb34 f756cc7f-1727-4f82-8c5e-5b4468a74e72 
├─nvme0n1p3 704621ef-9b45-4e96-ba7f-1becd3924f08 63413441-e35b-41a7-9dab-536a91b8f418 
└─nvme0n1p4 6DEC-64F9                            0497bfdf-73d7-47a8-9d8e-6b911574f774 
erlangen:~ # 

I exclusively rely on UUID:

erlangen:~ # cat /mnt/etc/fstab 
# /etc/fstab: static file system information.
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=**fad3604b-5a61-4653-8c14-518d850400ba** /              ext4    defaults,noatime 0 1
UUID=**4A24-B10D**                            /boot/efi      vfat    defaults,noatime 0 2
erlangen:~ # 

Always check /etc/fstab for valid UUIDs. :wink:

I beg to differ.

I was the HP systems engineer that had to come up with an HPUX Unix and Linux fix for over 200 machines that had this issue that had multiple ethernet ports. The customer was seeing issues with connections after a reboot on some machines and had to physically go to the rack and force a reboot on the affected card. HPUX 10.20 fix was easy as the hardware address was easily retrieve and renaming the port was a system call. Redhat (was the Linux Vendor) came up with the naming convention, not me, I wanted to have the BIOS sort the hardware addresses then order them not on the order that the interrupts showed up but by bus location. This was a few kernels ago - hint Pentium III CPU at 450mhz was the state of the art and Y2K was the main issue. These were machines to test Y2K problems and some of the 1st high density rack mount machines. Dell’s rack mount did not have this problem with their BIOS - HP did. At the time these HP motherboards had to have the BIOS chip popped out to change it and apparently there was not enough space left to do this and there were 1000’s of these being installed so no change was made. Hopefully all of these rack machines have been retired as they consumed a lot of electricity and generated a lot of heat.

My temporary fix for Redhat Enterprise Linux was to get the mac address and id (eth0) and if it was not the same as installed order force a reboot until it was (usually took 2 tries to get the same order). If they have changed the kernel to look up hardware to do the same as the poor designed BIOS - someone should have rejected that idea as brain dead - they still could sort the responses by hardware id and be always in the same location.

It feels like change for no good reason again.

My 2 cents.

Very interesting discussion, thanks guys! I accepted the predictable names as resident evil, they bug me more than a decade, and now I see I’m just two kernel parameters away to get rid of them. Neat! :slight_smile: How many % of linux PCs have more than one adapter anyway? Surely it will be more % than windows PCs, but I think this is fine example, where minority spoils the life of the majority. It should have been opt-in, not opt-out :wink:

Thank you, Karl, but since I work with most of my linux PCs remotely, I don’t think I have the balls to rely on UUIDs anymore :shame: I liked them too, till this thursday when I realised, that change of system can also change UUID and make system unbootable. I did the swap on site, so no big deal, there was no need to travel to fix that, but I got a lesson. I think I better rename e2label to prevent screwing up. When I will see cnf e2label, I will (hopefully) recall why not do that :wink:

Still thinking of the UUIDs, are they at least always the same in the same system, or can they change under some circumstances too?

AsI I tried to explain there are many UUIDs around in the world. And as this thread is about naming of network interface devices (which have no UUID, but have MAC addresses), I must assume that you are going off topic and maybe ask about the UUIDs that can be used for mounting.

When that is correct. As said, these UUIDs are a property of file systems and they are stored inside a file system. They are created anew when a new file system is created. Thus normaly, when you do not create a new file system, they stay as they are (even if you move the file system to another computer). But one can change the UUID of at least some type of file systems. E.g. look at

man tune2fs

and you will see that you can change the UUID of an ext2/3/4 file system with

tune2fs -U <UUID> ...........

The situation where an eth1 is created when you move your disk to another system is easily explained…

When you set up your network interface in the original network, even if configured as a DHCP client all settings are based on connecting to the network using the configured MAC address, and every hardware NIC is assigned a world-unique MAC address when it’s manufactured.

When you moved your hard drive to another system, when the system booted up for the first time it didn’t find the NIC with the configured MAC address but found another with a different MAC address, so created a new interface configuration for the new NIC.

Known Workarounds and solutions…

  • Remove the NIC from the original system and install in the new.
  • Before shutting down the system on the original hardware the last time, delete/remove the network interface configuration.
  • Edit the interface files directly, copying the essential information (MAC address in particular) from eth1 to eth0.

Is similar to what happens in a VM when you move it from one network to another, typically the new deployment is configured with a new MAC address so that if the original machine was ever booted up it the two machines wouldn’t conflict.


Thank you again for patience with explaining. How that happened with eth1 have been perfectly explained and I know it surely. UUIDs have been perfectly explained too. But what caused the change of UUID of the same partition on the same disk, that is still not quite clear. To explain better, system tried to boot, but halted half way with wait message and time count (I don’t remember exactly the message), but it waited indefinitely (there was no time limit). I suspect it was because of btrfs partition, which I have for extra data mounted to /mydata. And UUID of this partition must have been different in the new system. I don’t know if I put into fstab the UUID of the GPT partition, or UUID of btrfs, because I was not aware (before this discussion) that the very same thing can have multiple UUIDs. It was surely my mistake, I simply picked up “variable” UUID. But how can I distinguish persistent UUID from one that will can change when placed into other system?

@karlmistelberger]( : so those UUIDs marked with bold font should be those persitent across systems, right?

When you use YaST > System > Partionerto manage your partitions and file systems, and there choose to mount a file system by UUID, YaST will be clever enough to use the correct UUID.

When you look in /dev/disk, you will see something like:

henk@boven:/dev/disk> l
total 0
drwxr-xr-x  8 root root  160 Nov 18 09:47 ./
drwxr-xr-x 20 root root 4100 Nov 18 09:47 ../
drwxr-xr-x  2 root root  780 Nov 18 09:47 by-id/
drwxr-xr-x  2 root root  100 Nov 18 09:47 by-label/
drwxr-xr-x  2 root root   60 Nov 18 09:47 by-partlabel/
drwxr-xr-x  2 root root  120 Nov 18 09:47 by-partuuid/
drwxr-xr-x  2 root root  280 Nov 18 09:47 by-path/
drwxr-xr-x  2 root root  120 Nov 18 09:47 by-uuid/

You can of course look in all those directories and you will find the file system UUIDs in by-uuid. You will find the partition UUIDs in by-partuuid, but only for GPT partitions.

And please re-read your own last post above. You are still talking about a partition UUID that would have changed, but I assume you mean file system UUID instead, because that is what is normaly used for /etc/fstab, kernel parameter resume, etc.

As long as you do not realy understand the difference between a partition (the box) and it contents (the file system) you will have problems undrstanding much of these things. Remind that file systems (contents) can also be stored in other boxes then partitions, like Logical Volumes, whole disks, RAID devices. Remind also that file systems are not the only type of contents that can be stored in these different boxes, think e.g. of Swap space.

Hello and thank you very much for reply. I understand it does not look like it, but I can surely tell the difference between device, partitions and filesystems on them, I was confused just about the uuids and which of them are used. Now what is actually very interesting, that UUIDs did not change:O, yet the new system fails to boot with them (luckily I have kept those non functional, just commented them out):

ls -la /dev/disk/by-uuid/
total 0
drwxr-xr-x 2 root root 240 Nov 22 12:28 .
drwxr-xr-x 8 root root 160 Nov 21 17:30 ..
lrwxrwxrwx 1 root root  15 Nov 21 22:15 **03345cc9-cd7f-4e67-b8ae-893342501433** -> ../../nvme0n1p3
lrwxrwxrwx 1 root root  10 Nov 21 17:30 0940ed5f-4343-4d89-be0a-015083bdf579 -> ../../sda4
lrwxrwxrwx 1 root root  15 Nov 21 23:37 1f5787e9-b8ed-475b-9be3-4b7dc5db7278 -> ../../nvme0n1p5
lrwxrwxrwx 1 root root  10 Nov 21 17:30 4ccd3339-f992-4e6e-aac9-744fe2f26f0f -> ../../sdb1
lrwxrwxrwx 1 root root  10 Nov 21 17:30 **56990d56-8249-42fa-b149-d3aae69cf2f0** -> ../../sdg1
lrwxrwxrwx 1 root root  15 Nov 21 22:15 B5D3-BCA7 -> ../../nvme0n1p2
lrwxrwxrwx 1 root root  15 Nov 21 22:15 B5E3-931B -> ../../nvme0n1p1
lrwxrwxrwx 1 root root  10 Nov 21 17:30 d5695e9c-3636-4a34-b9b0-4e2f2bfd59d1 -> ../../sda3
lrwxrwxrwx 1 root root  15 Nov 21 22:15 **eb62815f-8d7d-4250-b9a0-2f72dc1fd407** -> ../../nvme0n1p4
lrwxrwxrwx 1 root root  10 Nov 21 23:42 f3a39d2f-b333-4457-b6ec-ecf6339987e7 -> ../../sda5

sudo cat /etc/fstab
LABEL=opensuse  /      ext4   noatime,acl,user_xattr  0  1
LABEL=nvmeboot  /boot  ext4   noatime,acl,user_xattr,data=ordered  0  2
LABEL=vms       /vm    btrfs  defaults  0  0
#UUID=**03345cc9-cd7f-4e67-b8ae-893342501433**  /      ext4  noatime,acl,user_xattr  0  1
#UUID=**56990d56-8249-42fa-b149-d3aae69cf2f0**  /boot  ext4  noatime,acl,user_xattr,data=ordered  0  2
#UUID=**eb62815f-8d7d-4250-b9a0-2f72dc1fd407**  /vm    btrfs  defaults  0  0

So the new question is why I cannot boot with these uuids?