LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 08-14-2019, 03:44 PM   #16
luvr
Member
 
Registered: May 2005
Location: Boom - The Home Town of Tomorrowland, Belgium
Distribution: Slackware, Debian, Xubuntu
Posts: 323
Blog Entries: 1

Rep: Reputation: 136Reputation: 136
OOPS! My script does not pick up today’s upgraded kernel.


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.
 
Old 08-15-2019, 02:30 AM   #17
lioh
Member
 
Registered: Aug 2019
Location: Switzerland
Distribution: Slackware
Posts: 70

Rep: Reputation: Disabled
@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.
 
Old 08-15-2019, 06:19 AM   #18
ehartman
Member
 
Registered: Jul 2007
Location: Delft, The Netherlands
Distribution: Slackware
Posts: 975

Rep: Reputation: 512Reputation: 512Reputation: 512Reputation: 512Reputation: 512Reputation: 512
Quote:
Originally Posted by luvr View Post
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.
 
1 members found this post helpful.
Old 08-15-2019, 03:57 PM   #19
luvr
Member
 
Registered: May 2005
Location: Boom - The Home Town of Tomorrowland, Belgium
Distribution: Slackware, Debian, Xubuntu
Posts: 323
Blog Entries: 1

Rep: Reputation: 136Reputation: 136
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?
 
Old 08-15-2019, 04:41 PM   #20
ehartman
Member
 
Registered: Jul 2007
Location: Delft, The Netherlands
Distribution: Slackware
Posts: 975

Rep: Reputation: 512Reputation: 512Reputation: 512Reputation: 512Reputation: 512Reputation: 512
Quote:
Originally Posted by luvr View Post
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.
 
Old 08-15-2019, 05:27 PM   #21
Chuck56
Member
 
Registered: Dec 2006
Location: Colorado
Distribution: Slackware
Posts: 547

Rep: Reputation: 148Reputation: 148
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:~#
 
Old 08-16-2019, 04:34 PM   #22
luvr
Member
 
Registered: May 2005
Location: Boom - The Home Town of Tomorrowland, Belgium
Distribution: Slackware, Debian, Xubuntu
Posts: 323
Blog Entries: 1

Rep: Reputation: 136Reputation: 136
Quote:
Originally Posted by ehartman View Post
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.)
 
Old 08-16-2019, 04:39 PM   #23
luvr
Member
 
Registered: May 2005
Location: Boom - The Home Town of Tomorrowland, Belgium
Distribution: Slackware, Debian, Xubuntu
Posts: 323
Blog Entries: 1

Rep: Reputation: 136Reputation: 136
Quote:
Originally Posted by Chuck56 View Post
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.
 
Old 08-16-2019, 04:48 PM   #24
Chuck56
Member
 
Registered: Dec 2006
Location: Colorado
Distribution: Slackware
Posts: 547

Rep: Reputation: 148Reputation: 148
Quote:
Originally Posted by luvr View Post
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.
 
1 members found this post helpful.
Old 08-16-2019, 11:40 PM   #25
ehartman
Member
 
Registered: Jul 2007
Location: Delft, The Netherlands
Distribution: Slackware
Posts: 975

Rep: Reputation: 512Reputation: 512Reputation: 512Reputation: 512Reputation: 512Reputation: 512
Quote:
Originally Posted by luvr View Post
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.

Last edited by ehartman; 08-16-2019 at 11:42 PM.
 
1 members found this post helpful.
Old 08-23-2019, 03:23 AM   #26
lioh
Member
 
Registered: Aug 2019
Location: Switzerland
Distribution: Slackware
Posts: 70

Rep: Reputation: Disabled
@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
 
Old 08-23-2019, 04:02 AM   #27
denydias
Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 149

Original Poster
Rep: Reputation: Disabled
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 View Post
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 View Post
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.
 
1 members found this post helpful.
Old 08-23-2019, 04:21 AM   #28
luvr
Member
 
Registered: May 2005
Location: Boom - The Home Town of Tomorrowland, Belgium
Distribution: Slackware, Debian, Xubuntu
Posts: 323
Blog Entries: 1

Rep: Reputation: 136Reputation: 136
Quote:
Originally Posted by denydias View Post
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.
 
Old 08-23-2019, 04:27 AM   #29
lioh
Member
 
Registered: Aug 2019
Location: Switzerland
Distribution: Slackware
Posts: 70

Rep: Reputation: Disabled
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?
 
Old 08-23-2019, 04:52 AM   #30
denydias
Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 149

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by luvr View Post
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.
 
  


Reply

Tags
kernel, lilo, slackware -current, sysadmin, upgrade


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Upgraded distro which upgraded perl and modules from old version not transferred to new. systemlordanubis Linux - Software 1 03-25-2018 04:37 AM
[SOLVED] slackpkg+: how to keep one package in slackware being upgraded by a 3rd party repos? michaelslack Slackware 9 12-15-2014 07:28 AM
[SOLVED] keyboard stopped working in X when I upgraded udev from 1.75 to 1.82After I upgraded RandomTroll Slackware 3 07-26-2012 03:48 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 07:40 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration