Any hardware change breaks Qubes (even adding/removing SATA/NVMe drives) - wrong PCI devices get assigned

Max123 · October 19, 2025, 8:59am

Every time I add or remove hardware in Qubes 4.2, my qubes lose their assigned PCI devices or get the wrong ones assigned. This happens even when I just connect/disconnect SATA or NVMe drives between reboots.

Examples of what goes wrong:

sys-usb loses the keyboard controller and gets VGA instead
sys-usb suddenly contains random devices unrelated to USB
sys-net loses the network card
My storage qube gets USB controllers (2 items) instead of SATA controllers (2 items)
Sometimes I see “Unknown device” in assignments

When this happens to system qubes, the OS won’t boot. When it happens to my personal qubes, they either fail to start or don’t work properly.

My Use Case

I regularly need to connect and disconnect storage drives (SATA/NVMe) between boots for my workflow. This shouldn’t break the entire PCI device configuration, but it does.

All this makes Qubes not very useful, because in such cases I always need to reboot with system qubes auto start disabled and reassign (with help of Qubes Manager) literally all devices to qubes (sys-usb, sys-net, and my custom ones) from scratch and then reboot again.

I could understand this if it happened because of real hardware changes, but it ruins my life when I just add or remove drives.

What I Think Is Happening

It seems like PCI enumeration changes when hardware is added/removed, causing BDF addresses (Bus:Device.Function) to shift. Qubes appears to store device assignments by BDF address, so when a device that was at 00:12.0 moves to 00:13.0, my qubes get reassigned to whatever is now at the old address.

Please help.

KitsuneNoBaka · October 19, 2025, 9:39am

Is it started with Q4.2 but wasn’t present in Q4.1?

MellowPoison · October 19, 2025, 9:46am

It should be fixed in Qubes OS 4.3:

github.com/QubesOS/qubes-issues

Wrong PCIe devices get passed through to wrong qubes after adding new PCIe cards

opened 07:52PM - 25 Sep 22 UTC

closed 03:13PM - 27 Apr 25 UTC

ddevz

C: core P: major security hardware support diagnosed affects-4.1 affects-4.2 affects-4.3

After installing qubes and setting up your passthrough PCI devices, if you add a… new PCIe card, it can change the device numbers of the old cards. This will cause qubes to pass through the wrong devices to the wrong HVM qubes. The device renumbering is obviously a hardware thing, and preferably there would be a way to make persistent names similar to how linux gives ethernet cards persistent names. If you remove eth0 from a linux system and put another ethernet card in, linux starts calling that new card eth1, not eth0. Linux probably determines uniqueness by MAC address, so there might not be any way to uniquely identify PCIe cards like that. I expect this to become a bigger problem in the future when people are using sys-gui-gpu and video cards getting a new PCIe number means they will no longer pass through to sys-gui-gpu qube. (this is related to, but different then https://github.com/QubesOS/qubes-issues/issues/6587 )

github.com/QubesOS/qubes-issues

Replace bus/slot/function with full PCI paths

opened 05:25AM - 03 Nov 23 UTC

closed 02:26AM - 16 Apr 25 UTC

DemiMarie

C: core P: default pr submitted r4.3-host-cur-test targets-4.3

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) ###… The problem you're addressing (if any) PCI devices are currently assigned via bus/slot/function, which is not a stable identifier. ### The solution you'd like Use PCI paths instead, which are much more likely to be stable. Specifically, replace the "bus" part with the bridges path starting from bus 0. For example: ``` # lspci -t -[0000:00]-+-00.0 +-00.2 +-01.0 +-02.0 +-02.2-[01]----00.0 +-02.4-[02]----00.0 +-03.0 +-03.1-[03-61]-- +-04.0 +-04.1-[62-c0]-- +-08.0 +-08.1-[c1]--+-00.0 | +-00.1 | +-00.2 | +-00.3 | +-00.4 | +-00.5 | \-00.6 ... ``` The device `0000:c1:00.0` is behind bridge at `0000:00:08.1`. In some cases there may be more bridges. There may be more devices behind a single bridge (in the example above it's just a single multi-function device). You can get bus ranges handled by a given bridge by looking at "secondary" and "subordinate" attributes on lspci (and similarly in sysfs): ``` 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Phoenix Internal GPP Bridge to Bus [C:A] (prog-if 00 [Normal decode]) Subsystem: Device 0006:f111 Flags: bus master, fast devsel, latency 0, IRQ 106 Bus: primary=00, secondary=c1, subordinate=c1, sec-latency=0 ... ``` I imagine the path for the `0000:c1:00.0` device would look something like this: `0000:00:08.1-00:00.0`, where the `-00` part means "the first bus behind this bridge". The important part is to _not_ include "c1" in the address (but use the address relative to the bridge range), because if the bus will get renumbered (when somebody plugs some other devices for example), that number may change. If there would be device at bus 5, (which is the third bus behind bridge at 00:03.1), for example at 0000:05:01.5, it would have a path like `0000:00:03.1-02:01.5` PCI bridges cannot cross the PCI segment boundaries, so the first "0000" will stay the same (doesn't need to be duplicated in the address). ### The value to a user, and who that user might be Users will be less likely to have problems with PCI device renumbering.

Max123 · October 19, 2025, 10:07am

Unfortunately, I haven’t use Qubes 4.1.

Max123 · October 19, 2025, 10:18am

That’s great!
I see that #8681 has already been fixed in Qubes 4.3 RC2: Qubes OS 4.3 release notes — Qubes OS Documentation

I’ll be looking forward to the Qubes 4.3 release and will update immediately.

Meanwhile, is there any workaround for this in 4.2?

MellowPoison · October 19, 2025, 10:21am

I don’t think there is a workaround for this and this feature is unlikely to be backported to 4.2.