[SOLVED] How to roll back package after installation/upgrade?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
How to roll back package after installation/upgrade?
Hello,
I'm running slackware-current and as such, I'm prepared at least mentally to have issues here and then after package upgrade.
Here I think (aka yes not sure at all ) that my last slackpk update/install-new/upgrade break something.
CC tools/vppapigen/gram.o
CC vppinfra/timer.lo
CC tools/vppapigen/lex.o
In file included from /home/vpp/dev/vpp/build-root/../src/vppinfra/linux/mem.c:31:0:
/home/vpp/dev/vpp/build-root/../src/vppinfra/linux/syscall.h:43:1: error: static declaration of ‘memfd_create’ follows non-static declaration
memfd_create (const char *name, unsigned int flags)
^~~~~~~~~~~~
In file included from /usr/include/bits/mman-linux.h:115:0,
from /usr/include/bits/mman.h:45,
from /usr/include/sys/mman.h:41,
from /home/vpp/dev/vpp/build-root/../src/vppinfra/linux/mem.c:22:
/usr/include/bits/mman-shared.h:46:5: note: previous declaration of ‘memfd_create’ was here
int memfd_create (const char *__name, unsigned int __flags) __THROW;
^~~~~~~~~~~~
make[4]: *** [Makefile:6787: vppinfra/linux/mem.lo] Error 1
make[4]: *** Waiting for unfinished jobs....
make[4]: Leaving directory '/home/vpp/dev/vpp/build-root/build-tool-native/tools'
make[3]: *** [Makefile:7757: all-recursive] Error 1
make[3]: Leaving directory '/home/vpp/dev/vpp/build-root/build-tool-native/tools'
make[2]: *** [Makefile:3967: all] Error 2
make[2]: Leaving directory '/home/vpp/dev/vpp/build-root/build-tool-native/tools'
make[1]: *** [Makefile:686: tools-build] Error 2
make[1]: Leaving directory '/home/vpp/dev/vpp/build-root'
make: *** [Makefile:259: /home/vpp/dev/vpp/build-root/.bootstrap.ok] Error 2
15:45 vpp@r1:~/dev/vpp ((v18.01)) $
VPP source have not been updated ( no git pull ) so I guess it's something on my system that has changed.
Code:
In file included from /usr/include/bits/mman-linux.h:115:0,
from /usr/include/bits/mman.h:45,
from /usr/include/sys/mman.h:41,
from /home/vpp/dev/vpp/build-root/../src/vppinfra/linux/mem.c:22:
/usr/include/bits/mman-shared.h:46:5: note: previous declaration of ‘memfd_create’ was here
int memfd_create (const char *__name, unsigned int __flags) __THROW;
When checking with *mman* with `slackpkg file-search` got results that it has smth to do with glibc-2.27-x86_64-1
From /var/log/packages and /var/log/removed_packages , glibc has been upgrade during my last upgrade yesterday:
Code:
17:29 root@ws1:/home/nico # ls -lastr /var/log/removed_packages/glibc* | grep 2018
12 -rw-r--r-- 1 root root 8526 Oct 21 14:49 /var/log/removed_packages/glibc-solibs-2.26-x86_64-3-upgraded-2018-02-09,20:30:20
28 -rw-r--r-- 1 root root 25110 Oct 21 14:53 /var/log/removed_packages/glibc-2.26-x86_64-3-upgraded-2018-02-09,20:30:35
268 -rw-r--r-- 1 root root 270888 Oct 21 14:53 /var/log/removed_packages/glibc-i18n-2.26-x86_64-3-upgraded-2018-02-09,20:30:44
4 -rw-r--r-- 1 root root 1045 Oct 21 14:53 /var/log/removed_packages/glibc-profile-2.26-x86_64-3-upgraded-2018-02-09,20:30:56
72 -rw-r--r-- 1 root root 71505 Dec 9 16:24 /var/log/removed_packages/glibc-zoneinfo-2017c-noarch-1-upgraded-2018-01-30,00:52:32
So now ..... how do I get an older version of slackware glibc packages to test a roll back ?
Then, is there a better way or tool to track down history of package version on Slackware ?
I'd suggest keep a copy of the repo one version behind, so you can have it on your system for cases like this, then run
Code:
upgradepkg <pkg name(s)>
to revert back to the old ones in question.
ABob aka Alien BOB aka Eric Hameleers got a script to rsync http://www.slackware.com/~alien/tools/
well have a look for yourself. though i do now that is not a solution for the right now, so pls wait for it...
So now ..... how do I get an older version of slackware glibc packages to test a roll back ?
Then, is there a better way or tool to track down history of package version on Slackware ?
Sorry for the delay... by default, there is no way to roll back unless you keep the older versions. With -current being a rolling release, it doesn't keep older versions. You could tinker with Alien Bob's mirror script to change rsync to not delete older versions of files.
This would incur a larger amount of disk space, but could be handy to keep older versions of packages around.
With Alien Bob's mirror script, you can modify it to give it a unique name, so you can have two running then rotate them so one will always be one version behind the actual current updated one. that helps to cut back on taking up a lot of space, it is only going to be max under 15 GB for two full systems of Slack in my past experience in keeping only one. Just take the amount it it takes to install a full install of slack then times it by two and maybe give it a little more for the just in case I need it.
Looking at allend Idea it sounds good too, I'd mod it to just keep the what is already installed, if it is updated keep that old stuff and put it somewhere safe, add that checking for dups in the script that moves the old package. get the name check the storage for that name if it matches delete what is in storage then move the older one that has just been updated into storage. If no name match then just move it.
That way it is more like a rolling release but backwards. keeping only one version older then what has already been updated.
I use rsnapshot for backups. I maintain a local Slackware repository using a modified version of Eric's original rsync script. I configure rsnapshot to backup the patches directory of the local mirror. In a disaster recovery the remainder of the local repository can be repopulated at any time. The backups provide a nice way to archive previous package versions.
Having access to previous versions is helpful for debugging, such as the recent kernel issues I reported.
I started backing up previous versions many years ago. I remember an Samba update prevented Samba from working. The bug was from upstream and patched within a few days, but I had to scramble to find the previous version of the Samba package.
I've started to use Alienbob's script to get a local mirror of packages.
I will take a look this weekend for keeping 1-2-3 version behind following your advice.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.