Slackware-current kernel 4.14.15 and VMware workstation 12.5. vmnet/vmmon modules issues

Since my recent kernel upgrades to the 4.14. tree, got troubles using vmware workstation. Especially logs about unable to build kernels modules, VMNET and VMMON.

First… the UI would not start after install of WS12.5.9.  From logs, got the `Unable to load libfontconfig.so.1` classic problem.

Solution found here several month ago, and it’s still works: https://malisa.wordpress.com/2017/07/06/vmware-workstation-12-5-7-on-slackware-14-2-current-kernel-4-9-35/

# cd /usr/lib/vmware/lib/libz.so.1
# mv libz.so.1 libz.so.1.old
# ln -s /usr/lib64/libz.so.1 .

Then I could start the  Workstation GUI, but with my new kernel, got a message about rebuilding kernel modules, makes sense:

Tested on VMware Workstation 12.5.7 and latest 12.5.9 ( got no license for 14.1 )

From net searches, seems to be related to kernel code change since 4.13 tree. It’s fixed in workstation 14.0/1 from the VMware release notes, but it’s not backported in 12.5….

To fix, got no credit but I hope to make you save some time…

Found a lot of discussion on VMware forum, with various patches and so on, finally, I ended up just cloning the repos from mkubecek on github: https://github.com/mkubecek/vmware-host-modules

It has done magic for me, cause it just worked out of the box  🙂

#clone repos
:~/vmware # git clone https://github.com/mkubecek/vmware-host-modules.git
Cloning into 'vmware-host-modules'...
remote: Counting objects: 639, done.
remote: Total 639 (delta 0), reused 0 (delta 0), pack-reused 639
Receiving objects: 100% (639/639), 657.40 KiB | 1.46 MiB/s, done.
Resolving deltas: 100% (445/445), done.
:~/vmware #
:~/vmware # cd vmware-host-modules/
:~/vmware/vmware-host-modules (master) #

# checkout the branch matching your release.
:~/vmware/vmware-host-modules (master) # git checkout origin/workstation-12.5.9
:~/vmware/vmware-host-modules ((w12.5.9-k4.15)) # ls
LICENSE README vmmon-only/ vmnet-only/
:~/vmware/vmware-host-modules ((w12.5.9-k4.15)) #

I’ve been to vmnet-only and vmmon-only directory then try to `make` module ( if  it won’t build here, it will not build as well with vmware tool – it was building fine 😉 )

If it builds okay, then you can replace the vmnet/vmmom from upstream.

# build the archive
:~/vmware/vmware-host-modules ((w12.5.9-k4.15)) # tar cf vmmon.tar vmmon-only
:~/vmware/vmware-host-modules ((w12.5.9-k4.15)) # tar cf vmnet.tar vmnet-only

# backup the old module source ( just in case.. )
cp /usr/lib/vmware/modules/source/vmmon.tar /usr/lib/vmware/modules/source/vmmon.tar.12.5.9.bk
cp /usr/lib/vmware/modules/source/vmnet.tar /usr/lib/vmware/modules/source/vmnet.tar.12.5.9.bk

# replace upstream module source
:~/vmware/vmware-host-modules ((w12.5.9-k4.15)) # cp vmmon.tar /usr/lib/vmware/modules/source/
:~/vmware/vmware-host-modules ((w12.5.9-k4.15)) # cp vmnet.tar /usr/lib/vmware/modules/source/

 

Then you can try to build and install the modules with the vmware-modconfig utility

# vmware-modconfig --console --install-all

vmare-modconfig restart vmware services at the end of the module install, all green

<SNIP>
Starting VMware services:
   Virtual machine monitor                  [ OK ]
   Virtual machine communication interface  [ OK ]
   VM communication interface socket family [ OK ]
   Blocking file system                     [ OK ]
   Virtual ethernet                         [ OK ]
   VMware Authentication Daemon             [ OK ]
   Shared Memory Available                  [ OK ]
:/usr/lib/vmware/modules/source #

Then you can start vmware, the GUI popped up for me 🙂

 

Enjoy!

 

 

 

Slackware Slackpkg kernel update

Prior to get to the action, here is a reminder on how slackpkg update and blacklist works.
Why should you update your kernel ? and What you should take care off prior to start the kernel update ?

Why should you update the kernel ?

At least 3 reasons for that:

  • Bugfixes
  • Features
  • Security

Even if you are not looking for fancy features or not experiencing bugs, you should look for security patches.

Especially in those times of #spectre and #meltdown, you probably have seen a lot of kernel upgrade party.

Slackware is stability oriented, and won’t propose a new kernel everyday ( even on -current ). When security comes into play, then updates come at a higher pace.

