NetworkManager does not start / fails to start

Status changed to 'Confirmed' because the bug affects multiple users.

Looks like only a few packages have been upgraded to 1.0.4, but not all:
- network-manager-gnome is 0.9.10.1
- libnm-gtk0 & libnm-gtk-common are 0.9.10.1
- gir1.2-nmgtk-1.0 is 0.9.10.1

as that upgrade is incomplete, the build should have been set to 'block-proposed'

To get the network working again, the solution is to downgrade to 0.9.10.1

Importance=Critical --- YES!
No network, no internet - zilch. That is, if you choose to use this broken version.

Any developer around?

Please, anyone don't you go annoying me with apport reports (I hate apport), you will only get these few gdb lines from me, which ought to be enough to find the problem:

Reading symbols from /usr/sbin/NetworkManager...(no debugging symbols found)...done.
[New LWP 1745]
[New LWP 1746]
[New LWP 1747]
[New LWP 1748]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `NetworkManager'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0xb6f4961a in g_variant_iter_loop ()
   from /lib/i386-linux-gnu/libglib-2.0.so.0

--

g_variant_iter_loop()

It's an iterator mechanism: https://developer.gnome.org/glib/stable/glib-GVariant.html#g-variant-iter-loop
Possibly one pointer is NULL or the new NM build will only work with a bleeding-edge, devel version of glib (I assume it's the latter).

JFTR, mine is 2.45.3-1 . (libglibmm @ 2.44.0-1)

OK, so "my" bug must be in ./NetworkManager/libnm/nm-device-wifi.c

in the function as follows:

prepare_scan_options (GVariant *options)
{
 ..

if (!options)
    284 variant = g_variant_new_array (G_VARIANT_TYPE ("{sv}"), NULL, 0);
    285 else {
    286 g_variant_builder_init (&builder, G_VARIANT_TYPE_VARDICT);
    287 g_variant_iter_init (&iter, options);
    288 while (g_variant_iter_loop (&iter, "{sv}", &key, &value))
    289 {
    290 // FIXME: verify options here?
    291 g_variant_builder_add (&builder, "{sv}", key, value);
    292 }
    293 variant = g_variant_builder_end (&builder);
    294 }
...
}

Heh...

// FIXME: verify options here?

Yes, that would be a good idea. Otherwise things like these here may happen. :-]

If you are experiencing this bug in Ubuntu 15.04, please have a look at https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1434986.

This isn't a bug -- we're blocking packages in wily-proposed specifically because they can be slightly broken, and the tests that failed and currently block promotion of the package are meant to do just that -- block things that may be a little buggy. From there, partial upgrades make things even worse, since you may be missing important part of underlying libraries.

IN this case, a partial upgrade of NM is obviously slightly wrong. I don't know how you got to that state, but my guess is that you have the proposed repository enabled, something that is explicitly strongly discouraged on wily unless you really know what you're doing. I believe dino99 exposes it quite well -- partial upgrades would break things, and the packages have remained in proposed for that reason (regardless of block-proposed, which wouldn't stop you in getting out of your way to upgrade the packages manually).

I've just done an upgrade using wily-proposed here, of network-manager, and it more or less works appropriately when all the packages are installed.

For reference, the way to upgrade NetworkManager is the following:

sudo apt-get install -t wily-proposed network-manager libnm0 libnm-glib4 libnm-util2 gir1.2-networkmanager-1.0

network-manager-gnome (nm-applet) and the libnm-gtk* libraries *do not* always need to follow, they should (and appear to) still work just fine.

In the same vein, to downgrade back to network-manager versions that are in wily-release, first check the version available via 'apt-cache policy network-manager' from wily/main:

network-manager:
  Installed: 1.0.4-0ubuntu3
  Candidate: 1.0.4-0ubuntu3
  Version table:
 *** 1.0.4-0ubuntu3 0
        100 /var/lib/dpkg/status
     1.0.4-0ubuntu2 0
         99 http://ca.archive.ubuntu.com/ubuntu/ wily-proposed/main amd64 Packages
     0.9.10.0-4ubuntu23 0
        500 http://ca.archive.ubuntu.com/ubuntu/ wily/main amd64 Packages

(from my own system right now) the value for wily/main is 0.9.10.0-4ubuntu23.

sudo apt-get install network-manager=0.9.10.0-4ubuntu23 libnm0=0.9.10.0-4ubuntu23 libnm-glib4=0.9.10.0-4ubuntu23 libnm-util2=0.9.10.0-4ubuntu23 gir1.2-networkmanager-1.0=0.9.10.0-4ubuntu23

Here to downgrade back, I also needed to add 'network-manager-dbg- libnm0-' to the above line, because for this particular upgrade, NM 1.0 adds a new libnm0 package, and I also had network-manager-dbg installed. This will force them to be removed.

Since this isn't a bug and I've provided the way to roll back to the previous version, closing as Invalid.

If you find any other issues, please feel free to file new bug reports (and, if you think you see the same problem, still please file your own bug report -- lots of different things look quite similar).

Thanks!

Yes, the proposed packages are active cause it is a test version of an beta release... and it this should be so can be read on ubuntuusers.de.

So, how can it be,
- that i get an partial upgrade and
- HOW can it make shure, that this never ever happens in an released version?

I just did what every person (and the script in cron) would do - update and upgrade right every 24 hours.

>For reference, the way to upgrade NetworkManager is the following:
>
>sudo apt-get install -t wily-proposed network-manager libnm0 libnm-glib4 libnm-util2 gir1.2-networkmanager-1.0

Mathieu,

though this ssounds all pretty structured and logical, I think I know where these issues come from.
Most users will just go the all-in-one upgrade way by 'apt-get upgrade' and hence would not be able to fine-tune settings as in the APT line I've quoted from you above.

What you've suggested must be executed BEFORE even THINKING about using apt-get upgrade.
Because then, the network-manager including its dependencies will already have been crossed out from the list.

No, -proposed should never be enabled on a development release. We actively discourage it (it is still *possible*, but it's not done by default, and we strongly recommend people *not* to do that), because it's not abnormal for things to be broken for a period of time in -proposed during the development release. Things get updated from Debian, and stay stuck in proposed for a while because they don't build completely, cause other packages to be uninstallable, etc. Once these issues are fixed, we let them through to -release. Currently, wily is not yet released (won't be until October), so having proposed enabled can indeed break your system pretty badly -- if documentation says to enable it on a version of ubuntu in development, it's quite probably wrong and should be fixed.

This is very different from *stable* releases -- at this time, anything from Vivid and earlier. In that case, it's fine to install packages from -proposed if you want to test a fix to a bug that we're preparing an update for.

apt-get upgrade should always get you a properly upgraded system, but when -proposed is added to the mix, this can break since the packages there are "in testing", being prepared for an "official" update. Things *might* be broken.

Thanks for the detailed replay and the correction of the look at dev releases.

TBH, I only enabled -proposed because openbox 3.6.0 runs so well and because of major and severe bugs with old openbox and lxappearance. This was so unbearable that I chose to upgrade to (allegedly "unstable") v3.6.0 ... and lo' and behold, haven't run into problems for weeks.

the bug is still there

Any update on this outstanding issue?

@Vincent, @Yanik,

Please refer to comments #8 and #11. This is not a bug and has been closed.

This is a bug for me. I used my wifi just today and after shutting down my laptop and turning it on again I get all of this. no wifi and same errors. I use xenial so the versions are different. I have network manager 1.2.6-0ubuntu0.16.04.2.

Further to comments #7 and #16, the reported issue was due to installing packages from -proposed. Unsure why two users have re-opened this without comment so closing again.

Anyone still seeing an issue with network-manager should open their own report by running

ubuntu-bug network-manager

in a terminal so that their own logs get attached to the report.