I installed qubesos today on my asus z890p with intel core 7 265.
When i start qubes i cant enter anything after decrypting my luks drive with my mice and keyboard.
I have in journalctl an entry that states: “vm.sys-usb: start failed: requested operation is not valid: pci device 0000:80:14:0 is not assignable”…
Below that entry is anotherone from virtxend: “internal error: failed to find parent device for 0000:80:14.0”.
According to lspci this is a “usb controller: intel corportation device 7f4c”.
On 80:40.5 is also a “non-vga unclassified device: intel corporation device”.
I already tried both usb 2.0 and usb 3.0 for the Keyboard and a second keyboard.
I currently have sys-usb disabled, but is it possible to fix this so that i can reenable sys-usb?
Setting the sys-usb kernel in sys-usb setting → advanced to the latest 6.15.x. Then enabling it again. Rebooting and selecting the latest kernel from grub menu.
With 6.15.10-1 on the host and in sys usb i get the same errors as before.
This are the logs from journalctl when sys-usb is autostarting:
Aug 23 21:10:48 dom0 systemd[1]: Started lightdm.service - Light Display Manager.
Aug 23 21:10:48 dom0 systemd[1]: Received SIGRTMIN+21 from PID 757 (plymouthd).
Aug 23 21:10:48 dom0 qubesd[4592]: INFO: vm.sys-net: Starting qube sys-net
Aug 23 21:10:48 dom0 crond[6694]: (CRON) INFO (running with inotify support)
Aug 23 21:10:48 dom0 crond[6694]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 71% if used.)
Aug 23 21:10:48 dom0 crond[6694]: (CRON) INFO (Syslog will be used instead of sendmail.)
Aug 23 21:10:48 dom0 crond[6694]: (CRON) STARTUP (1.7.2)
Aug 23 21:10:48 dom0 systemd[1]: Starting plymouth-quit-wait.service - Hold until boot process finishes up...
Aug 23 21:10:48 dom0 systemd[1]: Starting lightdm.service - Light Display Manager...
Aug 23 21:10:48 dom0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=crond comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Aug 23 21:10:48 dom0 systemd[1]: Started crond.service - Command Scheduler.
Aug 23 21:10:48 dom0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-user-sessions comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Aug 23 21:10:48 dom0 systemd[1]: Finished systemd-user-sessions.service - Permit User Sessions.
Aug 23 21:10:48 dom0 systemd[1]: Starting systemd-user-sessions.service - Permit User Sessions...
Aug 23 21:10:48 dom0 systemd[1]: Starting qubes-vm@sys-whonix.service - Start Qubes VM sys-whonix...
Aug 23 21:10:48 dom0 systemd[1]: Starting qubes-vm@sys-net.service - Start Qubes VM sys-net...
Aug 23 21:10:48 dom0 systemd[1]: Starting qubes-vm@sys-firewall.service - Start Qubes VM sys-firewall...
Aug 23 21:10:48 dom0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-vm@sys-usb comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Aug 23 21:10:48 dom0 systemd[1]: Failed to start qubes-vm@sys-usb.service - Start Qubes VM sys-usb.
Aug 23 21:10:48 dom0 systemd[1]: qubes-vm@sys-usb.service: Failed with result 'exit-code'.
Aug 23 21:10:48 dom0 systemd[1]: qubes-vm@sys-usb.service: Main process exited, code=exited, status=1/FAILURE
Aug 23 21:10:48 dom0 qvm-start[5302]: Error: Start failed: Requested operation is not valid: PCI device 0000:80:14.0 is not assignable, see /var/log/libvirt/libxl/libxl-driver.log for details
Aug 23 21:10:47 dom0 systemd-homed[4460]: block device /sys/devices/virtual/block/dm-51 has been removed.
Aug 23 21:10:47 dom0 systemd-homed[4460]: block device /sys/devices/virtual/block/dm-51 has been removed.
Aug 23 21:10:47 dom0 systemd-homed[4460]: block device /sys/devices/virtual/block/dm-53 has been removed.
Aug 23 21:10:47 dom0 systemd-homed[4460]: block device /sys/devices/virtual/block/dm-53 has been removed.
Aug 23 21:10:47 dom0 systemd-homed[4460]: block device /sys/devices/virtual/block/dm-52 has been removed.
Aug 23 21:10:47 dom0 systemd-homed[4460]: block device /sys/devices/virtual/block/dm-52 has been removed.
Aug 23 21:10:47 dom0 virtxend[4722]: internal error: Failed to find parent device for 0000:80:14.0
Aug 23 21:10:47 dom0 qubesd[4592]: ERROR: vm.sys-usb: Start failed: Requested operation is not valid: PCI device 0000:80:14.0 is not assignable
Aug 23 21:10:47 dom0 virtxend[4722]: hostname: dom0
Aug 23 21:10:47 dom0 virtxend[4722]: libvirt version: 10.5.0, package: 2.fc41 (Unknown, 2024-10-22-03:56:24, )
Aug 23 21:10:47 dom0 dmeventd[2378]: Monitoring thin pool qubes_dom0-vm--pool-tpool.
Aug 23 21:10:47 dom0 dmeventd[2378]: No longer monitoring thin pool qubes_dom0-vm--pool-tpool.
Aug 23 21:10:47 dom0 dmeventd[2378]: Monitoring thin pool qubes_dom0-vm--pool-tpool.
Aug 23 21:10:47 dom0 dmeventd[2378]: No longer monitoring thin pool qubes_dom0-vm--pool-tpool.
Aug 23 21:10:47 dom0 kernel: Already setup the GSI :16
Aug 23 21:10:47 dom0 kernel: xen: registering gsi 16 triggering 0 polarity 1
Aug 23 21:10:47 dom0 kernel: pciback 0000:80:14.0: xen_pciback: seizing device
Aug 23 21:10:47 dom0 kernel: xhci_hcd 0000:80:14.0: USB bus 1 deregistered
The content of /var/log/libvirt/libxl/libxl-driver.log is:
2025-08-23 12:03:14.880+0000: libxl: libxl_event.c:855:libxl__ev_xswatch_deregister: remove watch for path @releaseDomain: Bad file descriptor
2025-08-23 12:49:13.902+0000: libxl: libxl_event.c:855:libxl__ev_xswatch_deregister: remove watch for path @releaseDomain: Bad file descriptor
2025-08-23 13:29:28.521+0000: libxl: libxl_domain.c:885:pvcontrol_cb: guest didn't acknowledge control request: -9
2025-08-23 13:43:01.739+0000: libxl: libxl_event.c:855:libxl__ev_xswatch_deregister: remove watch for path @releaseDomain: Bad file descriptor
2025-08-23 16:05:18.331+0000: libxl: libxl_event.c:855:libxl__ev_xswatch_deregister: remove watch for path @releaseDomain: Bad file descriptor
2025-08-23 18:42:29.843+0000: libxl: libxl_event.c:855:libxl__ev_xswatch_deregister: remove watch for path @releaseDomain: Bad file descriptor
2025-08-23 18:48:15.262+0000: libxl: libxl_event.c:855:libxl__ev_xswatch_deregister: remove watch for path @releaseDomain: Bad file descriptor
2025-08-23 18:52:27.755+0000: libxl: libxl_event.c:855:libxl__ev_xswatch_deregister: remove watch for path @releaseDomain: Bad file descriptor
2025-08-23 19:09:11.372+0000: libxl: libxl_event.c:855:libxl__ev_xswatch_deregister: remove watch for path @releaseDomain: Bad file descriptor
Additionally i found this in the log that says the usbs are not authorized:
Aug 23 23:19:09 dom0 kernel: usb 1-6: authorized to connect
Aug 23 23:19:09 dom0 kernel: hid-generic XXXXXXXX: input,hiddev96,hidraw1: USB HID v1.10 Device [Logitech USB Keyboard] on usb-0000:80:14.0-6/input1
Aug 23 23:19:09 dom0 kernel: input: Logitech USB Keyboard System Control as /devices/pci0000:80/0000:80:14.0/usb1/1-6/1-6:1.1/XXXXXXXX/input/input6
Aug 23 23:19:09 dom0 kernel: usb 1-11: new high-speed USB device number 6 using xhci_hcd
Aug 23 23:19:09 dom0 kernel: input: Logitech USB Keyboard Consumer Control as /devices/pci0000:80/0000:80:14.0/usb1/1-6/1-6:1.1/0XXXXXXXX/input/input5
Aug 23 23:19:09 dom0 kernel: hid-generic XXXXXXXX input,hidraw0: USB HID v1.10 Keyboard [Logitech USB Keyboard] on usb-0000:80:14.0-6/input0
Aug 23 23:19:09 dom0 kernel: usb 1-4.3: Device is not authorized for usage
Aug 23 23:19:09 dom0 kernel: usb 1-4.3: Manufacturer: Logitech
Aug 23 23:19:09 dom0 kernel: usb 1-4.3: Product: USB Optical Mouse
Aug 23 23:19:09 dom0 kernel: usb 1-4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Aug 23 23:19:09 dom0 kernel: usb 1-4.3: New USB device found, idVendor=046d, idProduct=XXXXXXXX, bcdDevice=XXXXXXXX
Aug 23 23:19:09 dom0 kernel: usb 1-4.3: new low-speed USB device number 5 using xhci_hcd
Aug 23 23:19:09 dom0 kernel: input: Logitech USB Keyboard as /devices/pci0000:80/0000:80:14.0/usb1/1-6/1-6:1.0/XXXXXXXX/input/input4
Aug 23 23:19:09 dom0 kernel: usb 1-6: Device is not authorized for usage
Aug 23 23:19:09 dom0 kernel: usb 1-6: Manufacturer: Logitech
Aug 23 23:19:09 dom0 kernel: usb 1-6: Product: USB Keyboard
Aug 23 23:19:09 dom0 kernel: usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Aug 23 23:19:09 dom0 kernel: usb 1-6: New USB device found, idVendor=046d, idProduct=XXXXXXXX, bcdDevice=XXXXXXXX
Aug 23 23:19:09 dom0 kernel: i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
Aug 23 23:19:09 dom0 kernel: fbcon: Deferring console take-over
Aug 23 23:19:09 dom0 kernel: fbcon: i915drmfb (fb0) is primary device
Aug 23 23:19:09 dom0 kernel: usb 1-6: new low-speed USB device number 4 using xhci_hcd
Aug 23 23:19:09 dom0 kernel: i915 0000:00:02.0: [drm] GT1: HuC: authenticated for all workloads
Aug 23 23:19:09 dom0 usbguard-daemon[576]: Ignoring unknown UEvent action: sysfs_devpath=/devices/pci0000:80/0000:80:14.0/usb1/1-4 action=change
Aug 23 23:19:09 dom0 kernel: usb 1-4: authorized to connect
Aug 23 23:19:09 dom0 kernel: hub 1-4:1.0: 4 ports detected
Aug 23 23:19:09 dom0 kernel: hub 1-4:1.0: USB hub found
Aug 23 23:19:09 dom0 kernel: usb 1-4: Device is not authorized for usage
Aug 23 23:19:09 dom0 kernel: usb 1-4: Product: USB2.0 Hub
Aug 23 23:19:09 dom0 kernel: usb 1-4: New USB device strings: Mfr=0, Product=1, SerialNumber=0
Aug 23 23:19:09 dom0 kernel: usb 1-4: New USB device found, idVendor=05e3, idProduct=XXXXXXXX, bcdDevice=XXXXXXXX
I’m using an MSI Z890 Tomahawk and have the same compatibility issue. If you want to get it up and running, you have to disable sys-usb functionality during the install, which also means it won’t be functional after the install. I left the bios stock except secure boot is disabled.
You could also use the install from your previous hardware but sys-usb functionality will still be an issue and will need to be disabled during boot.
Also I think you’ll have to install using the latest kernel. I was not able to finish the install without it.
I trace back my problem in my Lenovo ThinkPad P16 Gen 3 laptop to yours.
I can install R4.3.0rc2 with kernel-latest (6.15.11).
The sys-usb launch fails as yours. If I install without sys-usb then I create a sys-usb, the result is the same.
My USB controller is a different device (pci 80:14.0), an Intel Corporation Device 7f6e (rev 10) with also a 80:14.5 Non-VGA unclassified device (7f2f Rev 10)).
Some more information: sys-net is working with the PCI passthrough of the Ethernet device (as normal).
Maybe it is a problem where the usb controller is combined with other unrecognised devices - I believe it is normally true when multiple PCI items are the same except for after the dot.
Maybe it is useful to open “Settings” for sys-usb, go to Devices, and activate “No strict reset”. Then try to start sys-usb. Maybe it is even necessary to restart the computer, if the devices got “confused”.
It may be a possibility yes.
The other possibility is about the ability for Qubes to find the parent device. My CPU is a Core Ultra 9 275HX so the same generation as the OP. Maybe the associated components use a different way to identify the parents that usually.
I do have the exact same problem since I got a new PC last year.
I tried out a lot, but nothing has worked. In the end, I bought a PCIe USB controller.
Then I bound the PCIe USB controller to sys-usb, and the internal controllers to a sys-usb-dummy vm, which fails to start but keeps the controllers away from dom0.
I think this does not give any protection… if the dummy does not start, then the device remains in Dom0.
You would normally need the rd.qubes.hide_all_usb command line option for Dom0 ( or a specific option to hide a single PCI device.)
cat /proc/cmdline will show what command line options are set on the kernel.
The command lspci -k will show that the PCI device is bound to the inert “pciback” driver, which ensures that the device is not touched by Dom0, except if we tell it to.
It is also possible - I think - to use USBguard to block all use of the USB devices, but this does not prevent the Dom0 kernel from talking to the controller and looking at the identities of the devices on the USB bus. It is better for Dom0 to never even “see” them. so Qubes-OS hides them at the PCI level.
Well, actually, after starting the sys-usb-dummy vm, I no longer see the devices connected to my internal USB controller in dom0, even if it has failed. lspci -k then shows Kernel driver in use: pciback on my device 80:14.0, despite the failed start.
But you’re right, hiding the PCI device in cmdline is probably the better and safer solution, especially during system boot, although I’m not so sure if it may become tricky when the controller is part of an IOMMU group with other important controllers, such as a bridge or other critical components.
You are correct. It does not give no protection, but the protection does not start immediately on boot… I’m not sure how long the window of exposure would be. Maybe it is zero, but the possibility can be eliminated by binding to pciback from the beginning. rd.qubes.hide_all_usb should not cause any problem with other devices - certainly not PCI bridges &c. It should be the better way to keep the devices isolated. If this one USB controller is visible and active on Dom0 before the dummy vm fails to start, then it is probable that all of the other USB controllers are also, up until the launch of their different sys-usb qubes.
The problem with “hide_all” could come if a USB keyboard is necessary for boot… then we must allow some limited access for USB ↔ Dom0. I think this is not your case.