3. Does HVM sys-gui-gpu work? What about PV (not PVH!) sys-gui-gpu?I don't have a sys-gui-gpu at the moment, but will test that. This page (https://www.qubes-os.org/doc/guivm-configuration/) is still the most relevant/recent description, right?I think so? I don’t use sys-gui-gpu myself, and I will admit that there are quite a few bugs when using it. Still, if it works, then the possible parts of the code that could be to blame is much lower. If sys-gui-gpu in PV mode works, then the problem is almost certainly the userspace drivers (Mesa). If sys-gui-gpu in HVM mode works, but it fails in PV mode, then the problem is likely in the way i915 and Xen interact.I have tested this now. When I boot, the problem remains. Opening the Qube Manager shows that the sys-gui-gpu qube is not running. I tried starting it from the manager, and it led to immediate black screen, requiring a hard shutdown. The logs for that qube are here:dom0 will kernel panic if the GPU is removed from it while in use. I recommend preventing the i915 kernel module from being loaded in dom0 via the dom0 kernel command line.
I've tried some variants now. Disabling i915 (by moving the
driver flie) doesn't do much. It boots up as usual, same problems,
and if I try to boot the sys-gui-gpu qube, it blackscreens and
requires hard shutdown.
/Martin
You may want to keep your i915 driver and try: https://github.com/QubesOS/qubes-issues/issues/7507#issuecomment-1153081021
Well done!
How did you enable the 5.18 kernel? I've tried with
'qubes-dom0-unstable' and listing the available kernels, but it
shows only a few versions of 5.15 as installation candidates.
Cheers,
Martin
Qubes is working for me on Lenovo X1 Carbon gen 10.
To fix graphical glitches Dom0 needs to use kernel 5.18.16-1.fc32.qubes.x86_64 and create file with "sudo nano /etc/X11/xorg.conf.d/99-intel.conf" and add;
Section "OutputClass"Identifier "intel"MatchDriver "i915"Driver "intel"Option "AccelMethod" "sna"Option "TearFree" "true"Option "DRI" "3"EndSection
There will still be a graphical glitch when entering the LUKS password but everything else works fine.
To fix WiFi network you need to use kernel 5.15.64-1.fc32 on sys-net. Most of the time the network adapter works, sometimes it doesn't work on boot but restarting sys-net gets it working. Once I have had to reboot the whole computer to get it working.
--
You received this message because you are subscribed to a topic in the Google Groups "qubes-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qubes-users/01sauU58TsI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qubes-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CANC2dUd7m1UGFw2dSge2sFMpuU2B_j6obtSEFu1ZGTPWWMnh8Q%40mail.gmail.com.
On 28 August 2022 07:42:17 Martin Holst Swende <martin...@gmail.com> wrote:
--
That's odd, since it doesn't seem to work for me.
Related question: I've been searching and haven't found -- where
can I check the most recent packages on the various channels
(stable / unstable / testing / experimental etc) . Would be nice
to be able to check what different kernels are available via what
channels.
Cheers ,
Update on this.
I was able to update sys-net to use 5.15.64-1.fc32, and can
confirm that it fixed the wifi issues.
I also updated the dom0, to 5.19.9-1.fc32. However, that didn't
go as well, and the system now crashes on boot -- sometimes I get
to enter the LUKS password, sometimes it crashes before that.
If I do module_blacklist=i915, then I can bypass the crash and
enter the system.
/Martin
I installed an early version: 5.19.14-1 (see
https://github.com/QubesOS/qubes-linux-kernel/pull/649#issuecomment-1268337609).
Unfortunately, it didn't solve the issue -- crash at luks screen.
However, I did manage to snap a picture of the crash this time.
See attached.