On Mon, Aug 18, 2014 at 7:02 PM, Thomas Bächler <tho...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel