LinuxQuestions.org
Review your favorite Linux distribution.
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 06-06-2018, 07:35 AM   #1
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 2,294

Rep: Reputation: 895Reputation: 895Reputation: 895Reputation: 895Reputation: 895Reputation: 895Reputation: 895
A proposal about disallowing the "upgrade" of runtime kernel packages, and just to "install" them instead while using upgradepkg


It is clear that removing the system's live kernel and modules, while upgrading packages, can result in nasty situations.

May the user fails to properly update the bootloader, and some services may behave erratically without the live kernel modules on shutdown.

Like you known already, the "upgradepkg" script executes for every package a flow like: installing the new package, removing the old one, then (re-)installing the new one.

My idea is very simple: to stop this flow after initial installing of the new package, when its name is part of this certain list
Code:
kernel-generic
kernel-generic-smp
kernel-huge
kernel-huge-smp
kernel-modules
kernel-modules-smp
The final result of this change is that "upgradepkg" will always install those particular packages along with the existent ones, instead of "upgrading" them.

This way, even on a mass upgrade of packages, will leave the current kernel (and its modules) functional, leaving to the user the choice to configure the bootloader as he wish, for example inserting a new boot entry for the new kernels, etc..

BUT, the main advantage is that the administrator can do a clean reboot on the new kernel, with the ability to preserve and the previous one as backup, then eventually to remove "manually" the old ones.

For the records, a similar policy of install/remove only but not to "upgrade" for the runtime kernel packages is used from long time also by the major distributions like RHEL (and Fedora), (Open)SuSE, Debian (and Ubuntu or Mint).

Last edited by Darth Vader; 06-06-2018 at 08:47 AM.
 
Old 06-06-2018, 11:58 AM   #2
upnort
Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS, Ubuntu MATE
Posts: 546

Rep: Reputation: Disabled
The common approach by many Slackers is:

1. Exclude kernel updates with slackpkg.
2. Manually use installpkg to install newer kernels.
3. Run mkinitrd with the new kernel.
4. Manually edit the boot loader to support both kernel versions.

This is one aspect I think other distros do better. With other distros, multiple kernels are preserved so a new kernel cannot prevent booting the system. Also, slackpkg does not support GRUB, which I think more than a few Slackers use these days. I can live with the above steps but I much prefer the way other distros handle kernel updates.
 
1 members found this post helpful.
Old 06-06-2018, 12:07 PM   #3
TracyTiger
Member
 
Registered: Apr 2011
Location: California, USA
Distribution: Slackware
Posts: 477

Rep: Reputation: 219Reputation: 219Reputation: 219
I like feature but not implementation

A few days ago when running experiments on a throw-away Slackware installation, I was being lazy and trying to figure out if I could get slackpkg to "install" the officially updated kernel for Slackware instead of having slackpkg "upgrade" the kernel files. I couldn't see a way for slackpkg to do that so I just duplicated the affected kernel files/directories, let slackpkg do the kernel "upgrade", then cleaned up lilo.conf and links to make original kernel available.

On my lazy days I wish I could use slackpkg to "install" official Slackware kernel updates keeping the already installed kernel(s)

However, I don't generally approve of having software utilities behave differently based on file/module name. I prefer using an option/switch, perhaps with a warning when run in interactive mode, than hidden content/name dependent logic. That path does NOT lead to clean code as exception after exception is added through the years.
 
Old 06-06-2018, 12:12 PM   #4
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: Newport News, VA
Distribution: Slackware
Posts: 5,072

Rep: Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866Reputation: 2866
I like the idea behind this since this is a semi-frequent issue we see on the forum, however, I feel this would "muddy the waters" of what upgradepkg is designed to do. upgradepkg is one of those "raw" packages that should do just what I tell it to do. You'd also run into the problem of users never using the upgraded kernel and they'd still be running the kernel that was shipped with the Slackware version they're using.

Plus, I feel like most users use slackpkg to keep their systems upgraded, which is a lot more user friendly and is probably a better place to instigate something like this (the users who use upgradepkg manually are more likely to remember to handle their kernel upgrade and/or fix their system when something goes wrong). I personally think that /etc/slackpkg/blacklist should have the kernel portions uncommented by default. An alternative (or addition) could be to have slackpkg modified to run installpkg instead of upgradepkg when it comes across those packages or to keep the packages blacklisted by default but notify them when a kernel update was available in the changelog, but I realize that's extra work to code and I'm not willing to put in the time or effort to do it.

But to change upgradepkg to not actually upgrade some packages seems like the wrong direction to me.
 
Old 06-06-2018, 12:14 PM   #5
allend
Senior Member
 
Registered: Oct 2003
Location: Melbourne
Distribution: Slackware-current
Posts: 4,950

Rep: Reputation: 1702Reputation: 1702Reputation: 1702Reputation: 1702Reputation: 1702Reputation: 1702Reputation: 1702Reputation: 1702Reputation: 1702Reputation: 1702Reputation: 1702
This is horseshit. The only person able to update the kernel on a default Slackware system is the system administrator. If the system administrator screws up, there the blame lies.
 
10 members found this post helpful.
Old 06-06-2018, 12:31 PM   #6
a4z
Senior Member
 
Registered: Feb 2009
Posts: 1,576

Rep: Reputation: 664Reputation: 664Reputation: 664Reputation: 664Reputation: 664Reputation: 664
seems I did a lot wrong in the past.
always used slackpkg update , slackpkg upgrade-all
if there was a new kernel, it was installed,
manualy boot entry of course, if, than also initrd, but I became lazy recently and boot the huge kernel.
just works, never had any problem,
 
Old 06-06-2018, 01:46 PM   #7
montagdude
Member
 
