手册:PPC/安装/配置Linux内核

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Handbook:PPC/Installation/Kernel and the translation is 100% complete.
PPC 手册
安装
关于安装
选择安装媒介
配置网络
准备磁盘
安装 stage3
安装基础系统
配置内核
配置系统
安装系统工具
配置引导程序
安装收尾
使用 Gentoo
Portage 介绍
USE 标记
Portage 功能特性
Initscript 系统
环境变量
使用 Portage
文件和目录
变量
混合使用不同的软件分支
额外的工具
自定义软件包仓库
高级特性
配置网络
开始
高级配置
模块化网络
无线网络
添加功能
动态管理


可选:安装固件和微代码

固件

Linux Firmware

在开始配置内核部分之前,最好了解下,一些硬件设备需要先在系统上安装附加的固件,有时是非自由及开放源代码软件(FOSS)才能正常运行。我们经常网络接口上会使用附加的固件,特别是无线网络接口,常用于台式电脑和笔记本电脑。此外,来自 AMD,Nvidia 和 Intel 等供应商的现代视频芯片,要想使用完整的功能,通常也需要外部固件文件。现代硬件设备的大多数固件都可以在 sys-kernel/linux-firmware 软件包中找到。

为了在必要时提供固件,首次重启系统之前推荐安装 sys-kernel/linux-firmware 软件包:

root #emerge --ask sys-kernel/linux-firmware
附注
安装某些固件软件包时,经常需要接受固件关联的许可证。有需要的话,访问手册的许可证处理章节有助于你接受许可证。

注意,当内核以模块(M)加载内核符号时,将从文件系统中加载其相关的固件文件。对于以模块加载的符号,没有必要把设备固件文件加入内核二进制镜像中。

SOF Firmware

重要
Use of this firmware requires enabling certain Kernel options and is only supported on AMD64 currently. Enabling these options are only necessary if a manual configuration is planned, as the Distribution Kernels have them enabled already. The necessary options are covered in architecture specific kernel configuration.

Sound Open Firmware (SOF) is a new open source audio driver meant to replace the proprietary Smart Sound Technology (SST) audio driver from Intel. 10th gen+ and Apollo Lake (Atom E3900, Celeron N3350, and Pentium N4200) Intel CPUs require this firmware for certain features and certain AMD APUs also have support for this firmware. SOF's supported platforms matrix can be found here for more information.

root #emerge --ask sys-firmware/sof-firmware

微码

除了独立显卡硬件和网络接口之外,CPU 可能也需要固件更新。通常这种固件被称为微码(microcode)。有时需要更新版本的微码来修补 CPU 硬件中的不稳定性、安全问题或其他复杂的错误。

AMD CPU 的微码更新在前面提到的 sys-kernel/linux-firmware 软件包内分发。Intel CPU 的微码可以在 sys-firmware/intel-microcode 包中找到,并且需要单独安装。更多有关如何更新微码的细节,请查看微码文章

内核配置和编译

现在是时候来配置和编译内核源代码了。将介绍三种用内核管理安装的方法,但是安装后,任何时候都可以采用新的方法。

由操作最少到操作最多排序:

全自动方法:Distribution 内核
Distribution 内核用来配置、自动构建安装 Linux 内核、相关模块和 initramfs 文件(可选,但是默认启用)。将来内核就像其他的系统软件包一样,通过使用包管理器全自动升级。如果需要定制内核,它可以提供自定义内核配置文件。这种过程操作最少,并且非常适合新 Gentoo 用户,因为它开箱即用,并且系统管理员最少参与。
混合方法:Genkernel
通过系统包管理器安装新内核源代码。系统管理员可以使用 Gentoo 的 genkernel 工具的配置,构建和安装 Linux 内核、相关模块和 initramfs 文件(可选,但默认 启用)。如果要自定义内核,它可以提供自定义内核配置文件。将来每次更新内核配置、编译和安装都需要系统管理员运行 eselect kernelgenkernel和其他可能的命令。
全手动方法
通过系统包管理器安装新的内核源代码。使用 eselect kernel 和一大堆 make 命令手动配置、构建和安装内核。将来内核升级需要重复手动配置、构建和安装内核文件的过程。这是操作做多的过程,但是在内核更新过程提供最大程度控制。

Linux内核是所有发行版的核心。它位于用户程序和系统硬件之间。尽管手册提供给用户一些可选的内核源码,但是在内核概述页面有更全面的列表,上面有着更多的细节描述。

安装内核源码

附注
本小节只有关于使用 genkernel(混合)或手动内核管理方法

当为基于 ppc 的系统安装和编译内核时,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 list
Available kernel symlink targets:
  [1]   linux-3.16.5-gentoo

要创建一个名为 linux 的符号链接,使用:

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

备选:genkernel

附注
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.

如果全手动配置看起来太恐怖,系统管理员应该考虑使用 genkernel 混合方法来维护内核。

Genkernel 提供了通用的内核配置文件,并且会编译内核和 initramfs,然后将生成的二进制文件安装到适当的位置。它提供了系统首次启动时最小的常规硬件支持,并允许将来自定义内核配置以及对内核额外升级。

