https://bugzilla.novell.com/show_bug.cgi?id=849749 https://bugzilla.novell.com/show_bug.cgi?id=849749#c14 --- Comment #14 from Robert Milasan <rmilasan@suse.com> 2014-03-13 08:02:12 UTC --- (In reply to comment #13)
(In reply to comment #12)
In the past due to the naming there were collisions, especially if the user would use virtual function in the already named modules or supported nic's, which usually end-up that the virtual network adapters were called ethX, but the physical adapters end-up to be called renameX (this was due to the persistent rule which had already names setup for the physical adapters, but for the virtual ones, no). Also the virtual adapters can't have a persistent name due to random mac addresses (each reboot, new mac address), so you couldn't actually handle them. I haven't needed those so far, but I would imagine that virtual adapters based in the physical adapters should only be created after the physical adapters have appeared and been renamed. Also I don't know know what kind of persistence is desired if the MAC is generated at random and not saved.
No, the kernel doesn't do the naming of physical or/and virtual nic's on a normal level, meaning is random, which ever comes first gets eth0 and so on. That is why the persistent setup has been implemented in udev. If you have for example 2 nic's, eth0 and eth1, no persistent setup/rules, eth0 can be eth1 and vice-versa, every time you reboot. This means that which ever comes first will get the first name. The kernel doesn't care about the name, it just gives on basis of first come first served. Virtual nic's MAC addresses are random, so persistent naming can't be done, as there is no persistent MAC address at reboot.
If you want to leave it that way, at least make the input field for the interface name in yast (text version) longer (yast lan -> edit -> hardware -> udev rules -> change -> Device name). The field has only 5 characters, and first and last are used as indicators that the content is longer. It looks like this: "-p0s-"
Yast has nothing to do with systemd/udev, thats Yast people. Can you inform them or do you want me to open another ticket for that?
Yes, that would be the best idea. Open a new bug for Yast people.
The kernel names the devices ethX, not a rule, previously we had something called write_net_rules which would generate a persistent rule, which in terms would name the devices ethX (which ever came first got eth0, then eth1, etc). I know, the actual numbers could be different from these that the kernel assigned, but after the first boot the assigned number would be written to the persistent rule, and the name would not change later, ever.
That is the idea for persistent rule as the kernel doesn't keep the same name for the same nic. Problem is we where naming the same way as the kernel the nic's and this is how predictable names where born, never name a nic like ethX, makes it more stable (the concept is good, the practical side, it's a different story).
The new names are based on some logic (which doesn't seem to work well) I understand the logic, but I don't usually care how the motherboard assigns numbers to the slots. We also use /dev/sda and not/dev/sdp3s0. But I know, there are the /dev/disk/by* symlinks, and you can't use symlinks for network names.
I do not argue with you about this and I do understand that is a problem, but there is a workaround for those who have this kind of issue. Also this is how upstream and most other distros are doing it now a days, so to be a bit consistent with the Linux world, we need to keep it as much as possible the same. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.