What is linux kernel image

Kernel

According to Wikipedia:

The Linux kernel is an open-source monolithic Unix-like computer operating system 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.

Kernel packages are installed onto the file system under /boot/ . To be able to boot into kernels, the boot loader has to be configured appropriately.

Contents

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

• Zen Kernel — Result of a collaborative effort of kernel hackers to provide the best Linux kernel possible for everyday systems. Some more details can be found on https://liquorix.net (which provides kernel binaries based on Zen for Debian).

https://github.com/zen-kernel/zen-kernel || linux-zen

Compilation

Following methods can be used to compile your own kernel:

/Arch Build System Takes advantage of the high quality of existing linux 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

• Next — Bleeding edge kernels with features pending to be merged into next mainline release.

https://www.kernel.org/doc/man-pages/linux-next.html || linux-next-gitAUR

• Longterm 4.4 — Long-term support (LTS) Linux 4.4 kernel and modules.

https://www.kernel.org/ || linux-lts44AUR

• Longterm 4.9 — Long-term support (LTS) Linux 4.9 kernel and modules.

https://www.kernel.org/ || linux-lts49AUR

• Longterm 4.14 — Long-term support (LTS) Linux 4.14 kernel and modules.

https://www.kernel.org/ || linux-lts414AUR

• Longterm 4.19 — Long-term support (LTS) Linux 4.19 kernel and modules.

https://www.kernel.org/ || linux-lts419AUR

• Longterm 5.4 — Long-term support (LTS) Linux 5.4 kernel and modules.

https://www.kernel.org/ || linux-lts54AUR

Unofficial kernels

• Aufs — The aufs-compatible linux kernel and modules, useful when using docker.

http://aufs.sourceforge.net/ || linux-aufsAUR

• Ck — Contains patches by Con Kolivas (including the MuQSS scheduler) designed to improve system responsiveness with specific emphasis on the desktop, but they are suitable to any workload.

http://ck.kolivas.org/ || linux-ckAUR

• Clear — Patches from Intel’s Clear Linux project. Provides performance and security optimizations.

https://github.com/clearlinux-pkgs/linux || linux-clearAUR

• GalliumOS — The Linux kernel and modules with GalliumOS patches for Chromebooks.

https://github.com/GalliumOS/linux || linux-galliumosAUR

• Libre — Without propietary or obfuscated device drivers.

https://www.fsfla.org/ikiwiki/selibre/linux-libre/ || linux-libreAUR

• Liquorix — Kernel replacement built using Debian-targeted configuration and the Zen kernel sources. Designed for desktop, multimedia, and gaming workloads, it is often used as a Debian Linux performance replacement kernel. Damentz, the maintainer of the Liquorix patchset, is a developer for the Zen patchset as well.

https://liquorix.net || linux-lqxAUR

• MultiPath TCP — The Linux Kernel and modules with Multipath TCP support.

https://multipath-tcp.org/ || linux-mptcpAUR

• pf-kernel — Provides a handful of awesome features which are not merged into a kernel mainline. Maintained by a kernel engineer. If the port for the included patch for new kernels was not released officially, the patchset provides and supports patch ports to new kernels. The current most prominent patches of linux-pf are PDS CPU scheduler and UKSM.

https://gitlab.com/post-factum/pf-kernel/wikis/README || Packages:

• Repository by pf-kernel developer post-factum
• Repository, linux-pfAUR , linux-pf-preset-defaultAUR by pf-kernel fork developer Thaodan
• linux-pf-gitAUR by yurikoles

• 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-rtAUR , linux-rt-ltsAUR

• tkg — A highly customizable kernel build system that provides a selection of patches and tweaks aiming for better desktop and gaming performance. It is maintained by Etienne Juvigny. Amongst other patches, it offers various CPU schedulers: CFS, Project C PDS, Project C BMQ, MuQSS and CacULE.

https://github.com/Frogging-Family/linux-tkg || not packaged? search in AUR

• VFIO — The Linux kernel and a few patches written by Alex Williamson (acs override and i915) to enable the ability to do PCI Passthrough with KVM on some machines.

https://lwn.net/Articles/499240/ || linux-vfioAUR , linux-vfio-ltsAUR

• 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 CacULE 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-caculeAUR

Debugging regressions

Try linux-mainline AUR 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 ( linux-lts ) 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 linux-git AUR 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.

Источник

What is the Linux kernel?

