LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
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-23-2019, 05:02 AM   #31
lioh
Member
 
Registered: Aug 2019
Location: Switzerland
Distribution: Slackware
Posts: 70

Rep: Reputation: Disabled

I would like to know how often it really happens that a new kernel does not boot. I must admit that i am using the huge kernel and never had any issues with it, neither on stable nor on -current. I can imagine that an upgrade could eventually cause issues when one is using LVM / Full-Disk-Encryption or things like that.

For me the the main issues when using the -generic kernel is that I always have to remember to run lilo afterwards, which I sometimes forget and then (and only then) I have to boot the old kernel and fix the initrd.

So I am really interested in your real-life experience and would be happy if you could share some of the situations you had on kernel upgrades.
 
Old 08-23-2019, 05:12 AM   #32
denydias
Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 149

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by lioh View Post
I would like to know how often it really happens that a new kernel does not boot. I must admit that i am using the huge kernel and never had any issues with it, neither on stable nor on -current. I can imagine that an upgrade could eventually cause issues when one is using LVM / Full-Disk-Encryption or things like that.
LVM / Full-Disk-Encryption is my use case. I can't afford have no way around with a faulty new kernel. It never happened before, but who knows when...

Quote:
Originally Posted by lioh View Post
For me the the main issues when using the -generic kernel is that I always have to remember to run lilo afterwards, which I sometimes forget and then (and only then) I have to boot the old kernel and fix the initrd.
That's the reason why I decided to automate it and to keep the previous working kernel. Before that I had a TFTP server at home so I could boot to the rescue image and fix things, which also involves to mess with BIOS network and boot settings as I always keep my notebook pretty closed to booting with anything I can't control. There was one time I was away from home. You could imagine the rest. My current approach gives me all the tools I need to recover from a faulty upgrade, anywhere.
 
Old 08-23-2019, 09:56 AM   #33
Chuck56
Member
 
Registered: Dec 2006
Location: Colorado
Distribution: Slackware
Posts: 547

Rep: Reputation: 148Reputation: 148
autoslackpkg-0.4 RC1

I've been using my own Slackware upgrade scripts since last year. At that time I had 3 systems on current and the kernel upgrades were becoming robotic for me. Hopefully the scripts are ready for others to test drive. I named the scripts "autoslackpkg".

https://www.go4it2day.com/news/autoslackpkg-0.4.html

The scripts leverage slackpkg and manage kernel changes from start to finish on both EFI or LILO systems. The key to successfully using the scripts is to make sure 4 config files are appropriately customized. There are rudimentary help screens that try to explain the config customizations.
Code:
/etc/slackpkg/blacklist/usr/sbin/usermod
/etc/mkinitrd.conf
/etc/lilo.conf
/boot/efi/.../elilo.conf (location can vary)
I use the scripts on 11 systems currently, 14.2 & current, x86 & x86_64, desktops, servers, gateways & LXC containers. I've tried to hit all my edge cases but I'm sure there are others I haven't run into yet. You're welcome to use them or tear them apart for ideas for your own scripts.

Enjoy!

Last edited by Chuck56; 08-23-2019 at 11:19 AM.
 
3 members found this post helpful.
Old 08-23-2019, 05:09 PM   #34
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
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.
That is absolutely correct, but when I mentioned the "previous" kernel, I actually meant the earlier build of the $KCUR version. That will, obviously, get overwritten. Any earlier kernel versions that are still installed will, clearly, not be touched. Should the new build, for any reason, fail to boot up, then you can still fall back on such an older version - PROVIDED that you kept at least one of those.

Quote:
Originally Posted by lioh View Post
@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
Sounds like a great suggestion, and would make such a fallback a whole lot easier, should it ever be required. I'll look into it. Sure seems pretty much doable anyway.
 
Old 08-23-2019, 11:33 PM   #35
denydias
Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 149

Original Poster
Rep: Reputation: Disabled
I had some spare time today and could face the kernel build bump problem in my script. Follow are the results (with mocked values, of course).

First with a regular kernel upgrade, e.g. 4.19.66 to 4.19.67:

Code:
$ minskyup kernel
NEW kernel 4.19.67 available, current kernel is 4.19.66, upgrading boot menu:

- Slackware: 4.19.67 = /media/nas/mirrors/slackware64-current/slackware64/a/kernel-generic-4.19.66-x86_64-2.txz
- Slackprev: 4.19.66 = /boot/vmlinuz-generic-4.19.66
- DELETE   : 4.19.65 = /boot/vmlinuz-generic-4.19.65

The following resources will be upgraded:

- Packages: kernel-{source,headers,modules,generic}
- Images  : initrd, initrd-prev, recovery and memtest

Press [CTRL-C] to abort or [Enter] to continue...
Now with just a kernel build bump, e.g. 4.19.66-1 to 4.19.66-2:

Code:
$ minskyup kernel
BUMPED kernel 4.19.66-2 available, current kernel is 4.19.66-1, upgrading boot menu:

