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.
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"
VM1:/etc/udev/rules.d>
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.
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.
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.
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”.
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/99-default.link
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
...
DEVPATH=/devices/pci0000:00/0000:00:17.0/ata3/host2/target2:0:0/2:0:0:0/block/sdb
DEVNAME=/dev/sdb
DEVTYPE=disk
MAJOR=8
MINOR=16
ACTION=add
SUBSYSTEM=block
DONT_DEL_PART_NODES=1
ID_ATA=1
ID_TYPE=disk
ID_BUS=ata
...
ID_PART_TABLE_TYPE=gpt
COMPAT_SYMLINK_GENERATION=2
TAGS=:systemd:
USEC_INITIALIZED=4175914
Unload module index
Unloaded link configuration context.
erlangen:~ #
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:~ #
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.
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! 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
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
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
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?
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):
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