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-14-2020, 02:11 PM   #1
luvr
Member
 
Registered: May 2005
Location: Boom - The Home Town of Tomorrowland, Belgium
Distribution: Slackware, Xubuntu
Posts: 339
Blog Entries: 1

Rep: Reputation: 138Reputation: 138
kernel-headers removed from blacklist file in slackware-current?


I’ve just noticed that the “#kernel-headers” line got removed from the ‘etc/slackpkg/blacklist.new’ file, as distributed with Slackware-current:
Code:
#
# Automated upgrade of kernel packages aren't a good idea (and you need to
# run "lilo" after upgrade). If you think the same, uncomment the lines
# below 
#
#kernel-generic
#kernel-generic-smp
#kernel-huge
#kernel-huge-smp
#kernel-modules
#kernel-modules-smp
#kernel-source
Was that done intentionally?

I understand that the “#kernel-firmware” line got removed, since the firmware package version doesn’t really correspond directly to that of the actual kernel packages, but I’m quite surprised by the removal of the “#kernel-headers” line.
 
Old 06-14-2020, 11:46 PM   #2
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 7,151

Rep: Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820
Pat has felt for years that the kernel-headers package is not as big of a deal as it was back in the 2.4 and 2.6 kernel era. That might be his reasoning to remove it.
 
3 members found this post helpful.
Old 06-15-2020, 05:58 AM   #3
chrisretusn
Senior Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware64-current
Posts: 1,207

Rep: Reputation: 492Reputation: 492Reputation: 492Reputation: 492Reputation: 492
It was intentional. See ChangeLog.txt from Tue Oct 10 18:08:31 UTC 2017
Code:
ap/slackpkg-2.82.2-noarch-1.txz:  Upgraded.
  Updated mirrors-x86*.sample to remove dead mirrors and clarify
  intent to use mirrors.slackware.com.
  Add /usr/share/vim/ and /var/yp/ to search path for .new files.
  Minor tweaks to default blacklist file.
  Minor tweaks to manual pages.
  Thanks to Robby Workman.
 
1 members found this post helpful.
Old 06-15-2020, 07:33 AM   #4
slac
Member
 
Registered: May 2019
Posts: 82

Rep: Reputation: Disabled
Yeah, I have read somewhere else that is important to only install linux-headers corresponding to the version of the ones that were used to compile glibc though I do not why it is important. It would be good if someone explains it.
 
2 members found this post helpful.
Old 06-15-2020, 09:23 AM   #5
0XBF
Member
 
Registered: Nov 2018
Location: Winnipeg
Distribution: Slackware
Posts: 188

Rep: Reputation: 138Reputation: 138
Quote:
Originally Posted by slac View Post
Yeah, I have read somewhere else that is important to only install linux-headers corresponding to the version of the ones that were used to compile glibc though I do not why it is important. It would be good if someone explains it.
I tried to find an answer to your question but now I'm a little confused since what glibc's faq and the kernel documentation say seem to conflict on the subject. I'll pull some quotes out and you can see if it makes sense to you...

From glibc faq:
Quote:
The headers from the most recent Linux kernel should be used. The headers used while compiling the GNU C library and the kernel binary used when using the library do not need to match. The GNU C library runs without problems on kernels that are older than the kernel headers used. The other way round (compiling the GNU C library with old kernel headers and running on a recent kernel) does not necessarily work as expected. For example you can't use new kernel features if you used old kernel headers to compile the GNU C library.
Taken from: https://sourceware.org/glibc/wiki/FA...uld_be_used.3F

From kernel documentation:
Quote:
Kernel headers are backwards compatible, but not forwards compatible. This
means that a program built against a C library using older kernel headers
should run on a newer kernel (although it may not have access to new
features), but a program built against newer kernel headers may not work on an
older kernel.
Taken from: https://www.kernel.org/doc/Documenta...rs_install.txt
 
4 members found this post helpful.
Old 06-15-2020, 11:12 AM   #6
Lenard Spencer
Member
 
