TrustyTestNetwork boots with cloud-init-nonet timeout
Bug #1524452 reported by
Scott Moser
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ifupdown (Ubuntu) |
Confirmed
|
Low
|
Unassigned |
Bug Description
$ grep -ri "gave up waiting" --include "*-serial.log" output.success1/
output.
This reproduces with:
./tools/
basically something is causing networking to not automatically come up there.
Changed in curtin: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
To post a comment you must log in.
In curtin/ examples/ test/basic_ network. yaml
You can see we define an eth2 that is present, but is not configured.
This results in the following eni:
auto eth0
iface eth0 inet dhcp
auto eth1
iface eth1 inet static
gateway 10.0.2.1
address 10.0.2.100/24
mtu 1492
auto eth1:1
iface eth1:1 inet static
dns-nameservers 8.8.8.8
dns-search barley.maas
address 10.0.2.200/24
mtu 1492
auto eth2
iface eth2 inet manual
The auto then triggers the ifwait service to wait on it; but it never will.
What is the expected behavior for curtin when we see an 'type: physical' in the config?
- type: physical
mac_ address: "52:54:00:12:34:04"
name: eth2
It feels like we should emit the udev rules to ensure we do the iface to mac_address mapping, but in the absence of
a subnet to skip including it eni.
Will need to see if this affects things like bonds/bridges which expect an iface entry for the device.
For the test case Speed, we can certainly apply a subnet configuration here which will ensure the iface comes up and we save the 120 seconds of execution time, but will need to see whether we should skip emitting the auto XXX if no subnet is attached.