My apporach on how to keep Slackware-current upgraded

luvr · 08-14-2019, 02:44 PM

Today’s “Current (pre-release) ChangeLog for x86_64” announces availability of an upgraded kernel in the repositories:

Code:

Wed Aug 14 05:24:55 UTC 2019
a/kernel-generic-4.19.66-x86_64-2.txz: Upgraded.
       Recompiled with gcc-9.2.0.
a/kernel-huge-4.19.66-x86_64-2.txz: Upgraded.
       Recompiled with gcc-9.2.0.
a/kernel-modules-4.19.66-x86_64-2.txz: Upgraded.
       Recompiled with gcc-9.2.0.

My ‘upgrade-kernel.sh’ script, however, doesn’t pick up this new kernel, because kernel version “4.19.66” is already installed on my computer. Consequently, the script believes that there is no new kernel version available for installation. The script considers only the version number, and ignores the build number, which was incremented from “1” to “2”, while the version was left unchanged.

That makes me wonder what would be the recommended way to install this new kernel version. If you used ‘installpkg’, then, surely, it would get installed, but I guess you would then end up with a “broken /var/log/packages - with two versions of the same package”, wouldn’t you? Even so, I’m not aware of any real problems that this would cause; the only irregularity, as far as I can tell, would be a seemingly innocent warning from ‘slackpkg’ about the issue.

Anyway, to get my ‘upgrade-kernel.sh’ script, as it currently stands, to install this upgraded kernel, you can do the following:

Reboot the system with an older kernel that is still installed. (If you don’t have any, then you’re out of luck… Sorry!)
Run the script and instruct it to remove the latest kernel—i.e., in this case, version 4.19.66.
Rerun the script to install the new kernel version.

I’m not entirely sure if it would be worth it to try and adapt my script so it would handle this type of condition. Is this a common occurrence, or is it pretty much exceptional? In any case, this is the first time that I’m seeing it.

lioh · 08-15-2019, 01:30 AM

@luvr thanks for pointing that out. It would be great if you could find a way that your script could handle those edge cases. Could you please elaborate how you handle the parallel installation? As far as I have seen on my system /var/log/packages shows several versions of the same package (which I have also expected to be like that). As I have blacklisted the kernels in slackpkg there is also no warning about it.

ehartman · 08-15-2019, 05:19 AM

Quote:

Originally Posted by luvr

I’m not entirely sure if it would be worth it to try and adapt my script so it would handle this type of condition. Is this a common occurrence, or is it pretty much exceptional? In any case, this is the first time that I’m seeing it.

It happened before, although it isn't all that usual for the kernel to get a recompile, especially in -current, where upgrades happen that often that it mostly will be a version upgrade anyway.
A quick search in the ChangeLog's found a case in 14.1, where the kernel (3.10.17) even was rebuilt twice, within a few days:

Quote:

Thu Oct 24 01:22:57 UTC 2013
a/kernel-generic-3.10.17-i486-3.txz: Rebuilt.
+--------------------------+
Mon Oct 21 07:30:10 UTC 2013
a/kernel-generic-3.10.17-i486-2.txz: Rebuilt.

There may be more, but I only did a limited quick search.

BTW: the current (last) updated kernel for 14.1 is a -2 build too:
linux-3.10.107/kernel-generic-3.10.107-i486-2.txz
because of a security vulnerability.

luvr · 08-15-2019, 02:57 PM

It seems to me that it is not an option to leave two (or even more) builds of the same kernel version installed side-by-side, since they use the exact same names for the files that they install.

For instance:

Code:

$ tar -tvf kernel-generic-4.19.66-x86_64-1.txz
drwxr-xr-x root/root         0 2019-08-09 22:34 ./
drwxr-xr-x root/root         0 2019-08-09 22:34 boot/
-rw-r--r-- root/root   3554153 2019-08-09 22:34 boot/System.map-generic-4.19.66
-rw-r--r-- root/root    185303 2019-08-09 22:34 boot/config-generic-4.19.66.x64
-rw-r--r-- root/root   6068096 2019-08-09 22:34 boot/vmlinuz-generic-4.19.66
drwxr-xr-x root/root         0 2019-08-09 22:34 install/
-rw-r--r-- root/root       354 2019-08-09 22:34 install/doinst.sh
-rw-r--r-- root/root      1086 2019-08-09 22:34 install/slack-desc
$ tar -tvf kernel-generic-4.19.66-x86_64-2.txz
drwxr-xr-x root/root         0 2019-08-14 01:03 ./
drwxr-xr-x root/root         0 2019-08-14 01:03 boot/
-rw-r--r-- root/root   3553963 2019-08-14 01:03 boot/System.map-generic-4.19.66
-rw-r--r-- root/root    185303 2019-08-14 01:03 boot/config-generic-4.19.66.x64
-rw-r--r-- root/root   6068096 2019-08-14 01:03 boot/vmlinuz-generic-4.19.66
drwxr-xr-x root/root         0 2019-08-14 01:03 install/
-rw-r--r-- root/root       354 2019-08-14 01:03 install/doinst.sh
-rw-r--r-- root/root      1086 2019-08-14 01:03 install/slack-desc

