Linux Kernel Types

The Linux kernel comes in dozens of flavors, some are official and on the other end of the spectrum, they are highly specialized kernels for special use cases and/or hardware. An example, Proxmox has their own kernel, see this link to GitHub. Interestingly, they use the Ubuntu kernel sources for the kernel, but run Debian as the OS. If you want to build your own kernel, there is a guide on that page.

Officially supported kernels

Basic Linux kernel

This is the latest stable kernel for Linux. It's the latest available version of the Linux kernel. If you need the newest hardware, this is for you, the linux-kernel

Hardened kernel

The security hardened kernel linux-hardened, based on the latest stable Linux kernel.

For the security concerned, there is a hardened version of the latest stable kernel. This might be the best and safest choice for many web-based server applications.

Do note that several packages will not work when using this kernel.

LTS kernel

The linux-lts kernel package gives you the latest long-term Linux kernel. A LTS kernel has a much longer life than the linux kernel.

If you are afraid of something braking, use the linux-lts kernel. Usually kernel patches don't break things, but it's possible. For servers, this can be the optimal choice because you do not usually change the hardware and a slightly older kernel is OK.

Zen kernel

Performance tuned kernel linux-zen. If you want to get the most out of your system, you use the zen kernel which is basically a fork from the latest kernel and provides tunes at the cost of throughput and power usage.

Real-time kernel

The realtime kernel is maintained by a small group of developers led by Ingo Molnar.

This patch lets you preempt most of the kernel, except for a few small regions of the code, called the raw_spinlock critical regions.

This can be achieved by replacing most kernel spinlocks with mutexes that support priority inheritance, as well as moving all interrupts and software interrupts to kernel threads.

Kernels on kernel.org

• Git — Linux kernel and modules built using sources from Linus Torvalds' Git repository.
• Mainline — Kernels where all new features are introduced, released every 2–3 months.
• Next — Bleeding-edge kernels with features that need to be merged into the next mainline release.
• DRM — Linux kernel with bleeding-edge GPU drivers.
• Long term — Long-term support (LTS) Linux kernel and modules.
• There are a bunch of other kernels out there that you can experiment with

Other info

Each major version – identified by the first two numbers of a release version – is designated one of the following levels of support:

• Supported until the next stable version
• Long-term support (LTS)
  • maintained for a few years
• Super-long-term support (SLTS)
  • maintained for many more years by the Civil Infrastructure Platform (CIP)

Check the kernel version of Linux using uname -r command.

Changing kernel

Install the kernel in Arch Linux

I use my favorite version, Arch, for this example. You can use the pacman command to install the Linux kernel of your choice. You just need to know the package name.

Furthermore, you may also install more than one type of Linux kernel at the same time on the system. You can choose which kernel to use from the grub menu.

For the latest stable kernel:

sudo pacman -S linux

For the latest LTS kernel:

sudo pacman -S linux-lts

For latest stable kernel with hardened patches:

sudo pacman -S linux-hardened

To get the Zen kernel:

sudo pacman -S linux-zen

Tweak the grub configuration file to add more kernel options

By default, Arch Linux uses the latest kernel version as the default and additional kernel versions are available from under the advanced options.

Edit GRUB, to make it a better opening screen

• Make you see all kernels on the GRUB screen without having to enter the advanced option submenu.
• Make grub to recall the last kernel entry you booted and use it as the default to boot from the next time.

You need to edit the GRUB configuration file. All the configuration files in general are located at the /etc directory. Open your terminal and edit the config file.

sudo nano /etc/default/grub

• Disable grub submenu so that all the available kernel versions are shown on the main screen – not under Advanced Options.
• Add another 2 lines, so the final result should look like this:

GRUB_DISABLE_SUBMENU=y
GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true

1. The first line is used to disable the submenu.
2. The second line is used to save the last kernel entry.
3. Make GRUB use as a default the last saved entry.

Save the configuration file and exit.

Re-generate the GRUB configuration

To make the changes effective, you need to re-generate the configuration file.
To do so, open the terminal and run the following command:

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

Reboot

Reboot your Linux system and select the kernel you want to use.

If it goes sideways

Troubleshooting Kernel panics

When the Linux kernel encounters an unrecoverable failure state, a kernel panic occurs. The state typically originates from buggy hardware drivers, which can result in the machine being deadlocked, non-responsive, and requiring a reboot.
A diagnostic message is generated, which includes: the machine state when the failure occurred, a call trace leading to the kernel function that recognized the failure, and a list of the modules that are currently loaded.
Luckily, kernel panics rarely happen with stable kernel versions if your settings are correct. But if they do happen, you need to know how to fix the panic state. The first state is to examine and pinpoint the errors.

🗒️ Note

Kernel panics are sometimes referred to as oops or kernel oops. While both panics and oops occur as the result of a failure state, an oops is more general in that it does not necessarily result in a deadlocked machine. Sometimes the kernel can recover from an oops by killing the offending task and carrying on.

ℹ️ Tip

Pass the kernel parameter oops=panic at boot or write 1 to /proc/sys/kernel/panic_on_oops to force a recoverable oops to issue a panic instead.
This is advisable if you are concerned about the small chance of system instability resulting from an oops recovery which may make future errors difficult to diagnose.

Examine Panic Messages

If a kernel panic occurs very early in the boot process, you may see a message on the console containing "Kernel panic - not syncing", but once Systemd is running, kernel messages will typically be captured and written to the system log.
However, when a panic occurs, the diagnostic message output by the kernel is rarely written to the log file on disk. The machine deadlocks before the system-journald gets the chance to write to the log.
Therefore, the only way to examine the panic message is to view it on the console as it happens (without resorting to setting up a kdump crashkernel). You can do this by booting with the following kernel parameters and attempting to reproduce the panic on the tty. Alternatively, you could consider resorting to setting up a kdump crashkernel.

systemd.journald.forward_to_console=1 console=tty1

ℹ️ Tip

In the event that the panic message scrolls away too quickly to examine,
try passing the kernel parameter pause_on_oops= <seconds> at boot.

References

Linux kernels ^[1] Hardened kernel ^[2] LTS ^[3] ZEN ^[4] Kernel.org ^[5] Realtime kernel ^[6] Mainlaine ^[7] Next ^[8] DRM ^[9] The Linux Foundation ^[10]