Mouse and Keyboard Stuck After USB Qube

94 views
Skip to first unread message

jgmalh...@gmail.com

unread,
Jan 27, 2017, 9:24:38 AM1/27/17
to qubes-users
I just created a USB Qube, following the instructions from https://www.qubes-os.org/doc/usb/.
Immediately after booting the new qube, my mouse and keyboard stopped working.

After that, I waited for around 15 min, and nothing changed. So I powerd off my pc by pressing the button in the CPU.

When I turned it on again, my mouse and keyboard kept stuck in the page to input the password. The keyboard worked during the GRUB fase.

I'm pretty sure that I only need to give the USB's control back to dom0, but I have no ideia how to do that now that I can't even log in.

Has any one experienced similar problems? Do you know how I could solve that?

PS: Sorry for the grammar errors. I'm using my phone right now

Andrew David Wong

unread,
Jan 27, 2017, 10:39:19 PM1/27/17
to jgmalh...@gmail.com, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
It sounds like you have a USB keyboard and a USB mouse (at least
internally, if not externally). When you created a USB qube, you
removed your (probably sole) USB controller from dom0 and instead
delegated it to your USB qube. So, now your keyboard and mouse only
work inside that USB qube.

I haven't experienced this issue firsthand on Qubes, but from what I
understand:

If you unplug your USB mouse and plug it back in again, you should be
prompted to enable the mouse input proxy (unless you were already
prompted earlier and declined).

Keyboard input is more difficult, since plugging in a USB keyboard
doesn't automatically prompt you to enable the keyboard proxy (last I
heard, anyway). If you can temporarily attach a PS/2 keyboard, for
example, the solution is to either disable the USB qube (which you can
actually do with just the mouse), then to unhide the USB controller
from dom0 (which requires the keyboard), or, alternatively, to enable
the keyboard input proxy in dom0.

You should be aware that enabling the keyboard input proxy in dom0
(and, to a lesser extent, the mouse input proxy) can be very
dangerous, since it gives your USB qube great power -- potentially
control of the entire system.

Perhaps someone who has dealt with these issues on Qubes 3.2 will be
able to speak from experience.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYjBJYAAoJENtN07w5UDAw9okP/jJondLQnQIkwGxFN20ZhL+A
+2NUw/5AvlvsIZCkZyJ9IMPtqzupnLhADXTzjnRfbIQUAbU3Uj7cWynTTZIeqBuS
EmSIZ3C6caSpIJu8M5A8+e9QcLFhj1yetdY1aDS7eskWT4P0kyPsk7UENomF0xO/
rR2lJJO/+K/pGHUpeEa0MnWIOZdtH2lVMoclAfydnhLG/IKs6pyJSUDyhKh1vv2v
lVs73IWkLSYfViv/y4qZe7hezMSwuVMe7/ps/B3sKSEjNEb7YH2LAZkOisOTungQ
nBArmXo6o8d5PN2He4sxpGQdmupC2+wB78dMoefU1KYPCdbSPJ8aRoVWHBqxQ+qt
ZF4mPeRviVb1ihRmBsfNoWCAVsMHog9kXWrg3lwwBdA3EoYicYzCGwkKnXgzKnks
16G3XdUQV/CHUSwqGKytdB5dsCS+9lukNVC3AKe7R6tH5FpOPpjx5o4m+8vEFNWV
NMw/ZW+xMqlok7pzgZ3zdLnNYRfPlU/yyYqnGrVDg747nkPG0fACUsZA5hizbgRw
ZOU1k4yW9+9iV0meiN9la8lZLdNe23yh/3WXm9LO34PaYyBmWoZEENSa19wmgLqQ
WB/L9ZGdVi/f9we2jm6Z95BDsgL8em3UmEPSPu3KiUZpdgLP8IIU+mQqLnbFMkE8
nKSfHC+Rht2f1DChxI8m
=/NYh
-----END PGP SIGNATURE-----

jgmalh...@gmail.com

unread,
Jan 27, 2017, 11:00:35 PM1/27/17
to qubes-users
Thank you for the reply.

Yes, both my mouse and my keyboard are usb. Sorry for not saying it before.

I tried unplugging and plugging them in again, but i didn't work. I'm still stuck in the login screen.

I was wondering if there is any way to manually change how the dom0 handle usb (to disable proxies) through any recovery mode. It seems like the only way out, since I can't interact with the machine.

Mits Levojohn

unread,
Jan 28, 2017, 5:44:23 AM1/28/17
to qubes-users, jgmalh...@gmail.com
I had the same issue.

This helped me: https://github.com/QubesOS/qubes-issues/issues/2270

