artful images hang when cloud-init is disabled due to no network config

Bug #1728164 reported by Ryan Harper on 2017-10-27
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
cloud-images
Low
Unassigned

Bug Description

Modified the artful image to disable cloud-init like so:

qemu-img create -f qcow2 -b artful-cloud-image.img my.img && sudo mount-image-callback my.img -- mchroot touch /etc/cloud/cloud-init.disabled

THis prevents cloud-init from running.

Boot takes many minutes and eventually times out with:

[ OK ] Started LXD - container startup/shutdown.
[ *** ] A start job is running for Wait for… to be Configured (49s / no limit) [** ] A start job is running for Wait for…e Configured (1min 37s / no limit)s
ystemd-timesyncd.service: Got notification message from PID 492 (WATCHDOG=1) systemd-networkd.service: Got notification message from PID 497 (WATCHDOG=1)
systemd-resolved.service: Got notification message from PID 592 (WATCHDOG=1) systemd-logind.service: Got notification message from PID 594 (WATCHDOG=1)
systemd-journald.service: Got notification message from PID 360 (WATCHDOG=1) systemd-udevd.service: Got notification message from PID 383 (WATCHDOG=1)
[ **] A start job is running for Wait for…be Configured (2min 1s / no limit)R
eceived SIGCHLD from PID 514 (systemd-network).
Child 514 (systemd-network) died (code=exited, status=1/FAILURE)
systemd-networkd-wait-online.service: Child 514 belongs to systemd-networkd-wait
-online.service systemd-networkd-wait-online.service: Main process exited, code=exited, status=1
/FAILURE systemd-networkd-wait-online.service: Changed start -> failed
systemd-networkd-wait-online.service: Job systemd-networkd-wait-online.service/start finished, result=failed
[FAILED] Failed to start Wait for Network to be Configured.
See 'systemctl status systemd-networkd-wait-online.service' for details. systemd-networkd-wait-online.service: Unit entered failed state.
systemd-networkd-wait-online.service: Failed with result 'exit-code'. systemd-journald.service: Received EPOLLHUP on stored fd 44 (stored), closing.
network-online.target changed dead -> active
network-online.target: Job network-online.target/st

Without cloud-init which normally would emit a fallback network config, there isn't any network configuration in the image. systemd-networkd-wait-online-service waits until at least one network interface is online, but since no interfaces were configured it never exits until the unit times out.

Previously images shipped with the 'networking' service which only waited until at least one of the *configured* interfaces were online; it queried ifupdown (via ifquery) to see which ones were configured.

I expect this is "stray" network-online.target.wants/ in livecd-rootfs for the ubuntu-cpc project. I *think* we don't want that to exist by default, and let systemd manage it on its own. ubuntu-cpc has that configuration file in includes.chroot/ that other flavors don't.

OTOH, cloud-init should be able to detect the NoCloud datasource when there is no metadata available anywhere and write some default configuration that makes some sense, such as when a metadata store is provided via some separately-attached storage (where at least in the cases I've tested, no specific network configuration was provided).

On Fri, Oct 27, 2017 at 8:16 PM, Mathieu Trudel-Lapierre <
<email address hidden>> wrote:

> I expect this is "stray" network-online.target.wants/ in livecd-rootfs
> for the ubuntu-cpc project. I *think* we don't want that to exist by
> default, and let systemd manage it on its own. ubuntu-cpc has that
> configuration file in includes.chroot/ that other flavors don't.
>

I don't think the service presence is at issue; it's whether or not the
wait-online service
can determine if there are any *configured* network devices; it should not
be
waiting for unconfigured (or if no devices are present at all).

>
> OTOH, cloud-init should be able to detect the NoCloud datasource when
> there is no metadata available anywhere and write some default
> configuration that makes some sense, such as when a metadata store is
> provided via some separately-attached storage (where at least in the
> cases I've tested, no specific network configuration was provided).
>

Cloud-init already does this. This case, cloud-init is disable; since it
does not run
it cannot provide a fallback network configuration.

And even if cloud-init did run and the image has no network devices,
network-wait-online
should not block unless it's waiting for configured devices to come up.

If there isn't already, there should be a systemd task around networkd
wait-online checking for
configured interfaces and only blocking if there is one to bring up.

>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1728164
>
> Title:
> artful images hang when cloud-init is disabled due to no network
> config
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/cloud-images/+bug/1728164/+subscriptions
>

Dan Watkins (daniel-thewatkins) wrote :

Supporting removing cloud-init from the image seems like a low priority; am I missing something that makes it more important?

Changed in cloud-images:
importance: Undecided → Low
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers