Failure installing ubuntu 20.04 in virtual machine at 19.10

[Chris Ward]

I needed to install a 20.04 virtual machine, using virt-manager on a 19.10 system. Both real and virtual machines were amd64.
I found that the keyboard did not work for typing to the virtual machine, so I was not able to progress beyond the 'enter your name' screen. The mouse worked normally.
This occured while I was trying to progress bug #1863751 .

tjcw@tjcw-OptiPlex-790:~/Downloads$ lsb_release -rd
Description: Ubuntu 19.10
Release: 19.10
tjcw@tjcw-OptiPlex-790:~/Downloads$ apt-cache policy qemu-system-x86
qemu-system-x86:
  Installed: 1:4.0+dfsg-0ubuntu9.3
  Candidate: 1:4.0+dfsg-0ubuntu9.4
  Version table:
     1:4.0+dfsg-0ubuntu9.4 500
        500 http://gb.archive.ubuntu.com/ubuntu eoan-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu eoan-security/main amd64 Packages
 *** 1:4.0+dfsg-0ubuntu9.3 100
        100 /var/lib/dpkg/status
     1:4.0+dfsg-0ubuntu9 500
        500 http://gb.archive.ubuntu.com/ubuntu eoan/main amd64 Packages
tjcw@tjcw-OptiPlex-790:~/Downloads$

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: qemu-system-x86 1:4.0+dfsg-0ubuntu9.3
ProcVersionSignature: Ubuntu 5.3.0-29.31-generic 5.3.13
Uname: Linux 5.3.0-29-generic x86_64
ApportVersion: 2.20.11-0ubuntu8.4
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Wed Feb 19 20:53:18 2020
InstallationDate: Installed on 2020-02-13 (6 days ago)
InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
MachineType: Dell Inc. OptiPlex 790
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-29-generic root=UUID=15bac8d7-d2b7-49e5-bd3d-76a619ae2a53 ro quiet splash vt.handoff=7
SourcePackage: qemu
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/03/2018
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A22
dmi.board.name: 0D28YY
dmi.board.vendor: Dell Inc.
dmi.board.version: A01
dmi.chassis.type: 15
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA22:bd07/03/2018:svnDellInc.:pnOptiPlex790:pvr01:rvnDellInc.:rn0D28YY:rvrA01:cvnDellInc.:ct15:cvr:
dmi.product.name: OptiPlex 790
dmi.product.version: 01
dmi.sys.vendor: Dell Inc.

[Christian Ehrhardt  (paelzer)]

Hi Chris,
I tried installing the focal desktop image s(is that waht you used?) [1] in Eoan and in Focal under virt-manager.

I also tried it on early boot when the disk image initializes (the white/orange dots) there F2 got me to the boot console and I saw services coming up.

I switched back to the graphical UI and after loading for a while I got to the usual installer input boxes - I was able to type into those just as usual.

Is that issue reproducible for you, if so which guest image/iso exactly are you using?

P.S. the guest was rather slow, that was the only thing I realized being different than usual - after a while I realized I was running emulation instead of KVM. Fixing that still showed the same results (working keyboard).

[1]: http://cdimage.ubuntu.com/daily-live/current/focal-desktop-amd64.iso

[Bryce Harrington (bryce)]

Hi Chris and Chris,

There could be a number of different causes for why the keyboard may not work. You'll need to do a bit more sleuthing to isolate where it's getting hung up.

Given Christian is not reproducing it, it's unlikely to be a regression in the qemu software itself, but perhaps more likely a conflict for your particular combination of hardware and environment.

Generally for X input devices, the first thing I'd check is if the device is being recognized by the system. Two commands for this are:

  $ xinput
  $ sudo lsinput

The first command shows what X sees. You should see 'Virtual core keyboard' and some sub-devices off of it. I've seen situations where, for instance, a power button or webcam or other function key gets detected as "the keyboard", so keystrokes don't do anything; I'm doubtful this would happen under qemu but look for anything irregular. If the problem can be isolated to X devices, there are further troubleshooting steps that can be taken.

The second command shows the kernel layer. There should be at least one /dev/input/event* entry for a keyboard. I'm not versed in how this looks under qemu vs. ordinary desktops but again look for anything irregular. If the problem can be isolated to the kernel layer, then kernel troubleshooting steps should be followed.

Another thing I would check is if you can access the console and log in that way. This would isolate the problem to X as opposed to something lower in the stack.

Also note that sometimes if you can move the mouse cursor, but nothing else works (not just typing, but neither button clicks nor clock updates on the screen), then the problem might be a system lockup or crash, in which case the issue would probably be with the application layer. Checking dmesg or the journal for error messages would be the next step there.

Other random things to try would be to see if you can reliably reproduce the same issue or not on different hardware, or different ubuntu releases, or other variances.

[Chris Ward (tjcw)]

On retrying, the keyboard worked normally. So this can be closed as 'unreproducable'

[Chris Ward (tjcw)]

