gdm 2.26 locks running session on Jaunty upgrade

This also happens with x86--during upgrade, xsession will close without warning. There NEEDS to be a disclaimer or warning about this--I lost work by doing a update in the background & then GDM updated.

Architecture: i386
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: gdm 2.26.1-0ubuntu2
PackageArchitecture: i386
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-1.14-generic
Uname: Linux 2.6.31-1-generic i686
UserGroups: adm admin audio cdrom dialout dip fax floppy fuse lpadmin netdev plugdev sambashare tape video

did it actually close the session or just switch vts?

For my gdm 2.20 to 2.26 upgrade I'm not sure - my experience was that I was taken from my X session to a new-style gdm, and on logging in, back to my previous X session.

For my gdm 2.26.1-0ubuntu1 to -0ubuntu2 upgrade, it definitely killed my session outright.

for me on amd64 it killed X , I had to alt F1 and startx from a console screen it dumped me into , cmds were visible and the last one had not returned in that console . pannels were overlapped on the desktop with a partial bottom panel sitting on top of the top panel .

I had to alt F1. logged in on that console. "sudo /etc/init.d/gdm restart" got back to the greeter.

I had update-manager minimized whilst I was doing a forum posting (about this problem) & the ?random? typing b0rked things rather well...I rebooted 7 everything came back---but it now looks more like the Fedora login--so I would gather that something was lost in passing......

The "7" should be "&"

My 2 cents:

The first upgrade gave me a new login screen and I stayed logged in like everybody else.

Now for the second one... I don't think It killed the session but simply logged out. At least aptitude that was running in yakuake didn't get killed until all updates were processed and firefox had time to close itself (Didn't tell me it had crashed).
What I actually saw was getting kicked out to tty7 without X - and after a few seconds gdm came back up.

OK, I just upgraded another machine from gdm 2.20 to 2.26, and can confirm that for that upgrade, the new gdm is erroneously started on vt8 / X screen :1 whilst the previous session remains happily alive on vt7 / :0.

I am attaching apt-term.log from that upgrade - in particular I find it suspicious that there is first an attempt to reload gdm, which fails, followed by an attempt to start gdm afresh, with is presumably responsible for the extra spurious gdm.

It's entirely possible that this is just a side effect of bug 395302. I'm going to test the 2.20 -> 2.26 upgrade again with that bug fixed.

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

I am still being prompted to log in while gnome is loading (with login screen disabled)