Approximately 13 updates this morning. No issues installing on two systems. One NVIDIA/Integrated and the other integrated only. No video or kernel updates, but one was a Cinnamon update. I assume that was the culprit. I needed to reboot one of the systems, and on reboot display settings were shot. No dual monitors, no taskbar items, no background and no ability to change anything in display settings to read since it was going to default UHD resolution. Getting a bus error when trying to change anything. I wouldn’t have known without the reboot, so I rebooted the integrated only display machine and had similar issues of no background or taskbar. Second monitor was mirrored instead of extended, etc. At least this one the default resolution was readable. Both machines are almost unusable right now. If you need to get work done, get it done before rebooting I guess. Waiting around for updates while I work in Windows only I guess. Any advice would be great.
There is always the option to return to the pervious state before updates. Here is one way to do that…
Just set up the script, it will shjow you a calendar for choosing the date to return to, and return all packages to the state of that day. Do not re-upgrade until you hear what happened, and that it is fixed!
Or - better yet, try to figure out from the list of ‘pending updates’ (try checkupdatesext in the terminal for a list) what it might have been, then add it to the pacman ignore list, and have the rest of the updates as normal.
Edit: - There is a post here that suggests it might be cinnamon-settings-daemon that causes the problem… perhaps you could try to downgrade just the one package if so. (terminal downgrade and package name)
I just saw that post about the daemon. I’ll take a look shortly. Need to do some work first.
Not sure if it’s the same issue that has been happening on Cinnamon and also i had it happen on my Xfce machine with Nvidia. It ends up running in modesetting and is not using the graphics card. You can tell if you look at your hardware via inxi -Fxxxz --no-host and also inxi -Ga. It will show if it’s rendering using the graphics card and also if nvidia failed to load.
You have a different setup with multiple displays. It’s possible it’s another issue but you can easily check with these the hardware commands.
I just want to say that this approach is exceptionally dangerous if you don’t have a high degree of understanding of how all those packages are inter-related. This is going to put you in a “partial update” situation.
I would especially wary of doing this with parts of DE. The results of doing so could very easily be a completely broken system.
To be clear, rolling back your entire system to a prior point in time should be OK. Moving some of it forward while holding other parts back is quite dangerous.
Rick, I have already made these changes. The issue this morning happened on a non-NVIDIA machine (Intel integrated only) as well, so I am pretty sure this is not related.
What method are you referring to for rolling back the entire system to a prior point?
I wasn’t actually referring to a specific method. I think any methods that works is fine as long as you keep your packages in sync with each other.
I think he is referring to my little script to go back with using the Arch archive. He objects to upgrading from there with ‘ignore’ on because of the potential for troubles. Going back to a previous ‘co-ordinated’ condition is safe enough - and you can put off updates until a fix is in…
There is another user reporting issues with
I suggested downgrading but now reading your post I am having second thoughts.
(I had myself my DE broken after this update, downgrading and holding back the package has temporarily “resolved” the issue)
To be clear, I have no idea what the implications of downgrading that particular package are. In this case, there may not be an issue.
My point was, more broadly, be careful when you do this as it can cause major issues. I can’t tell you how much time I have spent helping people trying to recover their systems from partial update scenarios.
I do think holding back the package with ignorepkg is more dangerous as if you forget about it the chance of it breaking something in the future is quite large.
For the moment downgrading doesn’t seem to be causing any issues. By the looks of it this seems to be an upstream issue. A buggy update? Anyways, I have added the package to be ignored (IgnorePkg) for now. I will surely need to keep an eye on this to see how it will play out.
Sorry I wasn’t so clear when I wrote
I just downgraded the cinnamon-settings-daemon to 4.8.3-1 on my non-prod machine and added it to ignore. Rebooted, and everything restored (and for now everything is running fine). About to try my real machine where I will notice any issues sooner.
I had to reactivate my monitors and arrange them, etc. In display. That took seconds, and it worked fine including another round of pacman -Syu and a reboot.
New update to 4.8.4-2 has fixed the issue.
At least you know how to get around these little glitches now!
Until the next one, LOL! Funny, until 5.10.3 I didn’t worry much about a catastrophic system break. Now, it seams like a daily worry. Makes me want to spend more time in Windows or an Ubuntu derivative. Not!
This is the first time ever that i have seen Cinnamon with an issue.
TL;DR but I assume you are talking kernel version? Because I have two threads I posted in the last three days all boiling down to kernel problems. I am now, for the first time since I started with Arch in 2018, on the LTS kernel because 1) I got a bug with the welcome app, 2) got kernel dumps caused by a crashing Xorg with the latest NVIDIA drivers and 3) (not posted about) general instability all caused by the latest kernel (I am usually on Zen, but tried the vanilla kernel as well, same issues).