Comment 5 for bug 1669564

On 7 March 2017 at 14:37, Ryan Harper <email address hidden> wrote:
> On Tue, Mar 7, 2017 at 6:27 AM, Dimitri John Ledkov <email address hidden>
> wrote:
>
>> Should one not restart systemd-networkd after writing out .link et.al.
>> units?
>>
>
> systemd-networkd only deals with .netdev and .network files; .link files
> are handled by udev
>
>
> This occurs during boot, before systemd-networkd starts.
>
> cloud-init-local.service runs before network-pre.target and writes out a
> /etc/netplan/nplan.yaml,
> invokes `netplan generate` which writes out
> /run/systemd/network/10-netplan-xx.{.link,network,netdev}
> as needed; however, the cold plug of devices (systemd-udev-trigger.service)

does netplan rename the interfaces? this will then introduce a race,
ideally we'd want to rename interfaces only once.
(E.g. does udev in the initramfs rename interface from eth0 to e.g.
ens3, and then netplan's .link files rename enc3 again into something
else?)

> happens prior to
> cloud-init-local.service; as it's required for mounting the rootfs among
> other things.
>
> The udev service is also used for device renaming, which would need to
> occur before starting
> networkd. As such, in cloud-init-local, after generating netplan
> configuration, we re-trigger
> the net subsystem events which *should* process any .link files.
>
> The bug, I believe, is that during cloud-init-local execution, udev does
> *not* process the .link files
> prior to starting systemd.
>

Is there a typo here, and/or can you rephrase this assertion?
cloud-init-local is a systemd unit therefore by definition systemd and
udev are running "during cloud-init-local execution".

The rest of the comment sort of makes sense.

> I'm currently working around this using the side-effect of using udevamd
> test-builtin setup_net_link
> which will process the .link files.
>
> I'll collect a journal and attach it.

--
Regards,

Dimitri.