Installed 4.2.0RC1, install went fine 'til the end, no longer have to hex edit the ISO in advance to fix nouveau stuff which was nice. Right near the end of install, after the reboot and most of the config, it throws an error, which you can bypass by hitting OK and it immediately reboots without the progress bar going any further. This error reads:
['/usr/bin/qvm-start', 'sys-firewall'] failed:
stdout: ""
stderr: "Start failed: internal error: Unable to reset PCI device 0000:04:00.1:
internal error: Active 0000:04:00.0 devices on bus with 0000:04:00.1, not doing
bus reset, see /var/log/libvirt/libxl/libxl-driver.log for details
"
After the reboot, it boots into Qubes fine, seemingly no issue, until you go to use the system. When you try to do anything that depends on networking (launch personal cube, for instance, or try to update dom0) it goes to launch sys-net and throws the almost the same error:
Qube Status: sys-net
Qube sys-net has failed to start: internal error: Unable to reset PCI device 0000:04:00.1: internal error: Active 0000:04:00.0 devices on bus with 0000:04:00.1, not doing bus reset
That device is a card reader, by the way. The 00.1 device is an ethernet card. I don’t care about the ethernet card (at the moment) so I remove from sys-net to bypass this.
At this point, sys-net will launch if you tell it to, and it shuts down almost immediately after. I don’t recall if this is intended behavior, been a minute since I last used Qubes. If you try to launch sys-firewall or anything that uses it (such as qubes-update-dom0) it then starts sys-net, then tries to start sys-firewall and very quickly fails with:
Start failed: internal error: libxenlight failed to create new domain 'sys-firewall', see /var/log/libvirt/libxl/libxl-driver.log for details
Not sure what triggers this difference, but sometimes it would hang with sys-firewall on yellow status and in the qube systray icon menu a spinning wheel forever rather than immediately failing.
At this point I tried removing dependencies and deleting the qubes in question, and using the “distribution” tools to recreate them, which did not change anything behaviorally.
Looking at the driver log as the errors suggest just shows errors about the unable to reset PCI device stuff from earlier, as well as one from sys-usb that I had also dealt with (removed the USB3 controller from sys-usb as it had issues resetting too). In there it goes into “The kernel doesn’t support reset from sysfs for PCI device” for the USB3 controller’s ID in addition to the aforementioned ethernet controller error but nothing else to go on.
I tried setting the personal qube to directly use sys-net as an experiment, which caused it to fail the same way that sys-firewall was (unable to create domain and/or it hangs).
I tried setting strict reset on the device(s), which did not help.
I tried turning off autostart on all relevant qubes.
I tried setting the updater qube to sys-net which causes qubes-update-dom0 to hang and never complete.
I think I even tried setting personal qube to have no networking and still was unable to do anything with it, but I don’t remember enough detail about that attempt to be useful.
I tried explicitly launching qubes in order, e.g., “qvm-start sys-net && sleep 5 && qvm-start sys-firewall && sleep 5 && qvm-start personal” and similar variations.
Under no circumstances am I given any chance to join a wifi network with the wifi card. Even turning off networking, I am unable to launch the personal qube IIRC.
I tried too many things for too many hours including a full reinstall, so forgive my somewhat confused recollection, but somewhere along this I saw it stating “unable to add vif devices” - might have been in another log, perhaps the VM-specific log.
Machine has VT-d and IOMMU support, I’ve run older versions (4.1.x) of Qubes on here without issue, even had PCIe passthrough going, so I know the hardware works fine with the general Qubes ecosystem.
Edit: With 4.1.2 it has the same error at the end of installation but works fine once the ethernet is removed from sys-net.