LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   kernel-headers removed from blacklist file in slackware-current? (https://www.linuxquestions.org/questions/slackware-14/kernel-headers-removed-from-blacklist-file-in-slackware-current-4175677073/)

luvr 06-14-2020 02:11 PM

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.

bassmadrigal 06-14-2020 11:46 PM

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.

chrisretusn 06-15-2020 05:58 AM

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.


slac 06-15-2020 07:33 AM

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.

0XBF 06-15-2020 09:23 AM

Quote:

Originally Posted by slac (Post 6134533)
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

Lenard Spencer 06-15-2020 11:12 AM

Actually, if kernel-headers is not on the blacklist, it DOES get upgraded every time.

abga 06-15-2020 12:52 PM

@slac
I've been asking myself the same question(s).

@0XBF
Thanks for the info & links provided.

luvr 06-15-2020 01:02 PM

Quote:

Originally Posted by Lenard Spencer (Post 6134591)
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.

slac 06-16-2020 12:10 AM

Quote:

Originally Posted by slac (Post 6134533)
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 (Post 6134553)
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?

bassmadrigal 06-16-2020 12:48 AM

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.

slac 06-16-2020 03:01 AM

Quote:

Originally Posted by bassmadrigal (Post 6134825)
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.

chrisretusn 06-16-2020 07:45 AM

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

luvr 06-17-2020 12:22 PM

Quote:

Originally Posted by chrisretusn (Post 6134956)
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.

bassmadrigal 06-17-2020 05:32 PM

Quote:

Originally Posted by luvr (Post 6135394)
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.

chrisretusn 06-18-2020 09:42 AM

Quote:

Originally Posted by luvr (Post 6135394)
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.


All times are GMT -5. The time now is 04:14 AM.