手册：X86/安装/配置Linux内核
可选：安装固件和微代码
固件
Suggested: Linux Firmware
On many systems, non-FOSS firmware is required for certain hardware to function. The sys-kernel/linux-firmware package contains firmware for many, but not all, devices.
Most wireless cards and GPUs require firmware to function.
root #emerge --ask sys-kernel/linux-firmware安装某些固件软件包时，经常需要接受固件关联的许可证。有需要的话，访问手册的许可证处理章节有助于你接受许可证。
Firmware Loading
Firmware files are typically loaded when the associated kernel module is loaded. This means the firmware must be built into the kernel using CONFIG_EXTRA_FIRMWARE if the kernel module is set to Y instead of M. In most cases, building-in a module which required firmware can complicate or break loading.
{{#switch: x86 | amd64 | x86 =
微码
除了独立显卡硬件和网络接口之外，CPU 可能也需要固件更新。通常这种固件被称为微码（microcode）。有时需要更新版本的微码来修补 CPU 硬件中的不稳定性、安全问题或其他复杂的错误。
AMD CPU 的微码更新在前面提到的 sys-kernel/linux-firmware 软件包内分发。Intel CPU 的微码可以在 sys-firmware/intel-microcode 包中找到，并且需要单独安装。更多有关如何更新微码的细节，请查看微码文章。
sys-kernel/installkernel
Installkernel may be used to automate the kernel installation, initramfs generation, unified kernel image generation and/or bootloader configuration among other things. sys-kernel/installkernel implements two paths of achieving this: the traditional installkernel originating from Debian and systemd's kernel-install. Which one to choose depends, among other things, on the system's bootloader. By default, systemd's kernel-install is used on systemd profiles, while the traditional installkernel is the default for other profiles.
Bootloader
Now is the time to think about which bootloader the user wants for the system, if unsure, follow the 'Traditional layout' subsection below.
GRUB
Users of GRUB can use either systemd's kernel-install or the traditional Debian installkernel. The systemd USE flag switches between these implementations. To automatically run grub-mkconfig when installing the kernel, enable the grub USE flag.
/etc/portage/package.use/installkernelsys-kernel/installkernel grub
root #emerge --ask sys-kernel/installkernelsystemd-boot
When using systemd-boot (formerly gummiboot) as the bootloader, systemd's kernel-install must be used. Therefore ensure the systemd and the systemd-boot USE flags are enabled on sys-kernel/installkernel, and then install the relevant package for systemd-boot.
On OpenRC systems:
/etc/portage/package.use/systemd-bootsys-apps/systemd-utils boot kernel-install
sys-kernel/installkernel systemd systemd-boot
root #emerge --ask sys-apps/systemd-utils sys-kernel/installkernelOn systemd systems:
/etc/portage/package.use/systemdsys-apps/systemd boot
sys-kernel/installkernel systemd-boot
root #emerge --ask sys-apps/systemd sys-kernel/installkernelThe kernel command line to use for new kernels should be specified in /etc/kernel/cmdline, for example:
/etc/kernel/cmdlinequiet splash
EFI stub
UEFI-based computer systems technically do not need secondary bootloaders in order to boot kernels. Secondary bootloaders exist to extend the functionality of UEFI firmware during the boot process. That being said, using a secondary bootloader is typically easier and more robust because it offers a more flexible approach for quickly modifying kernel parameters at boot time. Note also that UEFI implentations strongly differ between vendors and between models and there is no guarantee that a given firmware follows the UEFI specification. Therefore, EFI Stub booting is not guaranteed to work on every UEFI-based system, and hence the USE flag is stable masked and testing keywords must be accepted for installkernel to use this feature.
/etc/portage/package.accept_keywords/installkernelsys-kernel/installkernel
sys-boot/uefi-mkconfig
app-emulation/virt-firmware
/etc/portage/package.use/installkernelsys-kernel/installkernel efistub
root #emerge --ask sys-kernel/installkernelroot #mkdir -p /efiTraditional layout, other bootloaders (e.g. (e)lilo, syslinux, etc.)
The traditional /boot layout (for e.g. (e)LILO, syslinux, etc.) is used by default if the grub, systemd-boot, efistub and uki USE flags are not enabled. No further action is required.
Initramfs
An initial ram-based file system, or initramfs, may be required for a system to boot. A wide of variety of cases may necessitate one, but common cases include:
- Kernels where storage/filesystem drivers are modules.
- Layouts with /usr/ or /var/ on separate partitions.
- Encrypted root filesystems.
Distribution kernels are designed to be used with an initramfs, as many storage and filesystem drivers are built as modules.
In addition to mounting the root filesystem, an initramfs may also perform other tasks such as:
- Running file system consistency check fsck, a tool to check and repair consistency of a file system in such events of uncleanly shutdown a system.
- Providing a recovery environment in the event of late-boot failures.
Installkernel can automatically generate an initramfs when installing the kernel if the dracut or ugrd USE flag is enabled:
/etc/portage/package.use/installkernelsys-kernel/installkernel dracut
root #emerge --ask sys-kernel/installkernelOptional: Unified Kernel Image
A Unified Kernel Image (UKI) combines, among other things, the kernel, the initramfs and the kernel command line into a single executable. Since the kernel command line is embedded into the unified kernel image, it should be specified before generating the unified kernel image (see below). Note that any kernel command line arguments supplied by the bootloader or firmware at boot are ignored when booting with secure boot enabled.
A unified kernel image requires a stub loader. Currently, the only one available is systemd-stub. To enable it:
For systemd systems:
/etc/portage/package.use/ukisys-apps/systemd boot
root #emerge --ask sys-apps/systemdFor OpenRC systems:
/etc/portage/package.use/ukisys-apps/systemd-utils boot kernel-install
root #emerge --ask sys-apps/systemd-utilsInstallkernel can automatically generate a unified kernel image using either dracut or ukify by enabling the respective flag and the uki USE flag.
For dracut:
/etc/portage/package.use/ukisys-kernel/installkernel dracut uki
/etc/dracut.conf.d/uki.confuefi="yes"
kernel_cmdline="some-kernel-command-line-arguments"
root #emerge --ask sys-kernel/installkernelFor ukify:
/etc/portage/package.use/ukisys-apps/systemd boot ukify # For systemd systems
sys-apps/systemd-utils kernel-install boot ukify # For OpenRC systems
sys-kernel/installkernel dracut ukify uki
/etc/kernel/cmdlinesome-kernel-command-line-arguments
root #emerge --ask sys-kernel/installkernelNote that while dracut can generate both an initramfs and a unified kernel image, ukify can only generate the latter and therefore the initramfs must be generated separately with dracut.
In the above configuration examples (for both Dracut and ukify) it is important to specify at least an appropriate root= parameter for the kernel command line to ensure that the Unified Kernel Image can find the root partition. This is not required for systemd based systems following the Discoverable Partitions Specification (DPS), in that case the embedded initramfs will be able to dynamically find the root partition.
Generic Unified Kernel Image (systemd only)
The prebuilt sys-kernel/gentoo-kernel-bin can optionally install a prebuilt generic unified kernel image containing a generic initramfs that is able to boot most systemd based systems. It can be installed by enabling the generic-uki USE flag, and configuring installkernel to not generate a custom initramfs or unified kernel image:
/etc/portage/package.use/ukisys-kernel/gentoo-kernel-bin generic-uki
sys-kernel/installkernel -dracut -ukify -ugrd uki
Secure Boot
If following this section and manually compiling your own kernel, then make sure to follow the steps outlined in Signing the kernel
The generic Unified Kernel Image optionally distributed by sys-kernel/gentoo-kernel-bin is already pre-signed. How to sign a locally generated unified kernel image depends on whether dracut or ukify is used. Note that the location of the key and certificate should be the same as the SECUREBOOT_SIGN_KEY and SECUREBOOT_SIGN_CERT as specified in /etc/portage/make.conf.
For dracut:
/etc/dracut.conf.d/uki.confuefi="yes"
kernel_cmdline="some-kernel-command-line-arguments"
uefi_secureboot_key="/path/to/kernel_key.pem"
uefi_secureboot_cert="/path/to/kernel_key.pem"
For ukify:
/etc/kernel/uki.conf[UKI]
SecureBootPrivateKey=/path/to/kernel_key.pem
SecureBootCertificate=/path/to/kernel_key.pem
内核配置和编译
It can be a wise move to use the dist-kernel on the first boot as it provides a very simple method to rule out system issues and kernel config issues. Always having a known working kernel to fallback on can speed up debugging and alleviate anxiety when updating that your system will no longer boot.
现在是时候来配置和编译内核源代码了。将介绍三种用内核管理安装的方法，但是安装后，任何时候都可以采用新的方法。
During the installation phase of Gentoo, only one kernel type should be installed i.e. either the sys-kernel/gentoo-kernel-bin or sys-kernel/gentoo-sources.
由操作最少到操作最多排序：
- 全自动方法：Distribution 内核
- Distribution 内核用来配置、自动构建安装 Linux 内核、相关模块和 initramfs 文件（可选，但是默认启用）。将来内核就像其他的系统软件包一样，通过使用包管理器全自动升级。如果需要定制内核，它可以提供自定义内核配置文件。这种过程操作最少，并且非常适合新 Gentoo 用户，因为它开箱即用，并且系统管理员最少参与。
- 混合方法：Genkernel
- 通过系统包管理器安装新内核源代码。系统管理员可以使用 Gentoo 的 genkernel 工具的配置，构建和安装 Linux 内核、相关模块和 initramfs 文件（可选，但默认不 启用）。如果要自定义内核，它可以提供自定义内核配置文件。将来每次更新内核配置、编译和安装都需要系统管理员运行 eselect kernel，genkernel和其他可能的命令。
- 全手动方法
- 通过系统包管理器安装新的内核源代码。使用 eselect kernel 和一大堆 make 命令手动配置、构建和安装内核。将来内核升级需要重复手动配置、构建和安装内核文件的过程。这是操作做多的过程，但是在内核更新过程提供最大程度控制。
Linux内核是所有发行版的核心。它位于用户程序和系统硬件之间。尽管手册提供给用户一些可选的内核源码，但是在内核概述页面有更全面的列表，上面有着更多的细节描述。
Kernel installation tasks such as copying the kernel image to /boot or the EFI System Partition, generating an initramfs and/or Unified Kernel Image, updating bootloader configuration, can be automated with installkernel. Users may wish to configure and install sys-kernel/installkernel before proceeding. See the Kernel installation section below for more more information.
distribution 内核
Distribution 内核是涵盖了解包、配置、编译和安装内核完整过程的 ebuild。这种方法的主要优点是，内核可以作为 @world 的一部分通过包管理器升级到新版本。只需要运行 emerge 命令即可。Distribution 内核默认支持大多数硬件，但是有两种定制的机制：savedconfig 和 config snippets。查看项目页面获取更多配置细节。
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:
/etc/portage/make.confEnable module signingUSE="modules-sign"
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
# 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.pemThe 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.pemroot #chmod 400 kernel_key.pemOptional: 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:
/etc/portage/make.confEnable custom signing keysUSE="modules-sign secureboot"
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
# 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.
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
# 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"
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.
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.
安装 distribution 内核
如果用 Gentoo 补丁从源码构建一个内核 ，输入：
root #emerge --ask sys-kernel/gentoo-kernel想要避免编译本地内核源代码的系统管理员可以使用预编译的内核镜像：
root #emerge --ask sys-kernel/gentoo-kernel-binDistribution Kernels, such as sys-kernel/gentoo-kernel and sys-kernel/gentoo-kernel-bin, by default, expect to be installed alongside an initramfs. Before running emerge to install the kernel users should ensure that sys-kernel/installkernel has been configured to utilize an initramfs generator (for example Dracut) as described in the installkernel section.
更新和清理
内核安装后，包管理器将自动更新到新版本。包管理器清理旧的软件包之前，将保留以前的版本。如果要回收磁盘空间，可以定期运行 emerge 加 --depclean 选项清理过时的软件包：
root #emerge --depclean或者，专门清理旧版本的内核：
root #emerge --prune sys-kernel/gentoo-kernel sys-kernel/gentoo-kernel-binBy design, emerge only removes the kernel build directory. It does not actually remove the kernel modules, nor the installed kernel image. To completely clean-up old kernels, the app-admin/eclean-kernel tool may be used.
安装后／更新任务
An upgrade of a distribution kernel is capable of triggering an automatic rebuild for external kernel modules installed by other packages (for example: sys-fs/zfs-kmod or x11-drivers/nvidia-drivers). This automated behaviour is enabled by enabling the dist-kernel USE flag. When required, this same flag will also trigger re-generation of the initramfs.
在像 sys-fs/zfs 和 sys-fs/zfs-kmod 这样的软件包上启用 USE 标记后，将允许它们自动根据最新更新的内核重新编译，如果合适的话，还会相应地重新生成 initramfs！
/etc/portage/make.confEnabling USE=dist-kernelUSE="dist-kernel"
手动重建 initramfs
需要的话, 可以手动重建 initramfs，内核更新后，执行：
root #emerge --ask @module-rebuild如果任何内核模块（例如 ZFS）需要提前启动，需要之后通过下面命令重建 initramfs：
root #emerge --config sys-kernel/gentoo-kernel
root #emerge --config sys-kernel/gentoo-kernel-bin
After installing the Distribution Kernel successfully, it is now time to proceed to the next section: Configuring the system.
安装内核源码
当为基于 x86 的系统安装和编译内核时，Gentoo 推荐使用 sys-kernel/gentoo-sources 软件包。
选择一个合适的内核并使用 emerge 来安装它。
root #emerge --ask sys-kernel/gentoo-sources这将在 /usr/src/ 中安装路径中特定版本的 Linux 内核源码。如果没有在所选内核源码包内启用 USE=symlink，它将不会自行创建符号链接。
我们习惯性的维护 /usr/src/linux 符号链接。这样，它指向与当前运行的内核相对应的源代码。然而，默认情况下不会创建这个符号链接。有一个简单创建符号链接的方法是利用 eselect 的内核模块。
更多有关符号链接的信息以及如何管理符号链接，请参考升级内核。
首先，列出所有已安装的内核：
root #eselect kernel listAvailable kernel symlink targets: [1] linux-6.6.21-gentoo
要创建一个名为 linux 的符号链接，使用：
root #eselect kernel set 1root #ls -l /usr/src/linuxlrwxrwxrwx 1 root root 12 Oct 13 11:04 /usr/src/linux -> linux-6.6.21-gentoo
可选：手动配置
In case it was missed, this section requires the kernel sources to be installed. Be sure to obtain the relevant kernel sources, then return here for the rest of section.
Manually configuring a kernel is commonly seen as one of the most difficult procedures a system administrator has to perform. Nothing is less true - after configuring a few kernels no one remembers that it was difficult! There are two ways for a Gentoo user to manage a manual kernel system, both of which are listed below:
Modprobed-db process
A very easy way to manage the kernel is to first install sys-kernel/gentoo-kernel-bin and use the sys-kernel/modprobed-db to collect information about what the system requires. modprobed-db is a tool which monitors the system via crontab to add all modules of all devices over the system's life to make sure it everything a user needs is supported. For example, if an Xbox controller is added after installation, then modprobed-db will add the modules to be built next time the kernel is rebuilt. More on this topic can be found in the Modprobed-db article.
Manual process
This method allows a user to have full control of how their kernel is built with as minimal help from outside tools as they wish. Some could consider this as making it hard for the sake of it.
无论如何，有一件事是真实的：当手动配置内核时，了解（硬件）系统是至关重要的。大多数信息可以通过安装包含lspci命令的sys-apps/pciutils来收集：
root #emerge --ask sys-apps/pciutils在chroot中，可以安全的忽略任何lspci可能抛出的关于pcilib的警告（比如pcilib: cannot open /sys/bus/pci/devices）。
另一个系统信息来源是运行lsmod来查看安装CD使用什么内核模块，它可能对启用什么提供了一个好的暗示。
现在进入内核源码目录并执行make menuconfig。这将启动一个菜单驱动的配置屏幕。
root #cd /usr/src/linux
root #make menuconfig
The kernel has a method of autodetecting the modules currently being used on the installcd which will give a great starting point to allow a user to configure their own. This can be called by using:
root #make localmodconfigIt's now time to configure using nconfig:
root #make nconfigLinux 内核配置有很多很多的章节。我们先列出一些必须激活的选项（否则 Gentoo 将无法工作，或者离开附加的调整将无法正常工作）。我们同时在 Gentoo 维基上有一个 Gentoo 内核配置指南可能会在将来有帮助。
Enabling required options
当使用 sys-kernel/gentoo-sources 时，强烈推荐启用 Gentoo 特有的配置选项。这些确保了系统可以正常运行所需的最少内核特性：
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
当然，最后两行的选择取决于所选择的 init 系统 (OpenRC 对比 systemd)。但是两种 init 系统都启用也并没有害处。
当使用 sys-kernel/vanilla-sources时，不能使用额外的 init 系统。可以使用已启用的 init 系统，但这超出了手册的范围。
Enabling support for typical system components
确保引导系统的每一个至关重要的驱动（比如 SATA 控制器，NVMe 块设备支持，文件系统支持，等等）是编译进内核而不是作为一个模块，否则系统将无法完全引导。
接下来选择最正确的CPU类型。同时建议启用MCE功能（如果可用）能在硬件出现问题时通知用户。在一些架构（比如x86_64），这些错误不会打印到 dmesg，但是会到/dev/mcelog。这需要app-admin/mcelog包。
同时选择Maintain a devtmpfs file system to mount at /dev来让重要的设备文件在引导过程的早期就已就绪(CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT):
Device Drivers --->
Generic Driver Options --->
[*] Maintain a devtmpfs filesystem to mount at /dev
[*] Automount devtmpfs at /dev, after the kernel mounted the rootfs
验证 SCSI 磁盘支持是否已激活(CONFIG_BLK_DEV_SD):
Device Drivers --->
SCSI device support --->
<*> SCSI device support
<*> SCSI disk support
Device Drivers --->
<*> Serial ATA and Parallel ATA drivers (libata) --->
[*] ATA ACPI Support
[*] SATA Port Multiplier support
<*> AHCI SATA support (ahci)
[*] ATA BMDMA support
[*] ATA SFF support (for legacy IDE and PATA)
<*> Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support (ata_piix)
验证已经启用基础 NVMe 支持：
Device Drivers --->
<*> NVM Express block device
Device Drivers --->
NVME Support --->
<*> NVM Express block device
也可以启用下列额外的 NVMe 支持：
[*] NVMe multipath support
[*] NVMe hardware monitoring
<M> NVM Express over Fabrics FC host driver
<M> NVM Express over Fabrics TCP host driver
<M> NVMe Target support
[*] NVMe Target Passthrough support
<M> NVMe loopback device support
<M> NVMe over Fabrics FC target driver
< > NVMe over Fabrics FC Transport Loopback Test driver (NEW)
<M> NVMe over Fabrics TCP target support
现在进入File Systems并选择系统将使用的文件系统。不要作为模块来编译根文件系统所使用的文件系统，否则系统可能不挂载这个分区。同时选择Virtual memory和/proc file system根据系统的需要选择一个或多个以下选项：
File systems --->
<*> Second extended fs support
<*> The Extended 3 (ext3) filesystem
<*> The Extended 4 (ext4) filesystem
<*> Btrfs filesystem support
<*> XFS 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)
如果使用PPPoE连接到互联网，或者是拨号调制解调器，则启用下面的选项(CONFIG_PPP, CONFIG_PPP_ASYNC, and CONFIG_PPP_SYNC_TTY)：
Device Drivers --->
Network device support --->
<*> PPP (point-to-point protocol) support
<*> PPP support for async serial ports
<*> PPP support for sync tty ports
这两个压缩选项将是无害的，但是它们一定是不需要的，包括基于以太网的PPP选项也是一样，只有在配置内核模式PPPoE时才会需要。
不要忘记在内核中包括网（以太网或无线）卡。
大多数系统会有多核心处理，所以激活 Symmetric multi-processing support（对称多处理） 很重要 (CONFIG_SMP)：
Processor type and features --->
[*] Symmetric multi-processing support
在多核系统中，每个核心视为一个处理器。
如果使用USB输入设备（比如键盘和鼠标）或其他USB设备，不要忘记启用那些：
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
Optional: Signed kernel modules
To automatically sign the kernel modules enable CONFIG_MODULE_SIG_ALL:
[*] Enable loadable module support
-*- Module signature verification
[*] Automatically sign all modules
Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->
Optionally change the hash algorithm if desired.
To enforce that all modules are signed with a valid signature, enable CONFIG_MODULE_SIG_FORCE as well:
[*] Enable loadable module support
-*- Module signature verification
[*] Require modules to be validly signed
[*] Automatically sign all modules
Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->
To use a custom key, specify the location of this key in CONFIG_MODULE_SIG_KEY. If unspecified, the kernel build system will generate a key. It is recommended to generate one manually instead. This can be done with:
root #openssl req -new -nodes -utf8 -sha256 -x509 -outform PEM -out kernel_key.pem -keyout kernel_key.pemOpenSSL 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
-*- Cryptographic API --->
Certificates for signature checking --->
(/path/to/kernel_key.pem) File name or PKCS#11 URI of module signing key
To also sign external kernel modules installed by other packages via linux-mod-r1.eclass, enable the modules-sign USE flag globally:
/etc/portage/make.confEnable module signingUSE="modules-sign"
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
# Optionally, when using 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
MODULES_SIGN_KEY and MODULES_SIGN_CERT may point to 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.
Optional: Signing the kernel image (Secure Boot)
When signing the kernel image (for use on systems with Secure Boot enabled) it is recommended to set the following kernel config options:
General setup --->
Kexec and crash features --->
[*] Enable kexec system call
[*] Enable kexec file based system call
[*] Verify kernel signature during kexec_file_load() syscall
[*] Require a valid signature in kexec_file_load() syscall
[*] Enable ""image"" signature verification support
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
[*] Enable loadable module support
-*- Module signature verification
[*] Require modules to be validly signed
[*] Automatically sign all modules
Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
Security options --->
[*] Integrity subsystem
[*] Basic module for enforcing kernel lockdown
[*] Enable lockdown LSM early in init
Kernel default lockdown mode (Integrity) --->
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
[*] Digital signature verification using multiple keyrings
[*] Enable asymmetric keys support
-*- Require all keys on the integrity keyrings be signed
[*] Provide keyring for platform/firmware trusted keys
[*] Provide a keyring to which Machine Owner Keys may be added
[ ] Enforce Machine Keyring CA Restrictions
Where ""image"" is a placeholder for the architecture specific image name. These options, from the top to the bottom: enforces that the kernel image in a kexec call must be signed (kexec allows replacing the kernel in-place), enforces that kernel modules are signed, enables lockdown integrity mode (prevents modifying the kernel at runtime), and enables various keychains.
On arches that do not natively support decompressing the kernel (e.g. arm64 and riscv), the kernel must be built with its own decompressor (zboot):
Device Drivers --->
Firmware Drivers --->
EFI (Extensible Firmware Interface) Support --->
[*] Enable the generic EFI decompressor
After compilation of the kernel, as explained in the next section, the kernel image must be signed. First install app-crypt/sbsigntools and then sign the kernel image:
root #emerge --ask app-crypt/sbsigntoolsroot #sbsign /usr/src/linux-x.y.z/path/to/kernel-image --cert /path/to/kernel_key.pem --key /path/to/kernel_key.pem --out /usr/src/linux-x.y.z/path/to/kernel-imageFor 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.
Then proceed with the installation.
To automatically sign EFI executables installed by other packages, enable the secureboot USE flag globally:
/etc/portage/make.confEnable Secure BootUSE="modules-sign secureboot"
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
# 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
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
# 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"
SECUREBOOT_SIGN_KEY and SECUREBOOT_SIGN_CERT may point to 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.
When generating an Unified Kernel Image with systemd's
ukify the kernel image will be signed automatically before inclusion in the unified kernel image and it is not necessary to sign it manually.
For x86 architectures, verify the 64-bit kernel option is unset/deactivated (CONFIG_64BIT=N), and then select the processor family as appropriate for the system's processor(s).
The processor family can be determined by reviewing output from the following two commands:
user $cat /proc/cpuinfo | grep -i vendor | uniquser $cat /proc/cpuinfo | grep -i 'model name' | uniq[ ] 64-bit kernel
Processor type and features --->
Processor family (Core 2/newer Xeon) --->
( ) 486
( ) 586/K5/5x86/6x86/6x86MX
( ) Pentium-Classic
( ) Pentium-MMX
( ) Pentium-Pro
( ) Pentium-II/Celeron(pre-Coppermine)
( ) Pentium-III/Celeron(Coppermine)/Pentium-III Xeon
( ) Pentium M
( ) Pentium-4/Celeron(P4-based)/Pentium-4 M/Xeon
( ) K6/K6-II/K6-III
( ) Athlon/Duron/K7
( ) Opteron/Athlon64/Hammer/K8
( ) Crusoe
( ) Efficeon
( ) Winchip-C6
( ) Winchip-2/Winchip-2A/Winchip-3
( ) AMD Elan
( ) GeodeGX1
( ) Geode GX/LX
( ) CyrixIII/VIA-C3
( ) VIA C3-2 (Nehemiah)
( ) VIA C7
(*) Core 2/newer Xeon
( ) Intel Atom
Compiling and installing
With the configuration now done, it is time to compile and install the kernel. Exit the configuration and start the compilation process:
root #make && make modules_installIt is possible to enable parallel builds using make -j N with N being an integer number of parallel tasks that the build process is allowed to launch. This is similar to the instructions about /etc/portage/make.conf earlier, with the MAKEOPTS variable.
When the kernel has finished compiling, copy the kernel image to /boot/. This is handled by the make install command:
root #make installThis will copy the kernel image into /boot/ together with the System.map file and the kernel configuration file.
Deprecated: Genkernel
Genkernel should only be considered by users with a required need that only Genkernel can meet. For others, it is recommended to use the Distribution kernel or manually compile their own as it will make maintaining a Gentoo system a lot more simple. An example of why genkernel is more difficult to manage is the lack of integration with sys-kernel/installkernel. This means a user will not get the same level of automation as provided by the other methods; for example, Unified Kernel Images will need to be created manually when using Genkernel.
Users still wishing to use Genkernel should see the Genkernel article for more information.
内核模块
列出可用的内核模块
硬件模块手动列出是可选的。在大多数情况下，udev 通常将加载所有被检测为已连接的硬件模块。然而，列出自动检测到的模块并没有什么不良影响的。有时，一些奇特硬件需要帮助来加载其驱动程序。
可以在 /etc/modules-load.d/*.conf 文件中添加需要在每次启动时加载的模块，格式为每行一个模块。如果模块需要附加选项，可以在 /etc/modprobe.d/*.conf 文件内设置。
对于特定的内核版本，如果要查看所有可用模块，使用下面的 find 命令。不要忘记在查找时替换 “<kernel version>” 为对应的内核版本：
root #find /lib/modules/<kernel version>/ -type f -iname '*.o' -or -iname '*.ko' | less强制加载特定内核模块
要强制加载内核 3c59x.ko 模块（3Com 网卡家族的特定驱动），编辑/etc/modules-load.d/network.conf 文件并在里面输入模块名字。
root #mkdir -p /etc/modules-load.d
root #nano -w /etc/modules-load.d/network.conf
注意，模块的 .ko 文件后缀对加载机制影响不大，所以配置文件中没有文件后缀：
/etc/modules-load.d/network.conf强制加载 3c59x 模块3c59x
继续到配置系统来安装。