Within the first week of 2018, you had two kernel updates proposed on -current:  4.14.11 and shortly after 4.14.12 ( cannot tell for Stable 14.2).

If you follow the Slackware package tree, and if a new kernel is available, you can install it via the slackpkg utility. Let’s check it out.

Slackpkg upgrade process

Slackware ships both version with each update, the latest kernel on Current was 4.14.11 at beginning of writing. Below is what I got after searching packages with kernel in the name.

# slackpkg search kernel

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

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

[ installed ] - kernel-firmware-20180102git-noarch-1
[ installed ] - kernel-generic-4.14.11-x86_64-1
[ installed ] - kernel-huge-4.14.11-x86_64-2
[ installed ] - kernel-modules-4.14.11-x86_64-1
[ installed ] - kernel-headers-4.14.11-x86-1
[ installed ] - kernel-source-4.14.11-noarch-1

Those Kernel packages are handled by slackpkg, they can be removed, installed and upgraded but you can have only one version at any time.

If a newer kernel version is found when using slackpkg update then search, it will be an ‘upgrade’ of the running kernel to the newer version.

Just like any software, the ‘upgrade’ is: remove/delete the old version, and install the new one.

As a consequence, if the new kernel refuse to boot and you are not prepared to face it. You will be in trouble ( aka using liveCD/USB/Netboot to fix).

Slackpkg Blacklist

That might not be the best moment to write about slackpkg blacklist, but a reminder of what it is might help some people. This part might not be helpful if  you are already willing to upgrade your kernel, but maybe after the upgrade.

If you know the slackpkg tool, the classic combo slackpgk update / install-new / upgrade-all is familiar to you.

Slackware official documentation more than suggests you to blacklist the kernel packages to avoid the upgrade by mistake. Which is a clever advice.

As all advice, you can follow it or not 😉

The file /etc/slackpkg/blacklist is here for that ! There is already a kernel section, with common kernel packages commented.

You can un-comment them if you wish to.

#                                                                                                                                                                                                                                                                                
# 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                                                                                                                                                                                                                                                                    
kernel-firmware                                                                                                                                                                                                                                                                  
kernel-headers

When you blacklist a package, the slackpkg search won’t show any result anymore for it. You can use slackpkg file-search instead. Note file-search will return probably more than what you expect.

Luckily during the redaction, Slackware updated again the kernel to 4.14.12 which was nice for the demo.

# slackpkg search kernel

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

No package name matches the pattern.

#
# slackpkg file-search kernel

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

The list below shows the packages that contains "kernel" file.

[ installed ] - grub-2.02-x86_64-1
[  upgrade  ] - kernel-firmware-20180102git-noarch-1 --> kernel-firmware-20180104_65b1c68-noarch-1
[  upgrade  ] - kernel-generic-4.14.11-x86_64-1 --> kernel-generic-4.14.12-x86_64-1
[  upgrade  ] - kernel-huge-4.14.11-x86_64-2 --> kernel-huge-4.14.12-x86_64-1
[  upgrade  ] - kernel-modules-4.14.11-x86_64-1 --> kernel-modules-4.14.12-x86_64-1
[ installed ] - pkgtools-15.0-noarch-1
[ installed ] - pm-utils-1.4.1-x86_64-5
[  upgrade  ] - kernel-headers-4.14.11-x86-1 --> kernel-headers-4.14.12-x86-1
[  upgrade  ] - kernel-source-4.14.11-noarch-1 --> kernel-source-4.14.12-noarch-1
[ installed ] - kde-workspace-4.11.22-x86_64-4
[ installed ] - boost-1.66.0-x86_64-1
[ installed ] - fuse-2.9.7-x86_64-1
[ installed ] - libnl-1.1.4-x86_64-1
[ installed ] - libnl3-3.4.0-x86_64-1
[ installed ] - qt-4.8.7-x86_64-8
[ installed ] - texlive-2017.171108-x86_64-2

You can search specific packages using "slackpkg search package".

Here we can see that a new kernel is available for upgrade, but Slackpkg won’t be able to install the new one until the blacklist is removed ( which is what blacklisting is all about ).

 # slackpkg upgrade kernel

Checking local integrity... DONE
DONEking for kernel in package list. Please wait... 

No packages match the pattern for upgrade. Try:

	/usr/sbin/slackpkg install|reinstall 

# 

If you are not using blacklist, you are not concerned. If you just have discovered it, maybe you can ask yourself about using it in the future.

Backup the running kernel

Prior to install a new kernel, I try to have at least a backup kernel in case the new one refuse to boot. It will save the pain to find a livecd/usb/netboot to repair.

I choose to save both the HUGE and GENERIC kernel, I just copy them with another name. As the initrd is not part of any kernel packages, you don’t need to save it.

 # ls /boot/ | grep vmlinuz
