UC22 network setup crashes

[valentindavid]

To reproduce it, just freshly install UC22, and in subiquity, unconfigure the network. Apply. Then reconfigure it.

It will crash when subiquity calls "netplan apply", which will crash when calling "networkctl reload". And it is not possible to reconfigure.

The issue is more obvious on real hardware like raspberry pi, because network might not have configured itself before subiquity starts.

subiquity stops systemd-networkd since
canonical/subiquity@4101440

netplan tries to reload systemd-networkd since
canonical/netplan@3ec52c4

These 2 commits are not compatible.

[valentindavid]

Here is the bug for netplan on LP https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/1962095
However I am not sure it is totally the same situation since it is not called through subiquity.

[xnox]

@mwhudson @slyon so it seems that somehow console-conf should be compatible with the recent netplan. Such that it does the compatible thing on UC20 and their netplan; and also on UC22 and their netplan. What's the way forward to detect what target's netplan is expecting and ensuring that networkd is not stopped when it is expected to still be up?

[sil2100]

I think there is a fix on the netplan side in the works already - there is no PR yet but there is a branch from Lukas: https://github.com/canonical/netplan/tree/slyon/fix-netplan-apply-race

[xnox]

@sil2100 sure, but canonical/netplan@2952644 is compatibility mode and is good making netplan compatible with old consumers.

But it would be nice for UC22 for consoleconf to use the optimal codepath - i.e. just do reload like the new netplan supports, without stopping and starting networkd. If that works?

[valentindavid]

Note that restarting the service will not work, because consolconf masks the service. You would have to unmask it. The socket unit as well.

[slyon]

Note that restarting the service will not work, because consolconf masks the service. You would have to unmask it. The socket unit as well.

From canonical/subiquity@4101440 it looks like it would actually be unmasking systemd-networkd before calling netplan apply. I wonder why it does not (re-)start systemd-networkd at the same time? This way netplan would not need to use a fallback/compatibility mode.

If systemd-networkd would be masked when netplan apply is called, netplan will not be able to start it even in compatibility mode.

[xnox]

Note that restarting the service will not work, because consolconf masks the service. You would have to unmask it. The socket unit as well.

From canonical/subiquity@4101440 it looks like it would actually be unmasking systemd-networkd before calling netplan apply. I wonder why it does not (re-)start systemd-networkd at the same time? This way netplan would not need to use a fallback/compatibility mode.

If systemd-networkd would be masked when netplan apply is called, netplan will not be able to start it even in compatibility mode.

It seems that subiquity change was applied from the pull request canonical/subiquity#681 which seems to indicate that something kept on deleting (and possibly not recreating) vlans when their config did not change. Which is pretty bad in s390x, where ones connectivity to the installer may be hanging off the the vlan in question.

Does networkd handle vlans / virtual devices more gracefully these days?

[valentindavid]

From canonical/subiquity@4101440 it looks like it would actually be unmasking systemd-networkd before calling netplan apply.

Right, I misread it.