Comment 6 for bug 1669564

On Tue, Mar 7, 2017 at 9:41 AM, Dimitri John Ledkov <email address hidden>
wrote:

> 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?

Netplan does not rename interfaces directly; it writes .link files which
are
processed by udev. cloud-init itself may rename interfaces via ip set link
names due to udev refusing to rename interfaces after they've been
renamed once.

> this will then introduce a race,
> ideally we'd want to rename interfaces only once.
>

All of the renames are in sequence, not parallel so I'm not sure I'm
following
the race. The kernel boots with one name for the devices; udev will rename
the interfaces by policy; then during rootfs boot, any .link files will
apply a third
rename, if needed. In my case, all of the .link files are matched via MAC,
so
interface name does not come into play.

> (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?)
>

Yes, see above.

>
> > 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".
>

Sure. The cloud-init-local unit will do the following things:

1) write /etc/netplan/nplan.yml
2) exec 'netplan generate'
3) exec 'udevadm trigger --subsystem-match=net'

After (2), we have .link files in /run/systemd/network/ which *should* get
processed
by "cold-plugging" the net subsystem(3); but they do not.

After boot is complete, one can login and re-run (3) and udev will at that
time
process the .link files. This bug wonders what the difference is between
running
(3) under cloud-init-local unit, and as a user logged in after boot is
complete.