My apporach on how to keep Slackware-current upgraded

denydias · 05-29-2019, 07:08 PM

Earlier this month a fellow LQ newbie asked us How to maintain a sane slackware64-current with Eric Hameleers multilib and ktown? Well, I gave my two cents there.

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.

The scripts are here:

https://gist.github.com/denydias/a10...08b8c1bec63ac8

And this is how they work:

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:

Code:

$ sudo minskyup mirror && sudo minskyup slack --force

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.

luvr · 06-23-2019, 09:29 AM

Thank you for your highly interesting post!

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:

Code:

# slackpkg update
# slackpkg install-new
# slackpkg upgrade-all
# slackpkg clean-system

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.

denydias · 06-26-2019, 02:21 AM

I'm glad you liked it. Thank you.

Quote:

Originally Posted by luvr

In case anyone is interested, I attach the script (with an extension of “.txt” instead of “.sh”) to this post.

That's what I call useful comments! Well done.

marcusmaria · 07-26-2019, 12:49 AM

Dear denydias,

thanks for sharing your workflow. I have one question concerning ktown. Is it really necessary to:

Code:

# slackpkg upgrade ktown

before:

Code:

# slackpkg upgrade-all

Doesn't the latter also upgrade ktown as well?

Greetings
Marcus

marcusmaria · 07-27-2019, 02:27 AM

@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

luvr · 07-27-2019, 02:55 AM

Quote:

Originally Posted by marcusmaria

Reason: solved it on my own.

Glad you figured it out.

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

Code:

# slackpkg update

Since I usually run the common sequence of

Code:

# slackpkg update
# slackpkg install-new
# slackpkg upgrade-all
# slackpkg clean-system

right after the rsync, and only then run my kernel update script, I won’t normally run into this issue.

marcusmaria · 07-27-2019, 10:38 AM

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 · 07-27-2019, 10:46 AM

For me it's usually:

Code:

slackpkg update
slackpkg upgrade-all
compat32pkg --convert-updates all
upgradepkg /var/cache/compat32pkg/compat-32/*.t?z
compat32pkg --clear-cache all

A couple more steps (including "geninitrd" and running the NVidia driver installer with "-K -k") if there's a kernel upgrade.

marcusmaria · 07-27-2019, 10:50 AM

@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?

dugan · 07-27-2019, 01:16 PM

http://compat32pkg.sourceforge.net/

I've found that Alien's multilib repo is often out of date.

luvr · 07-27-2019, 01:37 PM

Quote:

Originally Posted by marcusmaria

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.

marcusmaria · 07-27-2019, 01:45 PM

@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.

lioh · 08-09-2019, 04:08 AM

@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 · 08-10-2019, 08:17 AM

Quote:

Originally Posted by lioh

@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 (emphasis mine):

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:

Code:

--- upgrade-kernel.sh_orig	2019-08-10 15:02:21.158041934 +0200
+++ upgrade-kernel.sh	2019-08-10 15:03:06.550043756 +0200
@@ -900,7 +900,7 @@
       #*************************************************************************************************************************
       sed --silent                                                         \
           --regexp-extended                                                \
-          --expression='s~^[[:space:]]*file:/+(.+)/+[[:space:]]*$~/\1~p'   \
+          --expression='s~^[[:space:]]*file:/+(.+)/*[[:space:]]*$~/\1~p'   \
           "${SLACKWARE_MIRROR_CONFIGURATION}"
 
    )

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:

Code:

# patch < /tmp/plus2asterisk.patch

lioh · 08-11-2019, 09:02 AM

@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.