On Tue, Mar 7, 2017 at 9:41 AM, Dimitri John Ledkov <launch...@surgut.co.uk>
wrote:
> On 7 March 2017 at 14:37, Ryan Harper <1669...@bugs.launchpad.net> wrote:
> > On Tue, Mar 7, 2017 at 6:27 AM, Dimitri John Ledkov <
> launch...@surgut.co.uk>
> > 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.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1669564
Title:
udevadm trigger subsystem-match=net doesn't always run rules
Status in systemd package in Ubuntu:
Incomplete
Bug description:
1. root@ubuntu:~# lsb_release -rd
Description: Ubuntu Zesty Zapus (development branch)
Release: 17.04
2. root@ubuntu:~# apt-cache policy udev
udev:
Installed: 232-18ubuntu1
Candidate: 232-18ubuntu1
Version table:
*** 232-18ubuntu1 500
500 http://archive.ubuntu.com/ubuntu zesty/main amd64 Packages
100 /var/lib/dpkg/status
3. udevadm trigger --verbose --subsystem-match=net --action=add will run and
read .link files from /run/systemd/network/10-netplan-interface1.link
and apply MTU settings
4. during system boot running (3) does not set the MTU; running (3)
after boot has completed MTU is set correctly.
Here'a log during boot where cloud-init generates a netplan config,
invokes `netplan generate` which writes the networkd config out
and then udevadm trigger (3). Upon logging in interface1 has an MTU of 1500.
Re-running udevadm trigger now runs the rules/link files and updates the MTU.
Note that, if you run udevadm test /sys/class/net/interface1; this also will
apply the MTU (test probably shouldn't change the interface, I'll file a
bug for that as well).
# journalctl -o short-precise --no-pager -b | grep WARK
Mar 02 19:17:19.839797 ubuntu cloud-init[647]: WARK: ['netplan', '--debug',
'generate']:
Mar 02 19:17:19.839797 ubuntu cloud-init[647]: WARK: ['stat',
'/run/systemd/network/10-netplan-interface1.link']:
Mar 02 19:17:19.839797 ubuntu cloud-init[647]: WARK: ['cat',
'/run/systemd/network/10-netplan-interface1.link']:
Mar 02 19:17:19.839797 ubuntu cloud-init[647]: WARK: ['systemctl', 'start',
'--no-block', 'systemd-udev-trigger.service']:
Mar 02 19:17:19.839797 ubuntu cloud-init[647]: WARK: ['udevadm', 'trigger',
'--verbose', '--subsystem-match=net', '--action=add']:
root@ubuntu:~# cat /run/systemd/network/10-netplan-interface1.link
[Match]
MACAddress=52:54:00:12:34:02
[Link]
Name=interface1
WakeOnLan=off
MTUBytes=1492
root@ubuntu:~# ifconfig interface1
interface1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.2.100 netmask 255.255.255.0 broadcast 10.0.2.255
inet6 fe80::5054:ff:fe12:3402 prefixlen 64 scopeid 0x20<link>
inet6 fec0::5054:ff:fe12:3402 prefixlen 64 scopeid 0x40<site>
ether 52:54:00:12:34:02 txqueuelen 1000 (Ethernet)
RX packets 16 bytes 5053 (5.0 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 35 bytes 3287 (3.2 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root@ubuntu:~# udevadm trigger --verbose --subsystem-match=net --action=add
/sys/devices/pci0000:00/0000:00:04.0/virtio1/net/interface1
/sys/devices/pci0000:00/0000:00:05.0/virtio2/net/interface2
ys/devices/pci0000:00/0000:00:06.0/virtio3/net/interface0
/sys/devices/virtual/net/lo
root@ubuntu:~# ifconfig interface1
interface1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 10.0.2.100 netmask 255.255.255.0 broadcast 10.0.2.255
inet6 fe80::5054:ff:fe12:3402 prefixlen 64 scopeid 0x20<link>
inet6 fec0::5054:ff:fe12:3402 prefixlen 64 scopeid 0x40<site>
ether 52:54:00:12:34:02 txqueuelen 1000 (Ethernet)
RX packets 16 bytes 5053 (5.0 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 37 bytes 3504 (3.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: udev 232-18ubuntu1
ProcVersionSignature: Ubuntu 4.10.0-8.10-generic 4.10.0-rc8
Uname: Linux 4.10.0-8-generic x86_64
ApportVersion: 2.20.4-0ubuntu2
Architecture: amd64
Date: Thu Mar 2 19:22:14 2017
Lsusb: Error: command ['lsusb'] failed with exit code 1:
MachineType: QEMU Standard PC (i440FX + PIIX, 1996)
ProcEnviron:
TERM=vt220
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.10.0-8-generic
root=UUID=8bbb84fe-91e8-4a9a-bd91-f6af4793727e ro console=ttyS0
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/01/2014
dmi.bios.vendor: SeaBIOS
dmi.bios.version: 1.10.1-1ubuntu1
dmi.chassis.type: 1
dmi.chassis.vendor: QEMU
dmi.chassis.version: pc-i440fx-zesty
dmi.modalias:
dmi:bvnSeaBIOS:bvr1.10.1-1ubuntu1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-zesty:cvnQEMU:ct1:cvrpc-i440fx-zesty:
dmi.product.name: Standard PC (i440FX + PIIX, 1996)
dmi.product.version: pc-i440fx-zesty
dmi.sys.vendor: QEMU
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1669564/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