On trying again, I find I get the 'missing' keyboard when I try selecting 'install' from the boot screen, but a functional keyboard when I select 'try ubuntu' from the boot screen and then double-click the 'Install Ubuntu 20.04 LTS' icon after the boot. So maybe this problem is reproducible.

[Bryce Harrington (bryce)]

Christian, when you tested did you boot the live environment and then run the installer, or just go directly into install?

Chris, collecting the files I mentioned previously in the working environment would let you compare them with the broken environment. You could also try going to the console (F2 I think?) and see if the keyboard works there.

Good that you tested going through the live environment, I forgot to suggest trying that. That narrows down where the fault might lay (i.e. probably higher up than the kernel, and probably rules out qemu and X), as well as giving a way to workaround.

[Chris Ward (tjcw)]

I tried it again (with a view to going to the console), but this time the keyboard worked normally. So the problem isn't 100% reproducible. I will try a few more times to see if I can ever get the problem to reoccur.

[Chris Ward (tjcw)]

Trying again gives the keyboard not working. The difference between 'working' and 'not working' seems to be that it works when I have the virtual disk on an SSD, and doesn't work when I have the virtual disk on a real disk (on a USB3 bus). I have a problem believing this, though, because the failing install doesn't get as far as trying to access the disk. Maybe there is some unreliability in setting up the keyboard access.
In the failing case, I can get qemu to send Ctrl-Alt-F2 to the virtual machine to get a text console. When I do this, I get a login prompt; the keyboard is working so I can attempt to log in, but I don't know what user and password to use so I can't succeed in logging in and I can't issue the commands to collect the data you are asking for.

[Paride Legovini (paride)]

Hi,

I tried the described scenario a few times from both Eoan and Focal hosts and always ended up with a working keyboard. FWIW, while doing ISO testing I often ran installations of Ubuntu *server* on Eoan and now I do on Focal, and never experienced the issue.

I do not doubt the report is valid, but it's one of those cases where without a reproducer it is very difficult to take action.

Is the host system running Xorg or Wayland?

[Chris Ward (tjcw)]

Host is running Xorg

[Christian Ehrhardt  (paelzer)]

In the long past the install environment had user "ubuntu" and no password set, does this still work to get you logged in for checking the environment?

[Chris Ward (tjcw)]

Yes, 'ubuntu' with no password worked. Here is a 'typescript' log of the suggested commands at the beginning of an attempted install where there is no keyboard for X (which seems to happen about 1 time in 2 for me)
Script started on 2020-02-28 08:31:07+00:00 [TERM="linux" TTY="/dev/tty2" COLUMNS="128" LINES="48"]
ubuntu@ubuntu:~$ xinpo^H^[[Kut^M
Unable to connect to X server^M
ubuntu@ubuntu:~$ sudo lsinput^M
sudo: lsinput: command not found^M
ubuntu@ubuntu:~$ ld -^H^[[K^H^[[K^H^[[Ks -l /dev/input/event*^M
crw-rw---- 1 root input 13, 64 Feb 28 08:29 ^[[0m^[[40;33;01m/dev/input/event0^[[0m^M
crw-rw---- 1 root input 13, 65 Feb 28 08:29 ^[[40;33;01m/dev/input/event1^[[0m^M
crw-rw---- 1 root input 13, 66 Feb 28 08:29 ^[[40;33;01m/dev/input/event2^[[0m^M
crw-rw---- 1 root input 13, 67 Feb 28 08:29 ^[[40;33;01m/dev/input/event3^[[0m^M
ubuntu@ubuntu:~$ exit^M

Script done on 2020-02-28 08:32:15+00:00 [COMMAND_EXIT_CODE="0"]

[Chris Ward (tjcw)]

I have added the output from 'journalctl' and 'dmesg'. Do either of these help with understanding what is going on ?

[Chris Ward (tjcw)]

[ 17.684] (II) event1 - AT Translated Set 2 keyboard: is tagged by udev as: Keyboard
[ 17.684] (II) event1 - AT Translated Set 2 keyboard: device is a keyboard
[ 17.685] (II) event1 - AT Translated Set 2 keyboard: device removed
[ 17.685] (**) Option "config_info" "udev:/sys/devices/platform/i8042/serio0/input/input1/event1"
[ 17.685] (II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type: KEYBOARD, id 8)
[ 17.685] (**) Option "xkb_model" "pc105"
[ 17.685] (**) Option "xkb_layout" "us"
[ 17.686] (II) event1 - AT Translated Set 2 keyboard: is tagged by udev as: Keyboard
[ 17.686] (II) event1 - AT Translated Set 2 keyboard: device is a keyboard

in the Xorg.0.log looks suspicious; what does 'device removed' indicate ?

[Chris Ward (tjcw)]

I have tried multiple times this morning to start an install in a VM so that I could get comparison logs, but every time the keyboard is missing. @bryce or someone else, please can you try an install in a VM and post the matching files from a successful install attempt ? You only need to go as far as keyboard selection, if keying something into the keyboard test field works, then you have a viable install.

[Launchpad Janitor (janitor)]

[Expired for qemu (Ubuntu) because there has been no activity for 60 days.]