$DISPLAY not set in some cases, resulting in cryptic traceback

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

Thanks for your bugreport.

I don't think this is a bu in update-manager. Its crashing in " from gi.repository import Gtk" already.

Is this still a problem? Is this still reproducible ?

I managed to get this kind of error is DISPLAY is not set, but how could that happen for a "normal" user?

Duplicate bug 869320 has a testcase and indicates that this is likely a bug in gksu and it unsetting the DISPLAY variable.

Marking for -updates. I think we want this in as a 0-day SRU if we can get it.

Michael, do we have a reproducer for this issue? Is there a workaround we should be documenting in the release notes?

From bug #867629:

1) Start Update Manager
2) Only a partial upgrade is possible -> Click "Partial Upgrade"
3) Enter the user password
4) Partial Upgrade window appears
5) It crashes when it is showin "Calculating changes" below the status ba

Fwiw, I tried the above steps (and created a situation where a partial upgrade is needed) but it worked for me, I could not make it crash.

I am not aware of a way to reproduce this currently, but if someone can, I'm very keen on hearing about it.

I reported the duplicate bug, but I can't reproduce it at the moment.

Is there a way to manually force update manager to do a partial upgrade?

Internally it just runs:
$ gksu --desktop /usr/share/applications/update-manager.desktop -- update-manager --dist-upgrade
when a partial upgrade needs to be performed.

no explanation why this bug was closed for oneiric..

It's not clear to me what we can or should do here. This is easily reproducible by starting update-manager in an environment without a $DISPLAY, e.g. from an ssh session where the display is not forwarded.

The error message is perhaps too cryptic to be useful, so one fix might be to catch the exception and print a more helpful error message. If that fairly easy fix is enough, let me know and I'll work on that.

The issue here is not that the error message is unclear; the issue is that update-manager is being run with $DISPLAY unset, when this shouldn't ever happen on the desktop. So something is wrong in the privilege handling stack when we try to do a partial upgrade.

Dominik asks as good question in comment #10: if this has only been observed during a partial upgrade, how can we force a partial upgrade to try to reproduce the problem?

Colin suggests to just hack the code to think it always has to do a partial upgrade. I'll give that a try and see if I can reproduce the problem that way.

My observations so far:

 * Even with a hacked-up update-manager that always enters partial upgrade mode, I can't currently reproduce this bug, either directly or via update-notifier.
 * I think partial upgrade mode is a red herring anyway. Of this bug and its 16 duplicates, only two show "--dist-upgrade" in PythonArgs. Two have "--no-focus-on-map" (indicating a launch by update-notifier). Two have no arguments at all, and the others have "-d", suggesting launch from a menu/dash/launcher/terminal/whatever.
 * Only one of these bugs is from the final oneiric version of update-manager or newer, and there appears to be no bug pattern that might have prevented further reports.
 * All but three of these bugs are from systems recently upgraded from natty to oneiric, and two of the remainder from oneiric beta to oneiric.
 * Of the eight bugs with full update-manager logs attached, all eight have unity and unity-2d installed (though I can't really tell what desktop environment they're actually running), and seven have ubuntu-desktop installed. One has kde-window-manager installed, although not kubuntu-desktop. One has edubuntu-desktop installed.
 * I'm trying a natty install to see if I can reproduce this on upgrade from that.

My feeling so far is that this was probably a bug in some bit of desktop infrastructure which has since been fixed, and I expect to remove the rls-p-tracking tag if further reproduction attempts fail, due to the paucity of recent reports.

I've been unable to reproduce this in my testing; and as I said in my previous comment I don't think this actually has anything particular to do with partial upgrades, so I've retitled the bug accordingly.

With the exception of bug 929752, the only reports we've had of this are from natty->oneiric upgrades prior to release (the latest reported date is 2011-10-09). If this were still a major problem, I'd expect to have seen a similar number of reports from oneiric->precise upgrades. I can't identify a specific change that might have fixed this, so I'm not prepared to close the bug, but I'm removing the rls-p-tracking tag as it doesn't appear to be release-critical. We can revisit this if we start seeing more duplicates of this.

Colin, I found some duplicates that seem to be from upgrades from Oneiric to Precise and I've marked them as duplicates of this bug report. The reason they weren't automatically marked was due to line numbers in the tracebacks changing.

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/848915

Noek vanBiljon (noekvb),

please don't mark bugs as "In Progress" if you have no plans for working on them: https://wiki.ubuntu.com/Bugs/Status

 In Progress:
* If you are working on fixing a bug, set it to In Progress so people know what's going on
* In Progress bugs should be assigned to the person working on them

oneiric has seen the end of its life and is no longer receiving any updates. Marking the oneiric task for this ticket as "Won't Fix".

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release