Overview

The Linux® kernel is the main component of a Linux operating system (OS) and is the core interface between a computer’s hardware and its processes. It communicates between the 2, managing resources as efficiently as possible.

The kernel is so named because—like a seed inside a hard shell—it exists within the OS and controls all the major functions of the hardware, whether it’s a phone, laptop, server, or any other kind of computer.

What the kernel does

The kernel has 4 jobs:

Memory management: Keep track of how much memory is used to store what, and where

Process management: Determine which processes can use the central processing unit (CPU), when, and for how long

Device drivers: Act as mediator/interpreter between the hardware and processes

System calls and security: Receive requests for service from the processes

The kernel, if implemented properly, is invisible to the user, working in its own little world known as kernel space, where it allocates memory and keeps track of where everything is stored. What the user sees—like web browsers and files—are known as the user space. These applications interact with the kernel through a system call interface (SCI).

Think about it like this. The kernel is a busy personal assistant for a powerful executive (the hardware). It’s the assistant’s job to relay messages and requests (processes) from employees and the public (users) to the executive, to remember what is stored where (memory), and to determine who has access to the executive at any given time and for how long.

Where the kernel fits within the OS

To put the kernel in context, you can think of a Linux machine as having 3 layers:

1. The hardware: The physical machine—the bottom or base of the system, made up of memory (RAM) and the processor or central processing unit (CPU), as well as input/output (I/O) devices such as storage, networking, and graphics. The CPU performs computations and reads from, and writes to, memory.
2. The Linux kernel: The core of the OS. (See? It’s right in the middle.) It’s software residing in memory that tells the CPU what to do.
3. User processes: These are the running programs that the kernel manages. User processes are what collectively make up user space. User processes are also known as just processes. The kernel also allows these processes and servers to communicate with each other (known as inter-process communication, or IPC).

Code executed by the system runs on CPUs in 1 of 2 modes: kernel mode or user mode. Code running in the kernel mode has unrestricted access to the hardware, while user mode restricts access to the CPU and memory to the SCI. A similar separation exists for memory (kernel space and user space). These 2 small details form the base for some complicated operations like privilege separation for security, building containers, and virtual machines.

This also means that if a process fails in user mode, the damage is limited and can be recovered by the kernel. However, because of its access to memory and the processor, a kernel process crash can crash the entire system. Since there are safeguards in place and permissions required to cross boundaries, user process crashes usually can’t cause too many problems.

Why choose Red Hat?

At Red Hat, Linux is the foundation of everything we do. Red Hat is the second largest corporate contributor to the Linux kernel, bringing with it the experience and expertise of 25 years and a large community of partners, customers, and experts from across the industry. That’s a long relationship, with a history and level of experience that’s hard to come by.

The Linux kernel is open source, and open source is at the core of Red Hat’s values. Learn why we’ve built our company on our conviction that Red Hat® Enterprise Linux is the best.

Источник

Linux kernel release 4.x В¶

These are the release notes for Linux version 4. Read them carefully, as they tell you what this is all about, explain how to install the kernel, and what to do if something goes wrong.

What is Linux?В¶

Linux is a clone of the operating system Unix, written from scratch by Linus Torvalds with assistance from a loosely-knit team of hackers across the Net. It aims towards POSIX and Single UNIX Specification compliance.

It has all the features you would expect in a modern fully-fledged Unix, including true multitasking, virtual memory, shared libraries, demand loading, shared copy-on-write executables, proper memory management, and multistack networking including IPv4 and IPv6.

It is distributed under the GNU General Public License v2 — see the accompanying COPYING file for more details.

On what hardware does it run?В¶

Although originally developed first for 32-bit x86-based PCs (386 or higher), today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell, IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64 Xtensa, and ARC architectures.

Linux is easily portable to most general-purpose 32- or 64-bit architectures as long as they have a paged memory management unit (PMMU) and a port of the GNU C compiler (gcc) (part of The GNU Compiler Collection, GCC). Linux has also been ported to a number of architectures without a PMMU, although functionality is then obviously somewhat limited. Linux has also been ported to itself. You can now run the kernel as a userspace application — this is called UserMode Linux (UML).

Documentation¶

