Yes he has a point, and that is a good thing I do admit, but this forum is not very handy in many cases as I see a lot of “crap” that is spread all over the important information.
Many things I find aren’t even important or needed there as they have no baring on the issue that was being discussed in those posts. Which is kind of annoying and frustrating in many cases.
Well, I hope I’m not the only one, but then again I do have a more secure machine than generic Qubes. Most people just install Qubes and use it like that and think that it’s secure enough. I don’t.
Oh, but Domain-0 does do LESS with the drives.
Domain-0 does look and see the partitions, yes, but it doesn’t just keep sitting there looking and reading and looking and reading.
I have the drive sitting in Domain-0 and the light is static, nothing going on…
I attach it to a guest, and the light just keep flashing, drive keeps spinning, even when it is not mounted in the guest.
So it hasn’t even reached the point of mounting it yet. It should just be looking at it, seeing the partitions, and then showing that they can be mounted. That is what happens when I plug it into any other of my Unix based machines.
Yet in Domain-0 it does it correctly.
So, yes, Domain-0 does do less with the drive.
As I say here, 2 sentences later… I describe it in better detail.
The firmware is loaded from multiple locations.
Primarily /usr/lib/firmware though.
Well, I’m not moving anything that is attached to the CPU. It’s all on the motherboard. So it’s only MB hardware that’s being moved, the USBs that are attached to the South Bridge if memory serves.
When I attached both at once the screen did go black, the fans didn’t change speeds or anything.
My AMD firmware is still older as I don’t accept the bugs and things that aren’t needed.
How would I know if the firmware is the culprit?
It’s only a second generation CPU.
I described what I had to do in detail in a previous post. It’s not as simple as just “cold boot”…
That pillar doesn’t really tell me much.
I mean I can see that it tries to do things with guests that don’t exist.
and it looks at the USBs and PCI devices, yet it only looks at USB devices.
But I believe that it would still remove all the USBs from the system, including the card that I would have installed. Or even an extra USB HUB if I put in another cable to activate the other HUB.
Yes, comes from being in Data Recovery.
It’s hardware, not software.
But I can use software to do it.
So I plug directly on to the drive, not into the SATA. I use the terminal on the drive to download and scan the FLASH as well as the service area of the drive.
If it’s a USB drive, then I open up the case, and connect that way.
Would be good to know what these checks are.
If I have to get the AMD firmware and go through it and rewrite it, then I’ll have to do that.
Okay, so since they are both connected via the motherboard and controlled by the south bridge, attaching both to the guest can cause that one issue?
even thoguh they are completely different BUS’s?
There are no instructions in that guide though.
No-one actually reads these things.
Does not tell me how to manually create a USB hosting guest, which is what I was talking about.
It says how to do it automatically, which doesn’t allow me to do what I’m trying to do.
Which is why I asked for further details.
So, that guide actually has no instructions on how to create it manually.
It does show a methodology for how to get things going for those people that don’t know what they are doing and are basic end users.
So… Instructions… Something like this…
Note: If you are using a USB host guest you will require a PS/2 keyboard and mouse to maintain any semblance of security.
1: Create a guest to house the USBs and other insecure devices.
2: Make sure you have the ‘qubes-usb-proxy’ package up to date.
3: Open settings and go to devices.
4: Attach the root devices for the USB controllers that you want to add to the system.
(Remember to do them one at a time starting from the first root USB device)
(If you have any PCI cards for USB that are installed, these can also be passed through, but the strict reset may need to be enabled/disabled for these.)
5: Enable the proxy service in Domain-0 so that you can access the USB devices.
6: edit grub.cfg and in the module2 vmlinuz line.
Well, the SaltStack wouldn’t work. It has references and all to things that just don’t exist.
It would need a lot of editing to get it to work properly I would believe.
I am not sure if this will be useful, but the discussion about crashing when attaching USB controllers reminds me of something that happened installing QubesOS in a computer. That motherboard (ASUS, IIRC), has a special USB port for firmware upgrades. If that controller ever got passed to a VM, the computer would restart immediately on its own. All the other USB controllers could be passed to a VM with no problems. It took me a while to realize this was going on. So it can be certainly possible that a single USB controller causes issues when attaching it to sys-usb so it may be worth doing the passing one at a time (if you haven’t done it yet).
The funny thing about that port is that it is supposed to be able to be used as a regular USB port, and the BIOS has some special access to it to be able to read firmware update files so you can update it without loading the OS. But it seems there is something special in its wiring so it is not exactly a regular USB port in the end. Good luck finding your issue!
Normally the BIOS accesses it directly only when in the BIOS and running the update functionality or the backup/restore functions.
So it shouldn’t matter what it is once you are past the BIOS initialisation and into the operating system.
Literally should make no difference.
But the fact you had issues with that port specifically is very interesting.
Do you remember exactly what motherboard it was? Or maybe if it was a pre-built PC the model? Just curious, I know you said you thought it was ASUS, if you don’t remember more details it’s okay, just thought I’d ask in case you had remembered.
Interesting board. It really shouldn’t have an issue with the USB ports past the POST.
I find this very intriguing. Unless there is a bug in the BIOS that causes it to be misidentified or always accessing the BIOS port?
Might be a BIOS Update that fixes it?
It has a lot of different headers.
Would be interesting to see a DMI and HCL for it.
There are a lot of fixes for the BIOS since 1616 (16/05/2023).
They are up to 3208 as of 11/02/2025
And there are some issues with the 8000 series CPUs that they have fixed too.
If you would be able to send up an HCL and DMI that would be great.
If you don’t want to upload the DMI directly to here, you could DM it directly to me, just because I’m interested in why it would have issues with that like that.
If I had the money, I would upgrade to that board in a hertbeat, get a new CPU, RAM, Drives and more.
In the devices, are there all 4 connectors for USB? Or does it show less?
It does say you have 4 USB busses, but I’m wondering if one is a subset of another?
It looks like one could be a subset of another based on the 8 listings that are there.
But none actually are specified as a BIOS specific port.
So the issue you were facing is odd and could be related to what was mentioned earlier about attaching a parent and child at the same time. Or even just a protected child.
The USB_5_15_16_17 is the one that I’m looking at wonderng what it is that it is mainly.
But the others could be children of a parent, U32G2_12 and U32G2_C3 .
U32G2X2_C1 could be another hub, but I’m thinking it may be another child.
So ther eisn’t anything int he DMI to identify it as a BIOS only port. Makes things difficult. But just means that after post, and when not in the BIOS, it doesn’t have any specific designation. That the BIOS has direct reference to that exact port is the most likely scenario.