[solved] systemd refuses to let go of old interface name

Question

I'm installing a fresh system, trying to do everything the "new" way but systemd isn't making it easy for me to like it.
One thing I refuse to use is "persistent" network naming; so I created the symlink to /dev/null in /etc/udev/rules.d/80-net-name-slot.rules
That's all fine, the interface is now eth0 as it should be. I updated my netctl config to use eth0 as the interface, but systemd refuses to let go:
After issuing 'netctl start natures-adm', I get this error:
May 01 11:59:20 apoc.example.com systemd[1]: Job sys-subsystem-net-devices-enp9s0.device/start timed out.
May 01 11:59:20 apoc.example.com systemd[1]: Timed out waiting for device sys-subsystem-net-devices-enp9s0.device.
May 01 11:59:20 apoc.example.com systemd[1]: Dependency failed for A basic dhcp ethernet connection.
According to the error, systemd is being too smart for it's own good and waiting for the old enp9s0 interface, which never comes because it's now eth0 (which is ready and waiting).
[root@apoc ~]# cat /etc/netctl/natures-adm
Description='A basic dhcp ethernet connection'
Interface=eth0
Connection=ethernet
IP=dhcp
## for DHCPv6
IP6=dhcp
## for IPv6 autoconfiguration
#IP6=stateless
So how do I tell systemd to do what netctl is expecting instead of second guessing everything?
===EDIT===
It appears systemd is "holding on" due to this file: /etc/systemd/system/netctl\@natures\\x2dadm.service
Is this "normal"?
Last edited by fukawi2 (2013-05-01 04:57:38)

Answer 1

fukawi2 wrote:===EDIT===
It appears systemd is "holding on" due to this file: /etc/systemd/system/netctl\@natures\\x2dadm.service
Is this "normal"?
This was a service file corresponding to your old natures-adm profile mentioning enp9s0? Then either you forgot to update a service file you created, or netctl generated it (so you were not aware it was created) without cleaning it up. You should blame yourself or netctl (which is still in beta), respectively.
sullivanva linked your problem to encoded hyphens, without really explaining the connection. It seems unlikely that this really is the cause. Or a part of netctl responsible for generating service files fails to take this encoding into account, but I think netctl users are also expected to understand the correspondence between service files and profiles and be able manage them.
Last edited by Raynman (2013-05-03 18:30:47)