请注意:虽然使用 genkernel 维护内核可以让系统管理员对系统内核,initramfs 和其他选项更新时有更多的操作,但当新的源代码发行时,却投入更多的时间和精力去更新内核。所以那些希望不手动内核维护的人应该使用 distribution 内核

更进一步说,认为 genkernel 可以为正在运行的硬件自动生成自定义的内核配置 是一种误解;genkernel 使用了支持大多数通用硬件的预定的内核配置文件,并且可以自动处理 make 命令来汇编和安装内核、相关模块以及 initramfs 文件。

二进制可再分发软件许可证组

如果已经预先安装了 linux-firmware 软件包,那么跳转到安装章节

由于 sys-kernel/genkernel 软件包默认启用 firwmare USE 标志,所以包管理器还会尝试拉取 sys-kernel/linux-firmware 软件包。安装 linux-firmware 之前,需要接受二进制可再分发软件许可证。

通过在 /etc/portage/make.conf 文件为 ACCEPT_LICENSE 变量添加 @BINARY-REDISTRIBUTABLE 值,可以接受系统范围任何软件包的许可证组。通过在 /etc/portage/package.license/linux-firmware 文件添加特定内容,可以单独接受 linux-firmware 软件包的许可证组。

如果有必要,查看手册安装基本系统里的接受软件许可证的方法章节,然后修改一些可接受的软件许可证。

如果分析不出来,可以这样做:

root #mkdir /etc/portage/package.license
文件 /etc/portage/package.license/linux-firmware为 linux-firmware 软件包接受二进制可再分发许可证(binary redistributable)
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE

安装

说明完以及准备好之后,安装 sys-kernel/genkernel 软件包:

root #emerge --ask sys-kernel/genkernel

常规

运行genkernel all来编译内核源码。值得注意的是,使用 genkernel 编译的内核适用于不同计算机体系结构的各种硬件,这可能使编译过程需要一阵子来完成。

附注
如果 root 分区/卷 不是使用 ext4 作为文件系统,它可能需要使用 genkernel --menuconfig all 来手动配置内核,并在内核中添加对这个具体文件系统的支持(比如:不是作为一个模块)。LVM2用户可能要作为参数来添加--lvm
附注
LVM2 用户应该在下面 genkernel命令添加 --lvm 参数 。
root #genkernel --mountboot --install all

genkernel 完成后,将在 /boot 目录生成并安装内核和初始化内存文件(initial ram filesystem,initramfs)。/lib/modules 目录将安装相关模块。initramfs 将在内核加载后立即启动,然后进行硬件自动检测(就像在 live 磁盘镜像环境中一样)。

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

可选:手动配置

介绍

附注
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.

手动配置内核经常被 Linux 用户认为是最困难的步骤。但是事实并非如此──当您手动配置几次内核之后,你就不会再觉得它有多么难了!

无论如何,有一件事是真实的:当手动配置内核时,了解(硬件)系统是至关重要的。大多数信息可以通过安装包含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

Linux 内核配置有很多很多的章节。我们先列出一些必须激活的选项(否则 Gentoo 将无法工作,或者离开附加的调整将无法正常工作)。我们同时在 Gentoo 维基上有一个 Gentoo 内核配置指南可能会在将来有帮助。

启用必要的选项

当使用 sys-kernel/gentoo-sources 时,强烈推荐启用 Gentoo 特有的配置选项。这些确保了系统可以正常运行所需的最少内核特性:

内核 启用 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 系统,但这超出了手册的范围。

启用典型的系统组件支持

确保引导系统的每一个至关重要的驱动(比如 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):

内核 启用 devtmpfs 支持(CONFIG_DEVTMPFS
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):

