Usability issues with hardware changes on system Qubes

User Support
1

So, I had this idea of using Qubes OS on a couple of machines, and when preparing for that I wanted to test out Qubes OS on one machine first. I read somewhere that Nvidia GPUs can have issues so I made sure I’ll just use an Intel 11400 with an iGPU to start with. Got everything running nicely.

Read about the new Windows guest support, decided to give that a try, heard hardware passthrough should be easy with Nvidia GPUs nowadays, so I plugged it back in and …

Boot up Qubes OS, sys-net and sys-usb fail to start, some PCI device IDs no longer exist. I guess they’ve changed, cool. I open the properties to go manage them, it just says “Unknown device” for the ones that were previously added, not particularly helpful. I guess that for sys-net that’s ethernet controllers, so I remove the unknown device, add ethernet in, ok, start. Seems to be fine.

For sys-usb again just says “Unknown device”, not very helpful. It looked like it had some USB and ThunderBolt devices assigned, there were a number that were not. Not pausing to think about it too much, I think “usb wants USB”, so I added the USB and ThunderBolt devices there replacing the “Unknown device”, ok, start … and some of you may already guess what happens next. The keyboard and mouse stopped responding, and I think “ah, yes, of course, well this is inconvenient”.

See now that sys-net and sys-usb ARE configured correctly again, they autostart on boot, and to start them up to try the settings out I had to save the settings. This now means I can’t even log into Qubes OS to start guessing which of those USB controllers should maybe not have been added and why.

At this point I’m pretty convinced I will run into the same issue with every random hardware change in the systems and that I don’t have the energy to start guessing which specific USB controller etc. should replace which “Unknown device” when that happens, so I think my experiment with Qubes OS ends here for now.

I just hope that you figure out some better means of managing these passthroughs for the core services. I can figure out the passthrough IDs changing for a GPU on a VM I’ve configured myself, no problem, but sys-net and sys-usb should really have whatever logic set them up during the initial install constantly maintaining them, at least try reconfiguring when they fail to autostart on boot. Alternatively would probably be pretty nice if the way passthrough was configured wasn’t based on device identifiers that change when you do pretty normal changes to your system. Maybe the same logic that during the installer identified where my keyboard and mouse are plugged in should be present on that passthrough management screen and draw keyboard and mouse icons on the devices and give you a big warning saying “you will lose control over these input devices if you attach them here”.

2

When you add new hardware, there is a chance it’s going to change the PCI id of your current devices. In your case, the result is that the devices added to sys-net and sys-usb no longer exists, which is why they are unknown.

Didn’t the documentation warn you that GUI pass-through is for advanced users?

Most articles that have that disclaimer contains information that can have a negative impact on your system if you are not careful.

3

@anon97510207
This is a known issue, raised on GitHub.
But it is not Qubes specific, and is a known issue in Linux generally.
I’m not a Windows user, but it used to be an issue in Windows too.
Perhaps it still is.

So if your experiment with Qubes ends here, it’s likely that your use of
Linux will also end.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
4

What a strange assumption. If I use any other Linux distro, it won’t randomly fail when I add/remove a device in my system and expect me to pull the trigger on a Russian roulette of passing through some random USB controller to the sys-usb Qube and hoping it didn’t just disconnect my mouse and keyboard from the host, which is then permanently saved and reactivated on boot.

Yes, passthrough IDs may change on other distros, but other distros don’t DEPEND ON THEM.

If I’m playing around with passthrough on random VMs on another distro, they are likely not configured to just automatically start at boot because the system does not depend on them for functionality.

I’ve used Linux for about 25 years, in quite a lot of different forms.

This IS a Qubes issue, Qubes is what configured the sys-net and sys-usb Qubes, and while yes the PCI device IDs may change on other distros and other OSes, it’s Qubes which uniquely depends on them to not change and provides no means that I know of to reliably fix it - and really the fixing should be automatic.

I provided you 3 different options for how this could be solved, of which at least 2 are certainly applicable and one is a guess as to what might work, but it sounds like you just raise your hands up in the air and claim “well this issue is universal, nothing can be done about it”?

5

@renehoj I know what happened, I told you what happened. I have no idea what you’re talking about GUI passthrough being for advanced users and documentation warning about it. You seem to fail to comprehend that I’m talking about sys-net and sys-usb being broken and there was no obvious “fix” button or any similar thing either, so what did you expect people would do then? I was not creating random Qubes and randomly passing through devices to them.

