New Kernel in Slackware 14.2

hitest · 06-12-2020, 08:57 AM

Various bug and security fixes.

Code:

Thu Jun 11 21:17:43 UTC 2020
patches/packages/linux-4.4.227/*:  Upgraded.
  These updates fix various bugs and security issues, including a mitigation
  for SRBDS (Special Register Buffer Data Sampling). SRBDS is an MDS-like
  speculative side channel that can leak bits from the random number generator
  (RNG) across cores and threads.
  Be sure to upgrade your initrd after upgrading the kernel packages.
  If you use lilo to boot your machine, be sure lilo.conf points to the correct
  kernel and initrd and run lilo as root to update the bootloader.
  If you use elilo to boot your machine, you should run eliloconfig to copy the
  kernel and initrd to the EFI System Partition.
  For more information, see:
    Fixed in 4.4.218:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11668
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11608
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11609
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10942
    Fixed in 4.4.219:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11494
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11565
    Fixed in 4.4.220:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12826
    Fixed in 4.4.221:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19319
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12464
    Fixed in 4.4.222:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10751
    Fixed in 4.4.224:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10711
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1749
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12769
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10690
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13143
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19768
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12770
    Fixed in 4.4.225:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-9517
    Fixed in 4.4.226:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10732
    Fixed in 4.4.227:
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-0543
  (* Security fix *)
+--------------------------+

http://slackware.osuosl.org/slackwar.../ChangeLog.txt

tdmsoares · 06-12-2020, 11:36 AM

It's my first kernel update since I installed Slackware a few weeks ago

How can I tell if the boot is by initrd, grub, ou elilo?

When I type:

Code:

#grub-install -v
grub-install (GRUB) 2.00

But I have inside /boot/ the /initrd-tree folder

Inside /boot/efi/EFI/Slackware I have files like elilo.conf

ehartman · 06-12-2020, 12:25 PM

Now that we have got the newest 4.4 kernel again in 14.2, could we please have an updated kernel-firmware package too?
The current one is already more then 6 months old (kernel-firmware-20191108_f1100dd-noarch) and doesn't have the newest ligations for the recent hardware security problems.

bassmadrigal · 06-12-2020, 01:21 PM

Quote:

Originally Posted by tdmsoares

It's my first kernel update since I installed Slackware a few weeks ago

How can I tell if the boot is by initrd, grub, ou elilo?

When I type:

Code:

#grub-install -v
grub-install (GRUB) 2.00

But I have inside /boot/ the /initrd-tree folder

Inside /boot/efi/EFI/Slackware I have files like elilo.conf

If you didn't do anything out of the ordinary and just followed the stock install, you have elilo and no initrd. It *should* be as simple as running eliloconfig, which will copy the correct kernel to the EFI partition and make sure your elilo.conf is updated properly.

colorpurple21859 · 06-12-2020, 04:10 PM

You need to run

Code:

grub-mkconfig -o /boot/grub/grub.cfg

to update the grub menu
Not grub-install with a kernel update. Grub-install only installs boot code to the mbr/efi partition

tdmsoares · 06-12-2020, 07:01 PM

I was afraid to upgrade the kernel (it was 4.4.14)
Follow the instructions I downloaded all kernel files from x86_64 and ran upgradepkg for all of them, and then with the advice of bassmadrigal, I typed eliloconfig.
Reboot the computer, it worked fine: only a message:

Quote:

depmod: WARNING: could not open /lib/modules/4.4.14/modules.order: No such file or directory
depmod: WARNING: could not open /lib/modules/4.4.14/modules.builtin: No such file or directory

Should I worry about, or I could let go these messages, since my computer is working fine now with the fresh 4.4.227 kernel?

bassmadrigal · 06-12-2020, 10:46 PM

That means that it is running a 4.4.14 kernel and not your newer one. If you run uname -r, it will likely say 4.4.14.

It's hard to know what's wrong without knowing how your system is setup. Ultimately, eliloconfig will take the kernel that is symlinked to /boot/vmlinuz and copy that to the EFI partition.

Can you provide the output of the following:

Code:

ls -l /boot

However, with you stating you ran upgradepkg on the kernel packages and you still managed to boot a 4.4.14 kernel, I'm guessing you're actually using legacy booting, not EFI booting. This should be able to be checked by seeing if the /sys/firmware/efi/ directory exists.

tdmsoares · 06-13-2020, 08:42 AM

Quote:

Originally Posted by bassmadrigal

That means that it is running a 4.4.14 kernel and not your newer one. If you run uname -r, it will likely say 4.4.14.

It's hard to know what's wrong without knowing how your system is setup. Ultimately, eliloconfig will take the kernel that is symlinked to /boot/vmlinuz and copy that to the EFI partition.

Can you provide the output of the following:

Code:

ls -l /boot

However, with you stating you ran upgradepkg on the kernel packages and you still managed to boot a 4.4.14 kernel, I'm guessing you're actually using legacy booting, not EFI booting. This should be able to be checked by seeing if the /sys/firmware/efi/ directory exists.

Here is the content of /boot:

Code:

$ls -l /boot
lrwxrwxrwx  1 root root      37 May 22 19:30 README.initrd -> /usr/doc/mkinitrd-1.4.8/README.initrd
lrwxrwxrwx  1 root root      23 Jun 12 20:02 System.map -> System.map-huge-4.4.227
-rw-r--r--  1 root root 2759583 Jun 11 17:07 System.map-generic-4.4.227
-rw-r--r--  1 root root 3995627 Jun 11 17:06 System.map-huge-4.4.227
-rw-r--r--  1 root root     426 Apr 21  2016 coffee.dat
lrwxrwxrwx  1 root root      23 Jun 12 20:02 config -> config-huge-4.4.227.x64
-rw-r--r--  1 root root  160260 Jun 11 17:06 config-generic-4.4.227.x64
-rw-r--r--  1 root root  160260 Jun 11 17:04 config-huge-4.4.227.x64
drwxr-xr-x  4 root root    4096 Dec 31  1969 efi
-rwxr-xr-x  1 root root  214120 Mar 29  2013 elilo-ia32.efi
-rwxr-xr-x  1 root root  239720 Apr  1  2016 elilo-x86_64.efi
drwxr-xr-x  2 root root    4096 Jun 13  2016 grub
drwxr-xr-x 14 root root    4096 Jun 12 13:03 initrd-tree
-rw-r--r--  1 root root 4014080 Jun 12 13:03 initrd.gz
-rw-r--r--  1 root root   22578 Apr 21  2016 inside.bmp
-rw-r--r--  1 root root     432 Apr 21  2016 inside.dat
-rw-r--r--  1 root root    6878 Apr 21  2016 onlyblue.bmp
-rw-r--r--  1 root root     424 Apr 21  2016 onlyblue.dat
-rw-r--r--  1 root root   15634 Mar 27  2011 slack.bmp
-rw-r--r--  1 root root   33192 Apr 21  2016 tuxlogo.bmp
-rw-r--r--  1 root root     423 Apr 21  2016 tuxlogo.dat
lrwxrwxrwx  1 root root      20 Jun 12 20:02 vmlinuz -> vmlinuz-huge-4.4.227
lrwxrwxrwx  1 root root      23 Jun 12 20:02 vmlinuz-generic -> vmlinuz-generic-4.4.227
-rw-r--r--  1 root root 4463552 Jun 11 17:07 vmlinuz-generic-4.4.227
lrwxrwxrwx  1 root root      20 Jun 12 20:02 vmlinuz-huge -> vmlinuz-huge-4.4.227
-rw-r--r--  1 root root 7742912 Jun 11 17:06 vmlinuz-huge-4.4.227

Interesting is the command uname -r already shows an updated kernel version:

Code:

$uname -r
4.4.227

bassmadrigal · 06-13-2020, 01:48 PM

Something you may have built previously might be trying to run a depmod on the older kernel, and maybe that's where your error is coming from.

Based on your /boot/ and uname -r output, it seems like you had a successful upgrade to 4.4.227 and maybe the error message won't be a big deal. If you do have any 3rd-party packages that include kernel modules (virtualbox, nvidia drivers, etc), they may be the cause and would likely just require a rebuild.

hitest · 06-13-2020, 02:02 PM

Quote:

Originally Posted by tdmsoares

Should I worry about, or I could let go these messages, since my computer is working fine now with the fresh 4.4.227 kernel?

As bassmadrigal stated that error may be related to third party applications. I've seen similar errors when I've done a kernel upgrade that related to virtualbox. Re-installing virtualbox solved the issue for me.

tdmsoares · 06-13-2020, 06:46 PM

I made a reboot in the computer: No more Warning Messages

The problem now is Virtualbox: In full screen mode doesn't show anything, no matter what VM (linux or Windows) I was running (and before it worked fine). In Windowed mode works fine though

I am using version 6.1.8 (downloaded from Virtualbox website), I uninstalled and installed again but the problem continues. I already run the command:

Code:

/sbin/rcvboxdrv setup

Is this problem caused by the kernel update?

quickbreakfast · 06-13-2020, 10:50 PM

It is my first kernel update too.

Quote:

Originally Posted by tdmsoares

with the advice of bassmadrigal, I typed eliloconfig.

when I type eliloconf, I get

Code:

bash-4.3# eliloconfig
ERROR:  System is not running under UEFI.
bash-4.3#

Which answers the question of whether I'm using elilo.

However with my kernel update the computer would not boot from the vmlinuz-generic or vmlinuz-generic-4.4.227

During the boot to either of the above files, the computer told me there were no modules for 4.4.227. Nor would my root partition mount.

I had to edit lilo.conf to refer to vmlinuz

Code:

ls -l /boot
total 34052
lrwxrwxrwx  1 root root      38 May  3 14:01 README.initrd -> /usr/doc/mkinitrd-1.4.10/README.initrd
lrwxrwxrwx  1 root root      23 Jun 14 11:45 System.map -> System.map-huge-4.4.227
-rw-r--r--  1 root root 2759583 Jun 12 06:07 System.map-generic-4.4.227
-rw-r--r--  1 root root 3995627 Jun 12 06:06 System.map-huge-4.4.227
-rw-r--r--  1 root root     512 May  2 11:22 boot.0800
-rw-r--r--  1 root root     168 May  2 11:22 boot_message.txt
-rw-r--r--  1 root root     426 Apr 22  2016 coffee.dat
lrwxrwxrwx  1 root root      23 Jun 14 11:45 config -> config-huge-4.4.227.x64
-rw-r--r--  1 root root  160260 Jun 12 06:06 config-generic-4.4.227.x64
-rw-r--r--  1 root root  160260 Jun 12 06:04 config-huge-4.4.227.x64
-rwxr-xr-x  1 root root  215987 Nov 21  2017 elilo-ia32.efi
-rwxr-xr-x  1 root root  237749 Nov 21  2017 elilo-x86_64.efi
drwxr-xr-x  2 root root    4096 Jun 13  2016 grub
drwxr-xr-x 14 root root    4096 Jun 14 12:52 initrd-tree
-rw-r--r--  1 root root 7361484 Jun 14 12:52 initrd.gz
-rw-r--r--  1 root root   22578 Apr 22  2016 inside.bmp
-rw-r--r--  1 root root     432 Apr 22  2016 inside.dat
-rw-r--r--  1 root root 7289349 May 17 08:10 intrd.gz
-rw-------  1 root root  335360 Jun 14 13:18 map
-rw-r--r--  1 root root    6878 Apr 22  2016 onlyblue.bmp
-rw-r--r--  1 root root     424 Apr 22  2016 onlyblue.dat
-rw-r--r--  1 root root   15634 Mar 27  2011 slack.bmp
-rw-r--r--  1 root root   33192 Apr 22  2016 tuxlogo.bmp
-rw-r--r--  1 root root     423 Apr 22  2016 tuxlogo.dat
lrwxrwxrwx  1 root root      20 Jun 14 11:45 vmlinuz -> vmlinuz-huge-4.4.227
lrwxrwxrwx  1 root root      23 Jun 14 11:45 vmlinuz-generic -> vmlinuz-generic-4.4.227
-rw-r--r--  1 root root 4463552 Jun 12 06:07 vmlinuz-generic-4.4.227
lrwxrwxrwx  1 root root      20 Jun 14 11:45 vmlinuz-huge -> vmlinuz-huge-4.4.227
-rw-r--r--  1 root root 7742912 Jun 12 06:06 vmlinuz-huge-4.4.227
bash-4.3#

So because I saw a lot of removing directories, I'm curious. Am I running the new generic kernel?

ehartman · 06-13-2020, 11:42 PM

Quote:

Originally Posted by tdmsoares

Is this problem caused by the kernel update?

Probably yes. VB always lags behind as regards to kernel updates.
VB 6.1.10 should have been updated for Linux kernel version 5.7 support, but it probably is best to use a 5.6.x one or even the latest 5.4 long term stable release.

cwizardone · 06-14-2020, 12:23 AM

Quote:

Originally Posted by ehartman

Probably yes. VB always lags behind as regards to kernel updates.
VB 6.1.10 should have been updated for Linux kernel version 5.7 support, but it probably is best to use a 5.6.x one or even the latest 5.4 long term stable release.

VirtualBox was updated 05 June 2020, and does work with the 5.7 kernel.

ehartman · 06-14-2020, 04:32 AM

Quote:

Originally Posted by cwizardone

VirtualBox was updated 05 June 2020, and does work with the 5.7 kernel.

Yaeh, but he was referring to the older 6.1.8 version