Bug#517194: network-manager: Does not recognize/manage wired ethernet card any more
Raphael Hertzog
Version: 0.7.0.97-1
Severity: important
For some reason, network-manager doesn't manage my wired ethernet
connection any more (version 0.6 used to deal with it without problem).
nm-applet now just says: "device not managed"
My /etc/network/interfaces has nothing fancy in it:
----
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp
# Bridge interface with the ethernet card
#auto br0
#iface br0 inet dhcp
# bridge_ports eth0 vbox0 vbox1
# bridge_maxwait 0
#address 10.0.2.1
#netmask 255.0.0.0
----
(the second part was already deactivated prior to the upgrade)
I tried removing the two lines about eth0 but it didn't help.
The upgrade ended up without network available.
-- System Information:
Debian Release: 5.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.28-1-686-bigmem (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages network-manager depends on:
ii adduser 3.110 add and remove users and groups
ii dbus 1.2.12-1 simple interprocess messaging syst
ii dhcp3-client 3.1.1-6 DHCP client
ii hal 0.5.11-8 Hardware Abstraction Layer
ii ifupdown 0.6.8+nmu1 high level tools to configure netw
ii libc6 2.9-3 GNU C Library: Shared libraries
ii libdbus-1-3 1.2.12-1 simple interprocess messaging syst
ii libdbus-glib-1-2 0.80-3 simple interprocess messaging syst
ii libgcrypt11 1.4.4-2 LGPL Crypto library - runtime libr
ii libglib2.0-0 2.18.4-2 The GLib library of C routines
ii libgnutls26 2.6.4-2 the GNU TLS library - runtime libr
ii libgpg-error0 1.4-2 library for common error values an
ii libhal1 0.5.11-8 Hardware Abstraction Layer - share
ii libnl1 1.1-5 library for dealing with netlink s
ii libnm-glib0 0.7.0.97-1 network management framework (GLib
ii libnm-util1 0.7.0.97-1 network management framework (shar
ii libpolkit-dbus2 0.9-3 library for accessing PolicyKit vi
ii libpolkit2 0.9-3 library for accessing PolicyKit
ii libtasn1-3 1.8-1 Manage ASN.1 structures (runtime)
ii libuuid1 1.41.3-1 universally unique id library
ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip
ii wpasupplicant 0.6.4-3 Client support for WPA and WPA2 (I
ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime
Versions of packages network-manager recommends:
ii network-manager-gnome 0.7.0.97-1 network management framework (GNOM
ii policykit 0.9-3 framework for managing administrat
ii ppp 2.4.4rel-10.1 Point-to-Point Protocol (PPP) - da
Versions of packages network-manager suggests:
ii avahi-autoipd 0.6.24-2 Avahi IPv4LL network address confi
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Michael Biebl
See the README.Debian regarding the new managed mode.
If you want to keep your devices configured via /e/n/i but managed by NM, then
use managed=true in /etc/NetworkManager/nm-system-settings.conf and don't forget
to kill the running nm-system-settings instance.
Would it help you if I added a few lines in a NEWS.Debian?
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Raphael Hertzog
> See the README.Debian regarding the new managed mode.
>
> If you want to keep your devices configured via /e/n/i but managed by NM, then
> use managed=true in /etc/NetworkManager/nm-system-settings.conf and don't forget
> to kill the running nm-system-settings instance.
I tried to remove the entry in the interfaces file and restarted
network-manager (invoke-rc.d network-manager restart) and it didn't work.
Isn't nm-system-settings restarted at the same time ?
> Would it help you if I added a few lines in a NEWS.Debian?
Definitely if you plan to break compatibility from one release to the
other. Better would be to auto-add the required setting on upgrade
so that NM continues to manage what it used to manage.
It probably has implications for default desktop installation as well,
they would get the status "offline" back from NM, which is not really
desirable as you know, just because NM would refuse to manage the default
DHCP connection created by d-i.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Michael Biebl
> On Thu, 26 Feb 2009, Michael Biebl wrote:
>> See the README.Debian regarding the new managed mode.
>>
>> If you want to keep your devices configured via /e/n/i but managed by NM, then
>> use managed=true in /etc/NetworkManager/nm-system-settings.conf and don't forget
>> to kill the running nm-system-settings instance.
>
> I tried to remove the entry in the interfaces file and restarted
> network-manager (invoke-rc.d network-manager restart) and it didn't work.
> Isn't nm-system-settings restarted at the same time ?
No, it isn't. nm-system-settings is a dbus activated service (much like
nm-applet, just without GUI).
>> Would it help you if I added a few lines in a NEWS.Debian?
>
> Definitely if you plan to break compatibility from one release to the
> other. Better would be to auto-add the required setting on upgrade
> so that NM continues to manage what it used to manage.
It's a bit more complicated than that. With 0.7, NM can handle a lot more
scenarios like it did with 0.6, e.g. it finally supports static configurations.
So if I set "managed=true" for nm-system-settings, static configurations in
/e/n/i, which were previously ignored by NM, are now managed by NM.
That's going to change the behaviour to previous NM, one way or the other.
> It probably has implications for default desktop installation as well,
> they would get the status "offline" back from NM, which is not really
> desirable as you know, just because NM would refuse to manage the default
> DHCP connection created by d-i.
Yeah, I think I'm leaning towards enabling "managed=true" by default. There are
still some problems with that though, (like the device being brought up twice
during boot, first by ifupdown and second by NM).
Cheers,
Raphael Hertzog
> It's a bit more complicated than that. With 0.7, NM can handle a lot more
> scenarios like it did with 0.6, e.g. it finally supports static configurations.
>
> So if I set "managed=true" for nm-system-settings, static configurations in
> /e/n/i, which were previously ignored by NM, are now managed by NM.
> That's going to change the behaviour to previous NM, one way or the other.
So just add managed=true for the cases where NM did manage the connection
(i.e. for dhcp option-less entries) and not for the rest.
> > It probably has implications for default desktop installation as well,
> > they would get the status "offline" back from NM, which is not really
> > desirable as you know, just because NM would refuse to manage the default
> > DHCP connection created by d-i.
>
> Yeah, I think I'm leaning towards enabling "managed=true" by default. There are
> still some problems with that though, (like the device being brought up twice
> during boot, first by ifupdown and second by NM).
Yes, but that's already the case now. Maybe ifupdown could be smarter… but
that requires coordination with his maintainer.
Paul Menzel
> On Thu, 26 Feb 2009, Michael Biebl wrote:
> > See the README.Debian regarding the new managed mode.
> >
> > If you want to keep your devices configured via /e/n/i but managed by NM, then
> > use managed=true in /etc/NetworkManager/nm-system-settings.conf and don't forget
> > to kill the running nm-system-settings instance.
>
> I tried to remove the entry in the interfaces file and restarted
> network-manager (invoke-rc.d network-manager restart) and it didn't work.
> Isn't nm-system-settings restarted at the same time ?
>
> > Would it help you if I added a few lines in a NEWS.Debian?
>
> Definitely if you plan to break compatibility from one release to the
> other. Better would be to auto-add the required setting on upgrade
> so that NM continues to manage what it used to manage.
>
> It probably has implications for default desktop installation as well,
> they would get the status "offline" back from NM, which is not really
> desirable as you know, just because NM would refuse to manage the default
> DHCP connection created by d-i.
This thing also hit me today. I took a quick look at README.Debian but
thought the managed mode was something old and did not read it. It would
have helped me, if a small note (as the one from your message) had been
in NEWS.Debian.
Thanks,
Paul
Carl Worth
> It probably has implications for default desktop installation as well,
> they would get the status "offline" back from NM, which is not really
> desirable as you know, just because NM would refuse to manage the default
> DHCP connection created by d-i.
I can confirm this (or pretty close).
I just did a new "install" of unstable, (installed from lenny images and
immediately upgraded all packages to unstable). My network was working
fine with DHCP, (via entries created in /etc/network/interfaces by the
installer), but the GNOME network-manager applet gave me an icon
indicating "offline". Clicking on that showed me "Wired Network - Device
not managed". Right-clicking and going to "Edit connections" showed me
"ifupdown (eth0) never" which was completely uneditable.
So network manager came up broken by default and with nothing in its
user interface, (at least as far as the GNOME applet), to fix it. Not a
great first impression for this software.
-Carl