QubesOS freeze, crash and reboots

[Sven]

my guess is it’s Qubes or Xen related

… and related to function(s) most exercised when doing updates via salt.

most probably related to gui

I see no evidence of that

sys-gui

I’m not using it

[enmus]

@Sven

most probably related to gui

I see no evidence of that

https://forum.qubes-os.org/search?q=glitches%20order%3Alatest

[0x9060]

This is also happening to me randomly and is incredibly frustrating. My ThinkPad P51 never crashed with Qubes 4.0, and now frequently crashed with 4.1.

Crashes happen often randomly, and seem to be sometimes triggered by certain activity (e.g., copy/pasting an address from one Firefox browser to another browser window in the same dispoable VM).

One that that CONSISTENTLY causes a crash/reboot is by using the “Qubes Backup Restore - Test restore to verify backup integrity” feature. I can NEVER successfully verify that I’ve correctly created a backup, because this process ALWAYS causes my laptop to crash. This is especially concerning, because now I have no way to verify backup integrity, so if feels as though I have no type of disaster recovery mechanism.

[Sven]

I can NEVER successfully verify that I’ve correctly created a backup,
because this process ALWAYS causes my laptop to crash.

Did you check your logs? This actually sounds like a temperature related
issue (CPU load can get quite high and persistent during this
operation). If so, your log would tell you.

[0x9060]

To help me better understand the issue, does Qubes 4.1 run hotter than 4.0? This never happened to me with 4.0. Or is it that the temperature measurement is more accurate using 4.1?

Also, how can I check the logs after such a crash?

[Sven]

I am sure there is a more elegant way, but here is my pedestrian approach:

• immediately after rebooting open dom0 terminal and run sudo journalctl
• press the End button on your keyboard
• use the Page Up button on your keyboard to scroll up while keeping an eye on the date/time code … you’ll find a jump in time and a message that your system rebooted
• look at the lines before that. If you see some lines about ‘temperature critical’ then there you have it

[ephile]

@Sven

I am sure there is a more elegant way, but here is my pedestrian approach:

• immediately after rebooting open dom0 terminal and run sudo journalctl
• press the End button on your keyboard

journalctl -r will reverse the order of the log entries so that you only have to scroll down a few lines to find the critical entries

[tanky0u]

@unman

This is a huge backwards step for me - I’m now working on the basis that
my machine may go down at any time.

I share the same feeling with my X220 Qubes setup.

@Sven

For me this happens exclusively during salt-based updates.

This has been my casual observation, as well.

So, what is there to do? Do we, as QubesOS users, have some fix to look forward to with this bothersome situation?

[Sven]

journalctl -r will reverse the order of the log entries so that you
only have to scroll down a few lines to find the critical entries

Thank you!

[Sven]

So, what is there to do? Do we, as QubesOS users, have some fix to look
forward to with this bothersome situation?

I ran a poll a while ago that gave me the impression that this issue is
not seen by the majority of users. From this thread here I get the
impression it mostly concerns users of older hardware.

My T430 is not purchased from Nitrokey but matches the top configuration
you can get from them … it is therefor identical to a certified
laptop. I wonder if the team sees the same issue when testing Qubes OS
on their certified laptop?

[ephile]

@Sven

I ran a poll a while ago that gave me the impression that this issue is
not seen by the majority of users. From this thread here I get the
impression it mostly concerns users of older hardware.

Both my T430s and my 7th Gen Carbon X1 have crashed randomly a few times since installing 4.1,

[whitedust]

same here

Random system freezes after 4.1 clean install

I can’t find a topic close to my issue. I have upgraded from 4.0 to 4.1 by clean install. at random times specially when i am alt + tabbing between windows, the whole system freezes. I cannot do anything except move my mouse cursor. mouse clicks do not look like it works. What is the best way to get logs to see what happened? i tried “journalctl -p 3 -x -b -2” but i don’t know what I’m looking for here

Are you all experiencing the issue when you guys are using ALT + TAB?
I notice its more common while I’m doing this inside a fedora VM

I have cycled through the available kernel version but all of them get the same freeze issue.

[Isolator]

Ok, so just now my Qubes system froze and then rebooted on dom0 update while I was doing some tasks in the other qubes. It never crashed on me on updates before, I don’t like this development, because it already takes ages to update, especially dom0, it literally can take more than an hour, and in qubes update tool you don’t even get any feedback…

anyway, I’m running qubes on AsRock H370M motherboard with Intel i5-8500
right after I switched to 4.1 I had graphical glitches with mouse cursor not rendering properly, especially at the borders of windows
I solved this by creating a file in /etc/X11/xorg.conf.d/20-intel.conf that contains

Section “Device”
Identifier “Intel Graphics”
Driver “Intel”
EndSection

But I still get occasional glitching/not properly rendering windows that I never got in 4.0, but it is enough to just switch windows around to solve this

Anyway, right before it froze I had this visual glitch again with half of the window being black.
And this time I got something in the logs right before – Reboot –

dom0 kernel: BUG: Bad page map: 1332 messages suppressed
dom0 kernel: BUG: Bad page map in process Xorg pte:8000000787137365 pmd:10e039067

– Reboot –

I’m also using kernel 5.15.64-1.fc32
I also don’t use sys-gui

[tanky0u]

@Isolator

it already takes ages to update, especially dom0, it literally can take more than an hour, and in qubes update tool you don’t even get any feedback…

Yes. I experience the same. Especially if I route the updates over the Tor network.

Regarding the logs: interesting. I hope they will provide the devs with some clue for a solution.

[enmus]

I had glitches and artifacts while never before. Even more. Some of my templates stopped working either by not booting or showing blank screen only, and temporary fix was to to reverse gui and gui-emulated values after which they worked again (!?)

[Isolator]

Ok, more logs.
Apparently this Xorg kernel bug is a recurring error
I can see these kinda entries repeating for 8-9 times already

[tanky0u]

the screenshot image is broken? I onlt see a green-ish image with no logs visible.

[Isolator]

yes, apparently it needs png images

[tanky0u]

now visible, thanks.

[0x9060]

@Sven

I ran a poll a while ago that gave me the impression that this issue is
not seen by the majority of users. From this thread here I get the
impression it mostly concerns users of older hardware.

Certified hardware

These all have a maximum of 16GB of RAM. Qubes is already a resource pig. My Thinkpad P51 has 64 GB or RAM and ran Qubes 4.0 perfectly. In fact, my laptop is provided in your list from this thread of those supporting Qubes 4.1.

Am I boxed into taking a step back in computational resources if I want hardware that is assured of running Qubes 4.1 stably?

It feels like a walled garden has quietly been constructed around Qubes OS.