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

From Gentoo Wiki
Jump to:navigation Jump to:search
(Mentioning microcode per discussion on Handbook Talk:AMD64/Installation/Kernel#Microcode.)
(Move Firmware section to the beginning of the article so that readers do not have to recompile the kernel a second time after installing firmware. The goal will be to build firmware into the kernel binary during the first compile.)
Line 17: Line 17:
  
 
<!--T:10-->
 
<!--T:10-->
This will install the Linux kernel sources in {{Path|/usr/src/}} using the specific kernel version in the path. It won't create a symbolic link by itself without <code>USE=symlink</code> being enabled on the chosen kernel sources package.
+
This will install the Linux kernel sources in {{Path|/usr/src/}} using the specific kernel version in the path. It will not create a symbolic link by itself without <code>USE=symlink</code> being enabled on the chosen kernel sources package.
  
 
It is conventional for a {{Path|/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.
 
It is conventional for a {{Path|/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.
Line 38: Line 38:
 
lrwxrwxrwx    1 root  root    12 Oct 13 11:04 /usr/src/linux -> linux-{{Handbook Variable|kernel-version}}
 
lrwxrwxrwx    1 root  root    12 Oct 13 11:04 /usr/src/linux -> linux-{{Handbook Variable|kernel-version}}
 
}}}}
 
}}}}
 +
 +
== Optional: Installing firmware and/or microcode == <!--T:74-->
 +
 +
<!--T:75-->
 +
Some devices require additional firmware to be installed on the system before they will operate correctly. This is often the case for network interfaces, especially wireless network interfaces. Modern video chips, from vendors like AMD, Nvidia, and Intel, often need external firmware files. Most of the firmware is packaged in {{Package|sys-kernel/linux-firmware}}. On systems using graphics cards from these vendors, it is wise to emerge the firmware package in order to have it available before configuring the kernel.
 +
 +
<!--T:76-->
 +
{{Emerge|sys-kernel/linux-firmware}}
 +
 +
In addition to discrete graphics hardware and network interfaces, CPUs also can require firmware updates. Typically these are referred to as microcode updates. Newer revisions of micrcode are sometimes necessary to patch instability or other bugs in CPU hardware. Microcode updates are typically distributed with the linux-firmware package; although sometimes they are broken out into separate packages due to license issues. Please see the [[Microcode|Microcode article]] for more information on how to apply microcode updates.
  
 
<!--T:13-->
 
<!--T:13-->
Line 48: Line 58:
  
 
<!--T:14-->
 
<!--T:14-->
We explain the manual configuration as the default choice here as it is the best way to optimize an environment.
+
Manual configuration is explained as the default choice since it is the best way to optimize an environment.
  
 
== Kernel configuration and compilation ==
 
== Kernel configuration and compilation ==
Line 57: Line 67:
  
 
<!--T:17-->
 
<!--T:17-->
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 even remembers that it was difficult!
+
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!
  
 
<!--T:18-->
 
<!--T:18-->
Line 97: Line 107:
 
}}
 
}}
  
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.
+
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.
  
 
<!--T:85-->
 
<!--T:85-->
Line 312: Line 322:
 
<!--T:72-->
 
<!--T:72-->
 