- Slackware: BUMP 4.19.66-1 -> 4.19.66-2 = /media/nas/mirrors/slackware64-current/slackware64/a/kernel-generic-4.19.66-x86_64-2.txz
- Slackprev: KEPT 4.19.65 = /boot/vmlinuz-generic-4.19.65
- DELETE   : NONE

The following resources will be upgraded:

- Packages: kernel-{modules,generic}
- Images  : initrd, initrd-prev, recovery and memtest

Press [CTRL-C] to abort or [Enter] to continue...
Now let the kernels come so I can found the bugs in my logic...

Last edited by denydias; 08-23-2019 at 11:36 PM.
 
1 members found this post helpful.
Old 08-24-2019, 12:37 PM   #36
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 luvr View Post
(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.)
Hmmm... I have just tried the following (while “kernel-source-4.19.66-noarch-1” was the highest kernel-source version installed):
Code:
# upgradepkg kernel-source-4.19.66-noarch-1%kernel-source-4.19.66-noarch-2.txz
It doesn’t do what I intended, though, in that it removes all earlier versions of the kernel-source package, then installs the specified new package. Come to think of it, this doesn’t really come as a surprise; after all, it just performs the upgrade that I request—which, by definition, will remove all earlier versions of the package to be upgraded.

Thus, a sequence of ‘removepkg’ and ‘installpkg’ will be the way to go in order to upgrade an installed kernel version to a newer build.

Last edited by luvr; 08-28-2019 at 04:43 PM.
 
Old 08-24-2019, 01:35 PM   #37
denydias
Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 149

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by luvr View Post
Thus, a sequence of ‘removepkg’ and ‘installpkg’ will be the way to go in order to upgrade an installed package version to a newer build.
Only if you want to keep the previous working kernel and its source so you can recompile it for any reason. But kernel-headers won't work that way, as it always replace the previous files.

My approach is a little different: although I keep the previous kernel, I do so only to count on a booting system in case the worst happens, i.e. the just installed new kernel won't boot at all. As I have no intention to recompile the previous kernel, nor compile anything in the system against it anymore, I don't need kernel-source nor kernel-headers of the previous kernel.

As such, when a new kernel arrives (like 4.19.67 to replace 4.19.66), my script just upgradepkg kernel-source and kernel-headers, effectively replacing them with the newer versions. On the other hand, when the kernel upgrade is just a bump (like 4.19.66-1 to 4.19.66-2), there is no need to touch kernel-source and kernel-headers, so my script just skip this step.

In any case, version or bump upgrades, my script actively removepkg the selected kernel then installpkg the new one. I prefer this way to avoid conflicts that may left orphan files or dead links around in the system.
 
1 members found this post helpful.
Old 08-24-2019, 02:21 PM   #38
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
My approach is a little different: although I keep the previous kernel, I do so only to count on a booting system in case the worst happens, i.e. the just installed new kernel won't boot at all. As I have no intention to recompile the previous kernel, nor compile anything in the system against it anymore, I don't need kernel-source nor kernel-headers of the previous kernel.
Good catch… looking at it like that, I don’t actually need the older sources or headers either.
For now, it doesn’t hurt to keep them around either, but I’ll think it through a little further before I make up my mind about how to handle them in the future.

Quote:
Originally Posted by denydias View Post
As such, when a new kernel arrives (like 4.19.67 to replace 4.19.66), my script just upgradepkg kernel-source and kernel-headers, effectively replacing them with the newer versions.
Indeed, you'll wipe out the earlier versions… which are, in effect, just dead weight when you leave them installed.

Quote:
On the other hand, when the kernel upgrade is just a bump (like 4.19.66-1 to 4.19.66-2), there is no need to touch kernel-source and kernel-headers, so my script just skip this step.
That idea hadn't even crossed my mind just yet, but you're absolutely right!

Quote:
In any case, version or bump upgrades, my script actively removepkg the selected kernel then installpkg the new one. I prefer this way to avoid conflicts that may left orphan files or dead links around in the system.
I think I’ll experiment a little further to see what works best for me… but your comments certainly make sense. In any case, I remove the links that come with a kernel installation, and I create and maintain my own set of links—so far, without issues.

I do have an updated version of my script ready now, which maintains an additional set of links to the ‘previous’ kernel files (i.e., to the kernel version that is running when the script is being executed), but I’ll have to double-check that it doesn’t do any crazy things when it has to remove kernel packages.
 
Old 08-25-2019, 03:35 PM   #39
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
UPDATE to my 'upgrade-kernel.sh' script.

Attached to this post is an update to my ‘upgrade-kernel.sh’ script.

NEW FEATURE:
  • The script now maintains a set of symlinks to the “previous” kernel version—i.e., the one that is active at the time a new kernel is being installed. These symlinks will have the same names as their “new-kernel” counterparts, but with a suffix of ‘-prev’ appended.
Caveat: When you remove one or more kernel versions while no new kernel version is available, these ‘-prev’ symlinks will be recreated to point to the kernel version that is running at that time. As a consequence, if you’re running the latest installed kernel version at that time (which you normally will), then the ‘-prev’ and the “new-kernel” symlinks will both be made to point to that latest version. I don’t consider this a significant problem, because:
  1. the primary goal of the script is to install kernel upgrades—at which time it will let you remove any versions that you no longer want to keep;
  2. the currently active kernel is known to be good anyway, since otherwise you wouldn’t be running it in the first place.
