Comment 7 for bug 1031065

So, after much discussion [1] we came to the realization of why 'start networking' was here.
The issue was that the normal case for cloud-images (and ubuntu as a whole) is that / is mounted "ro" when /sbin/init starts. When this is the case, /run will be mounted before /. However, if / is mounted "rw" then "mountall first scans for all filesystems that don't require further processing and reports them mounted", so "mounted MOUNTPOINT=/" occurs before virtual-filesystems.

if mounted MOUNTPOINT=/ occurs before virtual-filesystems, then udev will not start because it depends on virtual-filesystems. That means means networking wont get started either, as ifup occurs via udev events for discovered network adapters. As a result, we hang in cloud-init-nonet waiting for networking devices to come up that never will.

Note, slangasek pointed out that while /run is guaranteed to be mounted before / (except withotu 'ro'), virtual-filesystems is *not* guaranteed. So, even with 'ro' root, a race condition could occur here. It would also, then imply that cloud-init cannot actually use some filesystems in cloud-init-local (such has /proc or /sys).

slangasek suggested that a fix for bug 643289 would improve the situation here as the virtual-filesystems could all move forward even while the 'mounted MOUNTPOINT=/' were processing (currently it blocks *everything*). That would mean we wouldn't deadlock here.

--
[1] http://irclogs.ubuntu.com/2012/09/05/%23ubuntu-devel.html#t18:16