keyboard input broken due to invalid keyboard variant set by VMWare installer

Bug #548891 reported by dlotton on 2010-03-26
218
This bug affects 40 people
Affects Status Importance Assigned to Milestone
xorg-server (Ubuntu)
Medium
Chris Halse Rogers
Lucid
Medium
Martin Pitt
Maverick
Medium
Chris Halse Rogers

Bug Description

[Problem]
/etc/default/console-setup has an invalid XKBMODEL="SKIP" and/or XKBLAYOUT="U.S. English"

[Workaround]
For affected machines, run: sudo dpkg-reconfigure console-setup

[Impact]
Due to console-setup using invalid keyboard model and layout identifiers on certain (common) hardware, this can break the keyboard functionality in certain circumstances. For example, the vmware installer copies these invalid values and propagates them in a way that causes them to become the X defaults, thus confusing X and leaving the keyboard improperly set up.

[Development]
The fix has been committed to the main ubuntu-x git branch, which will be used once Maverick Meerkat is open for development, thus this fix will automatically copy over into it.

[Patch]
The xkb rules are modified to simply ignore the invalid values XKBMODEL="SKIP" and XKBLAYOUT="U.S. English" and use the default -evdev settings.

[Test Case]
1. Set XKBMODEL="SKIP" and/or XKBLAYOUT="U.S. English" in /etc/default/console-setup.
2. Install vmware
3. Reboot. When login box appears, verify password can be typed in properly

[Regression Potential]
Negligible. These days there are hardly any systems which aren't going to work fine with the default evdev settings, and anyway those cases would neither work with "SKIP" or "U.S. English" either.

[Original Report]
VMWare Player 3.0.1 build-227600
Host OS: Windows XP
Guest OS: Ubuntu 10.04 Beta, Kernel 2.6.32-17-generic

After installing a slew of Ubuntu updates on 3/26/2010 keyboard input at the gnome login prompt no longer works. The mouse does work and I am able to use the 'on-screen keyboard' accessibility tool to input my password and gain entry. After logging in, there does not seem to be any problems using the keyboard, I experience the problem only at the gnome login screen.

I suspected that after updating that possibly some of the vmware drivers may not be working correctly, so I ran vmware-config-tools.pl to recompile the tools, which didn't work. I've tried a couple of cycles of rebooting the VM and restarting vmware player, which hasn't resolved the problem either.

I've attached the portion of the apt history.log showing the packages that were applied during the update.

dlotton (yellow56) wrote :

To clarify a point, I ran vmware-config-tools.pl to recompile/reinstall the vmware drivers in the Ubuntu 10.04 beta guest OS. This completed successfully, but it did not resolve the problem.

affects: ubuntu → gdm (Ubuntu)
Matt Griffin (mattgriffin) wrote :

It looks like this bug is affecting many vmware users - http://swiss.ubuntuforums.org/showthread.php?p=9056673

Changed in gdm (Ubuntu):
assignee: nobody → Canonical Desktop Team (canonical-desktop-team)
Martin Pitt (pitti) wrote :

I use kvm extensively with lucid, and have so such problem, so I need more information to see in which part of the stack the problem is.

What do you mean exactly with "the keyboard does no longer work"? It does not react at all to key presses, it has the wrong layout and thus entering your password does not work, or something else? Does Caps Lock work and toggle the LED on the keyboard/laptop?

 * Can you do Ctrl+Alt+F1 to go to a text console? (Be sure to grab the keyboard, so that you actually go into the guest's text console, not the hosts')
 * If switching to a text console works, can you type text there? (Try to log in as your user)
 * If switching to a text console does not work, can you boot the 10.04 installation into rescue mode (press shift during boot to get to the menu)? Does the keyboard work there?
 * Does it change anything if you uninstall the vmware guest tools?

Thanks!

Changed in gdm (Ubuntu):
status: New → Incomplete
dlotton (yellow56) wrote :

After getting logged in there are no issues at all with the keyboard. I only see the problem at the login screen.

1) The keyboard does not appear to react at all to key presses at the Ubuntu login screen.
2) I cannot Ctrl+Alt+F1 to get to a console when booted to the login screen
3) During a normal boot if I hit keys while it is booting I can see those key presses output to the terminal before it switches to the Ubuntu splash screen
4) booting in recovery mode I can navigate the text 'Recovery Menu' and drop into a root shell and the keyboard works fine.
5) I have not tried uninstalling the vmware guest tools, but I have upgraded the kernel twice, which breaks the vmware tools (i.e. they are not compiled to work with the new kernel yet) and requires you to re-run the tools config program. After installing the new kernel and rebooting the vmware tools are not running. The same keyboard problem is observed. I login and reconfigure the tools for the new kernel and get them up and running, then if I logout or reboot at this point, I see the same keyboard problem when I get back to the login screen.
6) keyboard input seems to work fine before the login screen and after logging in. I just doesn't work at the Ubuntu login screen.

From the link someone posted above and a similar post I found on the vmware site (link below), others are seeing the problem as well.

