Install failed near very end with the "Unable to reset PCI device". It boots but cannot run any qubes

User Support General
1

I just installed 4.2.2 ISO on my Dell Precision 3650 64BG RAM, 4TB HD, & 6-core I5-10505. So its a solid machine. Install seemed to go well until the very end, with sys-firewalll reporting:

[‘/usr/bin/qvm-start’, ‘sys-firewall’] failed:
stdout: “”
stderr: "Start failed: internal error: Unable to reset PCI device 0000:00:1f:6: no FLR, PM reset or bus reset available, see /var/log/libvirt/libxt/libxt-driver.log for details

It did seem to boot though, but all qubes now fail with both sys-net and sys-firewall reporting that same “unable to reset PCI…”; my 1f:6 device is an Intel ethernet adapter on the motherboard. If I look up the settings in the sys-net and sys-firewall qubes, its showing up in the right side as “always attached” for sys-net, and sys-firewall has it on the left “available”. So my best guess is my issue seems identical to this one where the user was asked to disable virtualization in BIOS before then doing a detach then persistant reattach with no-strict options, then re-enabling virtualization in the BIOS.

I’ve tried to replicate that, so have done the change in BIOS but then upon boot after I enter the disk/luks password I am prompted as usual to enter my user password but the keyboard and mouse dont work. Multiple reboots result in same, but as soon as I reenable virtualization in the BIOS, I can log in, but still with the same “unable to reset PCI…”

Hope this is salvageable?

2

This looks quite similar to FLR on intel network card not correctly detected on Novacustom V5xx laptops · Issue #9356 · QubesOS/qubes-issues · GitHub. Can you check exact network adapter model number, on lspci -nn output? Is it maybe 8086:550A ? If so, the fix may be to just install updated kernel-latest package. This may be not very easy without a network, but maybe you have some USB network device? Or maybe wifi card? You can make sys-net start by detaching the intel card from it, start sys-net and then attach the USB network device using devices widget.

3

You don’t need to disable the virtualization if your Devices list in sys-net Settings is not greyed out as was the case in the topic that you linked.
I think the issue in that topic was because of the bug and it was fixed already.
So you can try the @marmarek’s suggestion and if it won’t work then you can try to add the no-strict-reset option to your network controller attached to sys-net that is causing this issue:

4

ah cool, thanks all… so seems not soo bad here.

now, I do have a wifi dongle. When I plut it in Im advised by a popup that “Device 2357:0138 Realtek_802.11ac_NIC_123456 is available”

But its not showing anywhere in a dmesg, and not showing up as an available device that can be added from the left side of the sys-net qube’s devices to the “always connected”

Besides fighting with the network and a usb wifi dongle, can i just copy the updates to USB and install them directly from the file system?

5

Do you have the 8086:550A PCI Network Controller?
Check the output of this command in dom0 terminal:

lspci -nn

It’d look like this:

[user@dom0 ~]$ lspci -nn -s 00:1f.6
00:1f.6 Ethernet controller [0200]: Intel Corporation Device [8086:550a] (rev 20)
6

Yes its shows up as:

00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (14) I219-LM [8086:15f9 (rev 11)

but the last IDs are a bit different there are different from what you posted.

7

Then newer kernel won’t help here because it’s fixing the issue only for that specific Network Controller model with VID:PID 8086:550A:

Maybe your Network Controller model has similar issue with hardware errata but it needs to be fixed separately.

I guess you can only enable no-strict-reset for it to use it for now:

8

yup Im up and running using that option.
thanks all