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 )

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.

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).

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.

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:

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.

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.