vmlinuz@
vmlinuz-generic@
vmlinuz-generic-4.14.11
vmlinuz-huge@
vmlinuz-huge-4.14.11

Only vmlinuz-generic-4.14.11 and vmlinuz-huge-4.14.11 are considered. I add -bk- inside for backup.

# cp /boot/vmlinuz-generic-4.14.11 /boot/vmlinuz-bk-gen-4.14.11
# cp /boot/vmlinuz-huge-4.14.11 /boot/vmlinuz-bk-huge-4.14.11
# 
# ls /boot/ | grep vmlinuz
vmlinuz@
vmlinuz-bk-gen-4.14.11  <<<<<<<<
vmlinuz-bk-huge-4.14.11 <<<<<<<<
vmlinuz-generic@
vmlinuz-generic-4.14.11
vmlinuz-huge@
vmlinuz-huge-4.14.11

Then I edit the lilo configuration file to add the new entries.

# Linux bootable partition config begins                                                                                                  
image = /boot/vmlinuz                                                                                                                     
  root = /dev/sda1                                                                                                                        
  label = Linux                                                                                                                           
  read-only                                                                                                                               
                                                                                                                                          
image = /boot/vmlinuz-generic-4.14.11                                                                                                     
  initrd = /boot/initrd-4.14.11.gz                                                                                                        
  root = /dev/sda1                                                                                                                        
  label = gen-4.14.11                                                                                                                     
  read-only                                                                                                                               
                                                                                                                                          
image = /boot/vmlinuz-bk-huge-4.14.11                                                                                                  
  root = /dev/sda1                                                                                                                        
  label = bk-huge-4.4.11                                                                                                                  
  read-only
                                                                                                                                                                                                                                                                         
image = /boot/vmlinuz-bk-gen-4.14.11                                                                                                    
  initrd = /boot/initrd-4.14.11.gz                                                                                                        
  root = /dev/sda1                                                                                                                        
  label = bk-gen-4.14.11                                                                                                                  
  read-only                                                                                                                               
                                                                                                                                          
# Linux bootable partition config ends

Reload lilo’s config with lilo -v

# lilo -v
LILO version 24.2 (released 22-November-2015)
  * Copyright (C) 1992-1998 Werner Almesberger  (until v20)
  * Copyright (C) 1999-2007 John Coffman  (until v22)
  * Copyright (C) 2009-2015 Joachim Wiedorn  (since v23)
This program comes with ABSOLUTELY NO WARRANTY. This is free software 
distributed under the BSD License (3-clause). Details can be found in 
the file COPYING, which is distributed with this software.

Reading boot sector from /dev/sda
Using BITMAP secondary loader
Calling map_insert_data
Mapping bitmap file /boot/slack.bmp
Warning: Video adapter does not support VESA BIOS extensions needed for
  display of 256 colors.  Boot loader will fall back to TEXT only operation.
Calling map_insert_file

Boot image: /boot/vmlinuz -> vmlinuz-huge-4.14.11
Added Linux  *

Boot image: /boot/vmlinuz-generic-4.14.11
Mapping RAM disk /boot/initrd-4.14.11.gz
The initial RAM disk will be loaded in the high memory above 16M.
Added gen-4.14.11  +

Boot image: /boot/vmlinuz-bk-huge-4.14.11
Added bk-huge-4.4.11

Boot image: /boot/vmlinuz-bk-gen-4.14.11
Mapping RAM disk /boot/initrd-4.14.11.gz
The initial RAM disk will be loaded in the high memory above 16M.
Added bk-gen-4.14.11  +

Writing boot sector.
/boot/boot.0800 exists - no boot sector backup copy made.
One warning was issued.

The two new entries are added successfully, the warning about the video adapter is ‘normal’ on my machine.

At that point, you can decide to reload on the BK-HUGE or BK-GEN to make sure they are okay, or go directly to the kernel upgrade process. It’s really how cocky you want to be ^_^

Upgrade that kernel

If you have previously blacklisted the kernels packages, you can now comment them in /etc/slackpkg/blacklist so slackpkg can update them.

And upgrade all  kernel related packages with slackpkg upgrade kernel.

Slackpkg package selection for upgrade

Select the packages you want to upgrade and hit [OK], slackpkg will then download and install/upgrade them.

Slackpkg during package download and installation

At the end of the process, slackpkg will ask you if it can run lilo for you: say yes, and look for errors if any.

Your kernel image was updated.  We highly recommend you run: lilo
Do you want slackpkg to run lilo now? (Y/n)
y
Warning: Video adapter does not support VESA BIOS extensions needed for
  display of 256 colors.  Boot loader will fall back to TEXT only operation.
Added Linux  *
Fatal: open /boot/vmlinuz-generic-4.14.11: No such file or directory

