It seems to be independent from the VM’s history: A newly created Windows 10 VM shows the same behavior, i.e. it does not see an attached USB stick.
Just to be sure, I’ll try this VM now on another R4.2.2 installation that I had created from scratch.
Was your current Qubes OS 4.2 installation upgraded in-place from Qubes OS 4.1?
No - it was a fresh install of R4.2.0 and updated from there.
The test of the newly created Windows 10 VM on a new installation of R4.2.2 also did not provide access to the USB device.
Currently, I am completely losing any faith in Qubes R4.2.x. It simply has still too many bugs, compared with R4.1.2, and should, in my opinion, still be regarded as in beta status. (After the last updates, the updater only works after sys-net has been restarted, a bug that’s been mentioned earlier already. That’s just one of the annoying things.)
Which Windows 10 image did you use to install? What’s its sha256sum?
I can try to install fresh WIndows qube using the same image.
Also, can someone else confirm whether USB attachment in WIndos 10 qube without QWT works for them or not?
The image is Win10_22H2_German_x64.iso, dated September 08, 2022, with checksum A676A5E18036C49502D1F490FCA8EF69B3BBDBAB91800106ADB37A81B09C3DEE and installed as Windows 10 Pro
By the way, I copied the VM to Qubes R4.1.2, and there it does not have access to the USB drive, too. Installing QWT 4.1.68 with the Xen PV disk driver provides this access.
I can’t find the image with this checksum.
I’ve found the German Windows 10, version 22H2 [19045.2006] (Updated September 2022) image info but its checksum should be:
SHA-256: fd054604370c19149ccef7cdddbb3009d5f65a59f8071e52e46ed3f98f05aa56
Maybe your image is corrupted?
Can you download the latest Windows 10 image and try to install it?
Just to make sure, you didn’t forget to set qvm-features qubename stubdom-qrexec 1?
[user@dom0 ~]$ qvm-features win11 stubdom-qrexec
1
USB drive reports to be attached, but not present anywhere in Win qube.
In a Win qube where QWT without Xen PV disk drivers installed, USB attaching works.
Both, of course, under v4.2.2.
Xen PV Storage Host Adapter ’ Driver version: 9.1.0.3
This device cannot start. (Code 10)
{Operation Failed}
The requested operation was unsuccessful.
It lооks like you’re lucky. I’d like to see screenshots of your computer working all the things that don’t work for anyone else…
I’m not sure why it works for me but not for you.
Maybe you have some custom changes in dom0?
Did you patch stubdom or some other files in dom0?
My ISO tells the same version number [19045.2006]. I downloaded it from https://www.computerbild.de/download/Windows-10-als-ISO-Datei-13722475.html.
I didn’t go to files.rg-adguard.net, because my Firefox flags this as a malware site.
Anyhow, I don’t think that this is version-dependent, as the other tests, using Windows 7, and Windows 10 version [19045.3636] had the same results. Just Windows 11 is still worse, as it does not allow attaching the USB drive via the Qube Manager but only via CLI, and the drive is not seen in the VM.
In any case, I checked stubdom-qrexec, and it was set.
I wouldn’t trust this image. It’s clearly not an official MSDN image as it has wrong hash so it could contain malware inside.
You can download the WIndows image directly from microsoft.com like this:
Download a Windows 10 ISO directly from Microsoft (without the media creation tool) · GitHub
And later confirm (to some extent) that this image is valid by checking the cryptographic hash of the downloaded image and searching it using any search engine.
For example, if you search for the “fd054604370c19149ccef7cdddbb3009d5f65a59f8071e52e46ed3f98f05aa56” string in the search engine then you’ll get many links to the github/forums/etc with the lists of the official MSDN images hash e.g.:
https://www.reddit.com/r/MSCDB/comments/y7eq7h/windows_iso_updated_october_2022/?rdt=60118
fd054604370c19149ccef7cdddbb3009d5f65a59f8071e52e46ed3f98f05aa56 de-de_windows_10_consumer_editions_version_22h2_x64_dvd_ac60ae62.iso
I’d still try to install the official MSDN Windows image for a test. I don’t know what else could be different if you’ve tried it in the new Qubes OS 4.2 installation without any custom patched files in dom0.
I think this is wrong path to follow. If things work under some terms, and under the other it doesn’t work, then it’s about the terms. Here, it’s all about Qubes 4.2, since everything worked under 4.1.
As @fsflover said on the other topic
So, we saw no one but you your tips to work. The OP is still waiting another user to reproduce it, so it could be confirmed.
My setup:
Qubes OS 4.2 with latest current-testing dom0 updates and without any patched files (stubdom-rootfs/etc).
Windows 10 installed in a HVM qube with 4GiB memory and 4 VCPUs using the latest official MSDN WIndows 10 English image:
$ sha256sum en-us_windows_10_consumer_editions_version_22h2_updated_july_2024_x64_dvd_3245b006.iso
2eda4701d3e4061eccfdf0ad264b69392e67e2a29fef9eb7d7a57150b08e87e0 en-us_windows_10_consumer_editions_version_22h2_updated_july_2024_x64_dvd_3245b006.iso
Windows 10 with latest updates installed and without any custom system config modifications or software installed.
I disagree, because it works for me in Qubes OS 4.2 so I don’t see how this is Qubes OS 4.1 vs Qubes OS 4.2 issue.
Maybe there are some more issues that appeared in Qubes OS 4.2 that are not present in Qubes OS 4.1 but not the ones that we are talking about.
We can wait for more people to come and check it in their Qubes OS 4.2 then before trying to trace the issue further.
You’re right: The Windows 10 VM copied back to R4.1.2 shows the same behavior there as under R4.2.2: It has access to the USB drive if and only if QWT with the Xen PV disk driver is installed.
Maybe there is some issue with xen-hvm-stubdom-linux-full package in dom0.
What’s the output of these commands in dom0?
dnf list installed | grep xen-hvm-stubdom-linux-full
# check package files integrity
rpm -V xen-hvm-stubdom-linux-full
UPD:
On second thought if the USB integration without QWT works for other Windows qubes in R4.1.2 then it’s not the case.
Attaching block devices, which is the part of this topic’s subject, worked for me under 4.1, as well as attaching USB devices, when qwt were installed. Now it doesn’t work and this is workaround for that, so from my perspective it’s all about Qubes. Win qubes backed up under 4.1 don’t work under 4.2 and newly created win qubes will not work with Xen PV storage drivers, unless the way from OP.
Also, and the most important thing; there is no other way then from the OP to attach internal drives to a win qube, because it’s impossible for me to install Xen PV drivers v9.x. Did anyone except @apparatus ever succeeded to install them to be fully functional?
Here’s the output. Seems o.k. to me.
[Weck@dom0 ~]$ dnf list installed | grep xen-hvm-stubdom-linux-full
xen-hvm-stubdom-linux-full.x86_64 4.2.13-1.fc37 @qubes-dom0-cached
[Weck@dom0 ~]$ rpm -V xen-hvm-stubdom-linux-full
[Weck@dom0 ~]$
At least for the Windows Qubes restored from R4.2.2: This one had access to the USB drive only if running QWT with the Xen PV disk driver.
I now downloaded the official 22H2 image from the Microsoft website. It is larger now, dated March 05, 2023, and has the checksum D1A41A09E9AE09631A087EDF95D7F4EECAB622F88B3C824D856CFEA47FCC0B4C, which is what should be expected according the the website. (But who guarantees me that I am talking to the real website, and not a fake one?) So everything is different again - the usual mess with M$.
I’ll test this kit, too.
Yes, it’s good.
You can also check the Windows qube stubdom log to see if there are any errors when you attach USB device to it:
/var/log/xen/console/guest-QUBENAME-dm.log
The log does not show any errors, but I also did not find any items concerning the attachment of the USB drive.
In the meantime, I checked now with the “official”, SHA-256-correct version of the Windows installation ISO, and it behaves identically.
That’s strange. I have this log on USB attach:
[2024-08-17 22:11:27] 2024-08-17 22:11:27.189 qrexec-agent[498]: qrexec-agent-data.c:244:handle_new_process_common: executed: root:QUBESRPC qubes.USBAttach dom0 (pid 501)
[2024-08-17 22:11:27] vhci_hcd vhci_hcd.0: pdev(0) rhport(0) sockfd(0)
[2024-08-17 22:11:27] vhci_hcd vhci_hcd.0: devid(262215) speed(3) speed_str(high-speed)
[2024-08-17 22:11:27] vhci_hcd vhci_hcd.0: Device attached
[2024-08-17 22:11:28] usb 1-1: new high-speed USB device number 2 using vhci_hcd
[2024-08-17 22:11:28] usb 1-1: SetAddress Request (2) to port 0
[2024-08-17 22:11:28] 2024-08-17 22:11:28.179 qrexec-agent[498]: qrexec-agent-data.c:272:handle_new_process_common: pid 501 exited with 0
[2024-08-17 22:11:28] {"return": {}}
Can you post your guest-QUBENAME-dm.log?
I have this log without stubdom-qrexec 1:
[2024-08-17 11:32:20] + usb_args=
[2024-08-17 11:32:20] + test -e /bin/qrexec-agent
[2024-08-17 11:32:20] + sed -n /^-qubes-audio:/p
[2024-08-17 11:32:20] + echo '-xen-domid
And this log with stubdom-qrexec 1:
[2024-08-17 13:27:03] + usb_args=
[2024-08-17 13:27:03] + test -e /bin/qrexec-agent
[2024-08-17 13:27:03] + usb_args='-device
[2024-08-17 13:27:03] nec-usb-xhci,id=xhci'
[2024-08-17 13:27:03] + mkdir -p /var/run/qubes
[2024-08-17 13:27:03] + touch /dev/mdev.log
[2024-08-17 13:27:03] + mdev -d
[2024-08-17 13:27:03] + USER=root qrexec-agent
[2024-08-17 13:27:03] + sed -n /^-qubes-audio:/p
[2024-08-17 13:27:03] + echo '-xen-domid
And check the xen-hvm-stubdom-linux package integrity:
dnf list installed | grep xen-hvm-stubdom-linux
rpm -V xen-hvm-stubdom-linux