I really appreciate your quick response. I am having two other issues that I am curious how you addressed: 1. I have a constant cycling in my sys-USB that says “device : is available”, and then after some seconds it says “device : removed”. This never stops and there is no name for the device. I saw at least 2 other people on my digging around the Internet who mentioned they had this issue with Framewok and Qubes too. How did you handle that? Or did it not happen to you? 2. The XFCE desktop environment at this resolution is so minuscule that it’s almost unusable. Mostly it’s the font sizes but I can’t seem to change them. Even better would be to get Gnome on here, but I haven’t seen anyone succeed at that from my searching. What did you find the best solution for that was?
Thank you for taking the time to share your experience.
I have plans to improve my write-up on using Qubes with framework, but I haven’t done it yet. Hope that this description helps a bit.
I had something similar with USB device cycling in and out.
The problem is gone now (except for some issues with the camera).
I’ll explain what I did, and I am curious whether it is your problem as well.
My sys-usb uses the fedora-34-dvm template. Same with sys-firewall, and sys-net is fedora-34.
My first attempt at a Qubes install on framework tried the debian templates. I believe that this was what caused the USB problems. I suspect that sys-usb doesn’t work well with Debian, at least for framework. I chose disposable templates in both cases, just in case it matters.
Fonts
I had been slightly annoyed with this for a while, but hadn’t done anything
I finally noticed something today, after your questions.
Try this
System tools => Settings Editor
change FontName from “Sans 10” to “Sans 12” or something bigger.
See attached image.
This looks interesting, and I am going to dig into the xsettings as you showed in the image.
I can also report, that I did the same thing you did trying to resolve the USB device cycle issue: I installed everything with Debian Templates as default (because I like Debian and am familiar with it), and then when I had some of these issues, I decided to reinstall using Fedora 34 as the default (because I assumed that the developers might have built the system expecting those as default and maybe that would help). Unfortunately, in my system, that seems not to have fixed the strange USB cycling issue.
I suppose that the next thing to do is to try to install the Linux Firmware blobs from the “linux-firmware” package, and then try to update my kernel if that doesn’t work. Sadly, I still don’t feel comfortable with how to do the newer kernel process, so I will keep digging. But if anyone knows how to do it, I would be very appreciative!
Perhaps you and I and whomever else is trying this Framework Qubes foray can get some good documentation built to help others to do the same.
Back to the USB cycling.
Today, I had another round of problems with the camera dropping out of my chosen Qube
Also, I have trouble attaching my Android to a Qube
The microphone, however, stays attached.
I’ve successfully installed Qubes on my Framework, and have gotten almost everything working great. I’ve included a link to notes I made while installing
I haven’t tested anything to do with suspend, so no notes there. Shutting down and starting is fast enough for me anyway.
You both are awesome and I am looking forward to getting this all working for everyone. So far everything is going fairly well EXCEPT the AX210 card… I don’t understand it. I got it working for quite some time the same way that EncrytpedGiraffe did, but a recent intel linux firmware update seems to have broken it. Any other ideas? And also, WHY does the AX210 card work in every other linux distribution I have tested, but not Qubes. I suppose the clear antagonist must be the Xen virtualization somehow? I know I could buy an old card somewhere, but I feel that I must figure this out, as there will be many more Intel Wifi6 cards going forward in Qubes for the community no doubt.
Have you added the kernel-latest and kernel-latest-qubes-vm to dom0, and set your sys-net to use that kernel? That was the only way I could get my WiFi6 device recognized (not Framework) on my laptop.
pr0xy, Thanks for the suggestion. Yes I have done that, I hope, correctly. without kernel-latest, there were a few hardware issues, but those are resolved now running kernel 5.18.14 on sys-usb and sys-net. I personally would have expected your suggestion to fix the issue, as that does on other linux distributions (for example, LMDE 5). But alas, it still has trouble loading the driver. I do have the demsg screenshots of the driver failure. I will post them here, but if this is not the appropriate place for that (since this is the HCL Report page), please just let me know moderators and I will remove it.
As you can see, it attempts to load the wrong driver. It SHOULD be loading number 58 according to the Intel page. However, I have tried this process extensively with both the Debian VM as the base and the Fedora VM as rthe base, and both have issues. Debian actually tried to load the correct driver, but fails due to pvnm not loading. This demsg is from the Fedora 36 VM version of sys-net.
The next thing I was going to suggest was to make sure you had Fedora for sys-net…but you have that covered. The kernel change in combination with Fedora 36 was all I needed to get the WiFi6 adapter recognized and operational (again not a Framework device).
Have you tried booting from a live image of Fedora 36 to see if the device is properly detected and operational there?
That’s a really good idea. I just tried that with a fedora 36 live-USB and my wifi card was immediately detected and working on boot. However, I did notice that, yet again, the dmesg revealed that the card was technically running under the wrong ucode “drivers”(according to Intel’s Linux page, this card should use the .59 ucode…I incorrectly stated “58” in my previous post). It seems to try from the largest numbered ucode and then try them all until it finds one that sorta works well enough not to reject it outright. I am attaching the dmesg from Fedora 36 live USB here.
It seems that the universal constant causing the failure is when the pnvm doesn’t load…I am not sure why it doesn’t as the file is indeed there and it does actually load it. then just times out and fails to load anything after that. It should be noted, that I did also try renaming all the ucode files other than ucode .59, and it did the same thing where pnvm fails to load and causes it to simply not work. I am noticing that the hexadecimal identifier for pnvm version is different in Fedora 36 LiveUSB where it succeeds and the Qubes Fedora 36 VM where it fails… Perhaps it is actually trying to load the wrong pnvm somehow?
Other possible factors that I am not qualified enough to dig into: maybe there is some kernel issue specific to Qubes kernels or something with the Xen abstraction that interferes with the card.
After some investigation, this seems to be related to some interaction between pciback (the pcie passthrough driver of the AX210 Wifi 6E card in dom0) + iwlwifi firmware loading code.
Thank you for putting time into investigating. That makes a lot of sense since the firmware and card seem OK in a multitude of other distributions I have Live-booted. I have no idea at all how to work to rectify that passthrough issue… do you know anyone who does? The card has worked in Qubes in the past with strange workarounds in older kernels (which it no longer does), so I feel it must be technically possible somehow, but I don’t know the first thing about Xen.
I just installed 4.1.1 on the i5 model, and everything I have tried now works OK after some troubleshooting. Some comments to help others:
AX210 WiFi. Initially this didn’t work, but updating dom0 brought a new kernel (5.15.64-1.fc32) and then it just worked. I checked the box ‘Enable updates for qubes without known available updates’ in Qubes Update to force the dom0 update.
Suspend. Initially laptop wouldn’t wake up from suspend, the power button light would just pulse until I did a hard shutdown. echo deep | sudo tee /sys/power/mem_sleep made suspend work OK, I added a crontab line for after each reboot. Suspend isn’t perfect, using perhaps 15% of battery overnight, but it is enough to be useful.
Trackpad. It took me a while to realize that clicks in the bottom right corner of the trackpad register as right clicks.
The webcam worked fine, and I have not tried bluetooth or the fingerprint reader.
For anyone who jumps into the Framework Laptop 11th gen at this point (such as the HCL report is for this post), at this point the laptop works very well and new kernels have resolved all the major issues. I have posted a guide for Framework laptop users, for all generations, here on github Setting up and tweaking Qubes OS 4.1 and 4.2 on Framework Laptop · GitHub.
Fabulous machines and great forum. If you can look more into BIOS like Linux Boot it would make perfection. Former Machine Head… with lots of brain damage talking.
@moonlitOrca I moved your HCL report to its own topic so that it’s in the HCL category.
That makes processing easier, and makes it easier to find afterwards. And the move leaves a link here for people following the thread, so it’s a win-win situation
I’ll bring your HCL back