Hello everyone! Now that a few FW 12 batches have shipped I was wondering if anyone had the opportunity to test Qubes OS on the FW 12 to see how it runs, which compatibility issues there are, and so on. In particular I want to know how well the testing images of Qubes 4.3 would run compared to 4.2.
Also how is performance like with a few qubes running? How smooth is software based 1080p video playback in browsers?
Was hoping you’d get a reply. Really curious as well. Sadly can’t test on my machine RN.
Never seriously tried Qubes, mostly watched videos about it.
Is 4.3 the bleeding edge / latest development version? Can only find 4.2.4 on the download page.
It’s the latest testing version meant for people who want to test the next Qubes release: Testing new releases and updates | Qubes OS
A link to signed weekly ISOs can be found in the article above and it’s: Index of /qubes/iso-testing/
Maybe not too helpful as I am batch 8, though maybe you are a later batch. But I will certainly install it and post everything about how well it works and any helpful workarounds or tweaks when I get mine.
I have ran Qubes on my FW13 for awhile and it still works well. My FW16 also ran qubes for some time but the DPI scaling and poor battery life were kind of a deal breaker for me as I use the 16 for school. There were a few other issues with Qubes on the FW16 that did not occur on the FW13 like needing to manually setup an audiovm because the headphone jack is USB and the keyboard takes 5s to wake up after opening the laptop. I’m batch 9 for my 12 so somebody will probably get to this before me but if not I’ll try Qubes on the FW12 and report back.
For what it’s worth the first release candidate for Qubes OS 4.3 is now available (see their official website).
This should make testing on the FW12 much easier as it comes with newer kernel versions.
I have recently got mine and I haven’t tested things fully yet, but there is one issue.
I have for now installed the 4.3 rc-1, first installed with kernel-latest.
Seems the touchscreen and stylus support is not over USB, so works in dom0 (though then it is more complex to fully passthrough touchscreen to a qube, so that you can use touch finger scrolling, events in an appvm until Qubes moves to Wayland or implements touch events in the current gui protocol).
Have had only on Qubes an issue that sometimes trackad goes a bit wonky, fixed by reboot. Not sure if this linked to i/o activity (see below)
There is an issue, at least in my case with SN770M ssd, of getting in dmesg errors “nvme nvme0: I/O tag somenumber (hex number) QID 10 (or sometimes 2) timeout, completion polled”
The issue certainly seems worse with kernel-latest for dom0 compared to lts kernel, with kernel-latest often causing freezes when logging in.
I have been trying to restore backup, but during that time the system is in a cycle of freezing, burst of not freezing, then freezing, etc, and the cycle repeats. Freezing means that I think any I/O operations for the disk are not working. So graphics still work, you can open new terminal tabs or enter a command, but the shell won’t load or anything happen, even an ls command, which are all delayed until the temporary unfreezing.
During my first backup restore attempt, slowly like this I got 300gb over 18 hours, before cancelling.
Trying again with lts kernel and doing a subset of qubes, skipping large, after a period of no nvme issues, they started happening. (Though seems like with kernel-latest you consistently get them on every boot/login, but with LTS kernel they only started after backup restore had made some progress)
I have not tried setting that timeout kernel parameter yet (which apparently if set to zero as recommended will disable ssd power management?? Maybe shouldn’t do that, I also see some people say to set it to a high number)
I haven’t yet tried the potential disable Intel VMD workaround, as I could not find such an option in bios, nor disabling/enabling RAID for ssd.
I tried a bit disabling SMT in bios workaround, but haven’t not tested it fully. Didn’t see any errors with lts kernel, but didn’t try I/O write intensive operation such as restore backup.
I haven’t yet tested the potential workaround of setting kernel arguments dom0_max_vcpus=1 dom0_vcpus_pin
No such issues in Fedora.
There were no issues when I was restoring an image file of a 200GB partition at maximum speed on the SSD, from a Fedora live usb
I found a workaround for nvme freezing issue.
The issue seems to only occur if dom0 vcpus are running on more than one physical cpu.
Adding xen parameters dom0_max_vcpus=1 dom0_vcpus_pin fully eliminated the issue, was able to restore multiple large Windows qubes with no timeouts or freezes.
Though that limited dom0 to one vcpu, but that didn’t seem to lead to visible issues, at least with xfce. And in this case it was pinned to first core, which is p core.
Also, disabling SMT didn’t fix issue before, however disabling it does seem to break e-core power management, so better leave it on.
Tried without dom0_vcpus_pin , didn’t do as large of a test, but also no such issues were encountered.
Performance seems fine with one e core too.
However, an issue with this is that due to a Xen bug, still not fixed, read more here CPU Pinning Alder Lake - Community Guides - Qubes OS Forum all CPUs except one in this case do not have all their C-states detected, which reduces battery life and increases power consumption.
I tried instead setting to 12 vcpus (apparently in some places it says you should set to how many threads with smt, even if xen doesn’t use it, but this seems stupid as the output of some pm commands then doesn’t make much sense in that case, so probably simply unset dom0_max_vcpus variable).
The issue reappeared.
However, pinning all the dom0 vcpus to one core resolved the issue, for example, with xl vcpu-pin Domain-0 all 8. Or at least it seemed, for decently long time no errors, didn’t seem to freeze.
Then when I unpinned the dom0 vcpus with xl vcpu-pin Domain-0 all all the issue quickly reappeared, and the timeouts became common.
Though I then pinned them again to one with xl vcpu-pin Domain-0 all 5, and interestingly issue didn’t seem to disappear really this time, at least in logs? So I don’t know, make of this what you want. Had errors every thirty seconds or so before pinning, then no errors for 800 seconds, then when I unpinned them errors appeared once again every 30 seconds or so
An issue with this method is that dom0 responsiveness, performance under load certainly seams much worse when giving it many vcpus and pinning them to one cpu compared to simply giving it one vcpu.