Searching for NEW configuration files
		No .new files found.

#

The Fatal here was due to my use of the generic kernel: /boot/vmlinuz-generic-4.14.11 was part of the old generic package that has been ‘upgraded’ to 4.4.12.

Let’s remove this entry in lilo.conf, I probably need to build a new initrd for the new kernel anyway. I will boot from the new HUGE instead.

# Linux bootable partition config begins                                                                                                  
image = /boot/vmlinuz                                                                                                                     
  root = /dev/sda1                                                                                                                        
  label = Linux                                                                                                                           
  read-only                                                                                                                               
                                                                                                                                          
image = /boot/vmlinuz-bk-huge-4.14.11                                                                                                     
  root = /dev/sda1                                                                                                                        
  label = bk-huge-4.4.11                                                                                                                  
  read-only                                                                                                                               
                                                                                                                                          
image = /boot/vmlinuz-bk-gen-4.14.11                                                                                                      
  initrd = /boot/initrd-4.14.11.gz                                                                                                        
  root = /dev/sda1                                                                                                                        
  label = bk-gen-4.14.11                                                                                                                  
  read-only                                                                                                                               
                                                                                                                                          
# Linux bootable partition config ends

The first entry correspond to the huge kernel. /boot/vmlinuz is a symlink to the HUGE 4.14.12 kernel

# ls -lastr /boot/ | grep vmli
5360 -rw-r--r--  1 root root 5486352 Jan  6 00:20 vmlinuz-generic-4.14.12
8440 -rw-r--r--  1 root root 8640272 Jan  6 00:33 vmlinuz-huge-4.14.12
5356 -rw-r--r--  1 root root 5482256 Jan 13 15:52 vmlinuz-bk-gen-4.14.11
8436 -rw-r--r--  1 root root 8636176 Jan 13 15:53 vmlinuz-bk-huge-4.14.11
   0 lrwxrwxrwx  1 root root      23 Jan 13 16:10 vmlinuz-generic -> vmlinuz-generic-4.14.12
   0 lrwxrwxrwx  1 root root      20 Jan 13 16:10 vmlinuz-huge -> vmlinuz-huge-4.14.12
   0 lrwxrwxrwx  1 root root      20 Jan 13 16:10 vmlinuz -> vmlinuz-huge-4.14.12

Let’s run lilo -v , no error this time

# lilo -v
LILO version 24.2 (released 22-November-2015)
  * Copyright (C) 1992-1998 Werner Almesberger  (until v20)
  * Copyright (C) 1999-2007 John Coffman  (until v22)
  * Copyright (C) 2009-2015 Joachim Wiedorn  (since v23)
This program comes with ABSOLUTELY NO WARRANTY. This is free software 
distributed under the BSD License (3-clause). Details can be found in 
the file COPYING, which is distributed with this software.

Reading boot sector from /dev/sda
Using BITMAP secondary loader
Calling map_insert_data
Mapping bitmap file /boot/slack.bmp
Warning: Video adapter does not support VESA BIOS extensions needed for
  display of 256 colors.  Boot loader will fall back to TEXT only operation.
Calling map_insert_file

Boot image: /boot/vmlinuz -> vmlinuz-huge-4.14.12
Added Linux  *

Boot image: /boot/vmlinuz-bk-huge-4.14.11
Added bk-huge-4.4.11

Boot image: /boot/vmlinuz-bk-gen-4.14.11
Mapping RAM disk /boot/initrd-4.14.11.gz
The initial RAM disk will be loaded in the high memory above 16M.
Added bk-gen-4.14.11  +

Writing boot sector.
/boot/boot.0800 exists - no boot sector backup copy made.
One warning was issued.

Time to reload

You can now reaload and boot on the ‘new’ HUGE kernel, that should be labeled Linux, and you should eventually get to your login page.

I’m running the new HUGE kernel 4.4.12

$ uname -a
Linux ws1 4.14.12 #2 SMP Fri Jan 5 17:32:46 CST 2018 x86_64 Intel(R) Xeon(R) CPU D-1540 @ 2.00GHz GenuineIntel GNU/Linux
$ 
$ cat /proc/cmdline 
BOOT_IMAGE=Linux ro root=801
$ 

What to do next ?

  • You should probably makes sure everything is running fine.
  • Perhaps switch to the GENERIC kernel ?
  • Blacklist the kernel packages in /etc/slackpkg/blacklist ?
  • Clean the backup kernel if you don’t need them anymore ?

Sources

Slackware Documentation: https://docs.slackware.com/howtos:slackware_admin:systemupgrade#considerations_about_the_kernel

Experience about failure to boot after a kernel update -without- a fallback kernel.

 