TO DO:
  • Add support for installing a new build of an already installed kernel version.
I will be testing this support on my Slackware-current install, which I temporarily reverted back to kernel version 4.19.66, Build 1. I’m using a test version of the script that I point to what it thinks is my local repository mirror, but is in reality a simple folder into which I can copy any kernel version and build that I want to test with.
Attached Files
File Type: txt upgrade-kernel.txt (83.5 KB, 6 views)
 
2 members found this post helpful.
Old 08-27-2019, 01:46 AM   #40
denydias
Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 149

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by denydias View Post
Now let the kernels come so I can found the bugs in my logic...
Kernel 4.19.68 upgrade handled as usual. Now let's wait for a bump (e.g. 4.19.68-1 to 4.19.68-2) to test this case. It may take years though.
 
Old 08-28-2019, 04:22 PM   #41
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
Next update to my 'upgrade-kernel.sh' script.

Attached to this post is the next update to my ‘upgrade-kernel.sh’ script.

NEW FEATURE:
  • The script now supports installation of a new build of an already installed kernel version.
    To install a new build of the latest installed kernel version, it will first install the new build, and next remove the previously installed one. In this way, the removal operation is really only required in order to clean up installation registration of the overridden (and overwritten) build.
KNOWN ISSUE:
  • It remains a bad idea to remove the latest installed kernel version, since the version-independent symbolic links to the kernel files will then be left behind, but they will become “dangling” pointers—i.e., they will point to ‘nowhere’.
    Note that the script won’t even let you remove the latest kernel version anyway, unless you are running an earlier kernel version and there is no new kernel available for installation.
EXTRAS:
  • Script ‘fix-kernel-symlinks.sh’ will recreate the version-independent symbolic links to the latest installed kernel files.
    It will also allow you to select the kernel version to which you want to point the fallback (i.e., “previous”) symbolic links.
  • Script ‘rebuild-kernel-initrd.sh’ allows you to select the installed kernel versions for which you want to rebuild the Initial RAM Disks (“initrd”).
Attached Files
File Type: txt upgrade-kernel.txt (94.3 KB, 13 views)
File Type: txt fix-kernel-symlinks.txt (12.2 KB, 10 views)
File Type: txt rebuild-kernel-initrd.txt (13.8 KB, 10 views)
 
2 members found this post helpful.
Old 08-29-2019, 08:09 AM   #42
lioh
Member
 
Registered: Aug 2019
Location: Switzerland
Distribution: Slackware
Posts: 70

Rep: Reputation: Disabled
Thank luvr, I am going to try it out soon and give some feedback. The dangling symlinks is not so much an issue in my point of view.

Could you elaborate a bit more why exactly now three scripts are needed instead of one like before? Wouldn't it be possible to merge all the functionality into the main script?

Last edited by lioh; 08-30-2019 at 02:05 AM.
 
Old 08-30-2019, 05:04 PM   #43
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 lioh View Post
Could you elaborate a bit more why exactly now three scripts are needed instead of one like before? Wouldn't it be possible to merge all the functionality into the main script?
The main script, ‘upgrade-kernel.sh’, is the only one that’s needed. The other two, ‘fix-kernel-symlinks.sh’ and ‘rebuild-kernel-initrd.sh’ are just quick hacks that should not be required, but that can be used to repair anomalies with the symlinks or the initrds, should that ever be necessary. The ‘fix-kernel-symlinks.sh’ script for instance, will fix the “dangling pointer” issue for you, should you ever run into it.

I used the ‘fix-kernel-symlinks.sh’ while I was developing the latest version of my ‘upgrade-kernel.sh’ script, so I could verify if the latter behaved properly under various conditions. I haven’t encountered a situation in which the ‘rebuild-kernel-initrd.sh’ was useful, but you never know.

Thus, to recapitulate: Under normal conditions, you should still only really need the main ‘upgrade-kernel.sh’ script.

Last edited by luvr; 08-30-2019 at 05:07 PM.
 
Old 10-02-2019, 08:31 AM   #44
lioh
Member
 
Registered: Aug 2019
Location: Switzerland
Distribution: Slackware
Posts: 70

Rep: Reputation: Disabled
Thanks for pointing that out. I have to add some options to the mkintrd generation. Can I just modify the following line to look e.g. like this:

$(/usr/share/mkinitrd/mkinitrd_command_generator.sh -a -l sg-latin1 -h /dev/cryptvg/swap '-o '"${INITRD}" --run "${KERNEL}")

Greetings

Lioh
 
Old 10-02-2019, 08:49 AM   #45
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 lioh View Post
Can I just modify the following line to look e.g. like this:

$(/usr/share/mkinitrd/mkinitrd_command_generator.sh -a -l sg-latin1 -h /dev/cryptvg/swap '-o '"${INITRD}" --run "${KERNEL}")
Yes, that will work fine.
 
  


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:45 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