Registered: Sep 2004
Location: Florida
Distribution: Slackware, Linux from Scratch
Posts: 255

Rep: Reputation: 78
Actually, if kernel-headers is not on the blacklist, it DOES get upgraded every time.
 
Old 06-15-2020, 12:52 PM   #7
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,551

Rep: Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866Reputation: 866
@slac
I've been asking myself the same question(s).

@0XBF
Thanks for the info & links provided.
 
Old 06-15-2020, 01:02 PM   #8
luvr
Member
 
Registered: May 2005
Location: Boom - The Home Town of Tomorrowland, Belgium
Distribution: Slackware, Xubuntu
Posts: 339

Original Poster
Blog Entries: 1

Rep: Reputation: 138Reputation: 138
Quote:
Originally Posted by Lenard Spencer View Post
Actually, if kernel-headers is not on the blacklist, it DOES get upgraded every time.
Hmmm… Indeed… The most recent “kernel-headers” version will, then, be the only version installed on the system.

Seems to confirm that (as bassmadrigal noted), Pat must be right that the “kernel-headers” package is no longer such a big deal.

I’ll let this sink in a little further, and then decide whether or not I want to keep the “kernel-headers” package blacklisted. Probably also will have to think through how I can improve my ‘upgrade-kernel.sh’ script to handle the case where not all of the kernel packages are blacklisted.
 
Old 06-16-2020, 12:10 AM   #9
slac
Member
 
Registered: May 2019
Posts: 82

Rep: Reputation: Disabled
Question

Quote:
Originally Posted by slac View Post
Yeah, I have read somewhere else that is important to only install linux-headers corresponding to the version of the ones that were used to compile glibc though I do not why it is important. It would be good if someone explains it.
I have finally found a place from where I read such thing: http://www.linuxfromscratch.org/lfs/...ootable-kernel

Quote:
Originally Posted by 0XBF View Post
I tried to find an answer to your question but now I'm a little confused since what glibc's faq and the kernel documentation say seem to conflict on the subject. I'll pull some quotes out and you can see if it makes sense to you...

From glibc faq:

Taken from: https://sourceware.org/glibc/wiki/FA...uld_be_used.3F

From kernel documentation:

Taken from: https://www.kernel.org/doc/Documenta...rs_install.txt
Look at the end of the link from before (LFS Book), just before the chapter 8.2.3, there should be a warning saying:

Quote:

Warning

The headers in the system's include directory (/usr/include) should always be the ones against which Glibc was compiled, that is, the sanitised headers installed in Section 6.7, “Linux-5.5.3 API Headers”. Therefore, they should never be replaced by either the raw kernel headers or any other kernel sanitized headers.
That is the reason why I was asking myself if it is correct to replace the linux-headers or not. Maybe, that is a correct thing to do but only under certain circumstances and if so: What would be, such circumstances?
 
Old 06-16-2020, 12:48 AM   #10
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 7,151

Rep: Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820
This may well be the "by the book" answer, but the reality is it doesn't really matter anymore. Just look at everyone tracking -current and upgrading their kernel-headers package every time Pat pushes out a new update.

From a few posts later from my previous link, Pat states the following:

Quote:
My recollection is that the warning was issued either as the kernel was going from 2.2 to 2.4, or from 2.4 to 2.6, and was a good warning then. Every kernel since 2.6 has basically followed a similar structure and I've encountered no incompatibilities using the kernel-headers from whatever kernel is installed, regardless of whether that's what glibc was compiled against.
It seems that the kernel developers have stabilized things and the warning doesn't need to be followed anymore.

At least according to Pat and I think he has enough experience for me to follow suit and shrug off worrying about kernel-headers packages.
 
4 members found this post helpful.
Old 06-16-2020, 03:01 AM   #11
slac
Member
 
Registered: May 2019
Posts: 82

Rep: Reputation: Disabled
Thumbs up