Slackware Kernel HUGE and GENERIC

Here is a background on the difference between both flavors.
How you can switch from one to the other kernel from the Slackware package tree.

If you let Slackware installer makes the bootloader’s config, it will use the HUGE kernel. The documentation recommends that your switch afterwards on a GENERIC kernel.

This article will cover the switch from HUGE to GENERIC, but will also overlook the Initrd subject and giving some hint and advices.

Don’t be afraid, all is gonna be fine if you understand what you do ! ( do not just copy paste 😉 )

Background first

The HUGE kernel, as the name suggest, is big. Reason is that it has a lot of kernel modules directly built in it. You can see some of those modules as drivers for your hardware, the more you have, the more chance you will have a successful boot after installation.

On the other hand, you won’t probably need all those modules to make your machine works. That’s a goal of the GENERIC kernel, that are built with minimal hardware support, and loads dynamically modules when needed.

From my readings, I didn’t find a real technical reason not to keep the HUGE kernel for the lambda user except maybe the size of the Kernel on tiny machines ( around 40% bigger than the GENERIC )

$ ls -lh /boot/vmlinuz-*
-rw-r--r-- 1 root root 5.3M Jan  5 20:19 /boot/vmlinuz-4.14.12
lrwxrwxrwx 1 root root   23 Jan  5 18:32 /boot/vmlinuz-generic -> vmlinuz-generic-4.14.11
-rw-r--r-- 1 root root 5.3M Jan  3 03:06 /boot/vmlinuz-generic-4.14.11
lrwxrwxrwx 1 root root   20 Jan  5 18:32 /boot/vmlinuz-huge -> vmlinuz-huge-4.14.11
-rw-r--r-- 1 root root 8.3M Jan  3 20:11 /boot/vmlinuz-huge-4.14.11

Also, GENERIC kernels needs and initial ramdisk – initrd – to work.

GENERIC with its initrd has its utility of course other than the size, specifically it permits the 2 phases boot ability , than can be used for ( but not limited to) booting from an encrypted partition, or other special cases like RAID or NFS/diskless setup.

First phase is the bootloader initializing the ram disk prior and creates a temporary root partition to start the kernel . The ramdisk contains the modules and utility/tools.

Second phase is the kernel being able to load additional modules from the ram disk . When it’s done, the `real` root partition can be mounted from the real root partition location.

Obviously I won’t cover the encrypted partition case in that article, but in the encryption context: during the second phase, the kernel will load the encryption module and start the tool that will prompt you for the passphrase prior to mount the real root partition.

I’m not a power user  and  I must admit that I’ve changed to GENERIC not that long ago, just because I’ve never had a real reason to do so ( yes I didn’t followed the doc 😉 ).

The starting point for me was the need of the  GENERIC kernel to be able to use Docker on my machine.

What type of kernel am I using ?

That’s is a tricky question actually, and so far I’ve looked on the net, I couldn’t find a command that return the answer.

Clue/Hints

Instead, it’s more or less some hints about what you are running:

Uname is not really giving infos:

# uname -a
Linux ws1 4.14.11 #1 SMP Tue Jan 2 20:05:07 CST 2018 x86_64 Intel(R) Xeon(R) CPU D-1540 @ 2.00GHz GenuineIntel GNU/Linux

Content of /proc/cmdline will show the parameter given to kernel prior to load it. Here it shows just Linux … ok well it’s light but it’s usefull anyway.

# cat /proc/cmdline
auto BOOT_IMAGE=Linux ro root=801

LILO is the bootloader used by default on Slackware, and the BOOT_IMAGE return at least the ‘label’ of the entry: let’s check for that in /etc/lilo.conf

# Linux bootable partition config begins
image = /boot/vmlinuz
  root = /dev/sda1
  label = Linux
  read-only

It’s not obvious if you don’t know it…. but as GENERIC requires an initrd,  it should be present. No sign of an initrd there => very good chances that your are running HUGE.

Another way, trying to find something that is different between HUGE and GENERIC. As a good example, I’ve learned that the support for your filesystem is build-in for the HUGE kernel and compiled as a module in case of the GENERIC.

I use an EXT4 Filesystem and I’m running the HUGE kernel at the moment, so let’s look in the kernel config setting for that FS.

# zgrep 'CONFIG_EXT4_FS=' /proc/config.gz
CONFIG_EXT4_FS=y
#

On a GENERIC kernel:

# zgrep 'CONFIG_EXT4_FS=' /proc/config.gz
CONFIG_EXT4_FS=m
#

Here is a small bash script – genericOrHugeKernel.sh – that checks how the kernel has been configured for the filesystem ( and avoid me to remember the command).

#! /bin/bash

