Update to 0.9.4.0-0ubuntu4.1 results in no networking

Bug #1007561 reported by Mur
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Did recommended upgrade to ...-4.1 Result: Waiting for networking on splash screen, followed by :waiting for further 60 seconds on networking on splash screen. at login ifconfig only shows loopback. Rolled back to ...4 and everything works as expected again.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: network-manager 0.9.4.0-0ubuntu4
ProcVersionSignature: Ubuntu 3.2.0-24.39-generic 3.2.16
Uname: Linux 3.2.0-24-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.0.1-0ubuntu8
Architecture: amd64
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
Date: Fri Jun 1 15:36:11 2012
IfupdownConfig:
 auto lo
 iface lo inet loopback
 1dd
 up route add -host murman.mooo.com.com gw 192.168.1.1 dev eth1
 up route add-host dropbox.com.com gw 192.168.1.1 dev eth1
InstallationMedia: Xubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
IpRoute:
 default via 10.225.26.254 dev eth0 proto static
 10.225.26.0/24 dev eth0 proto kernel scope link src 10.225.26.11 metric 1
 169.254.0.0/16 dev eth1 scope link metric 1000
 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.126 metric 1
IwConfig:
 lo no wireless extensions.

 eth1 no wireless extensions.

 eth0 no wireless extensions.
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
 WimaxEnabled=true
ProcEnviron:
 LANGUAGE=en_CA:en
 PATH=(custom, no user)
 LANG=en_CA.UTF-8
 SHELL=/bin/bash
RfKill:

SourcePackage: network-manager
UpgradeStatus: Upgraded to precise on 2012-04-26 (35 days ago)
nmcli-con:
 NAME UUID TYPE TIMESTAMP TIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH
 Wired connection 2 b2ae3014-0a2f-43a0-b871-0145e598e45d 802-3-ethernet 1338575676 Fri 01 Jun 2012 03:34:36 PM ADT yes no /org/freedesktop/NetworkManager/Settings/1
 Wired connection 1 6a56ede1-cfd8-4022-af75-f7135514d62c 802-3-ethernet 1338575676 Fri 01 Jun 2012 03:34:36 PM ADT yes no /org/freedesktop/NetworkManager/Settings/0
nmcli-dev:
 DEVICE TYPE STATE DBUS-PATH
 eth1 802-3-ethernet connected /org/freedesktop/NetworkManager/Devices/1
 eth0 802-3-ethernet connected /org/freedesktop/NetworkManager/Devices/0
nmcli-nm:
 RUNNING VERSION STATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN
 running 0.9.4.0 connected enabled enabled enabled enabled disabled

Revision history for this message
Mur (themurman01) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in network-manager (Ubuntu):
status: New → Confirmed
Revision history for this message
rai4shu2 (rai4shu2) wrote :

I just had this happen on my 64-bit system, and the 32-bit system seems unaffected. I tried both static and DHCP configurations. Both fail. The only way to fix this is to revert back to the old network manager:

* download http://mirror.anl.gov/pub/ubuntu//pool/main/n/network-manager/network-manager_0.9.4.0-0ubuntu4_amd64.deb
* put that on a USB drive (or something similar)
* manually install that package on the affected system

for example: sudo dpkg -i network-manager_0.9.4.0-0ubuntu4_amd64.deb

This is a pretty severe problem as it leaves you without a way to fix the system unless you have more than one OS/computer.

Revision history for this message
Phillip Beckford (budgierless) wrote :

I Can confirm rai4shu2 advice works,

as i had the same idea only i went for a reinstall of the current version (which as we now know is a bug and not a bad installer script)

Thanks Guys.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

There is no indication of any "bug" in network-manager 0.9.4.0-0ubuntu4.1. If you're running into issues with connections with that version, please make sure you provide full logs -- the logs for NetworkManager should be found in /var/log/syslog; which you can attach to this bug report.

For delays at booting, make sure you wait the full amount of time for the system to come up to a login prompt; then attach /var/log/syslog.

In all cases, please also attach the contents of /etc/network/interfaces.

@mur:
The lines:
1dd
 up route add -host murman.mooo.com.com gw 192.168.1.1 dev eth1
 up route add-host dropbox.com.com gw 192.168.1.1 dev eth1
Are likely related to the issues you're seeing. Please try to comment them and see if it helps.

Thanks!

Revision history for this message
rai4shu2 (rai4shu2) wrote :

