https://bugzilla.novell.com/show_bug.cgi?id=849749 https://bugzilla.novell.com/show_bug.cgi?id=849749#c12 --- Comment #12 from Robert Milasan <rmilasan@suse.com> 2014-03-11 12:03:09 UTC --- (In reply to comment #11)
(In reply to comment #10)
This issue seems to be due to hardware, but also because of the implementation currently available in systemd/udev.
Basically, that upstream said, is that the BIOS or hardware in general does this and it shouldn't (cheap hardware, broken firmware, broken BIOS, etc). The board is from Gigabyte, so not exactly a cheap one.
Gigabyte doesn't come across expensive motherboard. I understand you payed some good money for it, but it's not what I would consider expensive motherboard (it's not the point, just part of the idea).
Is there a specification that says that the assigned numbers have to be the same across reboots? If not, then it is not cheap/broken hardware, but a flawed assumption in the software.
I, honestly, not sure what direction to take here Can you tell me a single advantage of the new system, compared to the previous state of opensuse? The previous state was not to let the kernel assign random numbers, but to make once assigned interface names permanent. Exactly what this change promised to bring, and exactly what it took away. And before, I had the predictable name eth0 for the common case, a machine with only one network interface, instead of enp3s0 or whatever. Even if this name was persistent, it would still be worse than before.
Logically, the predictable name should be 100% stable across reboots and you can't have 2 nic's named the same, like ever, due to the construction of the actual naming. That would be the idea, now that is doesn't always work well, thats something else. 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.
There is a workaround for this issue, meaning manually create the persistent rule, but some people may not like the idea of having to do some extra work.
Great, extra work for things that used to work automatically.
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. 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). The new names are based on some logic (which doesn't seem to work well) en (ethernet adapter) pX (port number, based on the location on the motherboard) sX (slot number, based on the location on the motherboard) So you got: enp0s3, means ethernet adapter on port(bus) 0 and slot 3. -- 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.