zgrep -q 'CONFIG_EXT4_FS=y' /proc/config.gz && IsGeneric=0 || IsGeneric=1
echo "IsKernelGeneric = $IsGeneric"

Running on a HUGE kernel, the script tells you so:

# ./dev/scripts/genericOrHugeKernel.sh
IsKernelGeneric = 0
#

Bottom line

From here … giving a proper name to your kernel might be a good idea, though it’s not 100% guarantee that it’s true. You can only complain to yourself if it’s not 😉

When running kernels from Slackware tree, I chose to label the GENERIC kernel entry like gen-X.Y.Z , while keeping the slackware ‘default’ Linux + symlink for the HUGE.

For out-of-tree kernel, I choose a different name but it’s another article.

 $ cat /proc/cmdline 
BOOT_IMAGE=gen-4.14.11 ro root=801

Following my naming convention, I’m pretty confident to run Slackware GENERIC 4.14.11 kernel.

Switching HUGE to GENERIC

Slackpkg Kernel Package

Slackware ships both version with each update, the latest kernel on Current was 4.14.11 at time of writing. Below is what I got after search packages with kernel in the name.

# slackpkg search kernel

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

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

[ installed ] - kernel-firmware-20180102git-noarch-1
[ installed ] - kernel-generic-4.14.11-x86_64-1
[ installed ] - kernel-huge-4.14.11-x86_64-2
[ installed ] - kernel-modules-4.14.11-x86_64-1
[ installed ] - kernel-headers-4.14.11-x86-1
[ installed ] - kernel-source-4.14.11-noarch-1

Make sure you have the generic and modules packages installed 😉

Kernels are stored in /boot , vmlinuz is the name of the Linux kernel executable. You can see below that you have the 2 kernels, vmlinuz-huge-4.14.11 and vmlinuz-generic-4.14.11

Symlinks are here I guess simplify the installer’s job with LILO. Aka the installer never touch /etc/lilo.conf file, it just changes the symlink and update LILO.

# ls -l /boot/vmlinuz*
lrwxrwxrwx 1 root root 20 Jan 5 18:32 /boot/vmlinuz -> vmlinuz-huge-4.14.11
lrwxrwxrwx 1 root root 23 Jan 5 18:32 /boot/vmlinuz-generic -> vmlinuz-generic-4.14.11
-rw-r--r-- 1 root root 5482256 Jan 3 03:06 /boot/vmlinuz-generic-4.14.11
lrwxrwxrwx 1 root root 20 Jan 5 18:32 /boot/vmlinuz-huge -> vmlinuz-huge-4.14.11
-rw-r--r-- 1 root root 8636176 Jan 3 20:11 /boot/vmlinuz-huge-4.14.11
#

Speaking of the lilo configuration, by default, Slackware put an entry only for the HUGE Kernel. You can see that image is pointing to /boot/vmlinuz which is a symlinks to vmlinuz-huge-X.Y.Z

# cat /etc/lilo.conf

<--- SNIP -->

# End LILO global section                                                                                                                 
# Linux bootable partition config begins                                                                                                  
image = /boot/vmlinuz                                                                                                                     
  root = /dev/sda1                                                                                                                        
  label = Linux                                                                                                                           
  read-only                                                                                                                               
                                       
# Linux bootable partition config ends

Creating the Initial Ramdisk – initrd

As explained earlier, the GENERIC kernel needs an initrd to work, and is not part of the kernel installation via slackpkg. I suppose the reason is that the GENERIC needs an initrd tailored for -your- machine and automate the initrd creation process would be pretty hard.

If you check in /boot/, you will find the initrd README, which you can obviously read of course 🙂

 # ls /boot/ | grep initrd
README.initrd@
#

The creation is helped thanks to 2 tools:

  • mkinitrd , it should be already installed, if not, feel free to use slackpkg for that.
# slackpkg search mkinitrd

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

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

[ installed ] - mkinitrd-1.4.11-x86_64-5

You can search specific files using "slackpkg file-search file".
  •  mkinitrd_command_generator.sh, which is a bash script that generate for you a proper command to use with mkinird.
# /usr/share/mkinitrd/mkinitrd_command_generator.sh
#
# mkinitrd_command_generator.sh revision 1.45
#
# This script will now make a recommendation about the command to use
# in case you require an initrd image to boot a kernel that does not
# have support for your storage or root filesystem built in
# (such as the Slackware 'generic' kernels').
# A suitable 'mkinitrd' command will be:

mkinitrd -c -k 4.14.11 -f ext4 -r /dev/sda1 -m xhci-pci:ohci-pci:ehci-pci:xhci-hcd:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:jbd2:mbcache:ext4 -u -o /boot/initrd.gz

The only thing I’ve changed from the proposed command, is that I always add the kernel version in the output initrd file. In that case the command will be something like:

mkinitrd -c -k 4.14.11 -f ext4 -r /dev/sda1 -m <lots of modules here> -u -o /boot/initrd-4.14.11.gz

When executing the command:

# mkinitrd -c -k 4.14.11 -f ext4 -r /dev/sda1 -m xhci-pci:ohci-pci:ehci-pci:xhci-hcd:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:jbd2:mbcache:ext4 -u -o /boot/initrd-4.14.11.gz
OK: /lib/modules/4.14.11/kernel/drivers/usb/host/xhci-hcd.ko added.
OK: /lib/modules/4.14.11/kernel/drivers/usb/host/xhci-pci.ko added.
OK: /lib/modules/4.14.11/kernel/drivers/usb/host/ehci-hcd.ko added.

<--- Output suppressed -->

OK: /lib/modules/4.14.11/kernel/fs/jbd2/jbd2.ko added.
OK: /lib/modules/4.14.11/kernel/fs/mbcache.ko added.
OK: /lib/modules/4.14.11/kernel/fs/ext4/ext4.ko added.
51688 blocks
/boot/initrd-4.14.11.gz created.
Be sure to run lilo again if you use it.
# 

Indeed, the initrd is located in /boot/ as stated:

# ls /boot/ | grep initrd
README.initrd@
initrd-4.14.11.gz
initrd-tree/
#

Also, if you look inside /boot/initrd-tree/ , you will find many things, including some binaries that can help during the second phase boot. So yeah, initrd is not just about loading modules.

 # ls /boot/initrd-tree/ -lasth
total 96K
4.0K drwxr-xr-x  4 root root 4.0K Jan 13 10:36 ../
4.0K drwxr-xr-x  2 root root 4.0K Jan 11 21:04 lib64/
4.0K drwxr-xr-x 14 root root 4.0K Jan 11 21:04 ./
4.0K drwxr-xr-x  3 root root 4.0K Jan 11 21:04 usr/
4.0K -rwxr-xr-x  1 root root  636 Jan 11 21:04 load_kernel_modules*
4.0K drwxr-xr-x  2 root root 4.0K Jan 11 21:04 sbin/
4.0K -rw-r--r--  1 root root   24 Jan 11 21:04 initrd-name
4.0K -rw-r--r--  1 root root  285 Jan 11 21:04 command_line
4.0K -rw-r--r--  1 root root    5 Jan 11 21:04 rootfs
4.0K -rw-r--r--  1 root root   10 Jan 11 21:04 rootdev
4.0K drwxr-xr-x  2 root root 4.0K Jan 11 21:04 dev/
4.0K drwxr-xr-x  4 root root 4.0K Jan  3 03:08 lib/
 16K -rwxr-xr-x  1 root root  13K Oct  9 20:06 init*
4.0K drwxr-xr-x  2 root root 4.0K Aug 21  2011 run/
4.0K drwxr-xr-x  3 root root 4.0K Apr  1  2010 etc/
   0 -rw-r--r--  1 root root    0 Dec 19  2009 lukskey
4.0K drwxr-xr-x  2 root root 4.0K Nov 26  2008 root/
4.0K drwxr-xr-x  2 root root 4.0K Nov 26  2008 bin/
   0 -rw-r--r--  1 root root    0 Apr  3  2008 keymap
   0 -rw-r--r--  1 root root    0 Feb 20  2008 resumedev
4.0K -rw-r--r--  1 root root    2 Oct  9  2007 wait-for-root
   0 -rw-r--r--  1 root root    0 Jun 27  2007 luksdev
4.0K drwxr-xr-x  2 root root 4.0K Jun  3  2007 sys/
4.0K drwxr-xr-x  2 root root 4.0K Mar  1  2004 proc/
4.0K drwxr-xr-x  2 root root 4.0K Mar  1  2004 mnt/
#

Adding the kernel entry in LILO config

Now that we have the initrd created, lets add an entry in /etc/lilo.conf . As a side note, the order of the entries matters. LILO will boot on the first entry by default.

Bellow is shown only the partition config from the LILO configuration file.

  • Image: Location of the kernel executable
  • Initrd: Location of the initrd file for that kernel.
  • Root: Location of the root (/) partition
  • Label: You can put what you want here, this will be seen on the boot menu and in the out of cat /proc/cmdline

Do not remove the HUGE kernel entry, if the GENERIC failed to load for whatever reason, then you can just reboot again on the HUGE to troubleshoot and fix.

Without a ‘working backup’ kernel, you would need to use a liveCD/USB/Netboot for that.

# Linux bootable partition config begins                                                                                               
image = /boot/vmlinuz                                                                                                                  
  root = /dev/sda1                                                                                                                     
  label = Linux                                                                                                                        
  read-only                                                                                                                            
                                                                                                                                       