"Bug" or not, there was no network with the new package. That's a fact. When I replaced it with the old package, I once again had a network. I can't think of a better indication than that. I've narrowed it down for you, however, in that I believe it to be related to the 64-bit CPU instruction set.

Revision history for this message
Mur (themurman01) wrote :

@Mathieu-tl

As this is a work machine, I will be unable to update this report for 4 days. I hope to be able to reply with the information you requested at that time.

Revision history for this message
rai4shu2 (rai4shu2) wrote :

Thanks for the info about where to look for logs.

Relevant portions of the syslog:

* With 4.1:

Jun 1 14:01:05 genma-MS-7309 kernel: [ 11.376425] init: networking main process (957) terminated with status 1

There is no indication at all that Network Manager is there.

* With 4:

Jun 1 14:12:51 genma-MS-7309 NetworkManager[965]: <info> NetworkManager (version 0.9.4.0) is starting...
Jun 1 14:12:51 genma-MS-7309 NetworkManager[965]: <info> Read config file /etc/NetworkManager/NetworkManager.conf
Jun 1 14:12:51 genma-MS-7309 modem-manager[925]: <info> Loaded plugin SimTech
Jun 1 14:12:51 genma-MS-7309 modem-manager[925]: <info> Loaded plugin Ericsson MBM

etc...

Revision history for this message
Phillip Beckford (budgierless) wrote :

Im sorry but i have to agree with (rai4shu2)

I run a production server, and i am very minded about the updates i install for conflicts and compatibility reasons, for example i use php5.2 as that is what i use for my server needs, so not everything i install, i have not every had a problem with a package before, but that is the reason i felt it had to be reported,

install for update manager then DAM no network, but when downgraded its works again know questions asked.
So yea maybe but a bug but the is a conflict of some kind, and i cant allow an update of this module until a supported fix/workaround is found, as i already lost most of the day trying to work out that the issue was.

I am about to waste anyone's time with this report, but i have to save other users from have this potential issue happen to them, as they may-not to able to fix it, and give-up as i Almost did after hours of troubleshooting.

I welcome the work that goes into Ubuntu, as a true Linux user it is my responsibility as well as the hole community to work together for the empowerment of the Linux flagship distribution we know and love as Ubuntu.

A small example of my system log, its mostly the same error in the hole file: (ports edited out for security purposes)

Jun 1 15:48:41 morganmultimediagroup64 named[1234]: error (network unreachable) resolving 'landscape.canonical.com/AAAA/IN': 2001:dc3::35#
Jun 1 15:48:41 morganmultimediagroup64 named[1234]: error (network unreachable) resolving 'landscape.canonical.com/AAAA/IN': 198.41.0.4#
Jun 1 15:48:41 morganmultimediagroup64 named[1234]: error (network unreachable) resolving 'landscape.canonical.com/AAAA/IN': 192.228.79.201#
Jun 1 15:48:41 morganmultimediagroup64 named[1234]: error (network unreachable) resolving 'landscape.canonical.com/AAAA/IN': 192.33.4.12#
Jun 1 15:48:41 morganmultimediagroup64 named[1234]: error (network unreachable) resolving 'landscape.canonical.com/AAAA/IN': 128.8.10.90#
Jun 1 15:48:41 morganmultimediagroup64 named[1234]: error (network unreachable) resolving 'landscape.canonical.com/AAAA/IN': 192.203.230.10#
Jun 1 15:48:41 morganmultimediagroup64 named[1234]: error (network unreachable) resolving 'landscape.canonical.com/AAAA/IN': 192.5.5.241#

Revision history for this message
rai4shu2 (rai4shu2) wrote :

Okay, I think I can narrow this down further:

Intel 32-bit machine: 4.1 works
AMD 64-bit ATI machine with Realtek network: 4.1 works
AMD 64-bit nVidia using ethernet bridge: fails

Maybe this is related to nVidia.

Revision history for this message
rai4shu2 (rai4shu2) wrote :

Another interesting observation: If I run

sudo NetworkManager --no-daemon

that seems to get the network back up even on this affected system. The system simply refuses to init NM on startup. Perhaps this is related also to upstart.

Revision history for this message
rai4shu2 (rai4shu2) wrote :

Okay, I just confirmed the above:

sudo NetworkManager

That will get your network back up, though you do have to endure two minutes at the boot up spash screen telling you "waiting for network" (whatever causes that).

