Cannot boot into DE (Gnome) after latest update replaced mutter-x11-scaling with mutter

Over the past week (around 10th November), there was a significant system update, mainly around GNOME 41. The update was stopped since mutter was going to replace mutter-x11-scaling, which I use since I have a 1440p and a 4K display. I knew that if I allowed this update I’d have to go back to not being able to use my 4K display at 150% scaling, which was fine by me, while I wait for mutter-x11-scaling to update to v41 as well. However, after this update it seems my DE has gotten borked. The login screen doesn’t even show up, instead my displays go to sleep. I have to press CTRL+ALT+F3 to get to the terminal mode, which works fine and also gives me the expected access to run programs and the files.

I tried reinstalling mutter-x11-scaling 40.5, but due to dependencies of other packages on mutter 41 it didn’t work.
I tried resetting the dconf but that didn’t work either.

Anyone has any suggestions? The mutter-x11-scaling git has updated to 41, but the AUR package is still on the older version.

I also tried installing plasma, but no luck there either, the login screen itself doesn’t load at all.

Lessons learnt

  1. Take snapshots before any major updates.
  2. Shouldn’t have updated and just waited for mutter-x11-scaling to update.

Edit: system hardware in case it matters
AMD Ryzen 5600X
ASUS X570 TUF GAMING
NVIDIA RTX 3080 FE
EndeavourOS is on 1TB Gen3 NVME (SK Hynix P31)

AUR is the source for it and bot are marked out of date:

  1. https://aur.archlinux.org/packages/mutter-x11-scaling/
  2. https://aur.archlinux.org/packages/gnome-control-center-x11-scaling/
aur/mutter-x11-scaling 40.5-1 (+1 0.10) (Out-of-date: 2021-11-10) 
    A window manager for GNOME (with X11 fractional scaling patch)
[build@buildsystem ~]$ yay -Ss gnome-control-center-x11-scaling
aur/gnome-control-center-x11-scaling 40.0-1 (+1 0.93) (Out-of-date: 2021-11-10) 
    GNOME's main interface to configure various aspects of the desktop (with X11 fractional scaling patches)

And almighty @jonathon is maintainer of them :rocketa_purple:

1 Like

Yup, I was wondering if there’s anything else I could do to get it working till it gets updated. I also realised I didn’t add my hardware to the OP in case it matters, doing so now.

You can update the PKGBUILD locally and test it.

… I guess I should have a look at them. :kissing:

Edit: patches don’t apply on 41.1. Needs more work.

1 Like

I’m not proficient enough to do this right now… maybe in the medium term as I become a better developer :sweat_smile: .

Understood. Thanks for your efforts! Will wait patiently. :grinning:

Does anyone else have any suggestions for things I could try here? Or would starting afresh be the best solution? I do have a spare SSD for set up, that way I can easily move my files and config over. Thinking of trying KDE this time around.

1 Like

With a spare SSD that is certainly the easiest and fastest option to get a working PC, especially if you go for KDE instead of GNOME. :wink:

Though, if you have the patience and time, this is a good learning opportunity, if you follow @jonathon’s instructions. However, in the end, you’ll still be on GNOME…

1 Like

There are a number of ways to ‘back up’ to a working 4.0 configuration without a reinstall, if you want - and then you could wait for 4.1 to be feature-complete before allowing it to update.

One of the easiest is a ‘date-based’ return to the state before the upgrade happened (see the EnOS wiki for a couple of ways to implement that - including eos-shifttime) and then the 4.1 parts could be listed in /etc/pacman.conf under IgnorePkg until the missing piece has been made ready.

This also will leave you on Gnome, just 4.0! :grin:

As always, your machine so your choice…

1 Like

I’ve updated the packages but I don’t know how well they will work; there are no patches in the Debian source repo for 41 so I’m using those from Georg Wagner’s (puxplayer) repo (not sure why he didn’t publish on the AUR, I think I did mention it but he wasn’t interested…).

3 Likes

Didn’t work, I tried installing mutter-x11-scaling, ran into this error. In an unrelated matter, all the other updates that popped up when I ran yay completed successfully, there were a lot of them! :sweat_smile:

I imagine these back up mechanisms should’ve been in place before I ran the update? Will keep in mind for the future… I just read the timeshift article, and it’s something I’m definitely going to set up and maintain going forward!

Try again now.

Yup, it passed that stage, but now it failed in the check() stage. The first 52 (or 55) tests passed, but the remaining tests failed, for the same reason. It could not find a config file, .config/monitors.xml, because of that the installation didn’t complete. I’ll record a video of it to get the exact error message and screenshot.

Is this issue related to the xorg updates that came through 10. November?

You might want to try to downgrade xorg and see if it helps you. I had to downgrade to fix an issue with darktable.

See this issue with instruction show to downgrade xorg:

So I decided to try uninstalling GNOME and installing KDE, which worked! The login screen showed up as expected and I was able to login. :smiley:
I didn’t spend any more time, the UI is quite different, and I have to do the setup over again really for KDE, so if I’m switching to KDE, I’d rather just start fresh with a new install on the spare drive I have.

Anyway, I then tried reinstalling GNOME, and this time I still get the login screen thankfully, I’m assuming because it’s KDE’s login screen. I tried GNOME Wayland, GNOME Xorg, and just the GNOME option, but for all three of them I get no display, my monitors go off to sleep.

So in the update I posted after your comment, I get a blank screen for GNOME Wayland as well. In any case, I’ll try downgrading xorg and seeing if it makes a difference.

They are for situations where nothing is pre-existing for handling update problems. Arch provides an archive of the state of all repo packages on a date basis, which allows you to return to a date previous to the problematic one. As I mentioned, check the EndeavourOS wiki for details.

IF you are using btrfs, then Timeshift is a viable option, but there are others - snapper in particular. If you are not, then other methods need to be considfered. Timeshift tries to work with rsync, but I found it pretty much useless in practice when not on btrfs…

Also, on a ‘per package’ basis, the downgrade program can revert to earlier versions (and optionally mark them in IgnorePkg) as well, so recovery from an update driven problem is well covered on Arch based systems. Of course, there is a completely manual way to downgrade as well, if masochism has any attractions! :grin:

@jonathon Complete shell log of the failed install here - https://pastebin.com/BxsjsNGJ
Let me know if you need any more information.

You’re getting this test failure because you’re not building in a clean chroot, and so it’s being affected by files in your home directory.

I seem to remember that the test will fail because you have set a fractional scaling value in the monitors.xml file, so to move forwards you can 1) move the file 2) build in a chroot 3) skip tests.

1 Like

Thanks a ton! It’s finally working just like before. :grinning_face_with_smiling_eyes:

1 Like