That should be my question. it’s absolutely OK to be frustrated. Who isn’t?
Do you use suspend regularly?
Never.
Did you try my setup?
Which setup is that?
Read my posts all the way above. Try, don’t think and have an opinion at the moment.
Would you be prepared to test this?
Can you identify a time when you were able to work without crashes?
Do you have the testing repositories enabled?
We should be able to identify packages that seemed to work, roll back to
them, and confirm that at that point all was good.
Will you help with this?
Also, and this is important, it isn’t true that every one experiences
this. Some people do - anecdotally, it’s more common in older hardware,
but it’s not all old hardware, and not even all users with the same
model, and it’s not restricted to there.
There are so many usage patterns in Qubes that it is very difficult to
find these common patterns which will allow full analysis.
1 Like
I’m taking the freedom to answer even though I wasn’t asked.
I am prepared to test whatever you @unman or some other core team member deems worth testing in this regard. I have two identical T430. One for my actual work, the other for testing/backup/standby.
For me unfortunately that is back in R4.0 before the kernel changed to 5.x … this was never stable for me. Actually it was quite horrible with several freezes per day.
I filed issue #6227 and @ludovic recommend I go back to the 4.19 kernel, which I did and it made things stable until I upgraded to R4.1.
One thing has become clear: it must have something to do with starting qubes. Whenever I saw the freeze I was doing one of these three things:
- qvm-backup-restore --verify-only (only on R4.0 with 5.x kernel)
- update all qubes via salt (only on R4.1)
- start another qube when the PC is already very busy – high CPU load (both R4.0 with 5.x kernel & R4.1)
No
1 Like
I agree that these three things are triggers for the crashing, however I’m not certain that it is the starting of VMs that is the issue because copying between VMs is something else that triggers it on my system.
I’m willing to help test, I don’t have the testing repositories enabled currently. For me the crashing that we are discussing in this thread does not occur in the base 4.1.0 iso without any updates applied.
That corresponds with symptoms observred by me. I was nearly to gave up using QubesOS since being up to date on 4.1, it was happening even few times a day.
I am experiencing nearly no freezes since updated dom0 to kernel-latest 5.18.16.
Can somebody explain to me these instructions for setting the kernel version?
My system is using UEFI, however this file does not seem to exist
/boot/efi/EFI/qubes/xen.cfg
I didn’t think GRUB and UEFI were mutually exclusive however the instructions read as if I should apply one or the other.
I’ve just had a small diagnosis breakthrough.
My workflow involves me doing lots of copying between qubes often of files 50+gb in size. Back when this first started happening the logs would always report the crashes as being due to overheating. However in playing around trying to recreate the overheating, I’ve gotten many crashes without any overheat log and with the temperature sensors visible I can see that the system was not overheating.
I’ll keep playing around, but it might be the case that I can now recreate these crashes on demand. Has anyone else encountered crashing doing large transfers between VMs?
1 Like
Thank you Sven.
I’m trying to pull together some sort of summary of user reports.
2 Likes
Some of the symptoms in this thread sound similar to the issues I have been experiencing over in Crash on dom0 kernel 5.15.57 - in case it helps with the summarisation. The crashy behavior occurs on 5.18, 19, and 20 (aka 6) (but not on 5.15 after .64) usually after suspend resume.
Thanks for the pointer.
Unfortunately, commonality of symptoms can mask different root causes.
unproductive, snarky remark
Well, good luck with that.
off-topic reaction to @Sven's unnecessary remark
This is wrong in so many ways…
After some testing, I can confirm it is your nick 
duplicate
forum logistics
Just in case three times isn’t enough, 