LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
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 07-14-2018, 04:34 PM   #1
Mechanikx
Member
 
Registered: Jul 2018
Posts: 350

Rep: Reputation: 258Reputation: 258Reputation: 258
Manually installing kernel security updates


I'm relatively new to Slackware and I would like to install kernel security updates manually. Essentially all the information I could find was about either upgrading from one version to another or compiling and installing a new kernel. I figured the process would be to install all the kernel updates then switch to the new kernel using the steps from "Switching to the Generic Kernel" tutorial from the SlackDocs, i.e. create a new initrd, edit lilo.conf, then reboot. But I came across a post that said not to update kernel headers unless glibc has been updated. This made me question whether or not I worked it out correctly. I'm hoping to get some clarification before I proceed.

I'm running Slackware 64 14.2 in Virtualbox with the generic kernel and lilo and have not updated glibc.

I download and install the following kernel packages:

Quote:
kernel-firmware
kernel-generic
kernel-modules
kernel-source
I then follow the steps from "Switching to the Generic Kernel" to boot the new kernel:

Quote:
Create a new initrd.
Edit lilo.conf with new kernel information.
Run lilo.
Reboot.
Is this correct?

Thank you for your time.
 
Old 07-14-2018, 04:53 PM   #2
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware
Posts: 1,893

Rep: Reputation: 1161Reputation: 1161Reputation: 1161Reputation: 1161Reputation: 1161Reputation: 1161Reputation: 1161Reputation: 1161Reputation: 1161
Look in /etc/slackpkg/blacklist. You'll find the default configuration has the following black listed:

kernel-firmware
kernel-generic
kernel-generic-smp
kernel-headers
kernel-huge
kernel-huge-smp
kernel-modules
kernel-modules-smp
kernel-source

Some Slackers do not enable automatic kernel updates and some do. I do not enable automatic updates on my production systems but I enable kernel updates in my Slackware VMs.

For those who manually update kernels, many prefer to use installpkg rather than upgradepkg. Using upgradepkg will remove the previous version. Using installpkg retains the previous kernel should the newer version prove problematic. LILO or GRUB need to be manually edited to support both versions. When the newer version proves successful, then manually remove the previous version packages.
 
Old 07-14-2018, 04:57 PM   #3
rkfb
Member
 
Registered: Oct 2003
Location: Guildford, England
Distribution: Slackware64 15.0 running i3
Posts: 494

Rep: Reputation: 174Reputation: 174
kernel-firmware doesn't necessarily change each time so just watch the version number and you may not need to upgrade it. If it does change I just download it and do upgradepkg.

I tend to keep my last working kernel as first choice in lilo.conf just in case and manually select the new kernel at the prompt. That way if there is a problem you should boot automatically in to the working one. Use installpkg instead of upgradepkg to install the new kernel then edit lilo.conf - don't forget to run lilo afterwards!

I keep two at a time loaded and removepkg the oldest.

If you compile programs or use something like sbopkg it would be a good idea to install kernel-headers from package group d/ .
 
1 members found this post helpful.
Old 07-14-2018, 05:12 PM   #4
Mechanikx
Member
 
Registered: Jul 2018
Posts: 350

Original Poster
Rep: Reputation: 258Reputation: 258Reputation: 258
Quote:
Originally Posted by upnort View Post
Look in /etc/slackpkg/blacklist. You'll find the default configuration has the following black listed:

kernel-firmware
kernel-generic
kernel-generic-smp
kernel-headers
kernel-huge
kernel-huge-smp
kernel-modules
kernel-modules-smp
kernel-source

Some Slackers do not enable automatic kernel updates and some do. I do not enable automatic updates on my production systems but I enable kernel updates in my Slackware VMs.

For those who manually update kernels, many prefer to use installpkg rather than upgradepkg. Using upgradepkg will remove the previous version. Using installpkg retains the previous kernel should the newer version prove problematic. LILO or GRUB need to be manually edited to support both versions. When the newer version proves successful, then manually remove the previous version packages.
Thank you for your reply.
 
Old 07-14-2018, 05:21 PM   #5
Mechanikx
Member
 
Registered: Jul 2018
Posts: 350

Original Poster
Rep: Reputation: 258Reputation: 258Reputation: 258
Quote:
Originally Posted by rkfb View Post
kernel-firmware doesn't necessarily change each time so just watch the version number and you may not need to upgrade it. If it does change I just download it and do upgradepkg.

I tend to keep my last working kernel as first choice in lilo.conf just in case and manually select the new kernel at the prompt. That way if there is a problem you should boot automatically in to the working one. Use installpkg instead of upgradepkg to install the new kernel then edit lilo.conf - don't forget to run lilo afterwards!

