pressing 2 or Enter terminates X server on live CD

[Eliah Kagan]

Binary package hint: xorg

On two machines with significantly different hardware (a VMware Workstation 7.1.4 build-385536 virtual machine and a Dell Inspiron E1505 laptop) running the Oneiric i386 20110616.1 daily-live (xorg/xserver-xorg 1:7.6+7ubuntu1, xserver-xorg-input-evdev 1:2.6.0-1ubuntu12) and US/English keyboard layouts, all keys work normally in X11 except for the Enter keys and the numeral 2 key on the alphanumeric portion of the keyboard. When either Enter key or the alphanumeric 2 key is pressed, the X server immediately terminates, and the following (taken from the VMware machine) is written to /var/log/Xorg.0.log:

[ 2354.948] (II) Power Button: Close
[ 2354.979] (II) UnloadModule: "evdev"
[ 2354.979] (II) Unloading evdev
[ 2354.995] (II) AT Translated Set 2 keyboard: Close
[ 2354.995] (II) UnloadModule: "evdev"
[ 2354.995] (II) Unloading evdev
[ 2354.995] (II) VMWARE(0): VMMOUSE DEVICE_OFF/CLOSE
[ 2355.307] (II) VMWARE(0): VMMOUSE DEVICE_OFF/CLOSE
[ 2355.404] (II) VMWARE(0): VMMouseUnInit
[ 2355.445] (II) vmwlegacy(0): Terminating Xv video-stream id:0
[ 2356.052] ddxSigGiveUp: Closing log

This does not occur with the 2 key on the numeric keypad, which works fine with Number Lock on (and works fine as a down arrow key, when Number Lock is off). Pressing the alphanumeric 2 key while holding down either Shift key (in an attempt to produce a @ character) has the same effect as typing '2' without any other keys depressed (it terminates the X server). This does not look like a crash, and there is no crash data in /var/crash. As expected, in the Terminal, ^M (Ctrl+M) works in place of the enter key--to report this bug I ran apport-cli in a Terminal after causing the X server to terminate by pressing the alphanumeric 2 key. In a virtual console, after the X server terminates, the alphanumeric 2 key and the enter keys work as expected.

While I triggered it in a unity-2d session this time around, I have also triggered this in a 3D Unity session (tested on the Dell Inspiron E1505), and in the graphical login screen (provided by lightdm) before any session has been started.

This bug has occurred with (at least) the last few Oneiric daily-lives. It is not new as of the 20110616.1 CD.

This occurs only with Oneiric live CD's; it does not happen on installed Oneiric systems.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: xorg 1:7.6+7ubuntu1
ProcVersionSignature: Ubuntu 3.0-0.1-generic 3.0.0-rc2
Uname: Linux 3.0-0-generic i686
Architecture: i386
Date: Fri Jun 17 01:46:05 2011
LiveMediaBuild: Ubuntu 11.10 "Oneiric Ocelot" - Alpha i386 (20110616.1)
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
SourcePackage: xorg
UpgradeStatus: No upgrade log present (probably fresh install)

[Jean-Baptiste Lallement (jibel)]

Thanks for your report.

That's interesting there's this output on your Xorg.log file:
[ 2354.948] (II) Power Button: Close
[ 2354.979] (II) UnloadModule: "evdev"
[ 2354.979] (II) Unloading evdev
[ 2354.995] (II) AT Translated Set 2 keyboard: Close

I can't reproduce it on a laptop but I'll try on a system with a US keymap.
Setting to confirmed/high for now.

[Eliah Kagan (degeneracypressure)]

With today's daily-live (20110617, with ubiquity 2.7.9), this bug is revealed to be even more interesting. In summary, it appears that this occurs when ubiquity-dm has not run.

Unlike previous daily-lives for a while, 20110617 has a ubiquity-dm (graphical Try/Install and language selector menu screen) that works on my machines. When I allow ubiquity-dm to come up, and I press 2 or Enter on the ubiquity-dm screen, the X server is not terminated. When I click Try Ubuntu, I get a lightdm login screen (like I got on previous daily-lives without working ubiquity-dm), where I can also press 2 and Enter without problems. And after I log in, 2 and Enter continue to work properly in the ensuing login session.

However, if instead of allowing ubiquity-dm to come up, I press Spacebar when the keyboard and person icons appear at the bottom of the screen during boot, and select "Try Ubuntu without installing" in the resulting text-based boot menu, it boots directly to the lightdm login screen (as expected), and the 2 and Enter keys do cause the X server to terminate. This happens when they are pressed at the lightdm login screen, and also in a login session started from that login screen.

