network-manager does not tell plymouth it has started

confirmed with Ubuntu Desktop.

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/924836

I'm not entirely sure that's NetworkManager's job, but rather one of the other upstart jobs. Is this happening on all the installs or is it specific to alternate?

it is not specific to alternate and reproducible with Desktop images.

NetworkManager indeed doesn't deal with this kind of signal, nor does it need to, AFAIK.

Reassigning to ifupdown, that's my best guess for what goes wrong (need to emit static-network-up AFAICT, as required by the failsafe upstart job, which is what writes this plymouth message).

Moving back to NM :)

ifupdown never does anything for interfaces that aren't listed in /etc/network/interfaces

It's Network Manager that's calling the up/post-up scripts through /etc/NetworkManager/dispatcher.d/01ifupdown

One of these, /etc/network/if-up.d/upstart emits net-device-up. I did a quick check and this script hasn't changed since at least Oneiric.

> ifupdown never does anything for interfaces that aren't listed in
> /etc/network/interfaces

Yes, and it doesn't matter, because interfaces not listed in /etc/network/interfaces have no impact on the 'static-network-up' event being issued from /etc/network/if-up.d/upstart. *Only* interfaces that are statically configured via /e/n/i are waited for.

18:02 < stgraber> slangasek: oh, right, misread the script ... I'll eventually get a clear picture of all that in my head :) right. when lo is brought up, the ifupdown hook
                  should emit static-network-up as all the interfaces are ready
18:03 < stgraber> slangasek: so the question is why it didn't happen or what make the script think there was something else to bring up

Can you please give /var/log/syslog and /etc/network/interfaces on the affected system.
Ideally, I'd also need /var/log/upstart/network* from a boot with --log used on the kernel command line.

Thanks

On Wed, Feb 01, 2012 at 06:04:27PM -0000, Stéphane Graber wrote:

> Can you please give /var/log/syslog and /etc/network/interfaces on the
> affected system. Ideally, I'd also need /var/log/upstart/network* from a
> boot with --log used on the kernel command line.

A listing of /run/network from this system is probably also helpful.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

I've seen this too:

ubuntu@ubuntu-virtual-machine:~$ ls /run/network
ifstate ifup.eth0

ubuntu@ubuntu-virtual-machine:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

This only happened to me on the first boot so I was unable to get the upstart logs.

This has been tracked down to a bug in the resolvconf package, causing /etc/network/if-up.d/000resolvconf to fail and taking the rest of the ifupdown hooks with it.

We can't create the initial /etc/resolv.conf symlink from the upstart job when using the live installer, because the job is never run until boot - and at the time it runs (start on mounted MOUNTPOINT=/run), the root fs is not writable. So this symlinking *must* be done in the postinst.

Targeting to beta-1 because we don't want to unsettle this for alpha-2.

This bug was fixed in the package resolvconf - 1.63ubuntu7

---------------
resolvconf (1.63ubuntu7) precise; urgency=low

  [ Stéphane Graber ]
  * Revert change from 1.63ubuntu5 where /etc/resolv.conf would be linkified
    by the upstart/sysvinit job. This wasn't working as / wasn't necessarily
    writable at the time.
    Instead, make the link at package install time but make it a relative
    link which should take care of the chroot usecase where you want
    to copy /etc/resolv.conf from outside the chroot into the chroot.
    Detect old flag file (/var/lib/resolvconf/convert) and re-run the
    conversion code if it's present (to try and fix broken systems).
    Use readlink -m when checking the link's destination.
    (LP: #924836)

  [ Steve Langasek ]
  * Use readlink -m also in the postrm, to account for our relative links
 -- Stephane Graber <email address hidden> Thu, 02 Feb 2012 14:28:45 -0500