do-release-upgrade to gutsy disables eth0

[ChrisBlack]

Binary package hint: update-manager-core

I believe this is a bug in the feisty to gutsy upgrade process.
I followed https://help.ubuntu.com/community/GutsyUpgrades to upgrade a brand new feisty install to gutsy. I did an apt-get update/upgrade to make sure I was up to date first and then followed the directions in GutsyUpgrades using do-release-upgrade.
The upgrade seems to have gone ok (packages upgraded, system functioning, etc) except that it disabled my network interface (which was especially problematic since I was doing this upgrade over ssh). When restarting the NetworkManager/network my ssh connection froze:
Setting up linux-generic (2.6.22.14.20) ...
Setting up network-manager (0.6.5-0ubuntu15) ...
Installing new version of config file /etc/dbus-1/system.d/NetworkManager.conf ...
Auto interfaces found: lo eth0 eth1 eth2 ath0 wlan0
iface to disable = eth0
iface to disable = eth1
iface to disable = eth2
iface to disable = ath0
iface to disable = wlan0
Disabling interface: eth0 ... done.
Disabling interface: eth1 ... done.
Disabling interface: eth2 ... done.
Disabling interface: ath0 ... done.
Disabling interface: wlan0 ... done.
 * Reloading system message bus config... [ OK ]
 * Restarting network connection manager NetworkManager
(no more response over ssh or ping after this point)

Note that it says it is disabling eth0 and did in fact do so. I was able to fix this by going to the local console and editing /etc/network/interfaces and restarting networking. Before my fix interfaces contained:
auto lo
iface lo inet loopback

auto eth0
#iface eth0 inet dhcp

auto eth1
#iface eth1 inet dhcp

auto eth2
#iface eth2 inet dhcp

auto ath0
#iface ath0 inet dhcp

auto wlan0
#iface wlan0 inet dhcp

So that when networking was started it said it did not know how to handle any of the interfaces.

I hope the upgrade is ok even though it ended this way, I would like some input on that. I am also able to upload any logs that might help in fixing this issue.

[ChrisBlack (chris-lotuscat)]

Worth noting is that this machine was installed from a regular ubuntu CD, not a server CD.

[Scott Kitterman (kitterman)]

What's intended to happen in this case is network-manger manages the interfaces and so commenting them out is by design. What appears not to have happened is then Network manager didn't restart them correctly. As we discussed on IRC this is at best an unusual use case (I actually think it's unsupported).

Can you replicate the network manager failure when upgrading in a more normal manner?

[ChrisBlack (chris-lotuscat)]

I really do think that even though using update-manager-core is not normally done for desktops it should work, or at least not be destructive, in this scenario. We have many desktops and I would rather be able to do the updates with this tool than have to fire up the GUI on each machine.
My main issue is that I started with a working network config as created by a desktop install. Then using the update-manager-core do-release-upgrade script breaks this by leaving /etc/networks/interfaces in a non-functional state. Is there any compelling reason that this update process should not or could not be fixed to avoid this?

[Patrick J. LoPresti (lopresti)]

I strongly agree do-release-upgrade should be supported for the desktop. What is Ubuntu's official policy on this question, and how would one go about changing it?

[Loye Young (loyeyoung)]

>Can you replicate the network manager failure when upgrading in a more normal manner?

Using do-release-upgrade *IS* a normal manner, and it is working as intended. Before Gutsy was released, it was even the _recommended_ method of upgrading in several situations. The same behavior happened to me six months ago when upgrading from Feisty to Gutsy using adept, so I'm marking this as confirmed.

This is really a bug in NetworkManager, which hijacks the network configuration without telling the user. The behavior was documented back when Gutsy was released (https://wiki.ubuntu.com/GutsyGibbon/ReleaseNotes), but no one bothered to fix the problem in the intervening six months.

The best work-around that has worked for me is to uninstall dhcdbd and network-manager before upgrading. If, after you do the upgrade, you want Network Manager to manage your network configuration, you can always add it back. I've never missed Network Manager, and none of my customers have either, so you may decide just to leave it out. If you want a GUI interface for managing your network, network-config does a better job IMHO.

[Risto H. Kurppa (risto.kurppa)]

Confirm here, upgrading from dapper to hardy (and the computer is on another continent, behind a firewall so a user there needs now to take action to reconnect to me..).

Setting up network-manager (0.6.6-0ubuntu5) ...
Installing new version of config file /etc/dbus-1/event.d/25NetworkManager ...
Installing new version of config file /etc/dbus-1/event.d/26NetworkManagerDispatcher ...
Installing new version of config file /etc/dbus-1/system.d/NetworkManager.conf ...
Auto interfaces found: lo eth0 eth1 eth2 ath0 wlan0
iface to disable = eth0
iface to disable = eth1
iface to disable = eth2
iface to disable = ath0
iface to disable = wlan0
Disabling interface: eth0 ... done.
Disabling interface: eth1 ... done.
Disabling interface: eth2 ... done.
Disabling interface: ath0 ... done.
Disabling interface: wlan0 ... done.
 * Reloading system message bus config...
Failed to open connection to system message bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused
invoke-rc.d: initscript dbus, action "force-reload" failed.

It definitely should not restart network interfaces unless user agrees..

[Lou Ruppert (louferd)]

Another confirmation, this time from an upgraded Gutsy to Hardy. I agree that the restart of Network Manager should not happen unless the user agrees. There are just too many things that can go wrong in a production environment to justify whatever dubious advantage this offers.

[Lou Ruppert (louferd)]

I haven't had any more incomplete or disabled network updates since the gutsy/hardy upgrade. Has anyone else? We could probably close this if the upgrade process is working again.