I keep two at a time loaded and removepkg the oldest.

If you compile programs or use something like sbopkg it would be a good idea to install kernel-headers from package group d/ .
Thanks for the reply.

Great. Other than what you mentioned about the firmware I can just go ahead and install the generic kernel, modules, and source?
 
Old 07-14-2018, 05:31 PM   #6
rkfb
Member
 
Registered: Oct 2003
Location: Guildford, England
Distribution: Slackware64 15.0 running i3
Posts: 494

Rep: Reputation: 174Reputation: 174
Quote:
Originally Posted by Mechanikx View Post
Thanks for the reply.

Great. Other than what you mentioned about the firmware I can just go ahead and install the generic kernel, modules, and source?
You can, yes, I'm just saying that it may be wise to include kernel-headers if you're thinking of compiling software.

Also, just looking at my post, if you don't use lilo then I have no advice on anything else but I'm sure someone else here can help with that.
 
1 members found this post helpful.
Old 07-14-2018, 05:42 PM   #7
Mechanikx
Member
 
Registered: Jul 2018
Posts: 350

Original Poster
Rep: Reputation: 258Reputation: 258Reputation: 258
Quote:
Originally Posted by rkfb View Post
You can, yes, I'm just saying that it may be wise to include kernel-headers if you're thinking of compiling software.

Also, just looking at my post, if you don't use lilo then I have no advice on anything else but I'm sure someone else here can help with that.
I do use lilo. I think I'm good to go now. If you don't mind me asking, why should kernel-headers be included if I want to compile software? Compiling and installing software manually is something I've been looking into lately and none of articles I've read mention kernel headers.
 
Old 07-15-2018, 08:28 AM   #8
chrisretusn
Senior Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware64-current
Posts: 2,949

Rep: Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531
I keep two kernels installed. One is the active kernel, the second in the last working kernel. This is my lilo.conf section related to the kernel images.
Code:
## kernel images ##
# Slackware64
image = /boot/vmlinuz
  initrd = /boot/initrd.gz
  label = Slackware64
# Working kernel
image = /boot/vmlinuz-working
  initrd = /boot/initrd-working.gz
  label = LastWorking
I also create a mkinitrd.conf file using /usr/share/mkinitrd/mkinitrd_command_generator.sh.

From the /boot/ directory, the steps I take after running slackpkg to update everything:
Note: I will use for the example my last update kernel versions.

1. Edit /etc/slackpkg/blacklist to comment out the kernel packages except for kernel-huge.
Note: I do not blacklist kernel-firmware or kernel-headers.
Code:
#kernel-generic
kernel-huge
#kernel-modules
#kernel-source
2. Run 'slackpkg download kernel' deselect firmware and headers since they have already been updated.