http://communities.vmware.com/message/1503455#236418
(note the original post may not be related, but a few of the later posts look like the same situation I describe)

dlotton (yellow56) wrote :

Oops, I missed part of your first set of questions.

The 'caps lock' and 'num lock' keys do not appear to do anything while at the Ubuntu login screen. The indicator LEDs do not respond to pressing the respective keys.

Martin Pitt (pitti) wrote :

Thanks. I see some potential problems here:

 * keyboard layout:
  - Can you please do Ctrl+Alt+F1, login, and give me the output of

     sudo DISPLAY=:0 xprop -root |grep NAMES.S

 * plymouth (splash screen):
   - Does the keyboard start to work if you press Ctrl+Alt+F1 and then go back to gdm with Ctrl+Alt+F7? (Could also be F8)
   - If you do "sudo apt-get purge plymouth" and reboot, do you still have the problem?

 * libxklavier when changing the password:
  - Does the keyboard work before you select an user in the user list? I. e. can you enter characters when you select "other user", or can you click on the lower-right power icon and select menu entries with the cursor keys?

dlotton (yellow56) wrote :

* keyboard layout:

I have to be logged in via the on-screen keyboard in order to do the Ctrl+Alt+F1. After logging in and Ctrl+Alt+F1 to get the terminal screen I logged in and executed the requested 'sudo DISPLAY=:0 xprop -root |grep NAMES.S' command. Here is the output:

_XKB_RULES_NAMES(STRING) = "evdev", "SKIP", "us", "", "terminate:ctrl_alt_bksp"

* plymouth (splash screen):

I have to be logged in in order to get a Ctrl+Alt+F1 text terminal, if I go back (i.e. Ctrl+Alt+F7), I get back to my logged in session where the keyboard works normally(as it did before I went to the text terminal). If I wait long enough before going back from the text terminal I get the Ubuntu screensaver password dialog and I am able to type in my password there without problem. Ctrl+Alt+F8 from the text terminal goes to a blank text screen with a blinking cursor, but doesn't respond to any keyboard input.

Interesting side note: If I login, Ctrl+Alt+F1 to a text terminal, then resize my vmware window, it goes to the Ubuntu login screen, however, the keyboard input still doesn't work.

"sudo apt-get purge plymouth" and a reboot did nothing to resolve the issue.

* libxklavier when changing the password:

Keyboard does not work before selecting a user. Cannot cursor up/down to select menu items after clicking power button icon. Cannot enter anything after selecting 'Other' user. 'Cap Lock' and 'Num Lock' do nothing.

Charles Redman (charles-redman) wrote :

Just to add to your woes and to add a bit of diversity. I would like to point out that this does not only apply to Ubuntu as VM on a Windows host.

I have exactly the same problem with Lucid, running under VM Fusion on Mac OSX. Interestingly, i only built this machine today and only had this problem once i updated the machine. I built the initial VM using a beta1 ISO and everything was wonderful.

Unfortunately i have not been one of the lucky ones and been able to use the onscreen keyboard to login. I have no way to log in whatsoever, the keyboard does not come up if i try using the onscreen keyboard. No matter what i do the minute i tick the box, it disappears.

Ok, i rebuilt the VM as it only takes about 10mins to recreate. I ran the following before the update:

sudo DISPLAY=:0 xprop -root |grep NAMES.S
_XKB_RULES_NAMES(STRING) = "evdev", "SKIP", "gb,us", "mac,", ""

and then again after the update:

sudo DISPLAY=:0 xprop -root |grep NAMES.S
_XKB_RULES_NAMES(STRING) = "evdev", "SKIP", "us", "U.S. English", ""

The only way i can do anything is by using an ssh session to the VM at the moment. I cannot login into GDM.
I have tried logging in remotely and doing a service gdm shutdown and then a start but makes no difference.

I am happy to setup a new VM without the updates and go through a troubleshooting process if anyone has any ideas as to
what they would like me to supply them to compare what is different between the working and broken setups.

Additionally when i run:
setxkbmap gb
Cannot open display "default display"

or setxkbmap of any form i get this error message.

I am running this from a ssh session.

Attached is my dmesg output just incase.

dlotton (yellow56) wrote :

Charles,

There's a user in a forum at the link below that had similar behavior regarding the on-screen keyboard not working. This user said the on-screen keyboard would come up, then close immediately. If they left it alone for 15 minutes after boot, then they can get the on-screen keyboard to work.

That's not really a practical solution ongoing, but it may get you past the hump for now if it works.

http://ubuntuforums.org/showthread.php?p=9022898#post9022898

Thanks for that, i did read the thread beforehand, which was how i found this bug report. However i am not one of the lucky few that seems to have option of a onscreen keyboard to get me by. The best i can do is ssh. I may try something like nomachine to get me by for now.

Robert Kesterson (robertk) wrote :

I have the same problem here (Host: Windows XP, Guest, Ubuntu 10.04 beta, updated to latest as of 4/2/10). The keyboard doesn't work at all at the login screen, but the mouse works fine. I can access the on-screen keyboard to log in. If I log into KDE, the keyboard still doesn't work at all. However, if I log into Gnome, the keyboard then works fine.

