Kernel

Arch Linux is based on the Linux kernel. There are various alternative Linux kernels available for Arch Linux in addition to the latest stable kernel. This article lists some of the options available in the repositories with a brief description of each. There is also a description of patches that can be applied to the system's kernel. The article ends with an overview of custom kernel compilation with links to various methods.

Related articles

According to Wikipedia:

The Linux kernel is an open-source monolithic Unix-like computer operating system kernel.

Kernel packages are installed under the /usr/lib/modules/ path and subsequently used to generate the vmlinuz executable image in /boot/. To be able to boot into kernels, the boot loader has to be configured appropriately.

Officially supported kernels

Community support on forum and bug reporting is available for officially supported kernels.

  • Stable — Vanilla Linux kernel and modules, with a few patches applied.
https://www.kernel.org/ || linux
  • Hardened — A security-focused Linux kernel applying a set of hardening patches to mitigate kernel and userspace exploits. It also enables more upstream kernel hardening features than linux.
https://github.com/anthraxx/linux-hardened || linux-hardened
  • Longterm — Long-term support (LTS) Linux kernel and modules.
https://www.kernel.org/ || linux-lts
  • Realtime kernel — Maintained by a small group of core developers led by Ingo Molnar. This patch allows nearly all of the kernel to be preempted, with the exception of a few very small regions of code ("raw_spinlock critical regions"). This is done by replacing most kernel spinlocks with mutexes that support priority inheritance, as well as moving all interrupt and software interrupts to kernel threads.
https://wiki.linuxfoundation.org/realtime/start || linux-rt, linux-rt-lts

    Compilation

    Following methods can be used to compile your own kernel:

    /Arch Build System
    Takes advantage of the high quality of existing PKGBUILD and the benefits of package management.
    /Traditional compilation
    Involves manually downloading a source tarball, and compiling in your home directory as a normal user.

    Some of the listed packages may also be available as binary packages via Unofficial user repositories.

    kernel.org kernels
    • Git — Linux kernel and modules built using sources from Linus Torvalds' Git repository.
    https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git || linux-gitAUR
    • Mainline — Kernels where all new features are introduced, released every 2-3 months.
    https://www.kernel.org/ || linux-mainlineAUR

    Semi-official kernel mirrors

    Semi-official mirrors of some of the kernel.org Git repositories are provided by their respective maintainers. These tend to be faster to clone from than kernel.org.

    Unofficial kernels
    • Clear — Patches from Intel's Clear Linux project. Provides performance and security optimizations.
    https://github.com/clearlinux-pkgs/linux || linux-clearAUR
    • XanMod — Aiming to take full advantage in high-performance workstations, gaming desktops, media centers and others and built to provide a more rock-solid, responsive and smooth desktop experience. This kernel uses the MuQSS or Task Type scheduler, BFQ I/O scheduler, UKSM realtime memory data deduplication, TCP BBR congestion control, x86_64 advanced instruction set support, and other default changes.
    https://xanmod.org/ || linux-xanmodAUR, linux-xanmod-ttAUR

    Troubleshooting

    Kernel panics

    A kernel panic occurs when the Linux kernel enters an unrecoverable failure state. The state typically originates from buggy hardware drivers resulting in the machine being deadlocked, non-responsive, and requiring a reboot. Just prior to deadlock, a diagnostic message is generated, consisting of: the machine state when the failure occurred, a call trace leading to the kernel function that recognized the failure, and a listing of currently loaded modules. Thankfully, kernel panics do not happen very often using mainline versions of the kernel--such as those supplied by the official repositories--but when they do happen, you need to know how to deal with them.

    Examine panic message

    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 almost never written to the log file on disk because the machine deadlocks before gets the chance. 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 tty1:

    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.
    Example scenario: bad module

    It is possible to make a best guess as to what subsystem or module is causing the panic using the information in the diagnostic message. In this scenario, we have a panic on some imaginary machine during boot. Pay attention to the lines highlighted in bold:

    1. Indicates the type of error that caused the panic. In this case it was a programmer bug.
    2. Indicates that the panic happened in a function called fw_core_init in module firewire_core.
    3. Indicates that firewire_core was the latest module to be loaded.
    4. Indicates that the function that called function fw_core_init was do_one_initcall.
    5. Indicates that this oops message is, in fact, a kernel panic and the system is now deadlocked.

    We can surmise then, that the panic occurred during the initialization routine of module firewire_core as it was loaded. (We might assume then, that the machine's firewire hardware is incompatible with this version of the firewire driver module due to a programmer error, and will have to wait for a new release.) In the meantime, the easiest way to get the machine running again is to prevent the module from being loaded. We can do this in one of two ways:

    • If the module is being loaded during the execution of the initramfs, reboot with the kernel parameter .
    • Otherwise reboot with the kernel parameter .

    Reboot into root shell and fix problem

    You will need a root shell to make changes to the system so the panic no longer occurs. If the panic occurs on boot, there are several strategies to obtain a root shell before the machine deadlocks:

    • Reboot with the kernel parameter , rd.emergency, or to receive a prompt to login just after the root filesystem is mounted and is started.
    • Reboot with the kernel parameter , rd.rescue, , , , or to receive a prompt to login just after local filesystems are mounted.
    • Reboot with the kernel parameter to obtain a very early root shell on tty9. Switch to it with by pressing Ctrl+Alt+F9.
    • Experiment by rebooting with different sets of kernel parameters to possibly disable the kernel feature that is causing the panic. Try the "old standbys" and .
    • As a last resort, boot with an Arch Linux installation medium and mount the root filesystem on then execute as the root user.
    • Disable the service or program that is causing the panic, roll-back a faulty update, or fix a configuration problem.

    Debugging regressions

    See General troubleshooting#Debugging regressions.

    Try linux-mainlineAUR to check if the issue is already fixed upstream. The stickied comment also mentions a repository which contains already built kernels, so it may not be necessary to build it manually, which can take some time.

    It may also be worth considering trying the LTS kernel () to debug issues which did not appear recently. Older versions of the LTS kernel can be found in the Arch Linux Archive.

    If the issue still persists, bisect and report the bug on the kernel bugzilla. It is important to try the "vanilla" version without any patches to make sure it is not related to them. If a patch causes the issue, report it to the author of the patch.

    Note: Bisecting the kernel can take a lot of time since it may need to be rebuilt many times.
    gollark: ... dual channel?
    gollark: SSDs are definitely too slow and also you'll kill them with constant writes.
    gollark: What? RAID is for disks, not RAM.
    gollark: I think you'd have unusably high latency/low memory bandwidth.
    gollark: Oh, the "Project December" thing?

    See also
    This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.