I don’t remember the getting started documentation explaining that 1) if I ever change my hardware configuration there was a high likelihood that Qubes OS would explode, and 2) that if I wanted to fix it afterwards it was too bad because GUI passthrough was for advanced users only, whatever that means.

6

To add to the previous points, at a minimum you should ensure that for the critical Qubes you don’t only store PCI device IDs that should be passed through, but also the name and any other additional identifiers that could be used to identify the device after it has been disconnected / moved, so a user has any chance whatsoever of being able to guess which device it may be that they should connect back to it, instead of just seeing 03:00.00 Unknown device, which is about as unhelpful as it could get.

7

I made no assumption. I pointed out that this is a universal problem to
do with PCI device number allocation.
If you have spent 25 years with Linux and not encountered any related issues,
then you have been luckier than me; many machines and OS will depend on PCI
numbers remaining constant, and will break when they change.
Qubes is not unique in this.

It’s true that Qubes is more complex because of the allocation of PCI
devices to individual qubes: this is so, whether they autostart or not.
If you were to review the issues in GitHub you would see a number of
different proposals.

I think you offered 2 “solutions”:

  1. Reconfigure sys-* qubes when they fail to autostart on boot.
  2. Have PCI allocation not based on device identifiers that are
    changeable.

I would be somewhat unhappy with automatically reconfiguring sys*
qubes, because of the potential for disaster. How would the system
automatically allocate NICs if I have a number of network qubes for
different purposes? What about cases where a user has a number of USB
qubes to serve different purposes (e.g. to separate ports; distinguish
internal devices from external ports)?

Your second “solution” is not a solution without a concrete proposal. If
you look on GitHub you will see that various possible approaches have
been discussed.

The third suggestion was to add a warning to the “Devices” tab. This is
probably a good idea, and the possibility of PCI numbering changing
should also be noted in the documentation.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
8

Flat out false. Almost no machine depends on PCI numbers remaining constant.

No, 3:

9

If any one of these were implemented, the situation would be easily salvageable. Currently it is apparently impossible to salvage as you have not clearly stated how is one supposed to identify which is the missing device from this, how the installer determined which devices can be safely connected, or any other means of recovery.

10

Oh, you are one of those people.
Just because you have not experienced something does not mean it does
not exist.
It would take seconds for you to find reports of such issues.

In any case, my view of your two “solutions” remains unchanged.

I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.

11

Random strawman and ad hominem attacks sure make you seem like a great person. I didn’t say it doesn’t exist, you are saying this is a common issue affecting many kinds of systems, when it is easily demonstrated to be false. If I were to install any random OS and then perform this kind of minimal hardware change, it would not blow up in a manner that was effectively unrecoverable without random chance -based guesswork. Ubuntu would not explode, Windows, Fedora, or Arch would not explode.

If by “many” you mean “a handful of rare cases here and there over the entire planet collectively making many individual samples”, sure … of course. There are quite a few machines out there. But normally “many” would be understood as a “significant %” and it’s absolutely not the case.

You seem to have a counting problem. I very clearly listed 3 solutions, here they are again:

image
image720×510 13.9 KB

And again, any one of these would prevent the issue from becoming catastrophic like it is right now.

You keep trying to attack me instead of proposing any solutions to this clear issue uniquely affecting Qubes, so how about you keep your mouth shut and stay away when you’re not helping in any way?

12

Also just some life advice, if you’re boasting the “Qubes Team” label on your profile, maybe don’t go out of your way to be a dick to people for no reason. It will leave a bad impression of the entire community. Or hey, maybe the entire “Qubes Team” is a bunch of dicks, who knows, for all I know that could just as well be the case.

Instead of just deleting the installation and moving on, I went out of my way to report the issue and propose 3 potential solutions that would’ve stopped this issue from being catastrophic. All I’ve received in return is random claims about “this being a common issue” - it’s not, assumptions about me never having used Linux before and never using it again, complaints about how I’ve not gone to some unknown GitHub repository that still remains unnamed instead of trying to ask on the forum which seems like it exists so that people would ask here first instead of creating issues about everything, some random constant intentional attempts to miscount 3 as 2 - is this some lame attempt at gaslighting? … and about how I’m “one of those people”.

The only additional response provided was some tiresome complaints about YOUR OPINION on my solutions, which I have zero interest in. I’m not invested in the solutions I proposed, I have zero interest in how Qubes OS will do in the future, but if you have any say in it, I’m sure it will not be very friendly to anyone.

13

There are 6 pages of repositories on Qubes OS Project · GitHub and you expect ME to guess which one this bug is related to? And you’re the one being upset that I’ve not checked the issues in 179 repositories :smile: