Secondary network interface left unconfigured after reboot of Core 18
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Expired
|
Undecided
|
Unassigned | ||
snapd |
Fix Released
|
High
|
Ian Johnson |
Bug Description
We're implementing extra networking support in Multipass, and relying on cloud-init to configure them.
On Ubuntu Core 18 images the extra interface's configuration gets purged after rebooting a couple times.
On first boot:
$ cat /etc/netplan/
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/
# network: {config: disabled}
network:
ethernets:
default:
dhcp4: true
match:
extra0:
dhcp4: true
match:
version: 2
But after (an automatic, due to refresh) reboot or two:
$ cat /etc/netplan/
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/
# network: {config: disabled}
network:
ethernets:
eth0:
dhcp4: true
match:
version: 2
Attached is the result of `collect-logs`.
Changed in snapd: | |
assignee: | nobody → Ian Johnson (anonymouse67) |
importance: | Undecided → Medium |
status: | New → Triaged |
Changed in snapd: | |
importance: | Medium → High |
status: | Triaged → In Progress |
Changed in snapd: | |
milestone: | none → 2.48.2 |
Thanks for the bug report, Michał! I'm going to break down what I'm seeing happen in the log in this comment, and then leave another comment with analysis of what I think may be happening.
On the first reboot, we see:
2020-11-27 15:10:03,596 - handlers.py[DEBUG]: start: init-local/ check-cache: attempting to read from cache [check] cloud/instance/ obj.pkl (quiet=False) cloud/instance/ obj.pkl cloud/seed/ nocloud/ meta-data (quiet=False) cloud/seed/ nocloud- net/meta- data (quiet=False) dev/sr0] [dsmode= net] check-cache: SUCCESS: cache invalid in datasource: DataSourceNoCloud [seed=/ dev/sr0] [dsmode= net]
2020-11-27 15:10:03,596 - util.py[DEBUG]: Reading from /var/lib/
2020-11-27 15:10:03,597 - util.py[DEBUG]: Read 10974 bytes from /var/lib/
2020-11-27 15:10:03,612 - util.py[DEBUG]: Reading from /var/lib/
2020-11-27 15:10:03,613 - util.py[DEBUG]: Reading from /var/lib/
2020-11-27 15:10:03,613 - stages.py[DEBUG]: cache invalid in datasource: DataSourceNoCloud [seed=/
2020-11-27 15:10:03,613 - handlers.py[DEBUG]: finish: init-local/
So cloud-init goes to find metadata for this boot, and detects this as a first boot:
2020-11-27 15:10:03,617 - __init__.py[DEBUG]: Seeing if we can get any data from <class 'cloudinit. sources. DataSourceNoClo ud.DataSourceNo Cloud'>
2020-11-27 15:10:03,617 - __init__.py[DEBUG]: Update datasource metadata and network config due to events: New instance first boot
However, it then finds metadata which indicates that the instance ID _hasn't_ changed (it's still august-guppy):
2020-11-27 15:10:03,838 - main.py[DEBUG]: [local] init will now be targeting instance id: august-guppy. new=False
And so we revert to the expected behaviour:
2020-11-27 15:10:03,863 - __init__.py[DEBUG]: Datasource DataSourceNoCloud [seed=/ dev/sr0] [dsmode= net] not updated for events: System boot
2020-11-27 15:10:03,863 - stages.py[DEBUG]: No network config applied. Neither a new instance nor datasource network update on 'System boot' event
Then, on the second reboot, things go sideways. We see the same invalid cache (at 2020-11-27 15:12:17,336) and the same first boot detection (at 2020-11-27 15:12:17,339). Where things change, however, is that cloud-init does not find any NoCloud metadata:
2020-11-27 15:12:17,351 - __init__.py[DEBUG]: Datasource DataSourceNoCloud [seed=None] [dsmode= net] not updated for events: New instance first boot search- NoCloud: SUCCESS: no local data found from DataSourceNoCloud
2020-11-27 15:12:17,352 - handlers.py[DEBUG]: finish: init-local/
This means that it treats this as a fresh boot; as there is no network_data available from a data source, cloud-init generates the fallback configuration and applies it to the system:
2020-11-27 15:12:17,470 - stages.py[INFO]: Applying network configuration from fallback bringup=False: {'ethernets': {'eth0': {'dhcp4': True, 'set-name': 'eth0', 'match': {'macaddress': '52:54: 00:f3:9f: 51'}}}, 'version': 2}
As we can see, this is the configuration you're seeing rendered into the instance.