Ubuntu
network-manager package

Intrepid -> Jaunty upgrade kills NetworkManager

Bug #327053 reported by Alex Ruddick
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Fix Released
High
Unassigned
Intrepid
Won't Fix
Medium
Alexander Sack
Jaunty
Fix Released
High
Unassigned
update-manager (Ubuntu)
Fix Released
Medium
Michael Vogt
Intrepid
Invalid
Undecided
Unassigned
Jaunty
Fix Released
Medium
Michael Vogt

Bug Description

TEST CASE:
1. use a intrepid install with network-manager for the default network connection
2. perform a release upgrade with update-manager
3. verify that at around ~25% of the install the network is no longer available
4. use a intrepid install with network-manager for the default network connection
5. run "update-manager --proposed"
6. verify that the network connection is available during the complete upgrade

Here is the section of /var/log/daemon.log at around the right time.

Feb 8 19:32:38 alex-laptop NetworkManager: <debug> [1234139558.846724] periodic_update(): Roamed from BSSID 00:0C:E6:D7:C7:DA (Villanova) to (none) ((none))
Feb 8 19:32:44 alex-laptop NetworkManager: <debug> [1234139564.847768] periodic_update(): Roamed from BSSID (none) ((none)) to 00:0C:E6:D7:C7:DA (Villanova)
Feb 8 19:34:05 alex-laptop hald: unmounted /dev/sdb1 from '/media/PAUL KOSSOF' on behalf of uid 1000
Feb 8 19:34:38 alex-laptop NetworkManager: <debug> [1234139678.915729] periodic_update(): Roamed from BSSID 00:0C:E6:D7:C7:DA (Villanova) to (none) ((none))
Feb 8 19:34:44 alex-laptop NetworkManager: <debug> [1234139684.919833] periodic_update(): Roamed from BSSID (none) ((none)) to 00:0C:E6:D7:C7:DA (Villanova)
Feb 8 19:36:38 alex-laptop NetworkManager: <debug> [1234139798.974801] periodic_update(): Roamed from BSSID 00:0C:E6:D7:C7:DA (Villanova) to (none) ((none))
Feb 8 19:36:44 alex-laptop NetworkManager: <debug> [1234139804.975860] periodic_update(): Roamed from BSSID (none) ((none)) to 00:0C:E6:D7:C7:DA (Villanova)
Feb 8 19:38:15 alex-laptop dhclient: DHCPREQUEST of 153.104.180.32 on wlan0 to 153.104.136.2 port 67
Feb 8 19:38:15 alex-laptop dhclient: DHCPACK of 153.104.180.32 from 153.104.136.2
Feb 8 19:38:15 alex-laptop dhclient: bound to 153.104.180.32 -- renewal in 714 seconds.
Feb 8 19:42:39 alex-laptop NetworkManager: <debug> [1234140159.178789] periodic_update(): Roamed from BSSID 00:0C:E6:D7:C7:DA (Villanova) to (none) ((none))
Feb 8 19:42:45 alex-laptop NetworkManager: <debug> [1234140165.182860] periodic_update(): Roamed from BSSID (none) ((none)) to 00:0C:E6:D7:C7:DA (Villanova)
Feb 8 19:44:39 alex-laptop NetworkManager: <debug> [1234140279.274811] periodic_update(): Roamed from BSSID 00:0C:E6:D7:C7:DA (Villanova) to (none) ((none))
Feb 8 19:44:45 alex-laptop NetworkManager: <debug> [1234140285.280276] periodic_update(): Roamed from BSSID (none) ((none)) to 00:0C:E6:D7:C7:DA (Villanova)
Feb 8 19:46:39 alex-laptop NetworkManager: <debug> [1234140399.354747] periodic_update(): Roamed from BSSID 00:0C:E6:D7:C7:DA (Villanova) to (none) ((none))
Feb 8 19:46:45 alex-laptop NetworkManager: <debug> [1234140405.358855] periodic_update(): Roamed from BSSID (none) ((none)) to 00:0C:E6:D7:C7:DA (Villanova)
Feb 8 19:48:39 alex-laptop NetworkManager: <debug> [1234140519.410787] periodic_update(): Roamed from BSSID 00:0C:E6:D7:C7:DA (Villanova) to (none) ((none))
Feb 8 19:48:45 alex-laptop NetworkManager: <debug> [1234140525.414949] periodic_update(): Roamed from BSSID (none) ((none)) to 00:0C:E6:D7:C7:DA (Villanova)
Feb 8 19:50:09 alex-laptop dhclient: DHCPREQUEST of 153.104.180.32 on wlan0 to 153.104.136.2 port 67
Feb 8 19:50:09 alex-laptop dhclient: DHCPACK of 153.104.180.32 from 153.104.136.2
Feb 8 19:50:09 alex-laptop dhclient: bound to 153.104.180.32 -- renewal in 877 seconds.
Feb 8 20:04:46 alex-laptop dhclient: DHCPREQUEST of 153.104.180.32 on wlan0 to 153.104.136.2 port 67
Feb 8 20:04:46 alex-laptop dhclient: DHCPACK of 153.104.180.32 from 153.104.136.2
Feb 8 20:04:46 alex-laptop dhclient: bound to 153.104.180.32 -- renewal in 848 seconds.
Feb 8 20:18:54 alex-laptop dhclient: DHCPREQUEST of 153.104.180.32 on wlan0 to 153.104.136.2 port 67
Feb 8 20:18:54 alex-laptop dhclient: DHCPACK of 153.104.180.32 from 153.104.136.2
Feb 8 20:18:54 alex-laptop dhclient: bound to 153.104.180.32 -- renewal in 709 seconds.
Feb 8 20:30:43 alex-laptop dhclient: DHCPREQUEST of 153.104.180.32 on wlan0 to 153.104.136.2 port 67
Feb 8 20:30:43 alex-laptop dhclient: DHCPACK of 153.104.180.32 from 153.104.136.2
Feb 8 20:30:43 alex-laptop dhclient: bound to 153.104.180.32 -- renewal in 728 seconds.
Feb 8 20:39:08 alex-laptop init: Re-executing /sbin/init
Feb 8 20:40:34 alex-laptop init: Re-executing /sbin/init
Feb 8 20:42:51 alex-laptop dhclient: DHCPREQUEST of 153.104.180.32 on wlan0 to 153.104.136.2 port 67
Feb 8 20:42:51 alex-laptop dhclient: DHCPACK of 153.104.180.32 from 153.104.136.2
Feb 8 20:42:51 alex-laptop dhclient: bound to 153.104.180.32 -- renewal in 822 seconds.
Feb 8 20:56:33 alex-laptop dhclient: DHCPREQUEST of 153.104.180.32 on wlan0 to 153.104.136.2 port 67
Feb 8 20:56:33 alex-laptop dhclient: DHCPACK of 153.104.180.32 from 153.104.136.2
Feb 8 20:56:33 alex-laptop dhclient: bound to 153.104.180.32 -- renewal in 679 seconds.
Feb 8 21:07:52 alex-laptop dhclient: DHCPREQUEST of 153.104.180.32 on wlan0 to 153.104.136.2 port 67
Feb 8 21:07:52 alex-laptop dhclient: DHCPACK of 153.104.180.32 from 153.104.136.2
Feb 8 21:07:52 alex-laptop dhclient: bound to 153.104.180.32 -- renewal in 896 seconds.
Feb 8 21:08:47 alex-laptop NetworkManager: <info> HAL disappeared
Feb 8 21:08:49 alex-laptop NetworkManager: <info> HAL re-appeared
Feb 8 21:08:49 alex-laptop NetworkManager: <info> (eth2): now unmanaged
Feb 8 21:08:49 alex-laptop NetworkManager: <info> (eth2): device state change: 2 -> 1
Feb 8 21:08:49 alex-laptop NetworkManager: <info> (eth2): cleaning up...
Feb 8 21:08:49 alex-laptop NetworkManager: <info> (eth2): taking down device.
Feb 8 21:08:49 alex-laptop NetworkManager: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Feb 8 21:08:50 alex-laptop acpid: client connected from 17480[107:116]
Feb 8 21:10:28 alex-laptop NetworkManager: <info> HAL disappeared
Feb 8 21:10:30 alex-laptop NetworkManager: <info> HAL re-appeared
Feb 8 21:10:30 alex-laptop NetworkManager: nm_device_get_managed: assertion `NM_IS_DEVICE (device)' failed
Feb 8 21:10:31 alex-laptop acpid: client connected from 21786[107:116]
Feb 8 21:18:13 alex-laptop acpid: client connected from 25464[107:116]
Feb 8 21:19:27 alex-laptop acpid: client connected from 25719[107:116]
Feb 8 21:22:48 alex-laptop dhclient: DHCPREQUEST of 153.104.180.32 on wlan0 to 153.104.136.2 port 67
Feb 8 21:22:48 alex-laptop dhclient: DHCPACK of 153.104.180.32 from 153.104.136.2
Feb 8 21:22:48 alex-laptop dhclient: bound to 153.104.180.32 -- renewal in 754 seconds.
Feb 8 21:35:22 alex-laptop dhclient: DHCPREQUEST of 153.104.180.32 on wlan0 to 153.104.136.2 port 67
Feb 8 21:35:22 alex-laptop dhclient: DHCPACK of 153.104.180.32 from 153.104.136.2
Feb 8 21:35:22 alex-laptop dhclient: bound to 153.104.180.32 -- renewal in 753 seconds.
Feb 8 21:39:50 alex-laptop NetworkManager: <info> starting...
Feb 8 21:39:50 alex-laptop NetworkManager: <info> Waiting for HAL to start...
Feb 8 21:47:55 alex-laptop dhclient: DHCPREQUEST of 153.104.180.32 on wlan0 to 153.104.136.2 port 67
Feb 8 21:47:55 alex-laptop dhclient: DHCPACK of 153.104.180.32 from 153.104.136.2
Feb 8 21:47:55 alex-laptop dhclient: bound to 153.104.180.32 -- renewal in 796 seconds.
Feb 8 21:51:31 alex-laptop dhcpd: Internet Systems Consortium DHCP Server V3.1.1
Feb 8 21:51:31 alex-laptop dhcpd: Copyright 2004-2008 Internet Systems Consortium.
Feb 8 21:51:31 alex-laptop dhcpd: All rights reserved.
Feb 8 21:51:31 alex-laptop dhcpd: For info, please visit http://www.isc.org/sw/dhcp/
Feb 8 21:51:31 alex-laptop dhcpd: Wrote 1 leases to leases file.
Feb 8 21:51:31 alex-laptop dhcpd:
Feb 8 21:51:31 alex-laptop dhcpd: No subnet declaration for wlan0 (153.104.180.32).
Feb 8 21:51:31 alex-laptop dhcpd: ** Ignoring requests on wlan0. If this is not what
Feb 8 21:51:31 alex-laptop dhcpd: you want, please write a subnet declaration
Feb 8 21:51:31 alex-laptop dhcpd: in your dhcpd.conf file for the network segment
Feb 8 21:51:31 alex-laptop dhcpd: to which interface wlan0 is attached. **
Feb 8 21:51:31 alex-laptop dhcpd:
Feb 8 21:51:31 alex-laptop dhcpd:
Feb 8 21:51:31 alex-laptop dhcpd: Not configured to listen on any interfaces!

Network-Manager died, although the applet stuck around. I'm on a laptop with a Broadcom card.
0c:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g (rev 01)

See original description

Related branches

lp:update-manager
Revision history for this message
Alex Ruddick (alexrudd0) wrote :

This also happened on a separate machine, a desktop using Ndiswrapper and a card I don't remember. Both are now working fine.

Revision history for this message
Alexander Sack (asac) wrote :

i saw this too. mvo, we really need a running NM during upgrade tests. can you try to reproduce and get a backtrace for this?

Once we have more info or receive more reports, we should consider to make this a release blocker.

Changed in network-manager:
assignee: nobody → mvo
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Alexander Sack (asac) wrote :

did this NM crash create a crash file in /var/crash? If so please submit that by double clicking on it in nautilus. Thanks.

Revision history for this message
Alexander Sack (asac) wrote :

Michael, if you cannot do this, we should get this to the QA team so they can get us a backtrace to show whats going on. Let me know.

Revision history for this message
Michael Vogt (mvo) wrote :

I am able to reproduce that network manager kill my connection during upgrade in the automatic kvm based upgrade tester. Here is the syslog output during the upgrade: http://people.ubuntu.com/~mvo/tmp/nm-upgrade-syslog

The lshal output before and after the first hal restart:
http://people.ubuntu.com/~mvo/lshal-before
http://people.ubuntu.com/~mvo/lshal-after

Revision history for this message
Alexander Sack (asac) wrote :

attaching mvo logs.

Revision history for this message
Alexander Sack (asac) wrote :
Revision history for this message
Alexander Sack (asac) wrote :
Revision history for this message
Michael Vogt (mvo) wrote :

"lshal-after" is the lshal output after ~20% of the upgrade (when hal restarts for the first time). The network connectin is gone at this point to, I had to manually dhclient to get network back to scp the syslog and lshal output files.

Revision history for this message
Michael Vogt (mvo) wrote :

At 20.7355% hal is restarted (udev gets configured a bit earlier) and then the network is dropped and lshal has only two devices left.

Changed in network-manager:
assignee: mvo → nobody
Revision history for this message
Michael Vogt (mvo) wrote :
Revision history for this message
Michael Vogt (mvo) wrote :

So the fact that hal is later not available is explained by:

Preparing to replace hal 0.5.11-4ubuntu4 (using .../hal_0.5.12~rc1+git20090204-0ubuntu1_i386.deb) ...^M
[48.1613] hal: Preparing hal
 * Stopping Hardware abstraction layer hald^M
   ...done.^M
Unpacking replacement hal ...^M
...
 [long time]
...
[95.5915] hal: Configuring hal
^M
Setting up hal (0.5.12~rc1+git20090204-0ubuntu1) ...^M
Installing new version of config file /etc/dbus-1/system.d/hal.conf ...^M

Revision history for this message
Paul Coleman (pdcoleman) wrote :

I don't have a radio killswitch but this happens on hal updates.

Feb 27 10:04:14 pdc-desktop NetworkManager: <info> HAL disappeared
Feb 27 10:04:17 pdc-desktop acpid: client connected from 6881[111:123]
Feb 27 10:04:17 pdc-desktop NetworkManager: <info> HAL re-appeared
Feb 27 10:04:17 pdc-desktop NetworkManager: <info> Found radio killswitch /org/freedesktop/Hal/devices/pci_1814_201_rfkill_rt2500pci_wlan
Feb 27 10:04:17 pdc-desktop NetworkManager: <info> Wireless now disabled by radio killswitch
Feb 27 10:04:17 pdc-desktop NetworkManager: <info> (wlan0): device state change: 8 -> 2
Feb 27 10:04:17 pdc-desktop NetworkManager: <info> (wlan0): deactivating device (reason: 0).

Revision history for this message
Floh (flo+-deactivatedaccount) wrote :

I've install Jaunty 9.04 Alpha 4 with KDE-Desktop

After Update my Knetworkmanager didn't run automatically, so i started it by hand but i can't login in networks.

Revision history for this message
Michael Vogt (mvo) wrote :

A new test with hal shows that it restarts itself because of the fdi hal triggers. This seems to happen at a time when udev is in unapcked state but not yet configured.

Revision history for this message
Michael Vogt (mvo) wrote :

I modified the release upgrader to remove the old hal.triggers before the upgrade to test if that helps, but it does not. When hal does its restart after it got upgraded "lshal" reports only two devices and the network goes away.

Revision history for this message
Michael Vogt (mvo) wrote :

I was successful now by deactivating the old (intrepid) /var/lib/dpkg/info/hal.postinst when the upgrade starts. This ensures that the hal trigger is not run (the postinst contains the trigger code) when no new hal is installed. After the new hal is installed restarting hal works fine in my tests so we should be ok. This is a one line change in update-manager. It should be ok to do this, if hal is installed it will be upgraded and a new postinst generated, if its not installed, then the code will do nothing.

Revision history for this message
Michael Vogt (mvo) wrote :
Michael Vogt (mvo)
Changed in update-manager (Ubuntu):
assignee: nobody → Michael Vogt (mvo)
importance: Undecided → Medium
status: New → In Progress
description: updated
Revision history for this message
Michael Vogt (mvo) wrote :

This is a upgrade log of a ssh upgrade in a kvm that runs network-manager. Notice that the log is continued even after halt gets upgraded at around ~22%.

Revision history for this message
Michael Vogt (mvo) wrote :

This is a upgrade log of a ssh upgrade in a kvm that runs network-manager. Notice that the log is end.

Revision history for this message
Alexander Sack (asac) wrote :

for network-manager the crashes we see when hal goes mad are fixed in jaunty; need to backport to intrepid.

Changed in update-manager (Ubuntu Intrepid):
status: New → Invalid
Changed in network-manager (Ubuntu Intrepid):
assignee: nobody → Alexander Sack (asac)
importance: Undecided → Medium
status: New → In Progress
Changed in network-manager (Ubuntu Jaunty):
status: Confirmed → Fix Released
Revision history for this message
Martin Pitt (pitti) wrote :

Accepted update-manager into jaunty-proposed-proposed; please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

tags: added: verification-needed
Revision history for this message
Alexander Sack (asac) wrote :

note that verifying this one is a bit different fromwhat martin posted. to verify:

1. install intrepid (or use an existing intrepid install) with access to internet
2. install flashplugin-nonfree
3. upgrade to jaunty like: sudo update-manager --proposed
4. ensure observe that network stays up and flashplugin properly gets installed (incl. downloading bits from the web)

Revision history for this message
Alexander Sack (asac) wrote :

oops. just saw that michael already posted instructions to bug summary. ignore my previous post then.

Revision history for this message
Steve Beattie (sbeattie) wrote :

I have reproduced the network-manager crash and networking being disabled issue with upgrades using jaunty's update-manager, 1:0.111.7, and can confirm that the version of update-manager in jaunty-proposed, 1:0.111.8, fixes the issue, and that networking continues to work throughout the upgrade.

tags: added: verification-done
removed: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package update-manager - 1:0.111.8

---------------
update-manager (1:0.111.8) jaunty-proposed; urgency=low

  * DistUpgrade/DistUpgrade.cfg:
    - add "grub" to the list of packages to keep installed
      (LP: #363465)
    - ensure brasero is upgraded (thanks to Chris Jones for
      the report) (LP: #364136)
    - ensure guidance-power-manager is removed on upgrade
      (LP: #364620)
  * DistUpgrade/DistUpgradeCache.py:
    - support DistUpgradeCache.markUpgrade()
  * DistUpgrade/mirrors.cfg:
    - add "mirror.files.bigpond.com" (thanks to wgrant)
  * debian/control:
    - build-depend on latest nvidia-common (LP: #363500) to ensure
      the nvidia-common if is included in the internal copy of
      u-m
  * DistUpgrade/DistUpgradeQuirks.py:
    - when the upgrade starts, remove old hal.postinst to prevent
      the trigger from running that causes network-manager to shutdown
      all connections (LP: #327053)
  * UpdateManager/Core/MetaRelease.py, UpdateManager/MetaReleaseGObject.py:
    - fix "no longer supported" message (LP: #364583)

 -- Michael Vogt <email address hidden> Mon, 20 Apr 2009 13:53:01 +0200

Changed in update-manager (Ubuntu Jaunty):
status: In Progress → Fix Released
Alexander Sack (asac)
Changed in network-manager (Ubuntu Intrepid):
status: In Progress → Won't Fix
Revision history for this message
Michael Vogt (mvo) wrote :

This is fixed in u-m trunk as well so I close this task.

Changed in update-manager (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.