Basically, I modified the xen.cfg to remove the entry that hides the usb controller from dom0 - rd.qubes.hide_all_usb

raah...@gmail.com

unread,
Jan 28, 2017, 11:34:49 AM1/28/17
to qubes-users, jgmalh...@gmail.com

Like andrew said unplugging the mouse and plugging it back in will prompt you to allow it. Why your kb don't works I have no idea. Thats weird to me. maybe its a uefi thing? I use legacy boot mode. Also check in your bios, there is sometimes options for allowing or disasble usb to work before os boots. maybe that helps?

I use a usb to pci adapter for my keyboard on desktop with only one controller. I think most laptop kb's are already pci?

On another machine i have two controllers and use one on dom0 just for kb and mouse. the other controller i have on sys-usb for all other usb devices.

jgmalh...@gmail.com

unread,
Jan 28, 2017, 5:31:57 PM1/28/17
to qubes-users
I have no ideia how to modify xen.cfg, and wasn't able to find any documentation online. Could you explain how you did that? I tried editing it with a bootable debian usb that I had laying around, but it only appears as an empty file.

cez...@gmail.com

unread,
Jan 28, 2017, 7:20:20 PM1/28/17
to qubes-users, jgmalh...@gmail.com
Did you try to unplug/plug first? You're not telling us much, it is hard to help you without much information, a little extra will be insightful.

Also do you have a PS/2 port as Andrew mentioned? If you do, then the fix is really, really straight forward and easy to fix by grabbing an old or cheap to buy PS/2 mouse or keyboard. Been there, done that, it works.
Also it is possible to use just a PS/2 keyboard without a PS/2 mouse, but it takes a bit of keyboard navigation to reach the USB-Qubes settings to disable the "Auto-start at boot" function. A PS/2 mouse would make that easier, best with both PS/2 devices if you got a password on your login. Once that auto-start on your USB-Qube QVM has been disabled then just reboot, and you're back to normal.
In the event you are on a laptop, then this likely won't work, but it should work on most desktops with a PS/2 port, or really old laptops with PS/2 ports.

Also be mindful if your system has any extra USB controllers which might still reside in Dom0, you might be lucky. Most cheap systems just have a single USB controller though, but for example if you got 3.1 or even sometimes with 3.0, then it is likely you got an extra USB controller. If you didn't remove that possible extra controller from Dom0, then you should still be able to use your USB keyboard/mouse on those USB ports. Assuming, of course, you got an extra unassigned controller left in Dom0.

If none of that works, then your best hope is probably indeed changing the Xen.cfg boot file. You already got a live USB Debian, that will be helpful. Boot it up and go to your terminal. It is likely that your xen.cfg is on separate boot partition, in that case you need to make an empty folder on your temporary live boot and mount that partition to it (i.e. in /media or /mnt). It's usually on the smallest partition, typically 100MB to 700MB in size. Also in order to edit the xen.cfg file you will likely need to either chroot to directly access it or alternatively use 'sudo mv' command to physically move the xen.cfg file to somewhere you have write access, whichever is easier for you. If you used the move method (i.e. to your live boot at /liveboot/home/user/ then remember to move it back to its original location after you modified it. It is far easier to just move it than to learn how to use chroot if you haven't used that before. Basically in short, move file to where you got write access, modify it, and then move it back again, done. There are other ways to do this, but this is pretty simple and straight forward.

Furthermore if your xen.cfg file was empty, then this is likely because you didn't open it correctly and instead it created a new file, since if you didn't get the path right, then it will just make a new file with that name at whatever path you put in. That, or it was the wrong xen.cfg file, because it can't be empty, your system can't boot without it. So be sure to get the path right.
You can always use the "cd" command to navigate the folders one by one. And each time you reach a new folder/directory, use the "dir" command to see the content before cd'ing to the next directory. Once you find the xen.cfg, you can i.e. use "nano xen.cfg" to read it, but remember you can't edit it without write access. So at this point you either chroot, move it, or other means to gain write access.

As for what you need to put into the xen.cfg I am not sure about, it is most likely a single and simple short command. Someone else might be able to provide you with that answer.

The xen.cfg file is the boot file for Xen/Qubes, so be sure not to mess up any existing commands in the file, or forgetting to move it back to its exact original location. Without it Qubes won't boot at all, or not boot correctly. So modify/move the xen.cfg file carefully. It definitely won't hurt to make a backup copy before you edit it.

Others might know more than me about this, but if there indeed is a rd.qubes.hide_all_usb command in your xen.cfg file as Levojohn suggested, then the above should work if you clear that commmand from the xen.cfg file.
Reply all
Reply to author
Forward
0 new messages