3. Edit /etc/slackpkg/blacklist to uncomment the kernel packages.
Code:
kernel-generic
kernel-huge
kernel-modules
kernel-source
4. Install the updated kernel packages.
installpkg /var/cache/packages/Slackware64/a/*.t?z
installpkg /var/cache/packages/Slackware64/k/*.t?z
Note: At this point I now have three kernels installed.

5. Delete the download packages as they are no longer needed.
rm /var/cache/packages/Slackware64/a/*
rm /var/cache/packages/Slackware64/k/*

6. Create the initrd for each kernel
mkinitrd -F -k 4.14.55
mkinitrd -F -k 4.14.53 -s initrd-working-tree -o initrd-working.gz

7. Set the working kernels symlinks to previous kernel
Note: I actually use mc to edit the symlinks.
rm System.map-working
ln -s System.map-generic-4.14.53 System.map-working
rm config-working
ln -s config-generic-4.14.53.x64 config-working
rm vmlinux-working
ln -s vmlinuz-generic-4.14.53 vmlinuz-working

8. Run lilo

9. Reboot

10. After the reboot I remove the unused kernel.

In virtual machines I don't blacklist the kernel packages (default) and let slackpkg update the kernel.

I have an Acer laptop I just acquired, was running with huge until I noted some things not loading, I switched to generic with an initrd. Used to mkinitrd_command_generator.sh to create a mkinitrd.conf which fixed the issue.
 
2 members found this post helpful.
Old 07-15-2018, 09:19 AM   #9
rkfb
Member
 
Registered: Oct 2003
Location: Guildford, England
Distribution: Slackware64 15.0 running i3
Posts: 494

Rep: Reputation: 174Reputation: 174
Quote:
Originally Posted by Mechanikx View Post
I do use lilo. I think I'm good to go now. If you don't mind me asking, why should kernel-headers be included if I want to compile software? Compiling and installing software manually is something I've been looking into lately and none of articles I've read mention kernel headers.
I can't pretend to know the actual reason but I was getting a '/lib/cpp fails sanity check' error every time I tried to compile a package.

A search here on LQ led me to thread:

https://www.linuxquestions.org/quest...e-time-823806/

which was marked as 'solved' following a suggestion to install kernel-headers. I now always upgrade kernel-headers along with the other kernel packages.
 
Old 07-16-2018, 02:14 PM   #10
Mechanikx
Member
 
Registered: Jul 2018
Posts: 350

Original Poster
Rep: Reputation: 258Reputation: 258Reputation: 258
Quote:
Originally Posted by chrisretusn View Post
I keep two kernels installed. One is the active kernel, the second in the last working kernel. This is my lilo.conf section related to the kernel images.
Code:
## kernel images ##
# Slackware64
image = /boot/vmlinuz
  initrd = /boot/initrd.gz
  label = Slackware64
# Working kernel
image = /boot/vmlinuz-working
  initrd = /boot/initrd-working.gz
  label = LastWorking
I also create a mkinitrd.conf file using /usr/share/mkinitrd/mkinitrd_command_generator.sh.

From the /boot/ directory, the steps I take after running slackpkg to update everything:
Note: I will use for the example my last update kernel versions.

1. Edit /etc/slackpkg/blacklist to comment out the kernel packages except for kernel-huge.
Note: I do not blacklist kernel-firmware or kernel-headers.
Code:
#kernel-generic
kernel-huge
#kernel-modules
#kernel-source
2. Run 'slackpkg download kernel' deselect firmware and headers since they have already been updated.

3. Edit /etc/slackpkg/blacklist to uncomment the kernel packages.
Code:
kernel-generic
kernel-huge
kernel-modules
kernel-source
4. Install the updated kernel packages.
installpkg /var/cache/packages/Slackware64/a/*.t?z
installpkg /var/cache/packages/Slackware64/k/*.t?z
Note: At this point I now have three kernels installed.

5. Delete the download packages as they are no longer needed.
rm /var/cache/packages/Slackware64/a/*
rm /var/cache/packages/Slackware64/k/*

6. Create the initrd for each kernel
mkinitrd -F -k 4.14.55
mkinitrd -F -k 4.14.53 -s initrd-working-tree -o initrd-working.gz

7. Set the working kernels symlinks to previous kernel
Note: I actually use mc to edit the symlinks.
rm System.map-working
ln -s System.map-generic-4.14.53 System.map-working
rm config-working
ln -s config-generic-4.14.53.x64 config-working
rm vmlinux-working
ln -s vmlinuz-generic-4.14.53 vmlinuz-working

8. Run lilo

9. Reboot

10. After the reboot I remove the unused kernel.

In virtual machines I don't blacklist the kernel packages (default) and let slackpkg update the kernel.

I have an Acer laptop I just acquired, was running with huge until I noted some things not loading, I switched to generic with an initrd. Used to mkinitrd_command_generator.sh to create a mkinitrd.conf which fixed the issue.
Thanks for your reply. I'm unclear about a couple of steps. Sorry if the answers are obvious.

On step 6 why do you create two initrds? The only reason I could think of is so the old one wouldn't be overwritten when the new one is created. In that case couldn't you just rename the old one first, before creating the new initrd?

On step 7 I thought you would have to create links to the new kernel? Unless I'm reading that wrong and that's what you're doing.

Thanks
 
Old 07-16-2018, 02:16 PM   #11
Mechanikx
Member
 
Registered: Jul 2018
Posts: 350

Original Poster
Rep: Reputation: 258Reputation: 258Reputation: 258
Quote:
Originally Posted by rkfb View Post
I can't pretend to know the actual reason but I was getting a '/lib/cpp fails sanity check' error every time I tried to compile a package.

A search here on LQ led me to thread:

https://www.linuxquestions.org/quest...e-time-823806/

which was marked as 'solved' following a suggestion to install kernel-headers. I now always upgrade kernel-headers along with the other kernel packages.
Gotcha. Thanks
 
Old 07-16-2018, 08:03 PM   #12
chrisretusn
Senior Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware64-current
Posts: 2,949

Rep: Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531
Quote:
Originally Posted by Mechanikx View Post
Thanks for your reply. I'm unclear about a couple of steps. Sorry if the answers are obvious.

On step 6 why do you create two initrds? The only reason I could think of is so the old one wouldn't be overwritten when the new one is created. In that case couldn't you just rename the old one first, before creating the new initrd?
I create to initrd's because I have two boot options in lilo.conf.

Slackware64; boots to the 4.14.55 kernel along with it's initrd.gz and it's initrd-tree source tree.
LastWorking; boots to the 4.14.53 kernel with it's seperate initrd-working.gz

I could probably rename for older kernel initrd.gz and initrd-working. It never really crossed my mind before. Just the way I do things I guess. I prefer to create fresh initrd.gs and tree for each kernel. It's also less letters to type than doing a move. <grin>

Quote:
On step 7 I thought you would have to create links to the new kernel? Unless I'm reading that wrong and that's what you're doing.
The is no need to create links to the new kernel. They are created by installpkg when kernel-generic is installed. I only need to change the links to the old working kernel since they would point to the kernel. If it's the first time I did this, then I would not have to change and links.

Example:
System.map -> System.map-generic-4.14.55 <<=== new kernel (Slackware64)
System.map-working -> System.map-generic-4.14.53 <<=== previous kernel (LastWorking)
System.map-working -> System.map-generic-4.14.52 <<=== old kernel (will be deleted)
config -> config-generic-4.14.55.x64
config-working -> config-generic-4.14.53.x64
config-working -> config-generic-4.14.52.x64
vmlinuz -> vmlinuz-generic-4.14.55
vmlinuz-working -> vmlinuz-generic-4.14.53
vmlinuz-working -> vmlinuz-generic-4.14.52



I hope you noticed that I do not download/install kernel-huge, it remains blacklisted. If I was to include kernel-generic and kernel-huge as part of the this install, kernel-huge would overwrite kernel-generic (as it should) and that would be the boot kernel. In this case I would have to adjust the links to point to kernel-generic.

Hope that answers your questions.

Last edited by chrisretusn; 07-16-2018 at 08:15 PM.
 
2 members found this post helpful.
Old 07-16-2018, 09:38 PM   #13
Mechanikx
Member
 
Registered: Jul 2018
Posts: 350

Original Poster
Rep: Reputation: 258Reputation: 258Reputation: 258
Quote:
Originally Posted by chrisretusn View Post
I create to initrd's because I have two boot options in lilo.conf.

Slackware64; boots to the 4.14.55 kernel along with it's initrd.gz and it's initrd-tree source tree.
LastWorking; boots to the 4.14.53 kernel with it's seperate initrd-working.gz

I could probably rename for older kernel initrd.gz and initrd-working. It never really crossed my mind before. Just the way I do things I guess. I prefer to create fresh initrd.gs and tree for each kernel. It's also less letters to type than doing a move. <grin>


The is no need to create links to the new kernel. They are created by installpkg when kernel-generic is installed. I only need to change the links to the old working kernel since they would point to the kernel. If it's the first time I did this, then I would not have to change and links.

Example:
System.map -> System.map-generic-4.14.55 <<=== new kernel (Slackware64)
System.map-working -> System.map-generic-4.14.53 <<=== previous kernel (LastWorking)
System.map-working -> System.map-generic-4.14.52 <<=== old kernel (will be deleted)
config -> config-generic-4.14.55.x64
config-working -> config-generic-4.14.53.x64
config-working -> config-generic-4.14.52.x64
vmlinuz -> vmlinuz-generic-4.14.55
vmlinuz-working -> vmlinuz-generic-4.14.53
vmlinuz-working -> vmlinuz-generic-4.14.52



I hope you noticed that I do not download/install kernel-huge, it remains blacklisted. If I was to include kernel-generic and kernel-huge as part of the this install, kernel-huge would overwrite kernel-generic (as it should) and that would be the boot kernel. In this case I would have to adjust the links to point to kernel-generic.

Hope that answers your questions.
Thanks for clearing that up for me. Your help is much appreciated.
 
1 members found this post helpful.
Old 07-16-2018, 11:30 PM   #14
chrisretusn
Senior Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware64-current
Posts: 2,949

Rep: Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531Reputation: 1531
Quote:
Originally Posted by Mechanikx View Post
Thanks for clearing that up for me. Your help is much appreciated.
Walang anuman. (Your welcome.)
 
  


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
gnutls, kernel and mariadb Security Updates tronayne Slackware 0 02-21-2014 06:48 PM
Slackware Recent Security Kernel Updates Procedure Ani Slackware 5 05-22-2013 08:30 AM
[SOLVED] Security updates custom kernel? kja_007700 Debian 4 01-31-2010 03:05 PM
LXer: Ksplice, Rebootless Linux Kernel Security Updates LXer Syndicated Linux News 0 04-26-2008 12:12 AM
Kernel security updates? Galaxy66 Slackware 5 02-21-2008 04:50 PM

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

All times are GMT -5. The time now is 04:57 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
Open Source Consulting | Domain Registration