• There is a lot of documentation available both in electronic form on the Internet and in books, both Linux-specific and pertaining to general UNIX questions. I’d recommend looking into the documentation subdirectories on any Linux FTP site for the LDP (Linux Documentation Project) books. This README is not meant to be documentation on the system: there are much better sources available.
• There are various README files in the Documentation/ subdirectory: these typically contain kernel-specific installation notes for some drivers for example. See Documentation/00-INDEX for a list of what is contained in each file. Please read the Documentation/process/changes.rst file, as it contains information about the problems, which may result by upgrading your kernel.

Installing the kernel source¶

If you install the full sources, put the kernel tarball in a directory where you have permissions (e.g. your home directory) and unpack it:

Replace “X” with the version number of the latest kernel.

Do NOT use the /usr/src/linux area! This area has a (usually incomplete) set of kernel headers that are used by the library header files. They should match the library, and not get messed up by whatever the kernel-du-jour happens to be.

You can also upgrade between 4.x releases by patching. Patches are distributed in the xz format. To install by patching, get all the newer patch files, enter the top level directory of the kernel source (linux-4.X) and execute:

Replace “x” for all versions bigger than the version “X” of your current source tree, in_order, and you should be ok. You may want to remove the backup files (some-file-name

or some-file-name.orig), and make sure that there are no failed patches (some-file-name# or some-file-name.rej). If there are, either you or I have made a mistake.

Unlike patches for the 4.x kernels, patches for the 4.x.y kernels (also known as the -stable kernels) are not incremental but instead apply directly to the base 4.x kernel. For example, if your base kernel is 4.0 and you want to apply the 4.0.3 patch, you must not first apply the 4.0.1 and 4.0.2 patches. Similarly, if you are running kernel version 4.0.2 and want to jump to 4.0.3, you must first reverse the 4.0.2 patch (that is, patch -R) before applying the 4.0.3 patch. You can read more on this in Documentation/process/applying-patches.rst .

Alternatively, the script patch-kernel can be used to automate this process. It determines the current kernel version and applies any patches found:

The first argument in the command above is the location of the kernel source. Patches are applied from the current directory, but an alternative directory can be specified as the second argument.

Make sure you have no stale .o files and dependencies lying around:

You should now have the sources correctly installed.

Software requirements¶

Build directory for the kernel¶

When compiling the kernel, all output files will per default be stored together with the kernel source code. Using the option make O=output/dir allows you to specify an alternate place for the output files (including .config). Example:

To configure and build the kernel, use:

Please note: If the O=output/dir option is used, then it must be used for all invocations of make.

Configuring the kernel¶

Alternative configuration commands are:

You can find more information on using the Linux kernel config tools in Documentation/kbuild/kconfig.txt.

NOTES on make config :

• Having unnecessary drivers will make the kernel bigger, and can under some circumstances lead to problems: probing for a nonexistent controller card may confuse your other controllers.
• A kernel with math-emulation compiled in will still use the coprocessor if one is present: the math emulation will just never get used in that case. The kernel will be slightly larger, but will work on different machines regardless of whether they have a math coprocessor or not.
• The “kernel hacking” configuration details usually result in a bigger or slower kernel (or both), and can even make the kernel less stable by configuring some routines to actively try to break bad code to find kernel problems (kmalloc()). Thus you should probably answer ‘n’ to the questions for “development”, “experimental”, or “debugging” features.

Compiling the kernel¶

Make sure you have at least gcc 3.2 available. For more information, refer to Documentation/process/changes.rst .

Please note that you can still run a.out user programs with this kernel.

Do a make to create a compressed kernel image. It is also possible to do make install if you have lilo installed to suit the kernel makefiles, but you may want to check your particular lilo setup first.

To do the actual install, you have to be root, but none of the normal build should require that. Don’t take the name of root in vain.

If you configured any of the parts of the kernel as modules , you will also have to do make modules_install .

Verbose kernel compile/build output:

Normally, the kernel build system runs in a fairly quiet mode (but not totally silent). However, sometimes you or other kernel developers need to see compile, link, or other commands exactly as they are executed. For this, use “verbose” build mode. This is done by passing V=1 to the make command, e.g.:

To have the build system also tell the reason for the rebuild of each target, use V=2 . The default is V=0 .

Keep a backup kernel handy in case something goes wrong. This is especially true for the development releases, since each new release contains new code which has not been debugged. Make sure you keep a backup of the modules corresponding to that kernel, as well. If you are installing a new kernel with the same version number as your working kernel, make a backup of your modules directory before you do a make modules_install .

Alternatively, before compiling, use the kernel config option “LOCALVERSION” to append a unique suffix to the regular kernel version. LOCALVERSION can be set in the “General Setup” menu.

In order to boot your new kernel, you’ll need to copy the kernel image (e.g. . /linux/arch/x86/boot/bzImage after compilation) to the place where your regular bootable kernel is found.

Booting a kernel directly from a floppy without the assistance of a bootloader such as LILO, is no longer supported.

If you boot Linux from the hard drive, chances are you use LILO, which uses the kernel image as specified in the file /etc/lilo.conf. The kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or /boot/bzImage. To use the new kernel, save a copy of the old image and copy the new image over the old one. Then, you MUST RERUN LILO to update the loading map! If you don’t, you won’t be able to boot the new kernel image.

Reinstalling LILO is usually a matter of running /sbin/lilo. You may wish to edit /etc/lilo.conf to specify an entry for your old kernel image (say, /vmlinux.old) in case the new one does not work. See the LILO docs for more information.

After reinstalling LILO, you should be all set. Shutdown the system, reboot, and enjoy!

If you ever need to change the default root device, video mode, ramdisk size, etc. in the kernel image, use the rdev program (or alternatively the LILO boot options when appropriate). No need to recompile the kernel to change these parameters.

Reboot with the new kernel and enjoy.

If something goes wrong¶

If you have problems that seem to be due to kernel bugs, please check the file MAINTAINERS to see if there is a particular person associated with the part of the kernel that you are having trouble with. If there isn’t anyone listed there, then the second best thing is to mail them to me (torvalds @ linux-foundation . org), and possibly to any other relevant mailing-list or to the newsgroup.

In all bug-reports, please tell what kernel you are talking about, how to duplicate the problem, and what your setup is (use your common sense). If the problem is new, tell me so, and if the problem is old, please try to tell me when you first noticed it.

If the bug results in a message like:

or similar kernel debugging information on your screen or in your system log, please duplicate it exactly. The dump may look incomprehensible to you, but it does contain information that may help debugging the problem. The text above the dump is also important: it tells something about why the kernel dumped code (in the above example, it’s due to a bad kernel pointer). More information on making sense of the dump is in Documentation/admin-guide/bug-hunting.rst

If you compiled the kernel with CONFIG_KALLSYMS you can send the dump as is, otherwise you will have to use the ksymoops program to make sense of the dump (but compiling with CONFIG_KALLSYMS is usually preferred). This utility can be downloaded from https://www.kernel.org/pub/linux/utils/kernel/ksymoops/ . Alternatively, you can do the dump lookup by hand:

In debugging dumps like the above, it helps enormously if you can look up what the EIP value means. The hex value as such doesn’t help me or anybody else very much: it will depend on your particular kernel setup. What you should do is take the hex value from the EIP line (ignore the 0010: ), and look it up in the kernel namelist to see which kernel function contains the offending address.

To find out the kernel function name, you’ll need to find the system binary associated with the kernel that exhibited the symptom. This is the file ‘linux/vmlinux’. To extract the namelist and match it against the EIP from the kernel crash, do:

This will give you a list of kernel addresses sorted in ascending order, from which it is simple to find the function that contains the offending address. Note that the address given by the kernel debugging messages will not necessarily match exactly with the function addresses (in fact, that is very unlikely), so you can’t just ‘grep’ the list: the list will, however, give you the starting point of each kernel function, so by looking for the function that has a starting address lower than the one you are searching for but is followed by a function with a higher address you will find the one you want. In fact, it may be a good idea to include a bit of “context” in your problem report, giving a few lines around the interesting one.

If you for some reason cannot do the above (you have a pre-compiled kernel image or similar), telling me as much about your setup as possible will help. Please read the admin-guide/reporting-bugs.rst document for details.

Alternatively, you can use gdb on a running kernel. (read-only; i.e. you cannot change values or set break points.) To do this, first compile the kernel with -g; edit arch/x86/Makefile appropriately, then do a make clean . You’ll also need to enable CONFIG_PROC_FS (via make config ).

After you’ve rebooted with the new kernel, do gdb vmlinux /proc/kcore . You can now use all the usual gdb commands. The command to look up the point where your system crashed is l *0xXXXXXXXX . (Replace the XXXes with the EIP value.)

gdb’ing a non-running kernel currently fails because gdb (wrongly) disregards the starting offset for which the kernel is compiled.

Источник