[Bug 1047712] Re: container-detect.conf should be 'start on virtual-filesystems'

2012-09-08 Thread Steve Langasek
A careful examination of the container-detect job shows that switching it to virtual-filesystems would also result in a race condition. The job has two functions: - emitting an event telling whether we're in a container or not - populating /run/container_type The first function is race-free

[Bug 1047712] Re: container-detect.conf should be 'start on virtual-filesystems'

2012-09-07 Thread Scott Moser
** Description changed: I'm running into some issues during my ephemeral boot (iscsi read-only root) work for maas. In debugging bug 1031065, we had 'cloud-init-nonet' actually mount all virtual-filesystems and then emit the event. After doing that, we were still timing out on

[Bug 1047712] Re: container-detect.conf should be 'start on virtual-filesystems'

2012-09-07 Thread Scott Moser
now that i think about it there is a race if we back resolvconf.conf to start on virtual-filesystems. in that as soon as that event occurs networking could come up before resolvconf has had a chance to prep itself. -- You received this bug notification because you are a member of Ubuntu Bugs,

[Bug 1047712] Re: container-detect.conf should be 'start on virtual-filesystems'

2012-09-07 Thread Scott Moser
marked as also-affects resolvconf as /etc/init/resolvconf.conf also is start on mounted MOUNTPOINT=/run ** Also affects: resolvconf (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1047712] Re: container-detect.conf should be 'start on virtual-filesystems'

2012-09-07 Thread Scott Moser
one othe rpiece of this puzzle is that /etc/init/iscsi-network- interface.conf is doing some magic to stop the interface from getting bounced. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1047712