dlotton (yellow56) wrote :

One further note to the developer,

I did not specify in my original post that I was using 64-bit Ubuntu as the guest OS and XP 32-bit as the host OS.

VMWare Player 3.0.1 build-227600
Host OS: Windows XP SP3 (32-bit)
Guest OS: Ubuntu 10.04 Beta (64-bit), Kernel 2.6.32-17-generic

It may be helpful for the developer if the others chime in with 32/64-bit specifics on the guest/host OS they're using.

I'm the guy who got the onscreen keyboard to work by waiting.

I'm using a Win7 x64 host, and an Ubuntu 10.4 x86 guest.

I don't believe that it was the waiting around specifically which made the on-screen keyboard work, rather that having come back to it, it had stopped freaking out, so...

Also, the virtual machine is definitely recognizing key-press events. When I try to type, the blinking cursor becomes steady, as it does whenever a key is pressed. However, nothing is being recognized as any kind of command sequence. My best guess would be that something is stealing all the key press events.

The on-screen keyboard crash appears to be a separate but annoyingly coincidental issue. I'll check debug logs for the on-screen keyboard when I get home, and post anything I find either here or in a separate bug depending upon what's crashing it.

My none-working setup is as follows:

VMWare Fusion 3.0.2 build-232780
Host OS: Mac OSX 10.6.3 (32/64bit)
Guest OS: Ubuntu 10.04 Beta (64-bit), Kernel Ubuntu 2.6.32-19.28-generic

I have setup a second VM should anyone wish to check the differences, with a standard install
of 10.04 beta1, no updates installed whatsoever. Which works. The setup for that is as follows:

VMWare Fusion 3.0.2 build-232780
Host OS: Mac OSX 10.6.3 (32/64bit)
Guest OS: Ubuntu 10.04 Beta (64-bit), Kernel Ubuntu 2.6.32-16.25-generic

Robert Kesterson (robertk) wrote :

