I cannot seem to find the means by which I can Roll Back my set-up (KDE).
I accepted some changes, which has created problems; I wish to undo them,
and most guides relate to Default install, which (previously) leads to loosing
All/Most, of my settings; That is why Roll Back would be the Resolution?
David.
When you want to be able to restore a former configuration, first backup before you start to meddle. For KDE that would mean making a copy of ~/.kde4/ and maybe also ~/.local
Or, make mental or written notes on what you change, so you can change back.
Or both, to be sure.
Or restore those files from your normal backup . I do not know what your backup frequency is, but even with weekly backups you can fall back to a maximum of one week ago and the frequency of changing the desktop configurations isn’t mostly that high.
If a default install was done with 13.2 then the file systems are BTRFS on root and XFS on home (where your KDE setting live). Root is set to use snapper which you can roll back but to my knowledge xfs can not. you must use your backups. You do have backups right??? In any case renaming or removing your /home/usernamehere/.kde4/share/config directory will bring you back to default. Note that you cna not do this while logged in and running KDE as your user since those files are in use. I boot to terminal log in rename the diectory and then reboot to the default desktop settings
It would appear that I am far from being alone in this respect.
What happens is that you do an Install, agree to changes, your system ‘breaks’, and you wish to revert.
So, if you can remember the change that you agreed to, how can you UNDO it, without leaving a corrupted Desktop,
i.e., One that existed, prior to the change?
Where should I search, in order to locate the Files etc., to, say, delete, in order to return to ‘normality’.
David.
I do not see your question as differenty from earlier. Thus the answer is the same: from any backup/copy you made, preferable just before the change.
And inside ~/.kde4 you can look for specific files used by specific parts/applications in ~/.kde4/share, specialy the apps and config directories there. You may try to edit individual files there (but, please first make a copy!) ro repair.
I can appreciate your frustration, so let me ask the question from a different perspective.
If you Download and Install some Software (Media Player), for which I had to accept some changes;
Why then, if it is Deleted, am I left with the altered state, rather than the system reverting to the Pre-Installed State.
Shouldn’t THAT be the accepted Norm?
David.
Which changes? It is unknown if some configuration change was done on behalf of a package intallation or because the system administrator simply wanted it for other reasons only known to him.
Why I admit that what you want might be achievable to a degree that goes a bit further then it does now, there is no fixed way to do this for every program and program combination (and you now have examples from system data as well as from the user data and you should maybe add all user data, like a changed document), except maybe by using a file system like btrfs and then run snapper quite often. It takes space, but as far as I know, it functions.
But it is you, in your system administrator role, that decides if you want to read about snapper, and if it is what you like and if you want to implement it on your system. The default is already to have snapper (with btrfs) switched on for the root partition and many people decided to switch it off and even not to use btrfs. Others love it because it enables them e.g. to revert faulty software updates easy. You can do likewise and even extend it to your /home partition.
And for anything you think it should be the excepted norm, but is only not in Linux out of lazyness, you are welcome to start designing and programming. This is the Open Source world and when you present your project wth enough enthousiasm, people may jump up to help you.
There are two levels you must deal with SYSTEM and USER. Since Linux is multi user these two groups are separate and distinct.
When you install software you generally do it as root user and the files go to the root partition. This is a SYSTEM change since all user can see and use the installed program.
When you change the configuration this is unique to a given user and thus is a USER change and the configuration files are stored in the given users home directory.
So your question seem to span two different groups of items. For installed software and assuming you used the default BTRFS file system then there is a program called snapper which takes snap shots and can be used to roll back changes. (see man snapper or look it up on the web)
If you are concerned with user configuration changes such as KDE settings they are in your and each other users personal home directory. These are not included in the snapshots. You must therefore rely on your backups.
Note back ups are essential for proper computer maintenance. If you are not keeping backups consider what happens when your disk drive or SSD breaks, and it will. What happens to your stuff then??
I know that this horror scenario is often presented to convince people to make backups. And of course these things happen and you should be prepaired.
But in daily life as I know it, the chance that one of your user (my wife, myself) hops in and says: I have just deleted some pictures, edited a document beyond recognition, … is much more frequent. And your backup policy should cope for that also. And that is also the scope where we are talking about here: some user that managed to break some of his files.
As systems manager/administrator, it is realy a worthfull thing to sit down for a while and ask yourself: for what incidents do I want to be prepaired. Like any combination of:
- individual lost files;
- completely broken mass-storage device (partition);
- being able to restore from how long ago (an hour, a day, a week,…)
- how many instances (a daily backup kept for 7 days and a weekly backup kept for 10 weeks, …)
- storage, what when the computer burns out (backups on connected hardware), what when the house burns down, …
After you deciede that (and that includes deciding what to do not), you can go and find tools. Not needed to use the same tool for everything you need. E.g. snapper for your system disk, rsync for individual user file, dd for e.g. a sable (not running) databse partitions, etc.
And once put into place, do not forget to make a restore plan and test that.
Without a backup or running a file system that supports snapshots like BTRFS or ZFS, you won’t have a quick and easy “one click” solution to roll back all changes to your system.
But, YAST might be able to help you roll back individual packages…
If you want to know what happened to your system whenever you updated or installed a package, YAST can provide that for you.
YAST > Options > History
You can select any package that changed and “jump to” to inspect the individual package.
You can then click on “changes” (or similar), by default all history is displayed but you can modify.
You can then select a specific historical version of that package and hopefully by clicking the “roll back” button YAST will try to roll back to that package version.
HTH,
TSU
A simple approach to enabling “undo” for config changes.
Requires foresight.
So, for instance if you intend to make extensive (or unknown) changes to your KDE desktop.
If the changes were to a known config file you would always be able to make a file backup by simply copying the file before making changes, but you might not have that luxury using GUI tools which don’t necessarily tell you what file is being changed.
So, copy the <entire directory> containing all files if you don’t know which one, so for instance the following for kde…
cp -r ~/.kde* ~/backup.kde*
You’d be making a copy of the entire KDE config directory for that User.
If you wanted to “roll back” the kde config changes just delete the existing directory and rename the backup directory to the correct name with something like the following
rm -r ~/.kde* && mv ~/.backup.kde* ~/.kde*
Code above is untested and only suggested to illustrate the idea.
TSU
Yes, there is a dot (.) to much in the second command, or one mising in the first command.
backup
is not the same as
.backup
Also there might be more files that answer to the path expansion .kde* (I have three of those, not only one).
Thanks for your responses.
Most feedback related to the 13.2 release, whereas I am running 13.1, so,for me, most info. is off-field;
w.r.t. the Yast-Option-History, where does that exist, I couldn’t locate it?
Maybe, if I were to be undertaking any Major Changes, then I am sure that you comments are justified, however,
in the Real World, sometimes you just accept changes, probably not realising that you may loose certain facilities.
But surely, basic functionality Should automatically be reversed, once an install/download, has been removed.
If you accept Changes to your system when you do an Install, I still can’t comprehend why there is not the ‘option’
to Accept a Change, which REVERTS the System to the previous configuration.
As someone who does not program, I respect your observations though very often, replies do seem to hinge upon,
“that is the way it is”, which seems NOT to relate to Real World experiences.
I still do not comprehend why this function is not the Norm, and why it has not always been that way?
David.
Sorry, you’re right I had opened up a 13.2 machine.
For a 13.1 machine,
YAST > Software Management > Extras > History
From there the previous instructions have different wording but with same functionality…
- For anything listed in the History, you can “Jump to” that package
- When the package is displayed, in the bottom right you will see “Versions” - You can click on the arrow to display previous versions and if desired click on the icon to the right to “re-install” that package.
HTH,
TSU
Well it is not as easy as you think. The snapper program which is currently only available if you use BTRFS file system lets you roll back the root partition but there is a cost in disk space for all those snapshots.Also snapshots are currently only used on root unless you take the effort to set thing up on home. Remember snapshots cost space on partitions. Note also again that snapshots are NOT backup. Backup protects against most data lose situations and proper computer usage requires you make backups if you wish to to protect your data and settings.
Yeah,
I think I opened in my earlier post that this isn’t a “one click” solution to rolling back extensive changes to the system from an update,
But,
It is a way to roll back individual packages one by one that were part of an update.
Probably better than any alternative if no backup exists.
But then, if someone wants to submit a feature request I assume that it might not be an overly difficult job to script rolling back an entire update since all the ingredients (history of package changes associated with an update) exists.
TSU
Can you try to Explain, and/or, guide me through this process?
I have found that I installed Bangarang, and on the same day, the following also appear:
libexiv2-14 ver. 0.25
kdebase4-runtime ver. 14.12.3
kdebase4-runtime ver. 13.1
When I removed Bangarang 2.1, Changes remained, which took away Widgets and Sounds (notification).
For my enlightenment, what did I change, and how can it be reversed?
David.
The OP started with wanting to roll back changes he did to his KDE configuration as I understood it. Then wondered in to package roll back. A completely different thing. For a few packages it is easiest to simply go back a version in Yast.
Let me just explain the concept, as I perceived it.
Did an Install, which I believe, modified my KDE setup; Removed Install;
In order to resolve the resulting ‘problem’, it was my belief, that Rolling Back KDE, would be the resolution?
David.
Not knowing what install and how it may have changed KDE no way for us to tell. There is NO roll back for KDE settings they are personal and in your home. If using BTRFS you can roll back installs but then you can also simply uninstall it.
It is often better to full disclose the problem rather then asking for help on a solution you guessed at