“So, I wonder if using Awesome or DWM wouldn’t require that “fix” and thus would result in no-freezes.”
I don’t have issues with AwesomeWM so far.
Btw it was the first tiling WM to be supported in 3.2. I’m unsure about it’s future though as it will never support Wayland. It might work with XWayland, let’s see…
Hey that’s cool to hear. I will be trying AwesomeWM soon.
Yes, but I’d certainly rather that than lose the ability to manage windows because of an infuriating crash bug.
I’ve been off Qubes for a bit over a month now, how is everything looking?
@sven @enmus @unman has the situation changed at all or still intermittent crashing?
With me absolutely stable. But as I wrote, in all these months I had only very few crashes and freezes in a several days in a row, and one freeze a month ago.
Still the same here. In normal operations it’s pretty stable (two “unprovoked” freezes in total). However, updating is another story entirely. If there are actual updates (not dom0 but template) a freeze is almost guaranteed.
Sad to say, nothing seems to have changed for me.
Still freezing , random qubes crash, and occasional Qubes restart.
The freeze/Qubes restart, almost always linked to qubes starting, (and
so definitely can be triggered by updating, or other salting.)
Are you aware of any progress that’s being made behind the scenes, or is this not a priority at the moment? Seems like you’ve identified the trigger which is a good step forward.
I had a total system freeze last night. I had left the machine running idle during the night. I was runnig awesomewm on it. And now, in the morning, I cannot wake it up from the i3lock—the OS is completely unresponsive to my keypresses. So, I think these freezes are independent of the type of window manager we are running.
What is this fb you are talking about?
for the record, this freeze has happened on a machine with the “intel fix” that many people (I included) do for fixing the visual glitches with i3wm. I had applied that “fix” for working with i3wm, and I then switched on the same setup to awesomewm. I might try next doing a clean install of qubesos and use awesomewm without the “intel fix” that using i3wm necessitates, and see if this type of freeze still occurs.
Nothing has changed for me. I’m on a Dell T5500 (original hardware with an SSD harddrive). I did no tweaks or any other deviation from the original install other then permissive mode for my Realtech PCI Ethernet controller.
I tried qubes 4.1.1 as well as 4.0.4 both gave the same results which are crashes, after something like 20 min of run-time. The crashes occur independent from the update manager and independent from the systems idle-level. They also occur directly after a fresh install…
In this state, the system is unusable
It may be that i3m introduces specific issues that lead to these
issues, or it may be that there is an underlying issue that does, and
i3m/awesome is a red herring.
If you do a clean install can you not install awesome to start with,
and see if you have those same issues?
If you then install awesomewm and the issues begin, we would have a clear
point from which we can start.
That would be very helpful.
Sorry to hear this.
Thanks for the diligent testing.
Had you updated the 4.0.4 install before getting the crashes, or did this
happen on a clean install with no updates?
In my case, and based on reports I have received, the issues began on 4.1
after updates on certified hardware.
It happened after a clean install of 4.0.4 before any updates. I especially installed 4.0.4, after 4.1.1 became unusable, couse I though it does not happen there. The only thing I did was activate permissive mode on net-vm, because no ethernet otherwise. Then opened a few qubes and did some “heavy work” by running youtube on them… I can install 3.2.1 too if you think that would make sense.
From my understanding running 4.04. will not upgrade automatically to a higher version, even on updating dom0. Is that correct?
I did a clear reinstall of QubesOS 4.1.1 as it is, without installing i3wm and without doing the intel fix. I had the total system freeze happen on me just now. Couldn’t wake the OS from xflock4 after ~1 hour of idling.
This is really annoying as I was using QubesOS latest version (with the latest updates) and as it is presented to the users, in vanilla mint condition. AND it still got frozen totally.
The last journalctl entry before I had to do a hard reboot (that is, pressing down the power button long enough so that power supply to the computer is killed) is a dom0 entry saying /etc/cron.hourly finished 0anacron.
This I observe over and over again. Seems like the last entry in the dom0 journal is most of the time anacron related, before the OS goes through a total system freeze.
… so no changes AT ALL in dom0? Nothing installed?
Please check the contents of your /etc/anacrontab. Does it look like this?
# /etc/anacrontab: configuration file for anacron
# See anacron(8) and anacrontab(5) for details.
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22
#period in days delay in minutes job-identifier command
1 5 cron.daily nice run-parts /etc/cron.daily
7 25 cron.weekly nice run-parts /etc/cron.weekly
@monthly 45 cron.monthly nice run-parts /etc/cron.monthly
Please run these commands:
ls -la /etc/cron.daily/
ls -la /etc/cron.weekly/
ls -la /etc/cron.monthly/
The daily should contain:
lvm-cleanupqubes-dom0-updates.cronand nothing else. The weekly and monthly should be empty.
… just checking on the “vanilla mint condition” 
Nothing installed. Apart from the system/xen updates that comes from QubesOS itself.
Here’s mine:
# /etc/anacrontab: configuration file for anacron
# See anacron(8) and anacrontab(5) for details.
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22
#period in days delay in minutes job-identifier command
1 5 cron.daily nice run-parts /etc/cron.daily
7 25 cron.weekly nice run-parts /etc/cron.weekly
@monthly 45 cron.monthly nice run-parts /etc/cron.monthly
Output of ls -la /etc/cron.daily/ :
total 16
drwxr-xr-x 2 root root 4096 Dec 12 00:16 .
drwxr-xr-x 102 root root 4096 Dec 12 12:35 ..
-rwxr-xr-x 1 root root 77 Jun 17 03:00 lvm-cleanup
-rwxr-xr-x 1 root root 351 Jun 17 03:00 qubes-dom0-updates.cron
Output of ls -la /etc/cron.weekly :
total 8
drwxr-xr-x 2 root root 4096 Jan 28 2020 .
drwxr-xr-x 102 root root 4096 Dec 12 12:35 ..
Output of ls -la /etc/cron.monthly :
total 8
drwxr-xr-x 2 root root 4096 Jan 28 2020 .
drwxr-xr-x 102 root root 4096 Dec 12 12:35 ..
Basically as they are expected.