My apporach on how to keep Slackware-current upgraded
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.
Now I'm here to expand on how I keep up with Slacware-current evolution in a safe manner, i.e. by avoiding system breakage between upgrades. Keep in mind that even if all this works perfectly for me and I haven't had not a single glitch in this process in the past couple years, it is solely my approach to the task. I have no intention at all that this may become an ultimate approach to it. It's just my way of doing things that could eventually help others with ideas.
1_mirror.sh: this is my mirroring script. It runs everyday on my NAS to keep up with Slackware-current and AlienBOB's Ktown. It also performs a very important task to anyone avoiding bad things to happen: package preservation.
2_minskyup.sh: this one upgrades Slackware-current according to the best practices exposed in Upgrading Slackware to a New Release. There are different functions for system and kernel upgrades. The later includes automation to preserve the last working kernel version so you can have a working system if the new kernel don't boot. It also includes the recovery and memtest images from Slackware's usbboot.img, meaning that if something goes really, really wrong, you'll have the tools to fix it right there. There are also functions to upgrade many of the tools of my daily workflow, that for one reason or another I decided to use the upstream binaries instead of a ready made package or SlackBuild out there: virtualbox, vagrant, docker, aws-cli, cli53, (git)hub, jq, ngrok, phpmyadmin, spectre-meltdown-checker, testssl, asciinema, calibre, pup, Synology Drive and zoom.
3_minskyup_completion.sh: this one goes in /etc/bash_completion.d/ to offer tab completion for minskyup.
4_lilo.conf: an example of my boot entries so the kernel upgrades works as expected.
But how it works? Whenever a see a new Slackware64 -current ChangeLog entry, or anytime I want, I run:
This will upgrade any packages but kernel. When there is a ktown upgrade, I go to init 3 and run it without --force as it's not advisable to upgrade KDE stuff with X running.
If the changelog entry also contains a new kernel version, then I run:
Code:
$ sudo minskyup kernel
This command will ask me to confirm all the changes it detects, so I have the information I need to decide where or not is safe to move on.
As for the other minskyup options, they are pretty self explanatory. For instance, to upgrade virtualbox:
Code:
$ sudo minskyup virtualbox
It'll detect the currently installed version and the latest one from Oracle. If the installed one is outdated, it moves on and upgrades.
But there are some other tools that do not provide a way to discover which the latest version is. In that case you have to check first, but it's quite simple too:
Code:
$ sudo minskyup docker
Docker CE version is required. Example:
minskyup docker 18.06.0
See https://download.docker.com/linux/static/stable/x86_64/ for available versions.
Currently installed: Docker version 18.06.0-ce
$ sudo minskyup docker 18.06.3
And so on...
So, this is how I do it. WFM. Damn, really WFM!
PS: why minskyup? My box is named after Marvin Minsky.
Last edited by denydias; 05-30-2019 at 06:13 AM.
Reason: Add note about ktown and --force.
I am taking a far less ambitious approach to keeping my Slackware systems up-to-date, but now that I finally got around to finishing my script for maintaining the Linux kernel under Slackware, I thought I’d share the procedure that I follow. Now, as you said:
Quote:
Originally Posted by denydias
I have no intention at all that this may become an ultimate approach to it. It's just my way of doing things that could eventually help others with ideas.
I actually restarted writing my script from scratch some four or five times, since I found it got too complex while I worked on it, and I then began to read various sources (man pages, the slackpkg source code, etc.), which taught me about quite a few useful features that could make my script so much simpler and more straightforward.
I maintain a local copy of the Slackware repository, which I keep up-to-date with the rsync utility.
I blacklisted the kernel packages (as well as ‘SBo’,‘alien’, and ‘compat32’) in my ‘/etc/slackpkg/blacklist’ file, and to install the Slackware updates, I run the typical command sequence:
Then, to maintain the Linux kernel versions on my Slackware system, I simply run my ‘upgrade-kernel.sh’ script without any parameters:
Code:
# upgrade-kernel.sh
The script presents a dialog-based interface that, depending on the circumstances, will let me install the latest kernel version and/or remove selected kernel versions (except for the currently running one).
In case anyone is interested, I attach the script (with an extension of “.txt” instead of “.sh”) to this post.
@luvr thanks for providing your script. Is it necessary in order to make it work to use a local mirror or does it also work with a remote? If the latter is the case, could you please share your opinion on why it's better to use a local mirror?
Greetings
Marcus
Last edited by marcusmaria; 07-27-2019 at 02:54 AM.
Reason: solved it on my own.
In case anyone ever runs into the same issue: After you rsync your local repository, a new kernel (or, by extension, any new or updated package) won’t get picked up until you run
That was exactly the point, thanks. Have you seen my additional question:
Quote:
Is it necessary in order to make it work to use a local mirror or does it also work with a remote? If the latter is the case, could you please share your opinion on why it's better to use a local mirror?
@dugan what is the compat32pkg about that you are using? Are you converting the regular packages in multilib with that? Would it also be possible to use aliens multilib repository instead?
Is it necessary in order to make it work to use a local mirror or does it also work with a remote?
As it stands, the script requires a local mirror.
The immediate reason is that it looks for an active “file:” line in your ‘/etc/slackpkg/mirrors’ file, and it will quit if it doesn’t find one.
The more fundamental reason is that the ‘installpkg’ command (which the script runs to install the new kernel packages) only installs packages that are available locally. Therefore, to support a remote mirror, the script will have to download the packages to a local directory before installing them. While I did consider implementing this (using something like ‘wget’ or ‘curl’), I decided in the end that it wasn’t worth the hassle. After all, the script was really just meant for my own use—“just a hobby, won't be big and professional like gnu”…
Quote:
[…] could you please share your opinion on why it's better to use a local mirror?
To be honest, I really didn’t give this question all that much thought. When I looked into Slackware package management for the first time (long before I even envisaged ever installing Slackware permanently and for real), the Slackware documentation kind of suggested using a local mirror, and that’s really the primary reason why I’m still using a local mirror.
@luvr thanks for the reply. I can imagine that a local mirror is also a bit more 'safe' especially for upgrades from stable to -current. I am using it now as you have implemented and till now I am very happy with it. Thanks for the work.
@luvr I have noticed one little thing concerning your script: I had the local mirror configured without the trailing slash first, like: file://home/ftp/pub/Linux/Slackware/slackware64-current and your script exited when it tried to detect the local mirror. After modifying the slackpkg mirror configuration so that it looked like this: file://home/ftp/pub/Linux/Slackware/slackware64-current/ everything worked as expected.
@luvr I have noticed one little thing concerning your script: I had the local mirror configured without the trailing slash first, like: file://home/ftp/pub/Linux/Slackware/slackware64-current and your script exited when it tried to detect the local mirror. After modifying the slackpkg mirror configuration so that it looked like this: file://home/ftp/pub/Linux/Slackware/slackware64-current/ everything worked as expected.
That’s correct—initially, I made the trailing slash optional, but then I saw the following note in the ‘/etc/slackpkg/mirrors’ file (emphasismine):
Code:
# Slackpkg only needs to point to the directory that contains
# "ChangeLog.txt", and don't forget the trailing slash.
So I reasoned that, since the trailing slash was required anyway, I could just as well enforce it.
Having said that, making the trailing slash optional requires just one simple change to the script (replacing a single ‘+’-sign with an asterisk), as implemented by the following patch:
To apply the patch, save it to a file (say, ‘/tmp/plus2asterisk.patch’), then ‘cd’ to the directory where you keep the ‘upgrade-kernel.sh’ script file, and run:
@luvr thanks for pointing that out and for the patch. I think I will let it like this now as it works perfectly. I have to admit that I did not read the note in the slackpkg mirrors config. I have just tried the script without having the trailing slash set before and then I have realized that in your script there was one, so I have added it an it worked.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.