Keyboard stops working during installation

[dpearceFL]

Trying to install ProxMox 6.2 on a machine that I have installed ten+ versions of Linux and ESXi successfully. I can get to the first splash page and use the keyboard to select ProxMox or ProxMox Debug.

When I get to the EULA, I can get no action from the keyboard or a mouse. Pressing ALT has no affect.

When I try Debug, I get to the first prompt (Control D to continue) and the keyboard is totally unresponsive.

Tried multiple keyboards, mice and USB ports. Always the same thing.

I'd like to try and recommend ProxMox but not getting anywhere.

 

[H4R0]

You can install debian buster and install pve afterwards, the debian installer usually works.

https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Buster

 

[dpearceFL]

Usually works? And I thought ESXi was particular about hardware.

 

[dpearceFL]

Still cannot get this to work. Reset the BIOS to legacy, tried multiple USB slots. It always hangs on the EULA screen. I got ProxMox to work on a smaller Intel motherboard (A4-5000) but not this AMD motherboard.

 

[dpearceFL]

I let the system sit on the EULA page and the following message show up: "Failed to execute child process "scrot" (No such file or directory". Does this ring any bells?

 

[t.lamprecht]

"Failed to execute child process "scrot" (No such file or directory". Does this ring any bells?

Did you tried making a screenshot? as scrot is such a program (we do not call it anywhere).

Anyway, a bit more details would be good to have, Motherboard, Keyboard, CPU, ... model

tried multiple USB slots

This may mean that keyboard isn't the real issue but USB is.

When I try Debug, I get to the first prompt (Control D to continue) and the keyboard is totally unresponsive.

Any messages there?

 

[dpearceFL]

I spent almost a day but I think I have it figured out. The motherboard I am using has three USB controllers. When at the first screen to select Install, Debug, etc. all of the USB ports work. By the time I get to the EULA, only two ports are working. I was using three USB devices: keyboard, install USB drive and another USB drive where I hoped to install Proxmox. Well, that is three devices with only two working ports. Therefore I am sunk. Until I get a new test server, I'll have to live with Proxmox installed in ESXi Free.

 

[dpearceFL]

I found several settings in the BIOS to allow "legacy" passthru. One of them worked. Now I have ProxMox running on my main box,

 

[jsterr]

I had this on a machine today at the summary page of the installer while accessing via ipmi AND having a physical usb-keyboard and mouse connected to the machine. Mainboard: H11DSi-NT BIOS all UEFI despite graphics -> LEGACY.

 

[aljaxus]

Did you tried making a screenshot? as scrot is such a program (we do not call it anywhere).

Necro-posting really isn't my thing, but just to confirm for other users that may face this warning during PVE installation.
Can confirm that pressing the screenshot button resulted in the popup with the warning.
Installing PVE via ThinkPad and accidentally pressed the key.

I'm glad it's not an issue with the installer.

 

[Darkhand]

Also necroing this thread to add that I also have this issue, the keyboard becomes 'undetected' at the EULA screen. Works perfectly at BIOS/EFI before that point.

The workaround I've found is to unplug/replug the keyboard. The device is then successfully redetected and installation can continue.

EDIT: Upon further research this may be a Debian bug, as I've seen other non-Proxmox Debian threads mentioning the same issue. Their solutions seem to include adding the 'noacpi' flag to the boot menu but I haven't tested it.

 

[ktdt00]

Necro-post... Same problem... Dell Precision T5810. I've tried unplugging/replugging to every port across three controllers, installed 3rd party PCI USB card, noapci, noapic nolapic, iommu=soft, iommu=on, intel_iommu=on and every possible bios setting. Debian installs natively just fine. I really wanted a native install instead of an "over the top"... Alas...

 

[t.lamprecht]

What happens if you try the debug mode, does it work there in the first two shells, i.e., before the graphical install mode starts?

 

[ktdt00]

What happens if you try the debug mode, does it work there in the first two shells, i.e., before the graphical install mode starts?

Both shells work fine and there are no observed errors. The issue doesn't present until the graphical mode starts. Two other observations:

1) If I use a standard USB keyboard the power light on it goes out right before the GUI starts. If I unplug/plug it into any other USB port the light won't come back on.

2) If I use a logitech keyboard/mouse combo with a dongle, when the GUI starts the mouse pointer will continue to move (weird!) but the buttons don't work and the keyboard is not functional. If I unplug/plug the dongle, regardless of port, the mouse pointer will no longer move.

