There was bug in mutter, a default Gnome Shell compositor for Wayland. There was a bug fixed in v3.38.4 fixed via !1784 that made Gnome Shell crash certain click event (like every ~5 minutes of usage or so).

When I have found out I cannot use my system like this anymore, I basically had these options until fix was released:

  1. Use the proposed workaround
  2. Downgrade mutter and related packages
  3. Restoring a snapshot
  4. Switch to different desktop environment

Let's break down all the steps to smaller pieces.

Using a workaround

The proposed workaround was to edit a CSS file I could not immediately find in my system. If I dug deep enough, I could probably make it work. The problems with workaround is their documentation.

Suppose I just did it and then forgot about it. There could be a package in the future that would interfere with it and it would be very hard to debug. The most basic solution is to at least put the file into version control.

This file was about to be located in the $HOME repository, so it would be included among the dotfiles. I have already written a post about my dotfiles management system. This would at least document the change, but I would still need to remember that the change was made and revert it back during the system upgrade. It would be possible to automate this with the system similar to informant, utilizing pacman hooks to prevent an action (a system upgrade) unless other action (remove the workaround) was performed.

Downgrading is usually easy, for instance in Arch Linux, there is a downgrader-git AUR package for this purpose. Things like a window manager and a compositor library, which mutter is are usually more tightly coupled to the system and require precise version matching. I somehow did not test this, but downgrading could certainly work here well.

Using a snapshot

Snapshotting is a technique where all files are "frozen" in time and can be collectively recalled, should the demand arise. It is worth creating a snapshot before a system upgrade. If there are packages that contain bugs, restoring the system to that snapshot make the system stable again. A time machine of sorts. After the snapshot, all system packages can be upgraded again, with the exception of the buggy package.

I do a rsync snapshot of my system weekly to the Raspberry Pi. It is a cron job that makes rsync snapshot to all my systems. Unfortunately, or rather fortunately, I was not forced to use a restore yet. I should also consider to set up a local snapshotting mechanism. But, everything is better than nothing.

Switching to a different package

The last solution I came up with is switching to a different software package altogether. It is usually not the best option, as there are no identical software packages with a different name - otherwise what would be the point. This means the feature sets of two distinct packages is different, even when task they perform is identical.

Due to open-source nature of a Linux on a desktop, there is a huge pile of desktop environments. The phenomenon is called fragmentation. Getting into advantages and disadvantages of this outcome could fill an entire book, so I have left that discussion out for now. Focusing on the positive side, I could choose a different package (or a package group to be more precise) and get similar output.

This is what I did. I have installed XFCE alongside Gnome Shell. It requires more packages to be present on the system, so the updates are also larger. I have been using XFCE on my previous laptops, for instance on ThinkPad T400, which I still keep, despite it's age (it is hard to destroy). As a side note, it is worth to have two working desktop environments set up and their configuration dotfiles version controlled. If there is another bug of a similar nature, it should not be hard to fall back on it.

This is a 17th post of #100daystooffload.