How do I determine if my keyboard and mouse pad are on a USB controller? How should this affect the configuration of sys-USB?
There are two USB controllers:
00:14:0 ...Intel Wildcat Point-LP USB xHCL Controller
00:1d:0 ...Intel Wildcat Point-LP USB EHCL Controller
After installation, sys-net did not work. The USB controller was assigned to it rather than the nic. That is fixed.
This may be an installation issue. Is there a wrong way to install that may result in this behaviour? If so, how can I install again and not make the same mistake?
Thank you
Thank you, that was a lot of info. This took me to here:
https://www.qubes-os.org/doc/usb-qubes/
From which as root, I executed:
qubesctl state.sls qvm.sys-usb
4 succeeded and 1 failed.
In sequence:
ID: hide-usb-from-dom0-legacy
Function: file.append
Name: /etc/default/grub
... This one succeeded
ID: grub2-mkconfig -o /boot/grub2/grub.cfg
Function: cmd.run
Result: True
Comment: State was not run because none of the onchanges reqs changed
Changes:
... This one succeeded
ID: sys-net-usb
Function: qvm.prefs
Name: sys-net
Result: False
Comment: The following requisition were not found:
require:
sls: qvm.sys-net
Changes:
... This one failed
Then there were two other successes for:
ID: qubes-input-proxy
ID: sys-usb-input-proxy
That was the complete emission. I guess the failure signal was the 'Result: False" and all the text was in red.
I have checked the terms in the emission but was not able to find anything that looked relevant.
It is not clear why sys-net was addressed in the usb process. But I do recall that a usb controller was installed in the sys-net but no wifi. While I have read some about the possibility of using sys-net for usb functions, I don't recall any reference to the installation doing that.
Any suggestions?
After entering the above command for usb, the output addressed sys-net:
These are notes on the solution path used. rc2 was tried one day, rc3 the next.
r...@aarden.me:
> It has taken four years to get to here. I have tried this with Debian and
> Qube OS. I could not get Xen on Debian to work due to my wireless only
> networking of my laptop. With Qubes, it has been getting wireless and USB
> to both work. This time, wireless worked maybe.
>
> There is a sys-USB qube. This will be my next challenge. I want to be
> able to use a mouse and, as this is a laptop, and I would like to connect
> to my USB3 docking station and test out the functionality.
Mouse shouldn't be too hard, but some USB controllers don't like running
inside a qube. To see the log, you need to be in su mode in a dom0
session, so "sudo nano /var/log/libvirt/libxl/libxl-driver.log" should
work. Check it shortly after attempting to start sys-usb if it is
failing to start.
Thank you for the info.
The sys-usb showed up in the qube manager. Clicking start on the start/resart context menu initiated start up. An error window popped up pointing to the log file you indicate, libxl-driver.log. The log reported:
---
[Dom0] Settings: sys-usb
“PVH mode is recommended if possible (Linux kernel 4.11 or newer, no PCI passthrough). For Windows qubes always use HVM”
Virtualization
Mode: HVM
“PVH mode is hidden since it doesn’t support PCI passthrough.”
---
I changed the setting to PV (the only choice). A note opened stating “Using PV mode exposes ore hypervisor attack surface.”
I selected start from the qube manager sys-usb item. A note popped up stating it started, then the same error message was reported.
Note:
I previously selected both USB controllers in sys-usb Devices.
On removing the erroring controller (14.0): Resulted in the same error.
On removing the other controller (no controllers selected): Resulted in “Resource temporarily unavailable”.
On adding the alternate controller:
Next:
From: https://groups.google.com/forum/#!topic/qubes-users/wdfpne96xhI
To be sure I went into Qube Manager, sys-usb->Qubes Setting->Devices and used the "Configure strict reset for PCI devices" button to set it on 00:14.0.
I opened sys-usb settings and found the controller listed in the settings pane (on the right). The control button/bar at the bottom entitled "Configure strict reset for PCI devices". I clicked on the controller in the ‘selected’ window, then clicked the strict reset button. The controller was then highlighted. After applying the changes, I restarted sys-usb. It worked.
It was unclear that the controller did not already have the strict reset button ‘on’.
The newly built vm uses the usb mouse.
It is curious that the mouse is also active in dom0.
I am using a windows laptop to take notes and work the web including this session. While the mouse works on dom0 on the other machine and the vm, it does not work on the windows machine (probably because it is not plugged into it). I am excited to learn how to work in qubes – being able to jump from dom0 to vms, take notes, post messages, email smoothly.