Right above you in my post.
can you be explicit??
kernel latest == ???
regular kernel == ???
I’ve been testing and playing around with the new rc4 for a few days without bigger problems but now I am getting
“maximum recursion depth exceeded in instancecheck”
when trying to start any VM. That’s a new on for me. Anybody encountered this error & any idea where this is coming from/how to recover?
I upgraded from 4.1.2 to rc4, updating dom0 went fine but the templates not so much, so I performed those manually. My problem atm is that I cannot get any domU window to show up, regardless of whether I’m using an updated fc37 template from my 4.1.2 installation (updated awkwardly using xl console) or a newly downloaded fc38 template. Could someone point me in the correct direction to start debugging this?
This is a Python exception. Do you get more info around it?
BTW, a casual grep for “instancecheck” in the qubes python lib returns 0 hits.
The kernel latest that came default for me was 6.5.6-2.qubes.fc37. But as I said in my post it would hang on template installation during configuration. The normal kernel that I ended up using for the install and worked (however igpu doesn’t work) was 6.1.56-1 (as least that was the number in grub . . . ). I’ll probably try to update the kernel though so I can get the igpu working so I can do pcie passthrough on my gpu.
Could you share more details about the whole procedure you used?
Used the official upgrade tool for steps 1 through 3 which went fine, then rebooted. Steps 4 and 5 don’t work automatically because there seems to be some kind of issue communicating with a VM so I manually ran the scripts and commands, which seemed to go okay. Then ran step 6 while excluding the templates for the same reason.
Rebooted again per suggestion, but while the templates work fine for stuff like sys net, and I can do things using XL console, I can’t get it to run any windowed apps and show them.
Not using sys-gui yet, running it on a ryzen 2700 and a RX 6700 XT which seem to be supported fine. (Also can’t currently activate sys gui mode because there’s no working fedora 38 xfce template that it wants to install.)
Huh, I just did a fresh install using kernel-latest and chose only the fedora template and no usb qube and configuration/template install didn’t hang. Yay working igpu.
Aha. Decided I’d try to log out to try a different compositor, and noticed it had selected Wayland by default during the upgrade process, which of course caused the issues displaying VM windows. Switched to x11 and things suddenly seem to work fine.
kernel-latest seems to be unstable (both in this RC and from packages repository). Impossible to finish the installation with kernel-latest, but no issue with the standard kernel.
( issue is not related specifically to the RC, but to kernel-latest. It is causing hang/freeze on my setup )
Not a direct reply, only cross-referencing for visibility because the issue(s) described in the topic also affects RC4:
Yes, taking a look into journalctl was showing me the astonishing number of 848.340 lines of repeating messages like the following:
File "/usr/lib/python3.11/site-packages/qubes/vm/qubesvm.py", line 746, in <lambda>
default=(lambda self: getattr(self.guivm, 'keyboard_layout', 'us++')),
(there might be a typo because I wrote this down. Not a single VM is starting because of this)
Another message found very often is this:
AttributeError: 'AppVM' object has no attribute '_qubesprop_keyboard_layout'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/qubes/__init__.py", line 227, in __get__ return gettattr(instance, self._attr_name)
Clearing the logs didn’t help, though.
I had sys-gui-gpu in use and it may (or may not) be connected. Well, something seems wrong with the keyboard-layout.
Kernel Latest wasn’t working for me previously but is working now.
To my knowledge the only changes I made were
- Only install fedora template (instead of all)
- Do not create usb qube (instead of default create usb qube)
- Only one screened plugged into igpu (instead of two plugged into nvidia gpu)
I used btrfs both times since I’ve heard rumors of 512 byte sector problems with some drives . . . Initial setup fail if disk using 4Kn sector size with lvm+thin pool · Issue #7398 · QubesOS/qubes-issues · GitHub
I’m experienceing a fairly major problem in that when the screens are turmed off by power saving, any open windows are killed in my ‘personal’ AppVM, and it’ll refuse to open any new ones until I reboot it. Other AppVMs are not affected, even though all are running based on the same template.
What is in the logs of this VM?
I’ll try to see if there’s anything visible if I log in with xl console next time it happens, unless those logs are also saved in dom0 somewhere (since I don’t think journal logs persist between boots)?
I’m not sure if they’re the logs you need, but in the Qube Manager, you can access a few different logs by right-clicking on a qube and selecting “Logs.”
Now the -rc4 is in the stable repository, see :
- 4.2 stable updates-status
qubes-release-4.2-0.8.fc37.noarch.rpmin 4.2 stable repo
what does that mean? that we have the release of 4.2 finally upon us?