Continue the installation with [[Handbook:{{#ifeq: {{NAMESPACE}}|Translations|Parts|{{ROOTPAGENAME}}}}/Installation/System|Configuring the system]].
 
Continue the installation with [[Handbook:{{#ifeq: {{NAMESPACE}}|Translations|Parts|{{ROOTPAGENAME}}}}/Installation/System|Configuring the system]].
 
=== Optional: Installing firmware and microcode === <!--T:74-->
 
 
<!--T:75-->
 
Some drivers require additional firmware to be installed on the system before they work. This is often the case for network interfaces, especially wireless network interfaces. Also, modern video chips, from vendors like AMD, Nvidia, and Intel when using open source drivers, often need external firmware files. Most of the firmware is packaged in {{Package|sys-kernel/linux-firmware}}:
 
 
<!--T:76-->
 
{{Emerge|sys-kernel/linux-firmware}}
 
 
{{Note|CPUs microcode updates are sometimes necessary to patch instability or other bugs in CPU hardware. Microcode updates are distributed with the linux-firmware package; although sometimes they are broken out into separate packages due to license issues. Please see the [[Microcode|Microcode article]] for more information on how to apply microcode updates.}}
 
  
 
<!--T:73-->
 
<!--T:73-->

Revision as of 07:20, 26 October 2021

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


Installing the sources

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

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

Optional: Installing firmware and/or microcode

Some devices require additional firmware to be installed on the system before they will operate correctly. This is often the case for network interfaces, especially wireless network interfaces. Modern video chips, from vendors like AMD, Nvidia, and Intel, often need external firmware files. Most of the firmware is packaged in sys-kernel/linux-firmware. On systems using graphics cards from these vendors, it is wise to emerge the firmware package in order to have it available before configuring the kernel.

root #emerge --ask sys-kernel/linux-firmware

In addition to discrete graphics hardware and network interfaces, CPUs also can require firmware updates. Typically these are referred to as microcode updates. Newer revisions of micrcode are sometimes necessary to patch instability or other bugs in CPU hardware. Microcode updates are typically distributed with the linux-firmware package; although sometimes they are broken out into separate packages due to license issues. Please see the Microcode article for more information on how to apply microcode updates.

Now it is time to configure and compile the kernel sources. There are three approaches for this:

  1. The kernel is manually configured and built.
  2. A tool called genkernel is used to automatically build and install the Linux kernel.
  3. A Distribution Kernel is used to automatically build and install the Linux kernel like any other package.

Manual configuration is explained as the default choice since it is the best way to optimize an environment.

Kernel configuration and compilation

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 huge risk that the system will not boot up properly as the tools that are responsible for mounting the file systems need information that resides on those 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
It is recommended to use genkernel for both building kernel and 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.

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

root #emerge --ask sys-kernel/genkernel
root #genkernel --install --kernel-config=/path/to/used/kernel.config initramfs

In order to enable specific support in the initramfs, such as LVM or RAID, add in the appropriate options to genkernel. See genkernel --help for more information. In the next example support is enabled for LVM and software RAID (mdadm):

root #genkernel --lvm --mdadm --install --kernel-config=/path/to/used/kernel.config initramfs

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.

Alternative: Using genkernel

If a manual configuration looks too daunting, then consider using genkernel. It will configure and build the kernel automatically.

genkernel works by configuring a kernel nearly identically to the way the installation CD kernel is configured. This means that when genkernel is used to build the kernel, the system will generally detect all hardware at boot-time, just like the installation CD does. Because genkernel doesn't require any manual kernel configuration, it is an ideal solution for those users who may not be comfortable compiling their own kernels. Note that genkernel does not automatically generate a custom kernel configuration the hardware on which it is being run.

Now, let's see how to use genkernel. First, emerge the sys-kernel/genkernel ebuild:

root #emerge --ask sys-kernel/genkernel

Next, edit the /etc/fstab file so that the line containing /boot/ as second field has the first field pointing to the right device. If the partitioning example from the handbook is followed, then this device is most likely /dev/sda1 with the ext4 file system. This would make the entry in the file look like so:

root #nano -w /etc/fstab
FILE /etc/fstabConfiguring the /boot mountpoint
/dev/sda1	/boot	ext4	defaults	0 2
Note
Further in the Gentoo installation, /etc/fstab will be configured again. The /boot setting is needed right now as the genkernel application reads in this configuration.

Now, compile the kernel sources by running genkernel all. Be aware though, as genkernel compiles a kernel that supports almost all hardware, this compilation will take quite a while to finish!

Note
If the root partition/volume doesn't use ext4 as filesystem it might be necessary to manually configure the kernel using genkernel --menuconfig all and add support for this particular filesystem in the kernel (i.e. not as a module). Users of LVM2 will probably want to add --lvm as an argument as well.
root #genkernel all

Once genkernel completes, a kernel, full set of modules and initial ram disk (initramfs) will be created. We will use the kernel and initrd when configuring a boot loader later in this document. Write down the names of the kernel and initrd as this information is used when the boot loader configuration file is edited. The initrd will be started immediately after booting to perform hardware autodetection (just like on the installation CD) before the "real" system starts up.

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

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

Kernel modules

Configuring the 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 automatically detected modules to be listed. Sometimes exotic hardware requires help to load their drivers.

List the modules that need to be loaded automatically in /etc/modules-load.d/*.conf files one module per line. Extra options for the modules, if necessary, should be set in /etc/modprobe.d/*.conf files.

To view all available modules, run the following find command. Don't forget to substitute "<kernel version>" with the version of the kernel just compiled:

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

For instance, to automatically 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 in it. The actual file name is insignificant to the loader.

root #mkdir -p /etc/modules-load.d
root #nano -w /etc/modules-load.d/network.conf
FILE /etc/modules-load.d/network.confForce loading 3c59x module
3c59x

Continue the installation with Configuring the system.