So, if I were to install Build “-2” without removing Build “-1” first, then the files from Build “-1” would be overwritten. In effect, there would, then, be two packages claiming ownership of the files.

In other words, I guess that if there’s a rebuild available of an already installed kernel version, then it shouldn’t be installed over the previous build, but the previous one should be removed first.

Any thoughts?

ehartman · 08-15-2019, 03:41 PM

Quote:

Originally Posted by luvr

In other words, I guess that if there’s a rebuild available of an already installed kernel version, then it shouldn’t be installed over the previous build, but the previous one should be removed first.

Of course build -2 must be an UPGRADE to build-1, because, as you said, they will need the same (but possible recompiled) modules, include files etc.

Chuck56 · 08-15-2019, 04:27 PM

If you use slackpkg then you get a dialog screen and the output from removepkg. The tools check the newer rebuilt package Skipping over duplicate file names. The net effect is that the older package is removed from the package list but the newer rebuilt files remain in place.

Code:

root@xxx:~# slackpkg remove kernel-generic-4.19.66-x86_64-1                                         
                                                                                                    
Looking for kernel-generic-4.19.66-x86_64-1 in package list. Please wait... DONE                    


 slackpkg 2.83.0
 ──────────────────────────────────────────────────────────────────────────────────────────────────


              ┌──────────────────────────────remove────────────────────────────────┐
              │ Choose packages to remove:                                         │  
              │ ┌────────────────────────────────────────────────────────────────┐ │  
              │ │[*] kernel-generic-4.19.66-x86_64-1                │ │  
              │ │                                                                │ │  
              │ │                                                                │ │  
              │ │                                                                │ │  
              │ │                                                                │ │  
              │ │                                                                │ │  
              │ │                                                                │ │  
              │ │                                                                │ │  
              │ │                                                                │ │  
              │ │                                                                │ │  
              │ │                                                                │ │  
              │ │                                                                │ │  
              │ │                                                                │ │  
              ├─└────────────────────────────────────────────────────────────────┘─┤  
              │                   <  OK  >          <Cancel>                       │  
              └────────────────────────────────────────────────────────────────────┘  

Package: kernel-generic-4.19.66-x86_64-1
        Removing... 
Removing package: kernel-generic-4.19.66-x86_64-1
Removing files:
  --> /boot/System.map (symlink) was found in another package. Skipping.
  --> /boot/config (symlink) was found in another package. Skipping.
  --> /boot/vmlinuz (symlink) was found in another package. Skipping.
  --> /boot/vmlinuz-generic (symlink) was found in another package. Skipping.
  --> /boot/System.map-generic-4.19.66 was found in another package. Skipping.
  --> /boot/config-generic-4.19.66.x64 was found in another package. Skipping.
  --> /boot/vmlinuz-generic-4.19.66 was found in another package. Skipping.

root@xxx:~#

Or you can directly use removepkg, not get the dialog screen and just get the Skipping messages. The same end result is the older package is removed from the package list and the newer rebuilt package & files remain.

Code:

root@xxx:~# removepkg kernel-huge-4.19.66-x86_64-1
Removing package: kernel-huge-4.19.66-x86_64-1
Removing files:
  --> /boot/System.map (symlink) was found in another package. Skipping.
  --> /boot/config (symlink) was found in another package. Skipping.
  --> /boot/vmlinuz (symlink) was found in another package. Skipping.
  --> /boot/vmlinuz-huge (symlink) was found in another package. Skipping.
  --> /boot/System.map-huge-4.19.66 was found in another package. Skipping.
  --> /boot/config-huge-4.19.66.x64 was found in another package. Skipping.
  --> /boot/vmlinuz-huge-4.19.66 was found in another package. Skipping.
root@xxx:~#

luvr · 08-16-2019, 03:34 PM

Quote:

Originally Posted by ehartman

Of course build -2 must be an UPGRADE to build-1, because, as you said, they will need the same (but possible recompiled) modules, include files etc.

True, but are you suggesting that I use ‘upgradepkg’ to install Build-2? Wouldn’t that remove all earlier kernel versions? Or could I use the “oldpackagename%newpackagename” construct to tell ‘upgradepkg’ that Build-2 (i.e., the new package) is an upgrade to Build-1 (i.e., the old package), and would it, then, leave the older versions alone?

