[systemd-devel] Networkd fails to activate the device on boot

Tom Gundersen teg at jklm.no
Mon Aug 18 10:34:49 PDT 2014


On Mon, Aug 18, 2014 at 7:02 PM, Thomas Bächler <thomas at archlinux.org> wrote:
> Am 18.08.2014 um 12:41 schrieb Tom Gundersen:
>>> 1) The enp3s0 interface does not activate on boot. I need to restart
>>> networkd manually to make it work.
>>
>> Hm, that is decidedly uncool. It seems we are not aware of the link.
>> Could you try with Environment=SYSTEMD_LOG_LEVEL=debug in your service
>> file to get some more info (of course that may hide the bug)? Is this
>> reproducible with current git (I don't know of any fix to this, but
>> you never know).
>
> I don't know if I'll get to it today, but I'll try to do it ASAP. I did
> not try latest git, and I'd like to avoid it on real hardware if possible.

Thanks.

>>> 2) The qemu interface does not have the correct MAC address. It gains a
>>> seemingly random address that is inconsistent across reboots.
>>
>> Oh fun, I should have known that allowing tun/tap devices to be
>> special-cased would come back to bite us. The issue here is that we
>> create tun/tap devices using an ioctl rather than the standard rtnl
>> interface. This ioctl does not allow us to set MTU, mac address etc.
>> We would have to fix that up after creating the device (over rtnl).
>>
>> I think the best solution would be to simply add support to the kernel
>> for creating persistent tun/tap links over rtnl (seems like it should
>> be very simple), so I don't think we should work around this in
>> networkd. In the meantime, I will add warnings/documentation to
>> networkd so people know that this won't work.
>
> I didn't know you can "simply" fix anything in the kernel.

Well, people could always backport. But I agree, it is slow work. The
patch itself should not be many lines though.

> With the
> general inertia of kernel development, such a fix would take between 4
> and 6 months to be available in a mainline release. Personally, I'd opt
> for the two-step process with ioctl+rtnl, which we could drop as soon as
> a new rtnl interface has existed for some time.

I'm hesitant to add the rtnl+ioctl work-around though, it would
probably mean that a real fix would never be made, and after all this
is just a missing feature rather than a real bug.

>> For those who need the functionality, a work-aronud is to do it by
>> dropping in a .link file, matching on the interface name.
>
> That was my first idea (before I even considered using a .netdev unit),
> since the tap interface was created by vde_switch. Here's the thing:
> .link units cannot match on names.
>
> There is no workaround for this problem with networkd only.

Indeed, you are right, the .link unit will not work. One would have to
write a custom udev rule.

-t


More information about the systemd-devel mailing list