KDE settings issues after stable updates

Did the update today.

KDE settings got borked, as has happened with every “stable” update since I installed in summer of 2019.

This time it was only panel customizations. Historically, it has been panels, custom keybindings, display resolutions and magnifications, etc.

I understand user-customization settings are stored somewhere in $HOME. Please stop writing to $HOME without my permission.

Maybe you could describe the issue?
Your ‘settings being borked’ doesnt mean Manjaro messed with your HOME.
For all we know it means you are using a dated and broken theme … which becomes pronounced as plasma updates itself.
But again we dont know because there isnt any information here.
In order to find a solution (or cause) then you will need to provide some sort of description and output etc.

For example … what does this mean ?

Also might as well leave this here:
[HowTo] Provide System Information



Have you reported it before?

Packages don’t install files to $HOME when updating. However, there are settings copied from /etc/skel/ when a new user is created.

Manjaro Log Helper (inxi and install log. Unsure what else might help.)

Yes, I have previously reported on other updates that display settings, panel arrangements, custom keybindings, and other personal settings had been altered. No further comments about it came. Following updates have slowly reduced the amount of reverted customization happening.

This update (2020-11-22), LightDM theme customizations were lost, LightDM display resolution and magnification settings were lost, KDE panel widget arrangement had changed, some custom keybindings and one KDE default keybinding was lost, custom locale settings were lost. It normally requires several days of system use to discover all the changes to my customizations that happen on each update, so it’s likely that more changes happened and I haven’t found them yet. All of my KDE settings are made via the KDE or Manjaro GUI configuration tools. I do not directly edit the config files of KDE or associated software.


LightDM theme stayed, but wallpaper reverted to theme-default, and display resolution and magnification were reset to conform to screen defaults.

Once logged in, my session display (resolution and magnification) custom settings were restored (in the past, they have not been) but LightDM had to be re-customized to a larger more readable state.

KDE session panel locations and sizes remained, but widget arrangement was altered. Theme was remembered, including icon and mouse cursor selections. One panel widget (the menu) had a custom keybinding, which was lost.

KRunner lost its global (not customized) keybinding.

Custom locale settings were lost; except terminal apps which received their settings from variables explicitly set in $HOME/.bash_env (which is called from .bashrc) (Yes, I know, I should move them to .bash_profile or .pam_environment.)

Yes, some of this was not reported originally. I have since rebooted because a kernel update (I’m on 5.9) came down and I wanted to ensure I didn’t get any weirdness from continuing to run on the un-updated version. That is when locale and LightDM changes had happened. As previously mentioned, it often takes days to find all the customization reversions that come with each update.

Did you ever looked at your .pacnew files? Just a guess here to try to go forward.

What’s a .pacnew?

run pacdiff -o

I think this specific part of Manjaro should be explained and put forward in front of users eyes somehow because this is something I notice more and more, most of users don’t know that.

This does happen and IMHO it’s expected to, over time. Some of my configs are (or were) from 3 or so years ago. Needed to change the theme last major update to fix things like blank tooltips etc…

pacdiff -o output:


I have looked into a couple of the files but I don’t know what I should be looking for so it’s not very helpful to me.

It may be possible that part of your issues are because you do not do a proper maintenance job of your Manjaro installation.

All these .pacnew files are created when a default config file got updated, to not overwrite your configuration files. example if you have a file /etc/myconfigblabla then it gets updated in the repositories, instead of overwriting your file /etc/myconfigblabla it will create a new file /etc/myconfigblabla.pacnew for you to be able to merge, or not, the new changes in the configuration file.



So the idea is that these files need to be merged, partially or fully, or not at all, with your own configuration file.

It is not automatic, often you do NOT want to apply the difference to your config file, a perfect example is the /etc/shadow.pacnew file, YOU ABSOLUTELY DO NOT WANT TO MERGE THIS ONE, or else all you user and system accounts are dead, all dead. This one you delete right now sudo rm /etc/shadow.pacnew or leave it but remember you do not modify you real config file /etc/shadow don’t touch it.

Look in the wiki articles, they explain the process.

Personally I installed and use meld for the DIFFPROG= value to use with the tool pacdiff (I don’t like the terminal compare tool, always clearer as graphical interface), even if not recommended to use a graphical tool as sudo, I still did it for this tool (actually I now use a more advanced script than simply running meld with sudo, found here, but most of people who don’t care just do a sudo DIFFPROG=meld pacdiff).

I recommend to do a snapshot with Timeshift before working on your .pacnew file, in case you mess your system, you could always restore config files to their previous state manually, or better, restore the snapshot, with the live USB

1 Like

a bit nifty … but also clunky - for example it doesnt do anything with the pacnews.
You can run it and merge changes … then run it again and all of the same pacnews are still there.

I actually run my own modification lol this is a part of a ‘big script’ I use to manage multiple thing on my computer, here is the part

        echo; echo; echo ".pacnew files found: $(/usr/bin/pacdiff --output | wc -l)"
        echo; /usr/bin/pacdiff --output; echo
        set -euo pipefail
        export PATH=/usr/bin:/usr/sbin
        for i in $(/usr/bin/pacdiff --output); do
          echo "Merging $i ..."
          /usr/bin/meld "admin://$i" "admin://${i/.pacnew/}"
          echo; echo
          read -p "Delete the .pacnew file $i? " -n 1 -r
          if [[ $REPLY =~ ^[YyOo]$ ]]
              echo; sudo rm -v $i

So mine actually does something :stuck_out_tongue:


Hm. Something more like that might even be a candidate for pacman hooks :thinking:

I think something need to be added to pacman yeah, currently only “tech-savvy” people look at .pacnew files and even some don’t know about it. Most of the ‘basic’ users will probably never hear about .pacnew files and will blame Manjaro if it breaks at some point and distro hop :rofl: or reinstall.

At least, I think it would be safe to add the .pacnew counting part, with a warning when .pacnew files are found. At least people would maybe ask themselves “what is pacnew” and would maybe then look after these files and maintain the system.
Also having a .pacnew warning in Pamac would be cool. But all that is another topic :slight_smile:

1 Like

Agreed. How many even know of this command: pacdiff -o :wink:

Just as a datapoint… i learned about it about 5-6 months after starting out. So yes… it took a while for me to take notice that this exists.

1 Like

I admit that this is a possibility, especially given that I just learned about pacnew and what it is. It’s possible that one of these pacnew files contains a correction to config-file read/apply priority.

However, these are only for system config settings. My user settings should be saved in one or more of the many . directories in my home dir (.config and .local leap to mind), and should be read from there – if exists – before applying global defaults.

So, while useful, it doesn’t directly address my problem that user customization is being changed on updates.

I have not yet done today’s Stable update, and probably will not for a few days so the more common fixes can be applied. I appear to be an edge-case, so I’d like this thread to remain alive. I will definitely report the my user session state after applying the update, though.

I tend to do the same. There have been cases where offered updates disappear after a day or so, presumably for this reason. Then, after testing on this machine, I’ll apply the updates to my mate’s.

As a new user of Linux in a desktop environment (I’ve been working with Linux and Unix/Unix-likes for decades, but only in niche applications in air-gaped embedded systems) I didn’t know about .pacnew until I read this thread.

Since most new users will be updating via GUI pamac I agree that something minor that draws a users attention to their existence could go a long way for new user accessibility. But I also think this could be improved with how the documentation is organized, as I never stumbled upon the maintenance page until it was linked here either. Maybe that’s just me because for some reason wiki organization has always felt “off” to me, never was my favorite medium.