(I’m really just thinking aloud here. If no-one has the answer to these questions, I will try out the “oldpackagename%newpackagename” construct and see what gives.)

luvr · 08-16-2019, 03:39 PM

Quote:

Originally Posted by Chuck56

If you use slackpkg then you get a dialog screen and the output from removepkg. The tools check the newer rebuilt package Skipping over duplicate file names. The net effect is that the older package is removed from the package list but the newer rebuilt files remain in place.

So, if I understand you correctly, your suggestion would be to ‘installpkg’ the new build first, and subsequently ‘removepkg’ the old one? In any case, that sounds to me like it should work.

Chuck56 · 08-16-2019, 03:48 PM

Quote:

Originally Posted by luvr

So, if I understand you correctly, your suggestion would be to ‘installpkg’ the new build first, and subsequently ‘removepkg’ the old one? In any case, that sounds to me like it should work.

Correct, that works.

I've been using scripts that follow that exact workflow for system upgrades (including the kernel). The scripts leverage slackpkg and manage the upgrade process from beginning to end including managing EFI & LILO files.

ehartman · 08-16-2019, 10:40 PM

Quote:

Originally Posted by luvr

So, if I understand you correctly, your suggestion would be to ‘installpkg’ the new build first, and subsequently ‘removepkg’ the old one? In any case, that sounds to me like it should work.

That's actually what "upgradepkg" does, it removes the existing package (you can even specify explicitly WHICH one instead of letting it search for it).

Quote:

Upgradepkg upgrades a Slackware package (.tgz, .tbz, .tlz, .txz) from an older version to a newer one. It does this by INSTALLING the new package onto the system, and then REMOVING any files from the old package that aren't in the new package. If the old and new packages have the same name, a single argument is all that is required. If the packages have different names, supply the name of the old package followed by a percent
symbol (%), then the name of the new package. Do not add any extra whitespace between pairs of old/new package names.

(from /sbin/upgradepkg).

It will never remove multiple old packages, only the one that is superceeded BY the newly installed one.

lioh · 08-23-2019, 02:23 AM

@luvr one thing that would be nice is to automatically create symlinks to the previous kernel (the one which is actively running) like: /boot/vmlinuz-generic-prev

denydias · 08-23-2019, 03:02 AM

Hey! I'm sorry for the late reply. For an unknown reason I'm not receiving LQ's reply notification messages.

Quote:

Originally Posted by marcusmaria

Doesn't the latter also upgrade ktown as well?

Yes, it does. But I want to make sure to upgrade ktown before other stuff.

Quote:

Originally Posted by luvr

My ‘upgrade-kernel.sh’ script, however, doesn’t pick up this new kernel, because kernel version “4.19.66” is already installed on my computer. Consequently, the script believes that there is no new kernel version available for installation. The script considers only the version number, and ignores the build number, which was incremented from “1” to “2”, while the version was left unchanged.

My script slipped on that too. A fix is in my personal backlog. I'm planning to use the approach to replace only the current kernel (build N) with the newer one (build N+1) and leave the previous one alone. I don't know how long I'll take to come up with that fix as I'm having busy days here.

luvr · 08-23-2019, 03:21 AM

Quote:

Originally Posted by denydias

I'm planning to use the approach to replace only the current kernel (build N) with the newer one (build N+1) and leave the previous one alone.

That was my initial idea, too, but I've come to the conclusion that that won't work, since the new build will overwrite the previous one anyway.

lioh · 08-23-2019, 03:27 AM

From how I understood it, the only way to handle those edge cases is to replace the old version using the upgradepkg old2%new2 feature, right?

denydias · 08-23-2019, 03:52 AM

Quote:

Originally Posted by luvr

That was my initial idea, too, but I've come to the conclusion that that won't work, since the new build will overwrite the previous one anyway.

The sequence bellow may work just fine for the case:

Code:

removepkg kernel-source-$KCUR-1
removepkg kernel-headers-$KCUR-1
removepkg kernel-modules-$KCUR-1
removepkg kernel-generic-$KCUR-1
installpkg $SLACK/k/kernel-source-$KCUR-2.txz
installpkg $SLACK/d/kernel-headers-$KCUR-2.txz
installpkg $SLACK/a/kernel-modules-$KCUR-2.txz
installpkg $SLACK/a/kernel-generic-$KCUR-2.txz

This does not look like it will mess with the previous one, being the previous kernel a version older then $KCUR, which in this particular use case happens to have only the build number increased. I don't see it touching modules and generic for the previous kernel.

On the other hand, the only way to preserve headers and source for the previous kernel is to copying their files before the installpkg/upgradepkg of them, but I don't really see the need for this. In the event of the new kernel don't boot, I'll use the previous one just to inspect the situation, fix it and boot into the new one asap.