Description of problem: When trying to add a VLAN device to a nic or to a bond using ip, it is not created properly. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. run "ip link add dev eth1.100 link eth1 type vlan id 100" 2. run "ip link show eth1.100" Actual results: Device "eth1.100" does not exist. Expected results: Device should be created. Additional info: Instead, a device named "renamexx@eth1" is created, while "xx" is a incrementing number.
What is the exact version+release of the systemd package?
this is probably related to the initscript udev rule for device renaming: https://bugzilla.redhat.com/show_bug.cgi?id=907365 What are your /etc/sysconfig/network-scripts/ifcfg-* ?
(In reply to comment #1) > What is the exact version+release of the systemd package? systemd-197-1.fc18.2
(In reply to comment #2) > this is probably related to the initscript udev rule for device renaming: > > https://bugzilla.redhat.com/show_bug.cgi?id=907365 > > > What are your /etc/sysconfig/network-scripts/ifcfg-* ? I have the same problem with em1_1.538. This message shows up in dmesg: [ 12.358181] systemd-udevd[543]: Tried to rename network interface em1_1.538, but the target name em1_1 already exists! The names that udev rules assign to network interfaces must be changed. Avoid names that collide with kernel created ones. A workaround will be attempted now, but this WILL BREAK in a future release! See https://bugs.freedesktop.org/show_bug.cgi?id=56929#c3 After reading BZ#907365 it looks like udev finds the mac address in ifcfg-em1_1 so it just decides that it's going to rename it to em1_1? Removing the HWADDR line from ifcfg-em1_1 does indeed fix the problem but doesn't seem like the "right" thing to do.
I believe the udev rule I proposed in https://bugzilla.redhat.com/show_bug.cgi?id=907365#c14 fixes this bug as well. *** This bug has been marked as a duplicate of bug 907365 ***