Ubuntu

kills X session during upgrade

Reported by tad1073 on 2009-07-03
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gdm (Ubuntu)
Critical
Martin Pitt

Bug Description

I am testing karmic kuola, kernel 2.6.31.1 w/ nvidia driver 185.18.18+patch, using compiz as window manager.
Both updates dropped you to a shell after the update was installed, have to input login information twice, overrides current theme, ignores gconf>apps>gdm>simple-greeter>wm_use_compiz

Sebastien Bacher (seb128) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:

 * Is this reproducible?
 * If so, what specific steps should we take to recreate this bug?

 This will help us to find and resolve the problem.

Changed in gdm (Ubuntu):
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
importance: Undecided → Low
status: New → Incomplete
tad1073 (tad1073) wrote :

It is reproducible, every time I reboot

Sebastien Bacher (seb128) wrote :

could you describe the issue in a clear way?

tad1073 (tad1073) wrote :

every time I reboot I have to enter login information twice, gdm overrides my selected window manager with metacity, etc.

Here is a link to the thread: http://ubuntuforums.org/showthread.php?t=1202843

Sebastien Bacher (seb128) wrote :

the description is still not really clear to me, you describe having to enter information twice, then gconf issues then compiz issues, could you describe what you do exactly, what errors you get and what else you would expect?

tad1073 (tad1073) wrote :

Here are my log files.

tad1073 (tad1073) wrote :
tad1073 (tad1073) wrote :
Martin Pitt (pitti) wrote :

This conflates multiple issues into one. Many symptoms are due to gdm restarting itself in the middle of the dist-upgrade and leaving gdm half-configured and utterly broken. I'm going to use this bug report for this issue. Please wait for version 0ubuntu3 (which will fix lots of bugs).

summary: - Wosre than the first update
+ kills X session during upgrade
Changed in gdm (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → Martin Pitt (pitti)
importance: Low → Critical
status: Incomplete → In Progress
Martin Pitt (pitti) on 2009-07-06
Changed in gdm (Ubuntu):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gdm - 2.26.1-0ubuntu3

---------------
gdm (2.26.1-0ubuntu3) karmic; urgency=low

  * Add 03_hide_system_users.patch: Do not show system users in the "frequent
    users" list. (LP: #395281)
  * debian/rules: Call dh_installinit with --no-scripts, to avoid restarting
    gdm (and killing your X session) during upgrade. The prerm/postinst
    scripts already have code to reload gdm if appropriate. Unfortunately this
    doesn't help to fix the upgrade from 0ubuntu2, its prerm already kills it.
    (LP: #395302) This also fixes the "locks session and spawns a second X
    server" issue on upgrades from Jaunty. (LP: #395313)
  * Drop 16_correct_customconf_naming.patch: Upstream uses
    and installs /etc/gdm/custom.conf, so gdm also needs to read this. Add
    debian/gdm.preinst to migrate the old name to the new name on upgrades.
    (LP: #395861)
  * 02_dont_force_us_keyboard.patch: Don't return NULL in
    get_default_layout(), but return an empty string and explicitly check this
    when setting $GDM_KEYBOARD_LAYOUT. With NULL, gdm trips over an assertion
    check. (LP: #395595)

 -- Martin Pitt <email address hidden> Mon, 06 Jul 2009 16:04:25 +0200

Changed in gdm (Ubuntu):
status: Fix Committed → Fix Released
Martin Pitt (pitti) wrote :

Please also see https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-July/000586.html

The upgrade to 2.26.1-0ubuntu3 will still break, there's no way to fix this unfortunately.

Hmm, I'm still experiencing gdm restarts during some upgrades; the last one was today, when upgrading from gdm 2.28.0-0ubuntu14 to gdm 2.28.0-0ubuntu17. I believe the HUP from the postinst file could be causing this, but as I don't want to reboot my computer again, I shrink from trying it:

PID=$(status "gdm" 2>/dev/null | awk '/[0-9]$/ { print $NF }')
[ -z "$PID" ] || kill -HUP $PID

What makes this even worse is that after gdm is restarted, neither the mouse nor the keyboard are working anymore. The only escape is rebooting the computer via Alt+SysRq+RSEIUB.

Martin Pitt (pitti) wrote :

Seinding HUP to gdm does not terminate it. It rather sounds like d-bus crashed during the upgrade, that's a plausible cause for crashing gdm, crashing hal, and not having any input devices in X any more (since that relies on hal). Can you reproduce this somehow? Can you please check afterwards with "status dbus" and "status hal" whether they are running or stopped?

tags: added: regression-release
tags: removed: regression-release

> Seinding HUP to gdm does not terminate it.

OK, you're right, I tried it :)

> It rather sounds like d-bus crashed during the upgrade

Seems you are right again:

martin /var/log # zgrep dbus syslog.1
Oct 14 19:57:29 martin dbus-daemon: Reloaded configuration
[...]
Oct 14 20:05:20 martin dbus-daemon: Reloaded configuration
Oct 14 20:11:52 martin avahi-daemon[32252]: dbus_bus_get_private(): Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
[...]
Oct 14 20:11:52 martin init: dbus main process ended, respawning
Oct 14 20:12:38 martin init: dbus main process ended, respawning
Oct 14 20:12:50 martin init: dbus main process ended, respawning
Oct 14 20:12:50 martin init: dbus main process (5278) killed by KILL signal
Oct 14 20:12:50 martin init: dbus main process ended, respawning
Oct 14 20:12:50 martin init: dbus main process (5352) terminated with status 1
Oct 14 20:12:50 martin init: dbus main process ended, respawning
Oct 14 20:12:50 martin init: Unable to connect to the system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused

I'll attach the complete syslog and apt/term.log.

> Can you reproduce this somehow?

I have no idea how. I tried to run a few dbus related postinsts, but that caused nothing.

> Can you please check afterwards with "status dbus" and "status hal" whether they are running or stopped?

When it happens again, I'll try to login via ssh, and post the results.

James Westby (james-w) wrote :

Martin,

I'm fairly sure you were hitting bug 446534. As you now have the fixed
versions installed you should not see this again.

Thanks,

James

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

Other bug subscribers