[qubes-users] USB controllers

Hello all,

After standard installation using a PS2 keyboard, I should have two separate usb controllers in the same sys-usb qube. I would prefer to have two distinct sys-usb so using one more secure for the mouse (PS2 mouse does not work) that should be somehow connected to dom0 and the other less secure for external USB disks.

i carefully examined the Qubes papers

https://www.qubes-os.org/doc/usb-qubes/#enable-a-usb-keyboard-for-login
but I am still very confused.
Which is the proper way to do that?
Best Franz

You can simply qvm-clone the existing sys-usb, and then fix up the
controller allocation between the two.
You can also set autostart with qvm-prefs for the "less secure" so that
it is not started by default. This will mean that you have to
consciously start that usb qube if you want to use external devices.
You might also consider using udev rules, or blacklisting modules in the
"mouse" usb, so that it cannot be used with other USB devices.

The idea to clone sys-usb is brilliant and seems easy, Unman. I will try to do that. Many thanks

So, I did the cloning, but without a mouse I am unable to detach the relevant US usb controller from the second sys-usb, using Qubes Manager because the keyboard seems unable to move it from Selected to Available.

So followed the CLI instructions https://www.qubes-os.org/doc/pci-devices/
qvm-pci gives the address of the usbcontroller to be detached dom0:00_.14.5 and tells the following:
sys-2usb (no-strict-rest=True), sys-usb (no-strict-reset=true)

Because the linked Qubes instructions apparently only teach how to attach, but not how to detach, I tried the following:
qvm-pci attach sys-usb dom0:00_14.5
but it replies: device dom0:00_14.5 of class pci already attached to sys-usb
and nothing is done.

So, I do not know how to go on. I would need a command to detach dom0:00_14.5 from sys-2usb without attaching it elsewhere.

Best.

– You received this message because you are subscribed to the Google Groups “qubes-users” group. To unsubscribe from this group and stop receiving emails from it, send an email to . To view this discussion on the web visit .

Many thanks it worked perfectly

take a look to the qvm-pci man page, it explains how to detach.

Many thanks it worked perfectly

It worked perfectly for a week or so, then the mouse stopped working. Thomas at Vikings, who built the D8 computer with preinstalled coreboot, says it should be a Qubes issue.

How may I tell if it is a Qubes issue or a hardware issue?
best

You aren't clear on what is happened here, because you haven't provided
sufficient detail..
Do you mean that you allocated a USB controller to a sys-usb, to use
with the mouse. After a week, the mouse stopped working.
When both controllers were attached to a single usb-qube the mouse
worked without interruption.
Is that the position?

Did the other USB qube continue to work?
If you type lsusb in the "mouse"-usb do you see the mouse attached?
If you attach another usb device, does lsusb and dmesg show the device
being attached?
If you attach the mouse to the *other* usb qube, does it appear there?
If you revert to a single usb qube, does the mouse work for more than a
week there?
If you move the mouse to the other controller, does the mouse work for
more than a week?

Let's think about this.
Many Qubes users will be using coreboot.
Many Qubes users will be using more than one usb qube.
Many Qubes users use a usb mouse for more than one week without
incident.
What is different about you? Coreboot, Your hardware.
I am not saying that your hardware is at fault - it's just that the most
likely source is *your configuration and hardware in Qubes*.

Of course, if Vikings can point to other users with your hardware and
coreboot build who use Qubes without a problem, that would help too.

I would prepare another usb mouse, that can work with the other usb
qube. Use your mouse-usb qube until it "breaks". Plug the mouse in to
the other usb qube, and start looking at the "broken" usb qube.
Look in logs, for any events that might be associated with the loss of
mouse. Remove and reinsert the broken mouse to see how it is handled.
Remove and reinsert other usb devices to see how they are handled.
journalctl, dmesg are your friends, as well as basic troubleshooting.
(Another mouse, use the other controller, etc)

1 Like

take a look to the qvm-pci man page, it explains how to detach.

Many thanks it worked perfectly

It worked perfectly for a week or so, then the mouse stopped working.
Thomas at Vikings, who built the D8 computer with preinstalled coreboot,
says it should be a Qubes issue.

How may I tell if it is a Qubes issue or a hardware issue?
best

You aren’t clear on what is happened here, because you haven’t provided
sufficient detail…
Do you mean that you allocated a USB controller to a sys-usb, to use
with the mouse. After a week, the mouse stopped working.
When both controllers were attached to a single usb-qube the mouse
worked without interruption.
Is that the position?

Yes, but it worked also when only one USB controller was allocated to the mouse qube.

Did the other USB qube continue to work?

yes it works, I am able to mount an external USB drive. Also lsusb works and shows the external USB drive

If you type lsusb in the “mouse”-usb do you see the mouse attached?

No, lsusb hangs, with no output
.

If you attach another usb device, does lsusb and dmesg show the device
being attached?

dmesg on mouse qube gives a lot of errors, even various red ones. But I am totally unable to understand if they are serious or related to the mouse issue.

If you attach the mouse to the other usb qube, does it appear there?

yes lsusb shows it there.

If you revert to a single usb qube, does the mouse work for more than a
week there?

I have not tried it yet, but I no longer have the original single USB qube, so I should reinstall Qubes from zero.

If you move the mouse to the other controller, does the mouse work for
more than a week?

I have not tried it yet, because I wanted to keep it separated. The controller allocated to the mouse qube is on the motherboard and administered by coreboot, but the controller allocated on the USB-key qube is on a PCI card and I know nothing about it. But I am quite sure it would work because lsusb works, mouse is recognized and disks are mounted.

Let’s think about this.
Many Qubes users will be using coreboot.
Many Qubes users will be using more than one usb qube.
Many Qubes users use a usb mouse for more than one week without
incident.
What is different about you? Coreboot, Your hardware.
I am not saying that your hardware is at fault - it’s just that the most
likely source is your configuration and hardware in Qubes.

Of course, if Vikings can point to other users with your hardware and
coreboot build who use Qubes without a problem, that would help too.

I asked but Thomas suggested asking the Qubes ML.

I would prepare another usb mouse, that can work with the other usb
qube. Use your mouse-usb qube until it “breaks”. Plug the mouse in to
the other usb qube, and start looking at the “broken” usb qube.
Look in logs, for any events that might be associated with the loss of
mouse. Remove and reinsert the broken mouse to see how it is handled.
Remove and reinsert other usb devices to see how they are handled.
journalctl, dmesg are your friends, as well as basic troubleshooting.
(Another mouse, use the other controller, etc)

I understand what you mean. Your suggestions are all well thought, very sound and give some hope. The weak point is my capacity to make use of the error messages of dmesg and journalctl.

Really I am a bit depressed about it. I spent $5000 on that computer ($2500 for the computer and 2500 for importation tax to South America) and also for some reason it is unable to reboot and also the fans go full speed all the time because coreboot is unable to administer it. It makes a terrible noise. Well years ago Taiidan on this ML said there is a way to administer the fans of D8 by buying some additional equipment, but nobody really knows what to buy and how to make it work.

So even basic things like mouse, reboot and noise are super complicated and time consuming. I wonder how it is that on the Qubes HCL this computer is marked as fully working.

But Unman really many thanks. Your effort to help and your brilliant expertise are obvious. At least now there is some hope. Before your intervention I was already contemplating using the computer as a $5000 bedside table, at least it has a nice black mirror door that can accomodate a book to read before sleeping.

Very sorry to hear of your problems.
Equally happy to help you (as far as I can) with resolving these issues,
so if you do want to keep working on this, let the list know how it
goes, and we will provide whatever help we can.