Thanks for engaging this old thread!

 

[t.lamprecht]

So, we'd need some logs, which in general would need keyboard support to switch to the other ttys, classic catch 22.

But, you could try using http to exfiltrate logs:

1. Use the debug mode and continue to the second level shell
2. Start a http server with the available python in the background: python3 -m http.server &
3. Pipe the kernel log to a file in the background: dmesg -wT >/run/k.txt &
4. Continue the installation but ensure you see what IP address the dhcp request gets for the installer
5. open that IP in the browser, e.g., http://192.168.0.123:8000 and go to run and open the k.txt file and check for errors or anything out of interest, other files of potential interest /var/log/Xorg.0.log

Maybe you can find anything that helps tracking this down..

 

[ktdt00]

So, we'd need some logs, which in general would need keyboard support to switch to the other ttys, classic catch 22.

But, you could try using http to exfiltrate logs:

1. Use the debug mode and continue to the second level shell
2. Start a http server with the available python in the background: python3 -m http.server &
3. Pipe the kernel log to a file in the background: dmesg -wT >/run/k.txt &
4. Continue the installation but ensure you see what IP address the dhcp request gets for the installer
5. open that IP in the browser, e.g., http://192.168.0.123:8000 and go to run and open the k.txt file and check for errors or anything out of interest, other files of potential interest /var/log/Xorg.0.log

Maybe you can find anything that helps tracking this down..

Please see attached. At the end of each file you will also see where I unplugged and replugged the USB device. It appearas as though it was properly detected, etc. although after doing so there appeared to be no response on the screen where previously I could see the mouse cursor moving. Note that in this case I was using a USB2.0 hub with the flash drive and the logitech transceiver plugged into it. I was trying the hub as another thread in an ubuntu forum suggested it for a similar issue.

Some time markers:
16:53 - arrived at 2nd debug shell. While here I manually brought up enp0s25 interface to test the web server. This took me a bit.
17:14 - pressed Ctrl-D to continue and tried to interact with the installer gui for a bit and looked at a few logs for a while
17:23 - manually disconnected and reconnected USB hub with flash drive and logitech transceiver

 

[t.lamprecht]

Hmm, that K400 Logitech keyboard is a bit out of the ordinary, but especially as it works in the tty console it should also work in xorg...

But hmm, the log seems okish enough, at least until the end:

[  1350.992][  1480.609] (EE) event3  - Logitech K400: client bug: event processing lagging behind by 13ms, your system is too slow

There are some reports of such things happening due to USB auto suspend:
https://wiki.archlinux.org/title/Power_management#USB_autosuspend

 

[ktdt00]

Hmm, that K400 Logitech keyboard is a bit out of the ordinary, but especially as it works in the tty console it should also work in xorg...

But hmm, the log seems okish enough, at least until the end:

[  1350.992][  1480.609] (EE) event3  - Logitech K400: client bug: event processing lagging behind by 13ms, your system is too slow

There are some reports of such things happening due to USB auto suspend:
https://wiki.archlinux.org/title/Power_management#USB_autosuspend

Thanks for the lead. I get the exact same symptoms with a regular ole usb kybd though... I'll mess around with it some more. I found another thread trying to load a newer version of xserver-xorg-input-all... Thanks!!!

 

[ktdt00]

FWIW and posterity I was able to resolve my USB issue during live install.

I had noticed during all my googling some obscure references to USB issues and the nouveau driver during debian/ubuntu installations. There was never anything definitive and no real solutions offered other than recompiling the kernel with newer/different versions of xorg or nouveau.

I also noticed in the dmesg logs that @t.lamprecht showed me how to capture (above) that immediately before the USB failure that nouveau was switching to frame buffer mode followed by a USB redetect. I thought maybe there was a potential conflict with frame buffer mode and sought how to disable it.

Putting this in the kernel start parms (press 'e' on the grub installation option - make edit - F10) resolved the issue and allowed me to complete the installation:

nouveau.modeset=0

Good Luck!

 

[t.lamprecht]

FWIW and posterity I was able to resolve my USB issue during live install.

Great work and many thanks for sharing your solution!

Putting this in the kernel start parms (press 'e' on the grub installation option - make edit - F10) resolved the issue and allowed me to complete the installation:

nouveau.modeset=0

Yuck. I mean the re-detection triggered by the modeset causing issues sounds like a sensible theory now, but I wouldn't have thought that such a line would make the difference between keyboard working or not..