Both my XP host and my Ubuntu guest are 32-bit. (As already noted, keyboard doesn't work at login or in KDE, but works in Gnome is you use the on-screen keyboard to log in.)

I have attached the Xorg logs from both the working and non-working VM's. There seems to be some issue with xkb creating xkm files at the end of the machine that is not working.

Travis B. Hartwell (nafai) wrote :

I've looked into it a bit, but could not reproduce under this
configuration:

VMware Player version 3.0.1 build-227600
Host is 64-bit Lucid system up to date as of today
Guest is 64-bit Lucid system up to date as of today

Tried both with and without VMware Tools installed.
VMware Tools version 8.1.4-227600 downloaded today.

No keyboard issues at all in the gdm login screen.

I note however that this is using a Ubuntu host, whereas from
reading the original report and previous comments, it seems the
problem is exhibited on OS X and Windows hosts.

I don't have access to either OS X or Windows, so someone else will
have to test.

I have the same problem after updates on the latest VMware player on Win 7 64 and on the latest VMware fusion on Snow Leopard. Initial beta install worked fine but updates killed the keyboard for the login screen. I was able to use the on-screen keyboard to login after enabling it and rebooting.

For the fusion VM I was able to get the keyboard input back by doing the following:
System->Preferences->Keyboard
On the Layouts tab I set the keyboard vendor to Apple and the model to Apple laptop (I'm on a MacBook Pro) and then applied system wide and rebooted.

I haven't tried similar steps on the Win host yet.

I just recently connected the dots, everyone who's having issues with the onscreen keyboard, this is your problem.
https://bugs.launchpad.net/ubuntu/+source/onboard/+bug/526791

After a little more research and VM building, this is what i find.

I can reproduce this problem with Ubuntu as guest on the following operating systems.

Ubuntu Karmic 64-bit
Mac OSX Snow Leopard
Windows XP
Windows 7
VMWare ESXi 4.0

For the most part, the problem is identical. Everything works with Lucid Beta 1 as the guest, up until applying updates
after that i can no longer log in with the same symptoms as previously reported on all of them, with the exception of Karmic. Karmic does not work from the get go, if i do a basic install of Lucid running on a Karmic host, the keyboard works but is mapped to the wrong keys and i have to use the onscreen keyboard to login. No matter what option i choose in under keyboard preferences after loggin in i cannot get the keyboard to map properly. After applying the updates to Lucid on the Karmic host it then mirrors the problems experienced with all the other hosts. The keyboard flat out does not work anymore.

Now the one thing i have noticed is that Lucid does not seem to pickup its keyboard mappings correctly for any of my hosts, when i say that, i mean it defaults to USA/USA as language and keyboard layout even though i have set it to use UK/UK as the language and keyboard layout.

I am assuming the reason some of us can work and some can't is because those that can are using a USA/USA layout.

Again, i am happy to test anything on any of the VM's i have should anyone wish to get to the bottom of this problem.

I am not sure the onscreen keyboard problem is necessarily exactly the bug listed above, as that was submitted in Feb and even though nothing has been resolved with it, Beta 1 shipped after that and the onscreen keyboard works in that release. Subsequent updates seem to have broken that again so i am sure its just a variation of it. I have experience exactly that bug but on a physical machine running Lucid and not in a VM.

This is definitely a problem with the guest not detecting the keyboard mappings or saving them. For some reason it insists on using American layout settings even if i log in an apply them system wide.

The only way i can use my machine at this point in time is to set it to AutoLogin and then i am fine but everytime i log in the first thing i have to do is change the keyboard layout.

dlotton [2010-04-01 18:55 -0000]:
> _XKB_RULES_NAMES(STRING) = "evdev", "SKIP", "us", "", "terminate:ctrl_alt_bksp"

Ah! This was also confirmed by Charles Redman. The "SKIP" here
definitively looks fishy. It ought to be "pc105" or something
similar, unless "SKIP" is a real keyboard model used by VMWare.

To track this down further, can you please give me the output of

  xprop -root |grep NAMES.S

when you are in the running GNOME session and the keyboard works? (My
hope is that the model is then "pc105" or something similar).

Please also give me the output of

 grep ^X /etc/default/console-setup
 udevadm info --export-db|grep LAYOUT|sort -u

Thanks!

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Martin Pitt (pitti) on 2010-04-05
Changed in gdm (Ubuntu):
assignee: Canonical Desktop Team (canonical-desktop-team) → Martin Pitt (pitti)

output of xprop -root |grep NAMES.S
_XKB_RULES_NAMES(STRING) = "evdev", "SKIP", "us", "", ""

output of grep ^X /etc/default/console-setup
XKBMODEL="SKIP"
XKBLAYOUT="us"
XKBVARIANT="U.S. English"
XKBOPTIONS=""

output of udevadm info --export-db|grep LAYOUT|sort -u
E: XKBLAYOUT=us

xprop -root |grep NAMES.S
_XKB_RULES_NAMES(STRING) = "evdev", "macbook79", "gb,us", "mac,", ""

grep ^X /etc/default/console-setup
XKBMODEL="macbook79"
XKBLAYOUT="gb"
XKBVARIANT="mac"
XKBOPTIONS=""

udevadm info --export-db|grep LAYOUT|sort -u
E: XKBLAYOUT=gb

The previous post was for a working machine with no updates installed.
With updates installed and no longer working, the above becomes:
xprop -root |grep NAMES.S
_XKB_RULES_NAMES(STRING) = "evdev", "SKIP", "gb,us", "mac,", ""

grep ^X /etc/default/console-setup
XKBMODEL="SKIP"
XKBLAYOUT="us"
XKBVARIANT="U.S. English"
XKBOPTIONS=""

udevadm info --export-db|grep LAYOUT|sort -u
E: XKBLAYOUT=us

Matt Griffin [2010-04-05 16:29 -0000]:
> output of grep ^X /etc/default/console-setup
> XKBMODEL="SKIP"

OK, thanks. This seems wrong, "SKIP" is not a valid keyboard layout.

To confirm that this is really the root problem, can you please do

  sudo dpkg-reconfigure console-setup

to reset the model on a system level?

> output of udevadm info --export-db|grep LAYOUT|sort -u

Ergh, I did a typo there. This was supposed to be "MODEL", not
"LAYOUT", but nevermind. /etc/default/console-setup is the top-level
definitive configuration resource, so the udev rules seem fine.

Martin: That worked. I ran through the questions in the application, restarted and the keyboard is working again at login.

output of xprop -root |grep NAMES.S
_XKB_RULES_NAMES(STRING) = "evdev", "apple_laptop", "us", "", ""

output of grep ^X /etc/default/console-setup
XKBMODEL="apple_laptop"
XKBLAYOUT="us"
XKBVARIANT=""
XKBOPTIONS=""

output of udevadm info --export-db|grep MODEL|sort -u
http://pastebin.ubuntu.com/409616/

Martin Pitt (pitti) on 2010-04-05
summary: - keyboard input broken at gnome login prompt after package updates
+ keyboard input broken due to invalid "SKIP" keyboard model

Martin,

To clarify my post above, note that I got "SKIP" from the 'xprop' command above ***after I was logged into a gnome session***.

I cannot get to a text console from gnome login screen using CTL+ALT+F1. I had to login first, then CTL+ALT+F1 to a text console, then run the 'xprop' command.

If I run the 'xprop' command in a Gnome terminal window within a logged in gnome session, I get 'SKIP' as well.

dpkg-recongure + reboot seems to fix the problem. I now have 'pc101' where 'SKIP' was before on the 'xprop' output.

Martin Pitt (pitti) wrote :

Thanks for checking. So the question is how this XKBMODEL="SKIP" appeared in /etc/default/console-setup in the first place. The file is written by console-setup's postinst, and that has a special case for "SKIP" once, but not in the code which actually writes the default file.

My guess would be that the question wasn't shown somehow in the installer, which leads to the debconf database having this "SKIP" value. On the date when it broke for you (3/26/2010) we did get a console-setup update, I guess this triggered the bug for you.

affects: gdm (Ubuntu) → console-setup (Ubuntu)
Changed in console-setup (Ubuntu):
assignee: Martin Pitt (pitti) → Canonical Foundations Team (canonical-foundations)
status: Incomplete → New
description: updated
Changed in console-setup (Ubuntu):
importance: Undecided → High

Martin, that is exactly the command i was looking for.
I have just run it and everything seems to be working as expected.

grep ^X /etc/default/console-setup
XKBMODEL="macbook79"
XKBLAYOUT="gb"
XKBVARIANT="mac"
XKBOPTIONS=""

Interestingly it has allowed me to drop the USA keyboard layout in GDM now too, which
i could not previously do. It would just come back after the next reboot.

xprop -root |grep NAMES.S
_XKB_RULES_NAMES(STRING) = "evdev", "macbook79", "gb", "mac,", ""

Thank you to both Martin and Matt for resolving this issue!
If there is any further feedback you require would be more than happy to assist.

oh, almost forgot to paste this. ;-)

output of udevadm info --export-db|grep MODEL|sort -u

http://pastebin.ubuntu.com/409642/

Hi Martin,

I think you are right in that the problem with the "SKIP" option appearing is as a result of something that is happening in the install
process. I think it is most likely something to do with the way that VMWare answers, or doesn't, the questions presented to it in the automated easy install option. I think this is the case because i have installed Lucid Beta 1 on physical machines from the same install ISO and not had the problem with the keyboard being set to "SKIP".

This may just be a case of VM needing to update their unattended install script, or possibly the Ubuntu post install checking to make sure the keyboard is not set to "SKIP" and if it is, prompting the user to specify a keyboard.

I have checked again and its definitely set to "SKIP" after a default install of Lucid without updates installed.

sudo DISPLAY=:0 xprop -root |grep NAMES.S

_XKB_RULES_NAMES(STRING) = "evdev", "SKIP", "gb,us", "mac,", ""

dlotton (yellow56) wrote :

Charles makes a good point.

I used the easy(unattended) install when I created my VM. Something in the VMware install script is probably be causing the keyboard type to be set as 'SKIP'.

That said, it works initially before upgrading packages and breaks after package upgrades. So it might be a good idea to see if the package upgrade is causing the keyboard type to change, or if something in the package update is just illuminating a dormant problem caused by the vmware install script.

The problem definitely exists from the beginning. I have checked a number of times with basic installs of Lucid Beta 1
without installing updates and they all come out with exactly the same output:

DISPLAY=:0 xprop -root |grep NAMES.S

_XKB_RULES_NAMES(STRING) = "evdev", "SKIP", "gb,us", "mac,", ""

So its seems the problem is dormant until such time as the latest console-setup update is applied and re-applies the settings
and then breaks things.

Marshall Levin (mlevin) wrote :

I had this exact problem. sudo dpkg-reconfigure console-setup fixed it for me. Thanks!

Ratan Mohapatra (ratan) wrote :

Hi All,
I am trying to enter the world of Linux. It's amazing, yet needs quite some learning for a novice like me! I am having the problem of "unappreciated" keyboard inputs in the login window of Ubuntu 10.04 desktop, as described in this forum. My environment: Ausus Windows 7 (64bit), vmware 3 for windows, Ubuntu desktop 10.04. I'll keep an eye on this forum for possible solutions.

Thanks
Ratan

Charles, it probably just needs to be fixed in the unattended install script, but Ubuntu should definitely be checking for nonsensical keyboard layouts. A simple sanity check when the keyboard is detected by hal should be enough. Throw a prompt if we get an undefined layout type. Should we be checking during the post-install? or at every keyboard plug-in?

I think the simplest way to do the sanity check, would be to do it as part of the clean-up process when a console-setup reconfigure is triggered.

Ratan Mohapatra (ratan) wrote :

As you suspected it's the vmware script. Here is what I did to get past it as I don't know how to play with its script. I was trying to use the auto install facility in vmware 3. I stopped it before running the skeleton of the vm and things worked fine. Guess it's a very dumb solution to the problem but I am happy as it works. If anyone is interested in the deatailed screen capture instruction feel free to drop an email to <email address hidden>

Joshua Kwan (joshk) wrote :

Hi guys!

I'm the one maintaining the VMware unattended installation of Ubuntu. First of all, sorry about this problem. It was not an issue until Lucid for us (I did note that someone saw this with Karmic, but I have to verify that myself.)

We've fixed the erroneous preseed of console-setup/modelcode=SKIP (and corrected it to 'evdev'), and you should see this in our upcoming maintenance and new product releases of Player, Workstation, and Fusion.

Thanks for using VMware!

-Josh

Joshua Kwan (joshk) wrote :

As a side comment for developers, perhaps console-setup should not accept preseeding of invalid output and do db_fset $question seen false and make sure the preseeded value is invalidated?

Hi Joshua,

Thanks for getting back to us. I just wanted to respond and clarify i don't think this affects Karmic. The only mention of Karmic was myself, having installed an instance of the guest running under Karmic for testing to eliminate whether it was an OS specific issue with respect to the host.

This problem only seems to exist with Lucid running as a guest within any given OS host, be it OS X, Windows or Linux.
I hope this helps clarify any ambiguity regarding where the problem lies.

David Clayton (dcstar) wrote :

I did test installs of 10.04 beta in VMware Player 3.1 (beta) and the "Easy Install" option resulted in a broken login keyboard (among other problems), selecting the other install method which requires a "normal" install process results in a VM that actually works.

I have the same problem and i am not using vmware.

My setup is a Lenovo W500 laptop . After upgrade to 10.04 beta 2 my keyboard is not responding anymore.

Changed in console-setup (Ubuntu):
status: New → Confirmed
kokot kokotovic (empacc100) wrote :

Great...
dpkg-reconfigure console-setup nice, and how am I supposed to know all that stuff it wants? (Not to mention that my KB is not listed there.) I set it up how I think I could be OK, then the KB works only partially (letters work, numbers and numeric part does not... some keys do not match).

I've never ever had any problems like this with any version of Windows or any keyboard before.
Linux usability & productivity ftw .... not.

Colin Watson (cjwatson) wrote :

Joshua: console-setup/modelcode=SKIP is actually supposed to be valid (the semantics are that it does not touch the kernel keymap). Evidently it should be considered invalid for Lucid due to this problem, but I'll need to look at fixing this.

Colin Watson (cjwatson) wrote :

For the history, see bug 59889.

16:08 <cjwatson> pitti: bug 548891: SKIP actually is meant to be valid - it's a magic value defined by me in console-setup a while back, meaning "just leave the kernel keymap alone and don't change it". I have a vague memory that X has a reasonable default keymap it could use, doesn't it?
16:09 <cjwatson> pitti: I could make the value be something different if that's easier, but actually I'm inclined to suggest that since SKIP has been there way back to hardy, whatever's failing to interpret it on the desktop side should be fixed instead. What would the correct package be to reassign this to?
16:27 <pitti> cjwatson: ah, so if it's supposed to be in /e/d/console-setup, then this can be reassigned to xserver-xorg-input-evdev; I'll care about it then
16:28 <pitti> cjwatson: the only sensible change would be to leave it empty (which I take isn't appropriate?), so let's keep it like it is
16:31 <cjwatson> pitti: I don't remember why I didn't leave it empty, although it may be that that would cause other problems and there's still the upgrade issue anyway
16:32 <cjwatson> pitti: I'll reassign, thanks; shall I assign to you?
16:32 <pitti> cjwatson: please do, yes
16:32 <cjwatson> pitti: this has the advantage that it seems SRUable, so we could automatically fix people in this situation
16:32 <pitti> cjwatson: sounds like an easy SRU (well, I need to test what X does if you don't specify a keyboard layout)
16:33 <pitti> cjwatson: but as long as X behaves without any keyboard layout set (like, default to US), then it's a trivial udev rule change
16:33 <cjwatson> right

affects: console-setup (Ubuntu) → xserver-xorg-input-evdev (Ubuntu)
Changed in xserver-xorg-input-evdev (Ubuntu):
assignee: Canonical Foundations Team (canonical-foundations) → Martin Pitt (pitti)
Martin Pitt (pitti) on 2010-04-27
Changed in xserver-xorg-input-evdev (Ubuntu Lucid):
status: Confirmed → In Progress
Martin Pitt (pitti) wrote :

I can't seem to be able to reproduce the actual keyboard breakage any more with XKBLAYOUT="SKIP". Perhaps something in Lucid changed to make X/GNOME/etc. more robust against invalid models. But anyway, let's fix it properly.

I confirmed that if XBKMODEL is not specified at all, X.org assumes "evdev", which is very sensible. So /lib/udev/rules.d/64-xorg-xkb.rules should be fixed to unset a value of "SKIP".

affects: xserver-xorg-input-evdev (Ubuntu Lucid) → xorg-server (Ubuntu Lucid)
Martin Pitt (pitti) wrote :

For those of you who can still reproduce this by switching /etc/default/console-setup back to "SKIP", can you please try to install my proposed fix in my SRU test PPA?

  sudo add-apt-repository ppa:pitti/sru-test
  sudo apt-get update
  sudo apt-get upgrade

(packages should be built in about 30 minutes).

I tested it on my systems, and the keyboard works fine. Thanks in advance!

Changed in xorg-server (Ubuntu Lucid):
milestone: none → lucid-updates
Chris Cheney (ccheney) wrote :

The updates in the ppa do not seem to fix the problem for me on VMware 7.0.1, host Ubuntu Lucid, guest Ubuntu Lucid. I still can't type my password into the login box after restarting with the updates applied. Though maybe not all of the updates are processed yet since you posted only about 31m ago. It did however pull a few packages from your repo.

dlotton (yellow56) wrote :

I set XKBMODEL="SKIP" in '/etc/default/console-setup' and restarted.

This does not cause the keyboard problem to return at login for me.

> sudo DISPLAY=:0 xprop -root |grep NAMES.S
>_XKB_RULES_NAMES(STRING) = "evdev", "SKIP", "us", "", "terminate:ctrl_alt_bksp"

Chris Cheney (ccheney) wrote :

Oh for my above problem that is still showing I do have both xserver-common and xserver-xorg-core from pitti's sru-test ppa.

My vmware setup might be slightly different than others in that I upgraded today from fully up to date Karmic 64bit to Lucid 64bit using update-manager -d. After rebooting I no longer had keyboard access at gdm and found this bug report.

My /etc/default/console-setup has:

XKBMODEL="SKIP"
XKBLAYOUT="us"
XKBVARIANT="U.S. English"
XKBOPTIONS=""

At GDM where it doesn't work (from the command line check) it shows up as:

_XKB_RULES_NAMES(STRING) = "evdev", "evdev", "us", "U.S. English", ""

In Gnome where it does work it shows up as:

_XKB_RULES_NAMES(STRING) = "evdev", "evdev", "us", "", ""

It also appears the virtual keyboard is very fragile and crashes after trying to turn it on and off, maybe related to 526791, but I am using VMware 7.0.1 on a ThinkPad X200 not a Macbook.

Hello dlotton,

dlotton [2010-04-27 20:57 -0000]:
> I set XKBMODEL="SKIP" in '/etc/default/console-setup' and restarted.
>
> This does not cause the keyboard problem to return at login for me.

Is that with the lucid packages or my PPA?

Thanks, Martin

Martin Pitt (pitti) wrote :

Hello Chris,

Chris Cheney [2010-04-27 21:20 -0000]:
> XKBMODEL="SKIP"
> XKBLAYOUT="us"
> XKBVARIANT="U.S. English"

Hm, this is also an invalid variant. Now that you mention it, a lot of
other reporters also has this, so I suppose it's again a bug in the
vmware setup script. However, comment 8 has an empty variant.

So my current working theory is that it previously choked on both an
invalid model and an invalid variant, and now the invalid model
doesn't hurt any more.

I tested your configuration and can perfectly reproduce the problem
with XKBVARIANT="U.S. English".

Does it start to work for you too if you set XKBVARIANT to ""? Also,
does it work with the lucid final X server for you, too?

We might consider adding a workaround for this "U.S. English" variant
and ignore it, but at this point it really gets messy.

For now I suggest that everyone who is affected fixes
/etc/default/console-setup to replace the broken
XKBVARIANT="U.S. English" with XKBVARIANT="".

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

summary: - keyboard input broken due to invalid "SKIP" keyboard model
+ keyboard input broken due to invalid keyboard varient set by VMWare
+ installer
Changed in xorg-server (Ubuntu Lucid):
importance: High → Low
milestone: lucid-updates → none
summary: - keyboard input broken due to invalid keyboard varient set by VMWare
+ keyboard input broken due to invalid keyboard variant set by VMWare
installer
Martin Pitt (pitti) wrote :

Ah, I just noticed that "U.S. English" is in fact the default value of console-setup's console-setup/layout debconf question, so it does make sense to special-case this as well.

Changed in xorg-server (Ubuntu Lucid):
importance: Low → Medium
milestone: none → lucid-updates
Martin Pitt (pitti) wrote :

I. e. due to some strange interaction with the VMWare installer, the value from console-setup/layout ended up in /variant..

Martin Pitt (pitti) wrote :

I now uploaded version 2:1.7.6-2ubuntu7pitti2 to my PPA, which ignores the "U.S. English" breakage as well. Testing appreciated!

The i386 build will be available in some 30 minutes, the amd64 variant will unfortunately take another two hours, due to PPA builders being clogged.

Changed in xorg-server (Ubuntu Lucid):
status: In Progress → Fix Committed

Joshua Kwan: do you know why we might have ended up with this weird
XKBVARIANT value?

dlotton (yellow56) wrote :

>Is that with the lucid packages or my PPA?
>
>Thanks, Martin

Martin,

My results were with the Lucid packages.

From the subsequent posts it looks like the issue may be an interaction of both model and layout parameters.

Chris Cheney (ccheney) wrote :

Martin,

The new packages work for me. :-)

Thanks!

Chris

Martin Pitt (pitti) wrote :

debdiff, for SRU review and git committing

description: updated
Bryce Harrington (bryce) wrote :

Committed to ubuntu-x git

Bryce Harrington (bryce) on 2010-04-28
description: updated
Bryce Harrington (bryce) wrote :

Martin, I've added the SRU bits to this bug report, but please review and elaborate on it. In particular I'm unsure I captured the test case correctly so could benefit from your review.

John Dong (jdong) wrote :

ACK from the SRU team if Martin doesn't want to ACK his own patch ;-)

I was a victim of this bug and the patch does work :)

Bryce Harrington [2010-04-28 21:52 -0000]:
> Martin, I've added the SRU bits to this bug report, but please review
> and elaborate on it. In particular I'm unsure I captured the test case
> correctly so could benefit from your review.

Looks great, thank you!

harveygfl (harveygfl) wrote :

When i tried to use the easy install i got the same problem that all of you are describing with the keyboard...
(OSX 10.6.3/VMWARE Fusion 3.02) to get it to work..

I changed the Install method by unchecking the easy install method, l and used the live cd to test to see what would happen, when I ran the Live CD the Keyboard worked.

So i Did the install from the the Live CD instead of the vmware fusion scrip and the install worked. This means that there is something wrong with the VMWARE Script and Ubuntu 10.04 (32Bit). For whatever reason the keyboard autodetect parameter does not pass of perhaps the parameter name has changed and is not recognized during the process.

a vmware update script should should fix this problem, untill then dont use the easy install method.

Noel J. Bergman (noeljb) wrote :

I have now upgraded, twice, a VM from 8.04 to 10.04, and can still reproduce this problem despite running

  # dpkg-reconfigure console-setup

to ensure correct values.

I have other Lucid VMs that I installed from scratch which work, and this VM works as 8.04 prior to upgrading to Lucid.

Any suggestions or requests (for further info)?

Noel J. Bergman (noeljb) wrote :

One bit of information regarding comment #70. I don't get to the login screen because the VM is configured to auto-login.

Noel J. Bergman (noeljb) wrote :

Found and fixed. It was necessary to rm /etc/X11/xorg.conf, which was present because of the upgrade from 8.04.

Accepted xorg-server into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

tags: added: verification-needed
Martin Pitt (pitti) wrote :

assigning to Chris for Maverick, since he'll upload it.

Changed in xorg-server (Ubuntu):
milestone: lucid-updates → maverick-alpha-2
assignee: Martin Pitt (pitti) → Chris Halse Rogers (raof)
milestone: maverick-alpha-2 → none
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xorg-server - 2:1.7.6-2ubuntu7.1

---------------
xorg-server (2:1.7.6-2ubuntu7.1) lucid-proposed; urgency=low

  [Bryce Harrington]
  * Add 123_exa_sys_ptr_nullpointer_check.patch: Patch from upstream to
    verify a pointer is not NULL before dereferencing it. Fixes X
    segfault in miCopyRegion which occurs while using firefox (e.g. typing
    into fields in AOL). Issue found by Jerry Lamos.
    (LP: #539772)
  * Add 19-exa-handle-pixmap-create-destroy-in-lower-layers.diff: Patch
    from Debian to fix X segfault on mouse click in xfig, when pixmaps
    are created in the course of software fallbacks.
    (LP: #553647)
  * debian/rules: Don't reference the package uploader for support; instead point
    users to the standard Ubuntu support page.
    (LP: #589811)

  [Martin Pitt]
  * debian/local/64-xorg-xkb.rules: Ignore XKBMODEL=="SKIP" and
    XKBVARIANT=="U.S. English", which happen to get into
    /etc/default/console-setup in some cases like the VMWare automatic
    installer.
    (LP: #548891)

  [ Christopher James Halse Rogers ]
  * Update 122_xext_fix_card32_overflow_in_xauth.patch to most recent version
    on patchwork tracker. This one actually fixes the crash with xauth
    generate (LP: #519049)
 -- Christopher James Halse Rogers <email address hidden> Mon, 07 Jun 2010 12:56:54 +1000

Changed in xorg-server (Ubuntu Lucid):
status: Fix Committed → Fix Released
Martin Pitt (pitti) wrote :

Chris, please upload this ASAP to maverick (SRU policy).

Changed in xorg-server (Ubuntu Maverick):
milestone: none → maverick-alpha-2
Changed in xorg-server (Ubuntu Maverick):
status: Fix Committed → Fix Released
Chris Halse Rogers (raof) wrote :

This fix was already in 2:1.7.6-2ubuntu8 which is in the history of 2:1.8.1.901-1ubuntu1, but when uploaded this merge didn't get the full changelog added to the sources so this bug wasn't automatically closed.

This should be fixed already in Maverick; if it isn't please re-open.

Clive Darra (osde8info) wrote :

keyboard is also completely when when xubuntu 9 with vmplayer is used to build a xubuntu 10.04 vm from 'official' CD !

another workaround is build your vm on a windoz pc running vmware player and copy vm files to ed/x/ubuntu pc !

Ted Gulesserian (tguless) wrote :

Thank you noel for the "rm /etc/X11/xorg.conf" tip. There are a million websites saying that dpkg-reconfigure console-setup is the trick to fix this issue, but I had to read through this thread to find the nugget of information you provided.

My keyboard works again in lucid lynx running on vmware 7.1

Thank you.

Mike Savory (msavory) wrote :

Clean Install of Lucid Server 10.04.1 from CD image using VMWare 3.1.1 install wizzard suffered from this issue (most noticeably the arrow keys were not functional. Re-running the sudo dpkg-reconfigure console-setup and selecting the Dell 101 key, keyboard and USA layout fixed the issue.

Mike

Kevin Pederson (kevinpederson) wrote :

The same Issue I am also facing with my Keyboard also but additionally, I am also facing the Problem with my AOL account, Is this issue has any connectivity with Keyboard Issue? For more information or have an issue regarding AOL account You may visit:
https://www.aoltechsupportnumber.com/blog/how-to-close-a-free-aol-account/

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

Other bug subscribers