Feedback for R4.1 installation issues

Let me preface this post with: I am not looking for help. Rather, I am providing feedback on my Qubes experience in hopes of improving the installation tools, guides, etc. I have been using Linux since the mid-1990s (started using Unix in 1991), have been a sysadmin in some roles, and have always been able to work through my installation and maintenance issues. I have never failed to troubleshoot a Linux problem until now (I finally ran out of patience and time after killing three weekends and a lot of evenings in between). I prefer to use an operating system in the most secure context possible, but it also MUST work reliably, and be able to connect to a network (where most computers arguably get most of their usefulness: being able to transmit information). I do not mind spending a little more time to do things if it means big gains in security and privacy, but I cannot lose days or weeks of productivity. Maybe I will try Qubes again in the future, but for now I went back to a distro that works reliably and I know well (and I managed to have fully operational in less than one hour).

I became aware of Qubes soon after it was first released, and was excited with the concepts, but waited for Qubes to mature. I tried playing with it in Release 3.1 (IIRC) and decided to wait for it to mature some more. With Release 4.0 I finally dived in and was fairly happy with it. I knew I would need to spend plenty of time learning to use Qubes OS in its intended security contexts. It was not easy getting it working on a current notebook PC I had just purchased (HP ProBook 650 G5 notebook PC w/ Intel Core i7-8565U). I managed to get most of it working after reading through troubleshooting guides and forum posts…

Under R4.0, I eventually figured out I needed to add my Intel USB 3.1 xHCI controller to the sys-usb setting “Configure Strict Reset for PCI Devices”, and do the same for the Intel Ethernet I219-V and AX200 WiFi 6 controllers in sys-net.

Also, the kernel under R4.0 did not support Intel AX200, and was not going to get updated to that revision for the foreseeable future (at the time) --the hazards of using kernels that tend to be far behind the current kernel includes not having support for the latest hardware, including the biggest names in the industry. So I was force to do without WiFi for a long time (not a problem most of the time for me, but there was one occasion where I really needed it).

Finally, I could not update by Fedora template to 32, despite the suggestions in the guides, Qubes forums, and Fedora forums (among other steps, I recall successfully using lvextend in dom0 but still failed upgrade). I feel for Steve123, who mentioned in a post they were stuck on R4.0 because they did not see their HP laptop on the hardware compatibility list for 4.1 (after they were chided for having an older Qubes installation).

So fast-forward to three weekends ago: I backed up my data and attempted a clean Qubes R4.1 installation on the same HP ProBook 650 G5 notebook PC (w/ Intel Core i7-8565U; and VTx, Vtd, and Hyperthreading enabled in BIOS). I have been unable start sys-usb, and unable to connect to my local network since (I get a flood of pop-up error windows). None of the installation or troubleshooting guides (PCI, USB), or numerous searches (the most useful being https://forum.qubes-os.org/t/please-do-not-drop-support-for-pv/9675, https://forum.qubes-os.org/t/usb-block-device-not-detected/8469, https://forum.qubes-os.org/t/usb-block-device-not-detected/8469), have helped resolve my problem.

One of the pop-up error windows during troubleshooting starting sys-net (to connect my 4.1 installation to my network), titled “[Dom0] Error Starting Qube!” reported:

Start failed: Internal error: Unable to reset PCI device 0000:00:1f.6: no FLR, PM reset or bus available. See /var/log/libvirt/libxl/libxl-driver.log for details.

Checking the log, as suggested, I can see many repeated entries (every time I booted or attempted to start sys-net):

libxl:libxl_pci.c:1489:libxl__device_pci_reset: The kernel doesn’t support reset from sysfs for PCI device 0000:00:14.0

lspci reports:

00:1f.6 is an Intel Corporation Ethernet Connection (6) I219-V (rev11)
00:14.0 is an Intel Corporation Cannon Point-LP USB 3.1 xHCI Controller (rev11)

Unlike the R4.0 installation, it appears the R4.1 installation added the Intel USB 3.1 xHCI Controller to the sys-usb Configure Strict Reset for PCI Devices, and did the same for the Intel Ethernet I219-V in sys-net.

As suggested in “USB block device not detected”, I tried to clone sys-usb and setting the clone to Para-Virtualization mode (was already and automatically start up, with the original set to not start automatically), assigned the USB 3.0 controller to it:

qvm-pci attach -v --persistent --option no-strict-reset=true sys-usb_clone dom0:00_14.0
This failed to resolve the issue when I try to start sys-usb and sys-net, even after a reboot.

I tried wiping the SSD and performing another clean installation. I still had the same issues above when I eventually made it through the re-installation.

Regardless of the above issues, this time I took a few notes on the frustrations of the installer tool:

  • The Installation Guide’s Initial Setup (https://www.qubes-os.org/doc/installation-guide/#initial-setup) has outdated screenshots which does not portray the options I had in the R4.1 installation tool (i.e. disposable VM options, custom storage pool), nor does it discuss the implications of those options. Searching the rest of the online Documentation failed to fully explain the advantages and disadvantages of the choices (could not find in the Forums either).
  • The installation tool’s built-in Help has very little help specific to Qubes, sometimes no content at all depending on the screen. This help could have answered some of the unanswered questions above.
  • While attempting to manually set up partitions, the installation tool freezes when I tried to change a partition size (from one value to another) and apply the change. I would have to restart the Live boot installation tool and start over. As long as I set the size once and did not go back to change it, I could proceed normally. Very frustrating time killer.
  • GUI look-and-feel is inconsistent with other tools, particularly buttons indicating “Done”, “Next”, “Finish” for navigating settings screens keep moving around. Most polished GUI tools put those sorts of buttons on the bottom right, or middle-right (depending on the layout), but are at least consistently placed.
  • Other: the Install tool should have a warning that Initial Setup will appear to hang while installing Templates, but just takes time.

The issues above remind me of several different discussions that were had during last summer’s Qubes Mini-Summit.

Fortunately, I had another old Linux PC take place of my primary system over the last few weeks while I banged away at this R4.1 upgrade attempt. Many potential Qubes users may not have the spare PC platform and time to expend so much effort in trying to make Qubes work. I hope all of the above helps.

1 Like

What I can add is that probably after installing kernel latest (5.16.xxx), or updated Xen or whatever update was, simple switching sys-usb with 00:14.0 controller from PV to HVM mode in its Settings worked like a charm.

I’m not sure if something like

sudo echo 0000:00:1f.6 > /sys/bus/pci/drivers/pciback/permissive

or

qvm-pci attach --persistent –option permissive=true --option no-strict-reset=true sys-usb dom0:<BDF_OF_DEVICE>

would actually help, but at the end of the day, at least for the older hardware, such issues, as I see it, tell us more about the hardware than about Qubes. It would be easy to allow all the hardware to “properly” function, but then that wouldn’t be Qubes and it’s philosophy,

For me there is no choosing between Qubes and other OSs. It’s not anymore about first choosing the hardware I like.

It’s about the only thing so far that can digitally protect me - Qubes. Reasonably.

I had the same error with the same I219-V device on a new install of 4.1 (kernel 5.10.104-3) and could not start sys-net with ethernet attached. Resolved easily by setting no-strict-reset=True. I simply followed the instructions in the Qubes PCI troubleshooting doc (scroll down to the next subsection “Domain […] has failed to start…”). I did not need to relax the permissive option.

Fortunately my wifi, Intel ac 9560, in this setup worked without issue, so I had internet from the start.