内核 启用 SCSI 磁盘支持(CONFIG_SCSI, CONFIG_BLK_DEV_SD
Device Drivers --->
  SCSI device support  ---> 
    <*> SCSI device support
    <*> SCSI disk support
内核 启用基础 SATA 和 PATA 支持(CONFIG_ATA_ACPI, CONFIG_SATA_PMP, CONFIG_SATA_AHCI, CONFIG_ATA_BMDMA, CONFIG_ATA_SFF, CONFIG_ATA_PIIX
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 支持:

内核 启用 Linux 4.4.x 基础 NVMe 支持(CONFIG_BLK_DEV_NVME
Device Drivers  --->
  <*> NVM Express block device
内核 启用 Linux 5.x.x 基础 NVMe 支持(CONFIG_DEVTMPFS
Device Drivers --->
  NVME Support --->
    <*> NVM Express block device

也可以启用下列额外的 NVMe 支持:

内核 启用额外的 NVMe 支持(CONFIG_NVME_MULTIPATHCONFIG_NVME_MULTIPATHCONFIG_NVME_HWMONCONFIG_NVME_FCCONFIG_NVME_TCPCONFIG_NVME_TARGETCONFIG_NVME_TARGET_PASSTHRUCONFIG_NVME_TARGET_LOOPCONFIG_NVME_TARGET_FCCONFIG_NVME_TARGET_FCLOOPCONFIG_NVME_TARGET_TCP
[*] 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根据系统的需要选择一个或多个以下选项:

内核 启用文件系统支持 (CONFIG_EXT2_FS, CONFIG_EXT3_FS, CONFIG_EXT4_FS, CONFIG_BTRFS_FS, CONFIG_XFS_FS, CONFIG_MSDOS_FS, CONFIG_VFAT_FS, CONFIG_PROC_FS, and CONFIG_TMPFS)
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):

内核 启用 PPPoE 所需要的驱动(PPPoECONFIG_PPPOECONFIG_PPP_ASYNCCONFIG_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):

内核 激活 SMP 支持(CONFIG_SMP
Processor type and features  --->
  [*] Symmetric multi-processing support
附注
在多核系统中,每个核心视为一个处理器。

如果使用USB输入设备(比如键盘和鼠标)或其他USB设备,不要忘记启用那些:

内核 启用 USB 和人类输入设备支持(CONFIG_HID_GENERICCONFIG_USB_HIDCONFIG_USB_SUPPORTCONFIG_USB_XHCI_HCD,var>CONFIG_USB_EHCI_HCD,CONFIG_USB_OHCI_HCD(CONFIG_HID_GENERICCONFIG_USB_HIDCONFIG_USB_SUPPORTCONFIG_USB_XHCI_HCDCONFIG_USB_EHCI_HCDCONFIG_USB_OHCI_HCDCONFIG_USB4
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:

内核 Sign kernel modules 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:

内核 Enforce signed kernel modules CONFIG_MODULE_SIG_FORCE
[*] 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.pem

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
内核 Specify signing key CONFIG_MODULE_SIG_KEY
-*- 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 signing
USE="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
附注
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.

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:

内核 Lockdown for secureboot
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):

内核 zboot CONFIG_EFI_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/sbsigntools
root #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-image
附注
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 sperate 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 Boot
USE="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.
附注
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.

Handbook:PPC/Blocks/Kernel/zh-cn

Kernel installation

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.

If unsure, follow the 'Traditional layout' subsection below.

systemd-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-boot
sys-apps/systemd-utils boot kernel-install
sys-kernel/installkernel systemd systemd-boot
root #emerge --ask sys-apps/systemd-utils

On systemd systems:

文件 /etc/portage/package.use/systemd
sys-apps/systemd boot
sys-kernel/installkernel systemd-boot
# Needed for <systemd-254
sys-apps/systemd gnuefi
root #emerge --ask sys-apps/systemd

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/installkernel
sys-kernel/installkernel grub
root #emerge --ask sys-kernel/installkernel

When systemd's kernel-install is used, it should be configured to use the grub layout, this is the default if the grub USE flag is enabled:

文件 /etc/kernel/install.conf
layout=grub

Traditional layout, other bootloaders (e.g. lilo, etc.)

The traditional /boot layout (for e.g. LILO, etc.) is used by default if the grub, systemd-boot and uki USE flags are not enabled. No further action is required.


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. The default configuration of the Project:Distribution Kernel requires an 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.

重要
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.

Installkernel can automatically generate an initramfs when installing the kernel if the dracut USE flag is enabled:

文件 /etc/portage/package.use/installkernel
sys-kernel/installkernel dracut

Alternatively, dracut may be called manually to generate an initramfs. Install sys-kernel/dracut first, then have it generate an initramfs:

root #emerge --ask sys-kernel/dracut
root #dracut --kver=3.16.5-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*

Optional: Building an Unified Kernel Image

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

An 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/systemd
sys-apps/systemd boot

For OpenRC systems:

文件 /etc/portage/package.use/systemd-utils
sys-apps/systemd-utils boot

Installkernel can automatically generate an unified kernel image using either dracut or ukify, by enabling the respective flag. The uki USE flag should be enabled as well to install the generated unified kernel image to the $ESP/EFI/Linux directory on the EFI system partition (ESP).

For dracut:

文件 /etc/portage/package.use/installkernel
sys-kernel/installkernel dracut uki
文件 /etc/dracut.conf
uefi="yes"
kernel_cmdline="some-kernel-command-line-arguments"

For ukify:

文件 /etc/portage/package.use/installkernel
sys-kernel/installkernel dracut ukify uki
文件 /etc/kernel/cmdline
some-kernel-command-line-arguments

Note that while dracut can generate both an initramfs and an unified kernel image, ukify can only generate the latter and therefore the initramfs must be generated separately with dracut.

Generic Unified Kernel Image

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/generic-uki
sys-kernel/gentoo-kernel-bin generic-uki
sys-kernel/installkernel -dracut -ukify uki

Secure Boot

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
uefi="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

Rebuilding external kernel modules

External kernel modules installed by other packages via linux-mod-r1.eclass must be rebuilt for each new kernel version. When the distribution kernels are used this may be automated by enabling the dist-kernel flag globally.

文件 /etc/portage/package.use/module-rebuild
*/* dist-kernel

External kernel modules may also be rebuilt manually with:

root #emerge --ask @module-rebuild

内核模块

列出可用的内核模块

附注
硬件模块手动列出是可选的。在大多数情况下,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

继续到配置系统来安装。