Ideally, the following should happen:
* boot
* Created link configuration context
<netplan creates/changes .link files to have a new MTU setting>
* Check if link configuration needs reloading -> appears in the debug logs
* New MTU is successfully applied
If the 'Check ...' is missing from the debug logs, after netplan has run, udevd will not reload the configs.
I also would have thought that calling udevadm control --reload would force it to reload the contexts for the builtins.
From the original bug report description there is a call to:
'systemctl', 'start', '--no-block', 'systemd-udev-trigger.service'
But if one is doing that, to avoid races, one should call udevadm settle -t 3 before re-triggering add.
Ideally, the following should happen:
* boot
* Created link configuration context
<netplan creates/changes .link files to have a new MTU setting>
* Check if link configuration needs reloading -> appears in the debug logs
* New MTU is successfully applied
If the 'Check ...' is missing from the debug logs, after netplan has run, udevd will not reload the configs.
I also would have thought that calling udevadm control --reload would force it to reload the contexts for the builtins.
From the original bug report description there is a call to: udev-trigger. service'
'systemctl', 'start', '--no-block', 'systemd-
But if one is doing that, to avoid races, one should call udevadm settle -t 3 before re-triggering add.
These things are possibly red herrings too.