It’s one of the devs asking for more information, actually trying to analyze/solve your problem… but I guess it’s true that empty vessels make the most noise.
4 Likes
corny
March 26, 2026, 10:44am
62
I checked this again and the slowness is gone
The slowness WAS in how long it takes from inserting the USB to the partitions showing up in notifications. During that time the widget was frozen.
No he wasn’t responding to me, he was responding to someone else. And he was criticizing that person’s response to my thread. Only OP gets to decide if a reply to OP’s post is apprepriate. Thus, he was out of line. And I called him on it. I think the horse has been beaten well enough to death now, don’t you?
Cool. If you experience it again, here are some related issues:
opened 08:51AM - 18 Apr 25 UTC
P: default
C: usb proxy
needs diagnosis
affects-4.2
affects-4.3
### Qubes OS release
Qubes OS 4.2
### Brief summary
Attaching USB device to q… ube makes some GUI components unresponsive. So far I've noticed that happening with the Qube manager as well as the USB devices tray icon.
This is quite annoying, as attaching USB devices (between the start and end of the process) can take even like 10 seconds on systems with a lot of USB devices attached.
### Steps to reproduce
1. Attach a USB device to a Qube
2. Try to do something in the Qube manager or in the qui-devices tray icon
3. They're frozen until the attach finishes
### Expected behavior
No freezing.
### Actual behavior
Freezing until the attach finishes.
### Additional information
Possibly related to: #9849
opened 09:43AM - 12 Jan 26 UTC
C: core
P: default
hardware support
needs diagnosis
affects-4.3
[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/)
###… Qubes OS release
r4.3
### Brief summary
Qubesd takes a really long time to query and manage USB devices with multiple USB hubs. This is quite annoying as qubesd uses 100% of one CPU core while doing that (in a blocking way), making it impossible to interact with Qubes GUI widgets or qubes-qube-manager (and other apps that rely on querying qubesd).
### Steps to reproduce
1. Connect multiple USB hubs to your computer. In my case it's 2 daisy-chained hubs (one plugged into the other) that are integrated into my displays.
2. Attach a USB device to a qube or query usb devices
### Expected behavior
Fast.
### Actual behavior
Slow and making almost all `dom0` Qubes GUI components unusable.
### Additional information
`time`d while not much else was happening on the system:
```
user@dom0 ~ % time qvm-usb attach personal sys-usb:2-1.1.1
qvm-usb attach personal sys-usb:2-1.1.1 0.11s user 0.04s system 0% cpu 30.660 total
user@dom0 ~ % time qvm-usb >/dev/null
qvm-usb > /dev/null 0.15s user 0.06s system 2% cpu 7.730 total
```
1 Like
did you found another way?
121212
April 19, 2026, 2:00am
67
Same here, reinstalled it twice and now it’s smooth for some reason
R4.3 did feel sluggish to me, especially soon after installing.
Somewhere along my configuration process the sluggishness decreased, but I have no idea why (maybe I got used to it).
Looking at objective data, my boot times are
4.8s for R4.3
4.6s for R4.2
6.1s for R4.1
4.7s for R4.0
R4.3 is par for the course (with R4.1 being the outlier)
However VM boot times do not tell the whole story, so there might be something going on.
Finally got around to installing R4.3 and updating the table for this release
I ran the test using @renehoj 's systemd-binfmt.service trick but it didn’t seem to reduce my boot times (and actually seemed to increase it a tiny bit). Overall R4.3 is slower than R4.2. but still significantly faster than R4.1.
The top post is a wiki post that can be edited by all, and Discourse has added a handy table-editing feature, so please feel free to add your results!
The methodology and data are in this thread. Feel free to add your boot times!