Registered: Apr 2016
Distribution: Slackware
Posts: 946

Rep: Reputation: 670Reputation: 670Reputation: 670Reputation: 670Reputation: 670Reputation: 670
Quote:
Originally Posted by a4z View Post
seems I did a lot wrong in the past.
always used slackpkg update , slackpkg upgrade-all
if there was a new kernel, it was installed,
manualy boot entry of course, if, than also initrd, but I became lazy recently and boot the huge kernel.
just works, never had any problem,
Yup, I'd be interested to know if anyone has actually run into issues on -stable Slackware using the default approach. You only get into potential trouble when you start editing the vmlinuz* symlinks, edit lilo.conf to not point to them, or forget to run lilo. Of course, that's enough failure modes to warrant keeping backups of old kernels.
 
Old 06-06-2018, 01:48 PM   #8
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 1,493

Rep: Reputation: 4336Reputation: 4336Reputation: 4336Reputation: 4336Reputation: 4336Reputation: 4336Reputation: 4336Reputation: 4336Reputation: 4336Reputation: 4336Reputation: 4336
The proposed behavior is not within the scope of what upgradepkg is intended to do, or will ever do.
 
12 members found this post helpful.
Old 06-06-2018, 02:24 PM   #9
brianL
LQ 5k Club
 
Registered: Jan 2006
Location: Oldham, Lancs, England
Distribution: Slackware & Slackware64 14.2
Posts: 7,692
Blog Entries: 57

Rep: Reputation: Disabled
We've had a few kernel upgrades on 14.2: 4.4.14 => 4.4.88 => 4.4.111 => 4.4.115 => 4.4.118 => 4.4.132. And I've used slackpkg update and slackpkg upgrade-all for all of them. Used mkinitrd_command_generator.sh to create an initrd for the new generic kernel, edited lilo.conf, and ran lilo before rebooting into the new kernel. No problems. Could it be something to do with them all being 4.4.* ? If I was building my own kernel I would keep the old reliable one, just in case.
 
1 members found this post helpful.
Old 06-06-2018, 03:43 PM   #10
rkfb
Member
 
Registered: Oct 2003
Location: Guildford, England
Distribution: Slackware64 -current running TWM on Toshiba Satellite L650D
Posts: 414

Rep: Reputation: 94
I agree with volkerdi, write programs that do one thing and do it well.
 
Old 06-06-2018, 05:26 PM   #11
wigums
Member
 
Registered: Oct 2013
Location: Detroit
Distribution: slackware and debian
Posts: 41

Rep: Reputation: Disabled
personally i do the same as upnort. blacklist kernel and install the new kernel alongside the existing.
 
Old 06-06-2018, 05:41 PM   #12
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1 on Lenovo Thinkpad W520
Posts: 8,280

Rep: Reputation: 3052Reputation: 3052Reputation: 3052Reputation: 3052Reputation: 3052Reputation: 3052Reputation: 3052Reputation: 3052Reputation: 3052Reputation: 3052Reputation: 3052
I agree with the aim and the rationale. About the implementation, I favor using the tool that provide downloading and applying the update, possibly tentatively through a wrapper script. I plan to do that with slapt-get in Slint, I assume that this could be done with slackpkg in Slackware.
 
Old 06-06-2018, 06:20 PM   #13
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.2
Posts: 2,936

Rep: Reputation: 1330Reputation: 1330Reputation: 1330Reputation: 1330Reputation: 1330Reputation: 1330Reputation: 1330Reputation: 1330Reputation: 1330Reputation: 1330
https://rg3.github.io/slackroll/ will install new kernels instead of upgrading them. (It also treats glibc-solibs, sed and pkgtools upgrades special.)
 
2 members found this post helpful.
Old 06-06-2018, 07:28 PM   #14
montagdude
Member
 
Registered: Apr 2016
Distribution: Slackware
Posts: 946

Rep: Reputation: 670Reputation: 670Reputation: 670Reputation: 670Reputation: 670Reputation: 670
Quote:
Originally Posted by Richard Cranium View Post
https://rg3.github.io/slackroll/ will install new kernels instead of upgrading them. (It also treats glibc-solibs, sed and pkgtools upgrades special.)
Interesting. I didn't know about slackroll. I might have to give it a try sometime if I get bored.
 
Old 06-06-2018, 11:23 PM   #15
solarfields
Member
 
Registered: Feb 2006
Location: Outer Shpongolia
Distribution: Slackware
Posts: 833

Rep: Reputation: 321Reputation: 321Reputation: 321Reputation: 321
On a -stable system I have never had problems when upgrading the kernel with slackpkg. It always worked as expected. I would just rebuild initrd for the new generic kernel and take care of lilo.conf. On -current, however, it has happened that the new kernel does not boot. Luckily I had a custom built kernel (the latest release candidate at that time) that I could use. I don't know what was wrong, but the issue was gone with the next kernel update in -current. But... it is -current, some issues are expected.
 
  


Reply


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] X: "loading extension glx" "no screens found" "fatal server error" (w/ nvidia driver) Geremia Slackware 7 12-29-2014 11:00 AM
upgrade to kernel 2.6.16.1 : "make bzImage" print "parse error" math_physics Red Hat 2 06-29-2007 11:04 PM
How to install/upgrade packages from "unstable" ? rangalo Debian 9 03-13-2007 04:00 AM
Can't install "glibmm" library. "configure" script can't find "sigc++-2.0&q kornerr Linux - General 4 05-10-2005 02:32 PM
how to install the "packages that have been held back" when doing "apt-get upgrade&qu zero79 Debian 5 06-27-2004 08:19 PM

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

All times are GMT -5. The time now is 05:22 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