Quote:
Originally Posted by bassmadrigal View Post
This may well be the "by the book" answer, but the reality is it doesn't really matter anymore. Just look at everyone tracking -current and upgrading their kernel-headers package every time Pat pushes out a new update.

From a few posts later from my previous link, Pat states the following:



It seems that the kernel developers have stabilized things and the warning doesn't need to be followed anymore.

At least according to Pat and I think he has enough experience for me to follow suit and shrug off worrying about kernel-headers packages.
Yes, seems like updating kernel-headers does not bring anything bad in most of the cases.

It still is a package that is worth to blacklist in some scenarios. For example, seems like nothing bad happens when using linux-headers older to the kernel but there may occur a problem when using linux-headers newer to the kernel and that could happen if switching in between LTS Linux Kernels like going from using linux-5.4.46-lts and its headers to use linux-4.4.14-lts. Anyway, that scenario will only happen if user intervention is made and since kernel-* and linux-headers packages are updated at the same time (by the maintainer, as far as I can see in the ChangeLog) that will likely not happen, by default.
 
Old 06-16-2020, 07:45 AM   #12
chrisretusn
Senior Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware64-current
Posts: 1,207

Rep: Reputation: 492Reputation: 492Reputation: 492Reputation: 492Reputation: 492
Here is my thoughts (rambling) on this. May not be the right ones, but makes sense to me.

In the expected normal usage of Slackware only one kernel version is installed. So when a kernel update is available you will be upgrading that one installed kernel version.

The packages kernel-modules and kernel-source are all installed to a versioned directory. The packages kernel-generic and kernel-huge are installed as versioned files. On the other hand, the packages kernel-firmware and kernel-headers are not installed this way.

Unless one has more than one kernel version installed there is no reason as I see it to not let kernel-firmware and kernel-headers be automatically upgraded by slackpkg since you should be upgrading the kernel soon after manually so everything will fall in to place. One could make the case for kernel-source also but I don't plan to push that envelope because I have other third party kernel modules that require building after a kernel update.

Another way to look at it. Which kernel packages have to most potential to break a system if slackpkg is allowed to automatically upgrade them. In my opinion, those would be kernel-generic, kernel-huge and kernel-modules. Reasoning is because I must take steps after those kernel packages are upgraded. By doing a kernel upgrade manually I am less apt to forget to take those necessary steps.

If you only have one one kernel version installed and you are using the huge kernel then blacklisting the kernel packages doesn't really make sense. By default, the huge kernel will be the default boot kernel (generic upgrades, the huge upgrades, leaving huge as the default). On the other hand, if you are using the generic kernel, I would remove the huge kernel and I would blacklist kernel-huge so it doesn't install or upgrade. This ensures the upgrade puts the generic kernel as the default boot kernel. When slackpkg is finished it reminds you your kernel image has been updated and you should take steps to handle updating your bootloader and initrd. Do those steps and your done. I have one system that I do allow slackpkg package to upgrade the kernel. My slackware64-current test system. It uses the huge kernel. Only step to take after slackpkg is finished is to run lilo.

Now if you have multiple kernel versions installed. Then I would say it makes sense to include kernel-headers in the blacklist. All of my other machine have more than one kernel installed. On these systems I blacklist all kernel packages except kernel-firmware and depending on which kernel I am using either kernel-generic or kernel-huge. In this case I never upgrade my kernels. I remove or install them. This is a use case where it makes sense to blacklist kernel-headers so all kernel versions are easily distinguished at the installed package level.

Hope this make sense. My

Last edited by chrisretusn; 06-16-2020 at 07:48 AM.
 
Old 06-17-2020, 12:22 PM   #13
luvr
Member
 
Registered: May 2005
Location: Boom - The Home Town of Tomorrowland, Belgium
Distribution: Slackware, Xubuntu
Posts: 339

Original Poster
Blog Entries: 1