Revision history for this message
Phillip Beckford (budgierless) wrote :

Thanks for the update.

Revision history for this message
rai4shu2 (rai4shu2) wrote :

Some more info (from lspci) on the affected system:

00:07.0 Bridge: NVIDIA Corporation MCP61 Ethernet (rev a2)
 Subsystem: Micro-Star International Co., Ltd. Device 7309
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0 (250ns min, 5000ns max)
 Interrupt: pin A routed to IRQ 43
 Region 0: Memory at dbf7d000 (32-bit, non-prefetchable) [size=4K]
 Region 1: I/O ports at de00 [size=8]
 Capabilities: [44] Power Management version 2
  Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
  Status: D0 NoSoftRst- PME-Enable+ DSel=0 DScale=0 PME-
 Capabilities: [50] MSI: Enable+ Count=1/8 Maskable+ 64bit+
  Address: 00000000fee0100c Data: 4179
  Masking: 000000fe Pending: 00000000
 Capabilities: [6c] HyperTransport: MSI Mapping Enable- Fixed+
 Kernel driver in use: forcedeth
 Kernel modules: forcedeth

Revision history for this message
rai4shu2 (rai4shu2) wrote :

Probably should have tried this earlier. I noticed I was missing /etc/network/interfaces (and this is what turns out to be the problem on this system here). I replaced it, and now it doesn't refuse to init at start. Seems like a house of cards, but you *really* need that file. As of right now, the file contains:

auto lo
iface lo inet loopback

Revision history for this message
Phillip Beckford (budgierless) wrote :

So you say, if missing, load a file called interfaces via vi or vim, than if blank, add:

auto lo
iface lo inet loopback

is this right?

Revision history for this message
Phillip Beckford (budgierless) wrote :

More important, did you have to use: sudo NetworkManager after each reboot?

Revision history for this message
rai4shu2 (rai4shu2) wrote :

I didn't notice it before, but I had removed interfaces. With the 4 version, this wasn't a problem, but it is with the 4.1 version (something to do with dnsmasq I guess). I created a file (with leafpad) that contained those two lines and saved it as /etc/network/interfaces and then rebooted. From that point on, the normal behavior returned: no delay at the splash, no need to run sudo NetworkManager. Sorry if this wasn't altogether clear, before.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

This has really nothing at all to do with the 64-bit instruction set.

Correct, /etc/network/interfaces is required for the system to work properly. The main difference is that NetworkManager is now expected to wait for ifupdown to bring up the loopback interface (because there otherwise were issues starting dnsmasq properly). Starting the loopback interface is an integral part of the system and is required by quite a few other services. What brings it up is the configuration in /etc/network/interfaces, so indeed, as a minimum it has to contain the following:

auto lo
iface lo inet loopback

For the technical; you would be able to notice the difference between network-manager package versions in the file installed at /etc/init/network-manager : there is a new "and static-network-up" line.

There is no need to start NetworkManager manually with "sudo NetworkManager" if /etc/network/interfaces is in place.

Since this isn't a bug; I'm closing this bug report as "Invalid".

Changed in network-manager (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Phillip Beckford (budgierless) wrote :

just an update:

problem for me was, ubnutu still had static ip config in /etc/network/interfaces

i removed the setting, and restored the default dhcp config, this fixed long network loading config time at ubuntu bootup stage, but I still had issue with the network startup at login stage as only sudo NetworkManager command worked for me, so i then went to /etc/init/networking.conf
removed line; emits static-network-up

and boot upstart was restored

hope this help anyone.

(this is not a bug but a conflict issue because the new update was smarter then then old one and would not bypass inaccurate configs like mine because i used to have an static IP setup, but stop using that and was back to using standerd dchp IP)

 if you had a static IP setup in the pasted that is know longer in use, make sure you remove any settings you made for it then you should be ok

Revision history for this message
Mur (themurman01) wrote :

Back to work today.

@Mathieu-tl
I've removed the lines in question, doesn't make any difference in behaviour.
I'm attaching the syslog and interfaces files of the system with the update installed.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Mur:

I can still see a "1dd " in your file /etc/network/interfaces. Remove that and I'm pretty sure things will work properly. It doesn't mean anything in that file anyway.

Revision history for this message
Mur (themurman01) wrote :

@Mathieu-tl

Thanks for your help. this has resolved my issue. Cheers!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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