Manual:IA64/Instalação/Kernel
Opcional: Instalando firmware
Firmware
Linux Firmware
Alguns drivers requerem que firmware adicionais sejam instalados no sistema antes para funcionarem. Isso ocorre normalmente com interfaces de rede, especialmente as interfaces de rede sem fio. Também placas de vídeo modernas de fabricantes como AMD, NVidia e Intel, quando usando drivers open source, frequentemente precisam de arquivos de firmware externos. A maioria dos firmwares estão empacotados em sys-kernel/linux-firmware:
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
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
É chegada a hora de configurar e compilar os fontes do kernel. Há duas formas de se fazer isso:
Ranked from least involved to most involved:
- O kernel é manualmente configurado e compilado, ou
- é usada uma ferramenta chamada
genkernel
para automaticamente compilar e instalar o kernel Linux
O núcleo em torno do qual todas as distribuições são criadas é o kernel Linux. Ele é a camada entre os programas de usuários e o hardware do sistema. O Gentoo provê aos seus usuários diversos possíveis fontes do kernel. Uma listagem completa está disponível na Página de visão geral do kernel.
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.
Instalando os fontes
This section is only relevant when using the following genkernel (hybrid) or manual kernel management approach.
The use of sys-kernel/installkernel is not strictly required, but highly recommended. When this package is installed, the kernel installation process will be delegated to installkernel. This allows for installing several different kernel versions side-by-side as well as managing and automating several tasks relating to kernel installation described later in the handbook. Install it now with:
root #
emerge --ask sys-kernel/installkernel
When installing and compiling the kernel for ia64-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
Isso irá instalar os fontes do kernel Linux em /usr/src/ no qual um link simbólico chamado linux estará apontando para o fonte do kernel instalado:
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.6.21-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.6.21-gentoo
Padrão: Configuração manual
Introdução
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.
Configurar manualmente um kernel é geralmente visto como o procedimento mais difícil que um usuário Linux pode fazer. Nada mais falso -- depois de configurar algumas vezes o kernel ninguém irá se lembrar que era difícil.
Porém, uma coisa é verdade: é vital conhecer o sistema quando um kernel é configurado manualmente. A maioria das informações pode ser coletada fazendo emerge no sys-apps/pciutils que contém o comando lspci:
root #
emerge --ask sys-apps/pciutils
Dentro do chroot, é seguro ignorar qualquer aviso da pcilib (como pcilib: cannot open /sys/bus/pci/devices) que o lspci possa emitir.
Uma outra fonte de informação do sistema é executar o lsmod para ver quais módulos do kernel o CD de instalação usa pois isso pode dar dicas sobre o que habilitar.
Agora vá para o diretório dos fontes do kernel e execute make menuconfig. Isso irá mostrar uma tela de configuração baseada em menus.
root #
cd /usr/src/linux
root #
make menuconfig
A configuração do kernel do Linux tem muitas, muitas seções. Vamos primeiro mostrar algumas opções que devem ser ativadas (ou senão o Gentoo não irá funcionar, ou não funcionar adequadamente sem alguns ajustes). Existe também o Guia de configuração do kernel do Gentoo no wiki do Gentoo que poderá também ajudar.
Ativando as opções necessárias
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:
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.
Enabling support for typical system components
Certifique-se de que todos os drivers que forem vitais para a inicialização do sistema (tais como controladores SCSI etc) são compilados no kernel e não como módulos, ou senão o sistema não será capaz de inicializar completamente.
Em seguida selecione o tipo exato do processador. É também recomendado habilitar os recursos MCE (se disponíveis) de modo que os usuários possam ser notificados sobre quaisquer problemas de hardware. Em algumas arquiteturas (tais como a x86_64), esses erros não são impressos pelo dmesg, mas em /dev/mcelog. Isso requer o pacote app-admin/mcelog.
Selecione também Maintain a devtmpfs file system to mount at /dev assim os arquivos de dispositivos críticos estarão disponíveis logo durante o processo de inicialização (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
Verifique se o suporte a discos SCSI foi ativado (CONFIG_BLK_DEV_SD):
Device Drivers --->
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)
Verify basic NVMe support has been enabled:
Device Drivers --->
<*> NVM Express block device
Device Drivers --->
NVME Support --->
<*> NVM Express block device
It does not hurt to enable the following additional NVMe support:
[*] 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
Vá agora para File Systems (Sistemas de Arquivos) e selecione suporte para os sistemas de arquivos que você usa. Não compile o sistema de arquivo que é usado como sistema de arquivo raiz como módulo, ou senão o sistema Gentoo não será capaz de montar a partição. Selecione também "Virtual memory" (Memória virtual) e "/proc file system" (sistema de arquivo /proc). Selecione uma ou mais das seguintes opções segundo as necessidades do sistema: (CONFIG_EXT2_FS, CONFIG_EXT3_FS, CONFIG_EXT4_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
<*> 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)
Se for usado PPPoE para conectar à Internet, ou um modem com discagem foi usado, então habilite as seguintes opções (CONFIG_PPP, CONFIG_PPP_ASYNC, e 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
As duas opções de compactação não vão atrapalhar mas definitivamente não são necessárias, assim como a opção de PPP sobre Ethernet (PPP over Ethernet), que pode apenas ser usada pelo ppp quando configurado para usar PPPoE em modo kernel.
Não se esqueça de incluir suporte no kernel para as placas de rede (ethernet ou sem fio).
A maioria dos sistemas tem múltiplos núcleos à disposição, então é importante ativar a opção "Symmetric multi-processing support" (suporte a multi-processamento simétrico) (CONFIG_SMP):
Processor type and features --->
[*] Symmetric multi-processing support
Em sistemas com vários núcleos, cada núcleo conta como um processador.
Se forem usados dispositivos de entrada USB (como teclado ou mouse) ou outros dispositivos USB, não se esqueça de habilitá-los também (CONFIG_HID_GENERIC and CONFIG_USB_HID, CONFIG_USB_SUPPORT, CONFIG_USB_XHCI_HCD, CONFIG_USB_EHCI_HCD, CONFIG_USB_OHCI_HCD):
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
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.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
-*- 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:
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:
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/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:
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.
Configuração do kernel específica da arquitetura
Selecione os tipos corretos de sistema e processador. "DIG-compliant" (compatível com DIG) é uma boa opção default. Se estiver instalando em um sistema SGI certifique-se de selecionar o tipo de sistema SGI, senão o kernel pode travar e se recusar a dar boot.
System type --->
(Change according to the system)
DIG-compliant
Processor type --->
(Change according to the system)
Itanium 2
Compilando e instalando
Com a configuração terminada, é hora de compilar e instalar o kernel. Saia da configuração e inicie o processo de compilação:
root #
make && make modules_install
É possível habilitar a compilação em paralelo usando
make -jX
onde X é o número de tarefas paralelas que o processo de compilação é permitido disparar. Isso é similar às instruções anteriores sobre o /etc/portage/make.conf, sobre a variável MAKEOPTS
.Quando terminar a compilação do kernel, copie sua imagem para o diretório /. Use qualquer nome que achar apropriado para sua escolha do kernel e lembre-se dele uma vez que será referenciado mais tarde durante a configuração do gerenciador de boot. Lembre-se de trocar "vmlinuz" pelo nome e versão do kernel instalado.
root #
cp vmlinux.gz /boot/vmlinuz
Alternativa: Usando o 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 should only be considered by users that have a required need that only Genkernel can meet, otherwise it is recommended to use the Distribution kernel or manually compile your 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, such as Unified Kernel Images will need to be created manually when using Genkernel.
Genkernel provides a generic kernel configuration file and will compile the kernel and initramfs, then install 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 predetermined 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.
Binary redistributable software license group
If the linux-firmware package has been previously installed, then skip onward to the to the installation section.
As a prerequisite, due to the firwmare
USE flag being enabled by default for the sys-kernel/genkernel package, the package manager will also attempt to pull in the sys-kernel/linux-firmware package. The binary redistributable software licenses are required to be accepted before the linux-firmware will install.
This license group can be accepted system-wide for any package by adding the @BINARY-REDISTRIBUTABLE
as an ACCEPT_LICENSE value in the /etc/portage/make.conf file. It can be exclusively accepted for the linux-firmware package by adding a specific inclusion via a /etc/portage/package.license/linux-firmware file.
If necessary, review the methods of accepting software licenses available in the Installing the base system chapter of the handbook, then make some changes for acceptable software licenses.
If in analysis paralysis, the following will do the trick:
root #
mkdir /etc/portage/package.license
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
Installation
Agora vamos ver como usar o genkernel. Primeiro faça emerge do pacote sys-kernel/genkernel:
root #
emerge --ask sys-kernel/genkernel
Generation
Agora, compile os fontes do kernel executando genkernel all. Note que, como genkernel all compila um kernel com suporte para quase todo tipo de hardware, a compilação pode demorar para terminar!
Se a partição de boot não usa ext2 ou ext3 como sistema de arquivos, pode ser necessário configurar manualmente o kernel usando genkernel --menuconfig all e adicionar suporte para esse sistema de arquivo em particular no kernel (não como módulo). Usuários de LVM2 provavelmente irão querer adicionar
--lvm
como argumento também.Users of LVM2 should add
--lvm
as an argument to the genkernel command below.root #
genkernel all
Quando o genkernel terminar, estarão criados um kernel, um conjunto completo de módulos e um ramdisk inicial (initrd). Usaremos o kernel e o initrd quando configurarmos o gerenciador de boot mais tarde neste documento. Anote os nomes do kernel e do initrd pois essas informações são utilizadas quando o arquivo de configuração do gerenciador de boot for editado. O initrd será executado imediatamente após o boot para fazer a autodetecção de hardware (como no CD de instalação) antes do sistema "real" inicializar.
root #
ls /boot/kernel* /boot/initramfs*
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:
sys-apps/systemd-utils boot kernel-install
sys-kernel/installkernel systemd systemd-boot
root #
emerge --ask sys-apps/systemd-utils
On systemd systems:
sys-apps/systemd boot
sys-kernel/installkernel systemd-boot
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.
sys-kernel/installkernel grub
root #
emerge --ask sys-kernel/installkernel
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:
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=6.6.21-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:
sys-apps/systemd boot
For OpenRC systems:
sys-apps/systemd-utils boot kernel-install
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:
sys-kernel/installkernel dracut uki
uefi="yes"
kernel_cmdline="some-kernel-command-line-arguments"
For ukify:
sys-apps/systemd ukify # For systemd systems
sys-apps/systemd-utils ukify # For OpenRC systems
sys-kernel/installkernel dracut ukify uki
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:
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:
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:
[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.
*/* dist-kernel
External kernel modules may also be rebuilt manually with:
root #
emerge --ask @module-rebuild
Módulos do kernel
Configurando os módulos
É opcional listar manualmente os módulos de hardware. udev irá normalmente carregar todos os módulos de hardware que forem detectados ou conectados na maioria dos casos. Entretanto, não causa problema que módulos carregados automaticamente sejam listados. As vezes, algum hardware mais exótico requer alguma ajuda para carregar seus drivers.
Liste os módulos que precisem ser carregados no arquivo /etc/modules-load.d/*.conf, um módulo por linha. Opções extra para os módulos, se necessárias, devem ser configuradas nos arquivos /etc/modprobe.d/*.conf.
Para visualizar todos os módulos disponíveis, execute o seguinte comando find. Não se esqueça de substituir "<kernel version>" pela versão do kernel recém compilada:
root #
find /lib/modules/<kernel version>/ -type f -iname '*.o' -or -iname '*.ko' | less
Force loading particular kernel modules
Por exemplo, para carregar automaticamente o módulo 3c59x.ko (que é o driver para uma placa de rede específica da família 3Com), edite o arquivo /etc/modules-load.d/network.conf e entre com o nome do módulo nele. O nome real do arquivo não é significativo para o carregador.
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:
3c59x
Continue a instalação em Configurando o sistema.