Difference between revisions of "Handbook:Parts/Installation/Kernel"

From Gentoo Wiki
Jump to:navigation Jump to:search
(Alternative: Using genkernel: Massive reword. Simply section by passing --mountboot to genkernel. This covers the case where Legacy boot/BIOS will have /boot on an ext4 partition and EFI systems where /boot is part of rootfs. Rename initrd -> initramfs. Remove outdated info. Clarify pros/cons.)
(Restructure so that distribution kernels is the recommended go-forward install path .)
(3 intermediate revisions by the same user not shown)
Line 33: Line 33:
  
 
<!--T:13-->
 
<!--T:13-->
Now it is time to configure and compile the kernel sources. There are three approaches for this:
+
Now it is time to configure and compile the kernel sources. For the purposes of the installation, three approaches to kernel management will be presented, however at any point post-installation a new approach can be employed.
 +
 
 +
Ranked from least involved with least control over updates, to most involved with most control over updates:
  
 
<!--T:77-->
 
<!--T:77-->
# The kernel is manually configured and built.
+
; [[Handbook:{{#ifeq: {{NAMESPACE}}|Translations|Parts|{{ROOTPAGENAME}}}}/Installation/Kernel/Dist-Kernel|Full automation]]: A [[Project:Distribution_Kernel|Distribution Kernel]] is used to configure, automatically build, and install the Linux kernel, its associated modules, and (optionally, but enabled by default) an initramfs file. Future kernel updates are fully automated since they are handled through the package manager, just like any other system package. It is possible provide a custom kernel configuration file if customization is necessary. This is the least involved process, and is perfect for new Gentoo users, but offers the least amount of update control.
# A tool called {{c|genkernel}} is used to automatically build and install the Linux kernel.
+
; [[#Alternative: Manual configuration|Genkernel]] (hybrid): New kernel sources are installed via the system package manager. System administrators use Gentoo's {{c|genkernel}} tool to generically configure, automatically build and install the Linux kernel, its associated modules, and (optionally, but '''''not''''' enabled by default) an initramfs file. It is possible provide a custom kernel configuration file if customization is necessary. Future kernel configuration, compilation, and installation require the system administrator's involvement in the form of running {{c|eselect kernel}}, {{c|genkernel}}, and potentially other commands for each update.
# A [[Project:Distribution_Kernel|Distribution Kernel]] is used to automatically build and install the Linux kernel like any other package.
+
; [[#Alternative: Manual configuration|Manual configuration]]: New kernel sources are installed via the system package manager. The kernel is manually configured, built, and installed using the {{c|eselect kernel}} and a slew of {{c|make}} commands. Future kernel updates repeat the manual process of configuring, building, and installing the kernel files. This is the most involved process, but offers maximum control over the kernel update process.
 +
 
 +
<!--T:6-->
 +
The core around which all distributions are built is the Linux kernel. It is the layer between the user's programs and the system hardware. Although the handbook provides its users several possible kernel sources, a more comprehensive listing with more detailed descriptions is available at the [[Kernel/Overview|Kernel overview page]].
  
<!--T:14-->
+
<!--T:87-->
Manual configuration is explained as the default choice since it is the best way to optimize an environment.
+
{{#switch: {{Handbook Variable|architecture}} | amd64 | x86 = {{Handbook:Parts/Installation/Kernel/Dist-Kernel}} }}
  
<!--T:6-->
+
=== Installing the kernel sources === <!--T:5-->
The core around which all distributions are built is the Linux kernel. It is the layer between the user programs and the system hardware. Gentoo provides its users several possible kernel sources. A full listing with description is available at the [[Kernel/Overview|Kernel overview page]].
 
  
=== Installing the sources === <!--T:5-->
+
{{Note|This section is only relevant when using the following {{c|genkernel}} (hybrid) or manual kernel management approach.}}
  
<!--T:7-->
+
When installing and compiling the kernel for {{Handbook Variable|architecture}}-based systems, Gentoo recommends the {{Package|sys-kernel/{{Handbook Variable|kernel-sources}}}} package.
When manually installing and compiling the kernel for {{Handbook Variable|architecture}}-based systems, Gentoo recommends the {{Package|sys-kernel/{{Handbook Variable|kernel-sources}}}} package.
 
  
<!--T:8-->
 
 
Choose an appropriate kernel source and install it using {{c|emerge}}:
 
Choose an appropriate kernel source and install it using {{c|emerge}}:
  
<!--T:9-->
 
 
{{Emerge|sys-kernel/{{Handbook Variable|kernel-sources}}}}
 
{{Emerge|sys-kernel/{{Handbook Variable|kernel-sources}}}}
  
Line 87: Line 88:
 
}}}}
 
}}}}
  
=== Manual configuration === <!--T:15-->
+
=== Alternative: Genkernel === <!--T:51-->
 +
 
 +
<!--T:52-->
 +
If an entirely manual configuration looks too daunting, system administrators should consider using {{c|genkernel}} as a hybrid approach to kernel maintenance.
 +
 
 +
Genkernel provides a generic kernel configuration file, automatically '''''gen'''''erates the '''''kernel''''', initramfs, and associated modules, and then installs the resulting binaries to the appropriate locations. This results in minimal and generic hardware support for the system's first boot, and allows for additional update control and customization of the kernel's configuration in the future.
 +
 
 +
Be informed: while using {{c|genkernel}} to maintain the kernel provides system administrators with more update control over the system's kernel, initramfs, and other options, it ''will'' require a time and effort commitment to perform future kernel updates as new sources are released. Those looking for a hands-off approach to kernel maintenance should [[#Alternative:_Using_distribution_kernels|use a distribution kernel]].
 +
 
 +
For additional clarity, it is a ''misconception'' to believe genkernel automatically generates a ''custom'' kernel configuration for the hardware on which it is run; it uses a per-determined kernel configuration that supports most generic hardware and automatically handles the {{c|make}} commands necessary to assemble and install the kernel, the associate modules, and the initramfs file.
 +
 
 +
<!--T:54-->
 +
Explanations aside, system administrators who want to proceed with {{c|genkernel}} should install the {{Package|sys-kernel/genkernel}} package:
 +
 
 +
<!--T:55-->
 +
{{Emerge|sys-kernel/genkernel}}
 +
 
 +
<!--T:60-->
 +
Compile the kernel sources by running {{c|genkernel all}}. Be aware though, as {{c|genkernel}} compiles a kernel that supports a wide array of hardware for differing computer architectures, this compilation may take quite a while to finish.
 +
 
 +
<!--T:61-->
 +
{{Note|If the root partition/volume uses a filesystem other than ext4, it may be necessary to manually configure the kernel using {{c|genkernel --menuconfig all}} to add built-in kernel support for the particular filesystem(s) (i.e. not building the filesystem as a module).}}
 +
 
 +
{{Note|Users of LVM2 should add <code>--lvm</code> as an argument to the {{c|genkernel}} command below.}}
 +
 
 +
<!--T:62-->
 +
{{RootCmd|genkernel --mountboot --install all}}
 +
 
 +
<!--T:63-->
 +
Once genkernel completes, a kernel and an initial ram filesystem (initramfs) will be generated and installed into the {{Path|/boot}} directory. Associated modules will be installed into the {{Path|/lib/modules}} directory. The initramfs will be started immediately after loading the kernel to perform hardware auto-detection (just like in the live disk image environments).
 +
 
 +
<!--T:64-->
 +
{{RootCmd
 +
|ls /boot/vmlinu* /boot/initramfs*
 +
|ls /lib/modules
 +
}}
 +
 
 +
=== Alternative: Manual configuration === <!--T:15-->
  
 
==== Introduction ==== <!--T:16-->
 
==== Introduction ==== <!--T:16-->
Line 110: Line 148:
  
 
<!--T:23-->
 
<!--T:23-->
{{RootCmd|cd /usr/src/linux
+
{{RootCmd
|make menuconfig}}
+
|cd /usr/src/linux
 +
|make menuconfig
 +
}}
  
 
<!--T:24-->
 
<!--T:24-->
Line 267: Line 307:
 
<!--T:50-->
 
<!--T:50-->
 
Now continue with [[#Kernel modules|Kernel modules]].
 
Now continue with [[#Kernel modules|Kernel modules]].
 
== Alternative: Using genkernel == <!--T:51-->
 
 
<!--T:52-->
 
If an entirely manual configuration looks too daunting, system administrators should consider using {{c|genkernel}} as a hybrid approach to kernel maintenance.
 
 
Genkernel provides a generic kernel configuration file, automatically '''''gen'''''erates the '''''kernel''''', initramfs, and associated modules, and then installs the resulting binaries to the appropriate locations. This results in minimal and generic hardware support for the system's first boot, and allows for additional update control and customization of the kernel's configuration in the future.
 
 
Be informed: while using {{c|genkernel}} to maintain the kernel provides system administrators with more update control over the system's kernel, initramfs, and other options, it ''will'' require a time and effort commitment to perform future kernel updates as new sources are released. Those looking for a hands-off approach to kernel maintenance should [[Alternative:_Using_distribution_kernels|use a distribution kernel]].
 
 
For additional clarity, it is a ''misconception'' to believe genkernel automatically generates a ''custom'' kernel configuration for the hardware on which it is run; it uses a per-determined kernel configuration that supports most generic hardware and automatically handles the {{c|make}} commands necessary to assemble and install the kernel, the associate modules, and the initramfs file.
 
 
<!--T:54-->
 
Explanations aside, system administrators who want to proceed with {{c|genkernel}} should install the {{Package|sys-kernel/genkernel}} package:
 
 
<!--T:55-->
 
{{Emerge|sys-kernel/genkernel}}
 
 
<!--T:60-->
 
Compile the kernel sources by running {{c|genkernel all}}. Be aware though, as {{c|genkernel}} compiles a kernel that supports a wide array of hardware for differing computer architectures, this compilation may take quite a while to finish.
 
 
<!--T:61-->
 
{{Note|If the root partition/volume uses a filesystem other than ext4, it may be necessary to manually configure the kernel using {{c|genkernel --menuconfig all}} to add built-in kernel support for the particular filesystem(s) (i.e. not building the filesystem as a module).}}
 
 
{{Note|Users of LVM2 should add <code>--lvm</code> as an argument to the {{c|genkernel}} command below.}}
 
 
<!--T:62-->
 
{{RootCmd|genkernel --mountboot --install all}}
 
 
<!--T:63-->
 
Once genkernel completes, a kernel and an initial ram filesystem (initramfs) will be generated and installed into the {{Path|/boot}} directory. Associated modules will be installed into the {{Path|/lib/modules}} directory. The initramfs will be started immediately after loading the kernel to perform hardware auto-detection (just like in the live disk image environments).
 
 
<!--T:64-->
 
{{RootCmd
 
|ls /boot/vmlinu* /boot/initramfs*
 
|ls /lib/modules
 
}}
 
 
 
 
<!--T:87-->
 
{{#switch: {{Handbook Variable|architecture}} | amd64 | x86 = {{Handbook:Parts/Installation/Kernel/Dist-Kernel}} }}
 
  
 
== Kernel modules == <!--T:65-->
 
== Kernel modules == <!--T:65-->
  
=== Configuring the modules === <!--T:66-->
+
=== Listing available kernel modules === <!--T:66-->
  
 
<!--T:82-->
 
<!--T:82-->
{{Note|Hardware modules are optional to be listed manually. {{c|udev}} will normally load all hardware modules that are detected to be connected in most cases. However, it is not harmful for automatically detected modules to be listed. Sometimes exotic hardware requires help to load their drivers.}}
+
{{Note|Hardware modules are optional to be listed manually. {{c|udev}} will normally load all hardware modules that are detected to be connected in most cases. However, it is not harmful for modules that will be automatically loaded to be listed. Modules cannot be loaded twice; they are either loaded or unloaded. Sometimes exotic hardware requires help to load their drivers.}}
  
 
<!--T:67-->
 
<!--T:67-->
List the modules that need to be loaded automatically in {{Path|/etc/modules-load.d/*.conf}} files one module per line. Extra options for the modules, if necessary, should be set in {{Path|/etc/modprobe.d/*.conf}} files.
+
The modules that need to be loaded during each boot in can be added to {{Path|/etc/modules-load.d/*.conf}} files in the format of one module per line. When extra options are needed for the modules, they should be set in {{Path|/etc/modprobe.d/*.conf}} files instead.
  
 
<!--T:68-->
 
<!--T:68-->
To view all available modules, run the following {{c|find}} command. Don't forget to substitute "<kernel version>" with the version of the kernel just compiled:
+
To view all modules available for a specific kernel version, issue the following {{c|find}} command. Do not forget to substitute "<kernel version>" with the appropriate version of the kernel to search:
  
 
<!--T:69-->
 
<!--T:69-->
 
{{RootCmd|find /lib/modules/<kernel version>/ -type f -iname '*.o' -or -iname '*.ko' {{!}} less}}
 
{{RootCmd|find /lib/modules/<kernel version>/ -type f -iname '*.o' -or -iname '*.ko' {{!}} less}}
 +
 +
=== Force loading particular kernel modules ===
  
 
<!--T:70-->
 
<!--T:70-->
For instance, to automatically load the {{Path|3c59x.ko}} module (which is the driver for a specific 3Com network card family), edit the {{Path|/etc/modules-load.d/network.conf}} file and enter the module name in it. The actual file name is insignificant to the loader.
+
To force load the kernel to load the {{Path|3c59x.ko}} module (which is the driver for a specific 3Com network card family), edit the {{Path|/etc/modules-load.d/network.conf}} file and enter the module name within it.
  
 
<!--T:71-->
 
<!--T:71-->
{{RootCmd|mkdir -p /etc/modules-load.d
+
{{RootCmd
 +
|mkdir -p /etc/modules-load.d
 
|nano -w /etc/modules-load.d/network.conf
 
|nano -w /etc/modules-load.d/network.conf
 
}}
 
}}
 +
 +
Note that the module's {{Path|.ko}} file suffix is insignificant to the loading mechanism and left out of the configuration file:
  
 
<!--T:83-->
 
<!--T:83-->
{{FileBox|filename=/etc/modules-load.d/network.conf|title=Force loading 3c59x module|1=3c59x}}
+
{{FileBox|filename=/etc/modules-load.d/network.conf|title=Force loading 3c59x module|1=
 +
3c59x
 +
}}
  
 
<!--T:72-->
 
<!--T:72-->

Revision as of 02:15, 19 February 2023


Warning
Readers should not try to follow instructions directly from the Handbook:Parts namespace (which is THIS page!). The sections displayed below are used as a skeleton for transcluding information into the computer architecture specific handbooks and are therefore lacking critical information.

Please visit the Handbook list to read instructions for a relevant computer architecture.
Parts Handbook
Installation
About the installation
Choosing the media
Configuring the network
Preparing the disks
The stage file
Installing base system
Configuring the kernel
Configuring the system
Installing tools
Configuring the bootloader
Finalizing
Working with Gentoo
Portage introduction
USE flags
Portage features
Initscript system
Environment variables
Working with Portage
Files and directories
Variables
Mixing software branches
Additional tools
Custom package repository
Advanced features
OpenRC network configuration
Getting started
Advanced configuration
Modular networking
Wireless
Adding functionality
Dynamic management


Optional: Installing firmware and/or microcode

Firmware

Before getting to configuring kernel sections, it is beneficial to be aware that some hardware devices require additional, sometimes non-FOSS compliant, firmware to be installed on the system before they will operate correctly. This is often the case for wireless network interfaces commonly found in both desktop and laptop computers. Modern video chips from vendors like AMD, Nvidia, and Intel, often also require external firmware files to be fully functional. Most firmware for modern hardware devices can be found within the sys-kernel/linux-firmware package.

It is recommended to have the sys-kernel/linux-firmware package installed before the initial system reboot in order to have the firmware available in the event that it is necessary:

root #emerge --ask sys-kernel/linux-firmware
Note
Installing certain firmware packages often requires accepting the associated firmware licenses. If necessary, visit the license handling section of the Handbook for help on accepting licenses.

It is important to note that kernel symbols that are built as modules (M) will load their associated firmware files from the filesystem when they are loaded by the kernel. It is not necessary to include the device's firmware files into the kernel's binary image for symbols loaded as modules.

Microcode

In addition to discrete graphics hardware and network interfaces, CPUs also can require firmware updates. Typically this kind of firmware is referred to as microcode. Newer revisions of microcode are sometimes necessary to patch instability, security concerns, or other miscellaneous bugs in CPU hardware.

Microcode updates for AMD CPUs are distributed within the aforementioned sys-kernel/linux-firmware package. Microcode for Intel CPUs can be found within the sys-firmware/intel-microcode package, which will need to be installed separately. See the Microcode article for more information on how to apply microcode updates.

Kernel configuration and compilation

Now it is time to configure and compile the kernel sources. For the purposes of the installation, three approaches to kernel management will be presented, however at any point post-installation a new approach can be employed.

Ranked from least involved with least control over updates, to most involved with most control over updates:

Full automation
A Distribution Kernel is used to configure, automatically build, and install the Linux kernel, its associated modules, and (optionally, but enabled by default) an initramfs file. Future kernel updates are fully automated since they are handled through the package manager, just like any other system package. It is possible provide a custom kernel configuration file if customization is necessary. This is the least involved process, and is perfect for new Gentoo users, but offers the least amount of update control.
Genkernel (hybrid)
New kernel sources are installed via the system package manager. System administrators use Gentoo's genkernel tool to generically configure, automatically build and install the Linux kernel, its associated modules, and (optionally, but not enabled by default) an initramfs file. It is possible provide a custom kernel configuration file if customization is necessary. Future kernel configuration, compilation, and installation require the system administrator's involvement in the form of running eselect kernel, genkernel, and potentially other commands for each update.
Manual configuration
New kernel sources are installed via the system package manager. The kernel is manually configured, built, and installed using the eselect kernel and a slew of make commands. Future kernel updates repeat the manual process of configuring, building, and installing the kernel files. This is the most involved process, but offers maximum control over the kernel update process.

The core around which all distributions are built is the Linux kernel. It is the layer between the user's programs and the system hardware. Although the handbook provides its users several possible kernel sources, a more comprehensive listing with more detailed descriptions is available at the Kernel overview page.

Distribution kernels

Distribution Kernels are ebuilds that cover the complete process of unpacking, configuring, compiling, and installing the kernel. The primary advantage of this method is that the kernels are updated to new versions by the package manager as part of @world upgrade. This requires no more involvement than running an emerge command. Distribution kernels default to a configuration supporting the majority of hardware, however two mechanisms are offered for customization: savedconfig and config snippets. See the project page for more details on configuration.

Installing a distribution kernel

Before installing the kernel package the dracut USE flag needs to be added for the package sys-kernel/installkernel in /etc/portage/package.use:

FILE /etc/portage/package.use/installkernelEnable dracut support
sys-kernel/installkernel dracut

Users may also wish to enable additional sys-kernel/installkernel USE flags at this stage. See the Installation/Kernel#Installkernel section for details.

To build a kernel with Gentoo patches from source, type:

root #emerge --ask sys-kernel/gentoo-kernel

System administrators who want to avoid compiling the kernel sources locally can instead use precompiled kernel images:

root #emerge --ask sys-kernel/gentoo-kernel-bin
Optional: Signed kernel modules

The kernel modules in the prebuilt distribution kernel (sys-kernel/gentoo-kernel-bin) are already signed. To sign the modules of kernels built from source enable the modules-sign USE flag, and optionally specify which key to use for signing in /etc/portage/make.conf:

FILE /etc/portage/make.confEnable module signing
USE="modules-sign"

# Optionally, to use custom signing keys.
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem" # Only required if the MODULES_SIGN_KEY does not also contain the certificate.
MODULES_SIGN_HASH="sha512" # Defaults to sha512.

If MODULES_SIGN_KEY is not specified the kernel build system will generate a key, it will be stored in /usr/src/linux-x.y.z/certs. It is recommended to manually generate a key to ensure that it will be the same for each kernel release. A key may be generated with:

root #openssl req -new -nodes -utf8 -sha256 -x509 -outform PEM -out kernel_key.pem -keyout kernel_key.pem
Note
The MODULES_SIGN_KEY and MODULES_SIGN_CERT may be different files. For this example the pem file generated by OpenSSL includes both the key and the accompanying certificate, and thus both variables are set to the same value.

OpenSSL will ask some questions about the user generating the key, it is recommended to fill in these questions as detailed as possible.

Store the key in a safe location, at the very least the key should be readable only by the root user. Verify this with:

root #ls -l kernel_key.pem
 -r-------- 1 root root 3164 Jan  4 10:38 kernel_key.pem 

If this outputs anything other then the above, correct the permissions with:

root #chown root:root kernel_key.pem
root #chmod 400 kernel_key.pem
Optional: Signing the kernel image (Secure Boot)

The kernel image in the prebuilt distribution kernel (sys-kernel/gentoo-kernel-bin) is already signed for use with Secure Boot. To sign the kernel image of kernels built from source enable the secureboot USE flag, and optionally specify which key to use for signing in /etc/portage/make.conf. Note that signing the kernel image for use with secureboot requires that the kernel modules are also signed, the same key may be used to sign both the kernel image and the kernel modules:

FILE /etc/portage/make.confEnable custom signing keys
USE="modules-sign secureboot"

# Optionally, to use custom signing keys.
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem" # Only required if the MODULES_SIGN_KEY does not also contain the certificate.
MODULES_SIGN_HASH="sha512" # Defaults to sha512.

# Optionally, to boot with secureboot enabled, may be the same or different signing key.
SECUREBOOT_SIGN_KEY="/path/to/kernel_key.pem"
SECUREBOOT_SIGN_CERT="/path/to/kernel_key.pem"
Note
The SECUREBOOT_SIGN_KEY and SECUREBOOT_SIGN_CERT may be different files. For this example the pem file generated by OpenSSL includes both the key and the accompanying certificate, and thus both variables are set to the same value.
Note
For this example the same key that was generated to sign the modules is used to sign the kernel image. It is also possible to generate and use a second separate key for signing the kernel image. The same OpenSSL command as in the previous section may be used again.

See the above section for instructions on generating a new key, the steps may be repeated if a separate key should be used to sign the kernel image.

To successfully boot with Secure Boot enabled, the used bootloader must also be signed and the certificate must be accepted by the UEFI firmware or Shim. This will be explained later in the handbook.

Upgrading and cleaning up

Once the kernel is installed, the package manager will automatically update it to newer versions. The previous versions will be kept until the package manager is requested to clean up stale packages. To reclaim disk space, stale packages can be trimmed by periodically running emerge with the --depclean option:

root #emerge --depclean

Alternatively, to specifically clean up old kernel versions:

root #emerge --prune sys-kernel/gentoo-kernel sys-kernel/gentoo-kernel-bin

Post-install/upgrade tasks

Distribution kernels are capable of rebuilding kernel modules installed by other packages. linux-mod-r1.eclass provides the dist-kernel USE flag which controls a subslot dependency on virtual/dist-kernel.

Enabling this USE flag on packages like sys-fs/zfs and sys-fs/zfs-kmod allows them to automatically be rebuilt against a newly updated kernel and, if applicable, will re-generate the initramfs accordingly.

Manually rebuilding the initramfs or Unified Kernel Image

If required, manually trigger such rebuilds by, after a kernel upgrade, executing:

root #emerge --ask @module-rebuild

If any kernel modules (e.g. ZFS) are needed at early boot, rebuild the initramfs afterward via:

root #emerge --config sys-kernel/gentoo-kernel
root #emerge --config sys-kernel/gentoo-kernel-bin

Installing the kernel sources

Note
This section is only relevant when using the following genkernel (hybrid) or manual kernel management approach.

When installing and compiling the kernel for amd64-based systems, Gentoo recommends the sys-kernel/gentoo-sources package.

Choose an appropriate kernel source and install it using emerge:

root #emerge --ask sys-kernel/gentoo-sources

This will install the Linux kernel sources in /usr/src/ using the specific kernel version in the path. It will not create a symbolic link by itself without USE=symlink being enabled on the chosen kernel sources package.

It is conventional for a /usr/src/linux symlink to be maintained, such that it refers to whichever sources correspond with the currently running kernel. However, this symbolic link will not be created by default. An easy way to create the symbolic link is to utilize eselect's kernel module.

For further information regarding the purpose of the symlink, and how to manage it, please refer to Kernel/Upgrade.

First, list all installed kernels:

root #eselect kernel list
Available kernel symlink targets:
  [1]   linux-6.1.38-gentoo

In order to create a symbolic link called linux, use:

root #eselect kernel set 1
root #ls -l /usr/src/linux
lrwxrwxrwx    1 root   root    12 Oct 13 11:04 /usr/src/linux -> linux-6.1.38-gentoo

Alternative: Genkernel

If an entirely manual configuration looks too daunting, system administrators should consider using genkernel as a hybrid approach to kernel maintenance.

Genkernel provides a generic kernel configuration file, automatically generates the kernel, initramfs, and associated modules, and then installs the resulting binaries to the appropriate locations. This results in minimal and generic hardware support for the system's first boot, and allows for additional update control and customization of the kernel's configuration in the future.

Be informed: while using genkernel to maintain the kernel provides system administrators with more update control over the system's kernel, initramfs, and other options, it will require a time and effort commitment to perform future kernel updates as new sources are released. Those looking for a hands-off approach to kernel maintenance should use a distribution kernel.

For additional clarity, it is a misconception to believe genkernel automatically generates a custom kernel configuration for the hardware on which it is run; it uses a per-determined kernel configuration that supports most generic hardware and automatically handles the make commands necessary to assemble and install the kernel, the associate modules, and the initramfs file.

Explanations aside, system administrators who want to proceed with genkernel should install the sys-kernel/genkernel package:

root #emerge --ask sys-kernel/genkernel

Compile the kernel sources by running genkernel all. Be aware though, as genkernel compiles a kernel that supports a wide array of hardware for differing computer architectures, this compilation may take quite a while to finish.

Note
If the root partition/volume uses a filesystem other than ext4, it may be necessary to manually configure the kernel using genkernel --menuconfig all to add built-in kernel support for the particular filesystem(s) (i.e. not building the filesystem as a module).
Note
Users of LVM2 should add --lvm as an argument to the genkernel command below.
root #genkernel --mountboot --install all

Once genkernel completes, a kernel and an initial ram filesystem (initramfs) will be generated and installed into the /boot directory. Associated modules will be installed into the /lib/modules directory. The initramfs will be started immediately after loading the kernel to perform hardware auto-detection (just like in the live disk image environments).

root #ls /boot/vmlinu* /boot/initramfs*
root #ls /lib/modules

Alternative: Manual configuration

Introduction

Manually configuring a kernel is often seen as the most difficult procedure a Linux user ever has to perform. Nothing is less true - after configuring a couple of kernels no one remembers that it was difficult!

However, one thing is true: it is vital to know the system when a kernel is configured manually. Most information can be gathered by emerging sys-apps/pciutils which contains the lspci command:

root #emerge --ask sys-apps/pciutils
Note
Inside the chroot, it is safe to ignore any pcilib warnings (like pcilib: cannot open /sys/bus/pci/devices) that lspci might throw out.

Another source of system information is to run lsmod to see what kernel modules the installation CD uses as it might provide a nice hint on what to enable.

Now go to the kernel source directory and execute make menuconfig. This will fire up menu-driven configuration screen.

root #cd /usr/src/linux
root #make menuconfig

The Linux kernel configuration has many, many sections. Let's first list some options that must be activated (otherwise Gentoo will not function, or not function properly without additional tweaks). We also have a Gentoo kernel configuration guide on the Gentoo wiki that might help out further.

Activating required options

When using sys-kernel/gentoo-sources, it is strongly recommend the Gentoo-specific configuration options be enabled. These ensure that a minimum of kernel features required for proper functioning is available:

KERNEL Enabling Gentoo-specific options
Gentoo Linux --->
  Generic Driver Options --->
    [*] Gentoo Linux support
    [*]   Linux dynamic and persistent device naming (userspace devfs) support
    [*]   Select options required by Portage features
        Support for init systems, system and service managers  --->
          [*] OpenRC, runit and other script based systems and managers
          [*] systemd

Naturally the choice in the last two lines depends on the selected init system (OpenRC vs. systemd). It does not hurt to have support for both init systems enabled.

When using sys-kernel/vanilla-sources, the additional selections for init systems will be unavailable. Enabling support is possible, but goes beyond the scope of the handbook.

Make sure that every driver that is vital to the booting of the system (such as SCSI controller, etc.) is compiled in the kernel and not as a module, otherwise the system will not be able to boot completely.

Next select the exact processor type. It is also recommended to enable MCE features (if available) so that users are able to be notified of any hardware problems. On some architectures (such as x86_64), these errors are not printed to dmesg, but to /dev/mcelog. This requires the app-admin/mcelog package.

Also select Maintain a devtmpfs file system to mount at /dev so that critical device files are already available early in the boot process (CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT):

KERNEL Enabling devtmpfs support
Device Drivers --->
  Generic Driver Options --->
    [*] Maintain a devtmpfs filesystem to mount at /dev
    [*]   Automount devtmpfs at /dev, after the kernel mounted the rootfs

Verify SCSI disk support has been activated (CONFIG_BLK_DEV_SD):

KERNEL Enabling SCSI disk support
Device Drivers --->
   SCSI device support  --->
      <*> SCSI disk support

Now go to File Systems and select support for the filesystems that will be used by the system. Do not compile the file system that is used for the root filesystem as module, otherwise the system may not be able to mount the partition. Also select Virtual memory and /proc file system. Select one or more of the following options as needed by the system (CONFIG_EXT2_FS, CONFIG_EXT3_FS, CONFIG_EXT4_FS, CONFIG_MSDOS_FS, CONFIG_VFAT_FS, CONFIG_PROC_FS, and CONFIG_TMPFS):

KERNEL Selecting necessary file systems
File systems --->
  <*> Second extended fs support
  <*> The Extended 3 (ext3) filesystem
  <*> The Extended 4 (ext4) filesystem
  <*> Reiserfs support
  <*> JFS filesystem support
  <*> XFS filesystem support
  <*> Btrfs filesystem support
  DOS/FAT/NT Filesystems  --->
    <*> MSDOS fs support
    <*> VFAT (Windows-95) fs support
 
  Pseudo Filesystems --->
    [*] /proc file system support
    [*] Tmpfs virtual memory file system support (former shm fs)

If PPPoE is used to connect to the Internet, or a dial-up modem, then enable the following options (CONFIG_PPP, CONFIG_PPP_ASYNC, and CONFIG_PPP_SYNC_TTY):

KERNEL Selecting PPPoE necessary drivers
Device Drivers --->
  Network device support --->
    <*> PPP (point-to-point protocol) support
    <*>   PPP support for async serial ports
    <*>   PPP support for sync tty ports

The two compression options won't harm but are not definitely needed, neither does the PPP over Ethernet option, that might only be used by ppp when configured to do kernel mode PPPoE.

Don't forget to include support in the kernel for the network (Ethernet or wireless) cards.

Most systems also have multiple cores at their disposal, so it is important to activate Symmetric multi-processing support (CONFIG_SMP):

KERNEL Activating SMP support
Processor type and features  --->
  [*] Symmetric multi-processing support
Note
In multi-core systems, each core counts as one processor.

If USB input devices (like keyboard or mouse) or other USB devices will be used, do not forget to enable those as well (CONFIG_HID_GENERIC and CONFIG_USB_HID, CONFIG_USB_SUPPORT, CONFIG_USB_XHCI_HCD, CONFIG_USB_EHCI_HCD, CONFIG_USB_OHCI_HCD):

KERNEL Activating USB support for input devices
Device Drivers --->
  HID support  --->
    -*- HID bus support
    <*>   Generic HID driver
    [*]   Battery level reporting for HID devices
      USB HID support  --->
        <*> USB HID transport layer
  [*] USB support  --->
    <*>     xHCI HCD (USB 3.0) support
    <*>     EHCI HCD (USB 2.0) support
    <*>     OHCI HCD (USB 1.1) support

Architecture specific kernel configurations

Note
Placeholder for architecture-specific kernel build information

Compiling and installing

Note
Placeholder for instructions for building and installing the kernel sources

Optional: Building an initramfs

In certain cases it is necessary to build an initramfs - an initial ram-based file system. The most common reason is when important file system locations (like /usr/ or /var/) are on separate partitions. With an initramfs, these partitions can be mounted using the tools available inside the initramfs.

Without an initramfs, there is a risk that the system will not boot properly as the tools that are responsible for mounting the file systems require information that resides on unmounted file systems. An initramfs will pull in the necessary files into an archive which is used right after the kernel boots, but before the control is handed over to the init tool. Scripts on the initramfs will then make sure that the partitions are properly mounted before the system continues booting.

Important
If using genkernel, it should be used for both building the kernel and the initramfs. When using genkernel only for generating an initramfs, it is crucial to pass --kernel-config=/path/to/kernel.config to genkernel or the generated initramfs may not work with a manually built kernel. Note that manually built kernels go beyond the scope of support for the handbook. See the kernel configuration article for more information.

To install an initramfs, install sys-kernel/dracut first, then have it generate an initramfs:

root #emerge --ask sys-kernel/dracut
root #dracut --kver=6.1.38-gentoo

The initramfs will be stored in /boot/. The resulting file can be found by simply listing the files starting with initramfs:

root #ls /boot/initramfs*

Now continue with Kernel modules.

Kernel modules

Listing available kernel modules

Note
Hardware modules are optional to be listed manually. udev will normally load all hardware modules that are detected to be connected in most cases. However, it is not harmful for modules that will be automatically loaded to be listed. Modules cannot be loaded twice; they are either loaded or unloaded. Sometimes exotic hardware requires help to load their drivers.

The modules that need to be loaded during each boot in can be added to /etc/modules-load.d/*.conf files in the format of one module per line. When extra options are needed for the modules, they should be set in /etc/modprobe.d/*.conf files instead.

To view all modules available for a specific kernel version, issue the following find command. Do not forget to substitute "<kernel version>" with the appropriate version of the kernel to search:

root #find /lib/modules/<kernel version>/ -type f -iname '*.o' -or -iname '*.ko' | less

Force loading particular kernel modules

To force load the kernel to load the 3c59x.ko module (which is the driver for a specific 3Com network card family), edit the /etc/modules-load.d/network.conf file and enter the module name within it.

root #mkdir -p /etc/modules-load.d
root #nano -w /etc/modules-load.d/network.conf

Note that the module's .ko file suffix is insignificant to the loading mechanism and left out of the configuration file:

FILE /etc/modules-load.d/network.confForce loading 3c59x module
3c59x

Continue the installation with Configuring the system.