I have tested the above on both the virtual and physical machines. Testing in login sessions was done in just unity-2d on the VM, and in both unity-2d and 3D Unity on the Inspiron E1505, and in each case with both the alphanumeric 2 key and the alphanumeric Enter key (since I was already testing numerous permutations, I forewent testing with the numeric keypad's Enter key).

I'm not sure how specific, if at all, this behavior is to the new daily-live. If ubiquity-dm worked on previous Oneiric live CD's, I'd expect them to have that same behavior. (Does ubiquity-dm work for some people on previous, but recent, daily-lives?)

[Eliah Kagan (degeneracypressure)]

@Jean-Baptiste Lallement
You had been (so far) unable to reproduce this bug. Given the above information, if you have not done so already, I recommend trying to produce it after manually selecting your language and "Try Ubuntu without installing" (or the equivalent menu item).

[Eliah Kagan (degeneracypressure)]

I have found that, once Ubuntu is installed (with Ubiquity), even in the same login session in which it was installed (after clicking Continue Testing), pressing 2 or Enter no longer terminates the X server. The test system was the 20110617 daily-live on the virtual machine.

So I reset the virtual machine to its pre-installation state, cloned it to create a control, and installed Oneiric on it again while running the control, so I could examine log files from both systems side by side. Specifically, I booted both systems (selecting "Try Ubuntu without installing" from the nongraphical boot menus) and logged on with unity-2d sessions, disabled screensaver screen locking, set their screen resolutions down from 1024x768 to 800x600, installed openssh-server (and set passwords for the live session user), and then monitored /var/log/Xorg.0.log and /home/ubuntu/.xsession-errors on both systems via tail -f in nongraphical SSH sessions. I launched Ubiquity and installed Ubuntu on the first machine (the experimental), and left the other (the control) alone for comparison. After installation, I pressed the alphanumeric 2 key in each machine; as expected, the experimental machine's X server was not terminated, but the control machine's X server was.

I did not notice any differences in the .xsession-errors files that appeared noteworthy, but there were additional XKB (X keyboard extension) messages in the experimental Xorg.0.log that appeared while Ubiquity was running, and did not appear at all in the control Xorg.0.log.

This was the output of tail -f on the experimental Xorg.0.log (running Ubiquity):

[ 78.985] (**) ImPS/2 Generic Wheel Mouse: (accel) acceleration profile 0
[ 78.996] (**) ImPS/2 Generic Wheel Mouse: (accel) acceleration factor: 2.000
[ 78.996] (**) ImPS/2 Generic Wheel Mouse: (accel) acceleration threshold: 4
[ 78.997] (II) VMWARE(0): VMMOUSE DEVICE_ON
[ 78.998] (II) VMWARE(0): vmmouse enabled
[ 79.006] (II) config/udev: Adding input device ImPS/2 Generic Wheel Mouse (/dev/input/mouse0)
[ 79.006] (II) No input driver/identifier specified (ignoring)
[ 99.634] (II) VMWARE(0): vmmouse enable absolute mode
[ 113.551] (II) XKB: generating xkmfile /var/lib/xkb/server-9A8405F3FE0A780485714A4B6DD41909C2CF9F83.xkm
[ 200.384] (II) XKB: reuse xkmfile /var/lib/xkb/server-9A8405F3FE0A780485714A4B6DD41909C2CF9F83.xkm
[ 864.528] (II) XKB: reuse xkmfile /var/lib/xkb/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm
[ 864.851] (II) XKB: reuse xkmfile /var/lib/xkb/server-9A8405F3FE0A780485714A4B6DD41909C2CF9F83.xkm
[ 878.207] (II) XKB: reuse xkmfile /var/lib/xkb/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm
[ 878.267] (II) XKB: reuse xkmfile /var/lib/xkb/server-9A8405F3FE0A780485714A4B6DD41909C2CF9F83.xkm

And this was the output of tail -f on the control Xorg.0.log (not running Ubiquity):

[ 74.291] (**) ImPS/2 Generic Wheel Mouse: (accel) acceleration profile 0
[ 74.293] (**) ImPS/2 Generic Wheel Mouse: (accel) acceleration factor: 2.000
[ 74.293] (**) ImPS/2 Generic Wheel Mouse: (accel) acceleration threshold: 4
[ 74.293] (II) VMWARE(0): VMMOUSE DEVICE_ON
[ 74.294] (II) VMWARE(0): vmmouse e...

[Eliah Kagan (degeneracypressure)]

@Timo Aaltonen
I have noticed that you have just marked this bug as a duplicate of bug 579313. However, Steve Langasek (https://launchpad.net/~vorlon) insists (https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/579313/comments/22) that this is a different bug. Based on that post, I am marking this no longer a duplicate of bug 579313, and I am adding lightdm as an affected source package. I have also subscribed Timo Aaltonen to both bugs and Steve Langasek to this bug, so that everybody knows what's going on, and nobody feels like they are being ignored. I apologize if this action (subscribing both of you) is inappropriate.

[Launchpad Janitor (janitor)]

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

[Richard Stellingwerff (remenic)]

I'd like to let you guys know that I am experiencing the same bug. It doesn't *always* crash when pressing the '2' key on the alphanumeric part of my keyboard, nor does it *always* crash when pressing enter, but it does so often enough (I've had it happen 50 times already today) that it makes me want to scream. In fact, is currently getting in my way of getting work done, something my employee certainly won't appreciate.

I'm running Lubuntu 11.04. This behavior started today (I've been running this setup for a few weeks now).

[Eliah Kagan (degeneracypressure)]

@Richard Stellingwerff
This bug is a duplicate of bug 802271, so you should post there instead. Your post here will likely be unseen, and ignored to the extent to which it is seen. It is strange that you are getting this on Natty, as this bug was specific to Oneiric (and was also fixed), so it might turn out to be a subtly different bug, but posting in bug 802271 is a good first step. I recommend against changing bug 802271's status without consulting others first (i.e., do not reopen that bug), because your issue may be more properly handled in a separate bug report. Hopefully you'll be advised by people who know best, after posting in bug 802271.