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.
Take snapshots before any major updates.
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)
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.
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.
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…).
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!
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.
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.
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.
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!