image = /boot/vmlinuz-generic-4.14.11                                                                                                  
  initrd = /boot/initrd-4.14.11.gz                                                                                                     
  root = /dev/sda1                                                                                                                     
  label = gen-4.14.11                                                                                                                  
  read-only                                                                                                                            
                                                                                                                                       
# Linux bootable partition config ends

My personal way of doing this is keeping the HUGE as the first and default entry, and manually boot the GENERIC until I validated the GENERIC.

Afterward, I either change the order or a use the default=<label> setting of lilo.conf to boot the GENERIC as default.

How you do it is really up to your personal taste… I tend to adapt this to the situation, on my laptop I run only kernels from the Slackware tree so two entries to swap is not big deal. My laptop config is also pretty stable ( no fancy config )

On the other hand, with my workstation, I have more kernels to play with and using the default setting is lazier easier

Then you just need to run lilo -v to update the bootloader’s config and pay attention to errors.

 # lilo -v
LILO version 24.2 (released 22-November-2015)
  * Copyright (C) 1992-1998 Werner Almesberger  (until v20)
  * Copyright (C) 1999-2007 John Coffman  (until v22)
  * Copyright (C) 2009-2015 Joachim Wiedorn  (since v23)
This program comes with ABSOLUTELY NO WARRANTY. This is free software 
distributed under the BSD License (3-clause). Details can be found in 
the file COPYING, which is distributed with this software.

Reading boot sector from /dev/sda
Using BITMAP secondary loader
Calling map_insert_data
Mapping bitmap file /boot/slack.bmp
Warning: Video adapter does not support VESA BIOS extensions needed for
  display of 256 colors.  Boot loader will fall back to TEXT only operation.
Calling map_insert_file

Boot image: /boot/vmlinuz -> vmlinuz-huge-4.14.11
Added Linux  *

Boot image: /boot/vmlinuz-generic-4.14.11
Mapping RAM disk /boot/initrd-4.14.11.gz
The initial RAM disk will be loaded in the high memory above 16M.
Added gen-4.14.11  +

Writing boot sector.
/boot/boot.0800 exists - no boot sector backup copy made.
One warning was issued.
# 

Both entries have been correctly added, which is nice.

You can also see that there was one Warning, related to my video adapter not supporting a certain config. I didn’t find a fix for that…. but the only consequence is stated:

Boot loader will fall back to TEXT only operation.

This means that I won’t have the pretty LILO boot menu with the Slackware Logo ( 🙁 ) to show the available kernels or the timeout. Instead I will have the LILO BOOT: prompt directly. If it’s also your case, then it’s not big deal.

  • LILO default timeout is 120secs and will boot the first kernel entry if you don’t touch any key.  You can edit the timeout =<tenth of second> setting in lilo.conf
  • [ENTER] will boot the first kernel entry
  • [TAB] will show the different available entries. Type fully the name of the entry without typo then [enter] to boot that kernel.

You can also switch to the classic LILO menu if you prefer.

Time to reload

If you are okay, you can reload your machine.

I cannot show you the generated menu, so here is a shot from the LILO prompt right after the BIOS POST, the available kernel matches the lilo.conf and the kernel loading.

LILO prompt, kernel loading and boot start

If  everything goes as expected, you will eventually get to your login prompt.

Checking if I run the GENERIC kernel below with tools we have seen earlier

# 
# cat /proc/cmdline 
BOOT_IMAGE=gen-4.14.11 ro root=801
# 
# zgrep 'CONFIG_EXT4_FS=' /proc/config.gz
CONFIG_EXT4_FS=m
# 
# ./dev/scripts/genericOrHugeKernel.sh 
IsKernelGeneric = 1
# 

If the boot fails, common boot error is hitting KERNEL PANIC. It can be various messages with various root-causes.

It can be hard to pinpoint the cause as you can’t scroll the screen up anymore….my advice is  to get photo/text of the message, reload to the HUGE kernel and start troubleshooting.

 

Sources

Initial Ram Disk – initrd

IBM article on initrd: https://www.ibm.com/developerworks/library/l-initrd/index.html

Wikipedia initial ramdisk page:  https://en.wikipedia.org/wiki/Initial_ramdisk

Initrd man page: https://linux.die.net/man/4/initrd

inird README: http://slackware.mirrors.ovh.net/ftp.slackware.com/slackware-current/README.initrd

LQ forum thread about checking which kernel you are using: https://www.linuxquestions.org/questions/slackware-14/kernel-huge-or-generic-which-is-running-4175597213/

Kernel

Official Documentation : https://docs.slackware.com/slackbook:booting and https://docs.slackware.com/slackware:beginners_guide#switch_to_a_generic_kernel