Rep: Reputation: 138Reputation: 138
Quote:
Originally Posted by chrisretusn View Post
The packages kernel-modules and kernel-source are all installed to a versioned directory. The packages kernel-generic and kernel-huge are installed as versioned files. On the other hand, the packages kernel-firmware and kernel-headers are not installed this way.
You’re right… I hadn’t even considered this, but it kind of settles the question for me. It clearly doesn’t make sense (any longer?) to have multiple versions of the “kernel-headers” package installed, because they will all point to the exact same files anyway.

In other words, it’s a whole lot cleaner to let slackpkg upgrade the “kernel-headers” package and have it remove the older version.

As for the “kernel-firmware” package, I don’t really consider that part of the kernel family of packages, since it doesn’t even follow the same version numbering scheme.
 
Old 06-17-2020, 05:32 PM   #14
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 7,151

Rep: Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820Reputation: 4820
Quote:
Originally Posted by luvr View Post
As for the “kernel-firmware” package, I don’t really consider that part of the kernel family of packages, since it doesn’t even follow the same version numbering scheme.
The kernel-firmware are just blobs that are upgraded on kernel.org's git. Ideally, they should be what the latest kernels require, but sometimes there are updates made for newer kernels, which breaks older kernels. But they tend to be relatively easy to revert.
 
1 members found this post helpful.
Old 06-18-2020, 09:42 AM   #15
chrisretusn
Senior Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware64-current
Posts: 1,207

Rep: Reputation: 492Reputation: 492Reputation: 492Reputation: 492Reputation: 492
Quote:
Originally Posted by luvr View Post
It clearly doesn’t make sense (any longer?) to have multiple versions of the “kernel-headers” package installed, because they will all point to the exact same files anyway.

In other words, it’s a whole lot cleaner to let slackpkg upgrade the “kernel-headers” package and have it remove the older version.
Yes, except in a system with more than one kernel installed. I think it's a good idea to blacklist all kernel packages except for firmware. I my use case at this moment I have two kernels installed. I had three installed for a while back.

Code:
# USEBL=off slackpkg search kernel

Looking for kernel in package list. Please wait... DONE

The list below shows all packages with name matching "kernel".

[ Status      ] [ Repository  ] [ Package                                                            ]
  installed       slackware64     kernel-firmware-20200610_887d2a1-noarch-1                         
  installed       slackware64     kernel-generic-5.4.46-x86_64-1                                    
  installed       slackware64     kernel-headers-5.4.46-x86-1                                       
  installed       slackware64     kernel-modules-5.4.46-x86_64-1                                    
  installed       slackware64     kernel-source-5.4.46-noarch-1                                     
  uninstalled     slackware64     kernel-huge-5.4.46-x86_64-1                                       
  upgrade         slackware64     kernel-generic-5.4.45-x86_64-1 --> kernel-generic-5.4.46-x86_64-1 
  upgrade         slackware64     kernel-headers-5.4.45-x86-1 --> kernel-headers-5.4.46-x86-1       
  upgrade         slackware64     kernel-modules-5.4.45-x86_64-1 --> kernel-modules-5.4.46-x86_64-1 
  upgrade         slackware64     kernel-source-5.4.45-noarch-1 --> kernel-source-5.4.46-noarch-1
When the next kernel update arrives, I will remove the 5.4.45 kernel, then download and install the updated kernel. I do not upgrade the kernel.

Last edited by chrisretusn; 06-18-2020 at 09:44 AM.
 
  


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
[kernel-headers-3.2.45-x86-3] OR [kernel-headers-3.2.45_smp-x86-3]? Sefid par Slackware 3 07-24-2013 09:59 AM
Zypper wants to dl the wrong kernel headers... YaST doesnt have current headers zorb SUSE / openSUSE 2 11-28-2009 11:12 AM
Automatic removal of kernel headers package when kernel packages are removed bgoodr Debian 3 12-30-2008 08:14 PM
?Odd bug. modprobe.blacklist~ behaves as modprobe.blacklist arubin Slackware 1 11-05-2006 07:08 PM

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

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