Manual:Partes/Instalación/Núcleo/Dist-Kernel

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Handbook:Parts/Installation/Kernel/Dist-Kernel and the translation is 100% complete.
Other languages:

Núcleos de la distrubución

Núcleos de la Distribución son ebuilds que cubren el proceso completo de descomprimir, configurar, compilar e instalar el kernel. La principal ventaja de este método es que el administrador de paquetes actualiza los kernels a nuevas versiones como parte de la actualización de @world. Esto no requiere más participación que ejecutar un comando emerge. Los núcleos de la distribución tienen de forma predeterminada una configuración que admite la mayoría del hardware; sin embargo, se ofrecen dos mecanismos para la personalización: savedconfig y fragmentos de configuración. Consulte la página del proyecto para más detalles sobre la configuración.

Opcional: Módulos del núcleo firmados

Los módulos del núcleo en el núcleo de distribución preconstruido (sys-kernel/gentoo-kernel-bin) ya están firmados. Para firmar los módulos de núcleos creados a partir del código fuente, habilite el indicador USE modules-sign y, opcionalmente, especifique qué clave usar para la firma en /etc/portage/make.conf:

ARCHIVO /etc/portage/make.confHabilitar módulos firmados
USE="modules-sign"

# Opcionalmente, para utilizar claves de firma personalizadas.
MODULES_SIGN_KEY="/ruta/a/clave_núcleo.pem"
MODULES_SIGN_CERT="/ruta/a/clave_núcleo.pem" # Solo es necesario si MODULES_SIGN_KEY no contiene también el certificado.
MODULES_SIGN_HASH="sha512" # sha512 por defecto.

Si no se especifica MODULES_SIGN_KEY, el sistema de compilación del kernel generará una clave, que se almacenará en /usr/src/linux-x.y.z/certs. Se recomienda generar manualmente una clave para garantizar que sea la misma para cada versión del kernel. Se puede generar una clave con:

root #openssl req -new -nodes -utf8 -sha256 -x509 -outform PEM -out kernel_key.pem -keyout kernel_key.pem
Nota
MODULES_SIGN_KEY y MODULES_SIGN_CERT pueden ser archivos diferentes. Para este ejemplo, el archivo pem generado por OpenSSL incluye tanto la clave como el certificado adjunto y, por lo tanto, ambas variables se establecen al mismo valor.

OpenSSL hará algunas preguntas sobre el usuario para el que se genera la clave, se recomienda responderlas lo más detalladamente posible.

Guarde la clave en un lugar seguro, como mínimo, que solo el usuario root pueda leerla. Verifiquelo con:

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

Si la salida es algo distinta a lo anterior, corrija los permisos con:

root #chown root:root kernel_key.pem
root #chmod 400 kernel_key.pem
Opcional: Firmar la imagen del núcleo (Arranque Seguro)

La imagen del núcleo en el núcleo de distribución preconstruido (sys-kernel/gentoo-kernel-bin) ya está firmada para su uso con Secure Boot. Para firmar la imagen del núcleo de los núcleos creados a partir del código fuente, habilite el indicador USE secureboot y, opcionalmente, especifique qué clave usar para la firma en /etc/portage/make.conf. Tenga en cuenta que firmar la imagen del núcleo para usarla con Secureboot requiere que los módulos del núcleo también estén firmados, se puede usar la misma clave para firmar tanto la imagen del núcleo como los módulos del núcleo:

ARCHIVO /etc/portage/make.confHabilitar claves de firma personalizadas
USE="modules-sign secureboot"

# Opcionalmente, para utilizar claves de firma personalizadas.
MODULES_SIGN_KEY="/ruta/a/kernel_key.pem"
MODULES_SIGN_CERT="/ruta/a/kernel_key.pem" # Solo es necesario si MODULES_SIGN_KEY no contiene también el certificado.
MODULES_SIGN_HASH="sha512" # El valor predeterminado es sha512.

# Opcionalmente, para arrancar con secureboot habilitado, puede ser la misma clave de firma o una diferente..
SECUREBOOT_SIGN_KEY="/ruta/a/kernel_key.pem"
SECUREBOOT_SIGN_CERT="/ruta/a/kernel_key.pem"
Nota
SECUREBOOT_SIGN_KEY y SECUREBOOT_SIGN_CERT pueden ser archivos diferentes. Para este ejemplo, el archivo pem generado por OpenSSL incluye tanto la clave como el certificado adjunto y, por lo tanto, ambas variables se establecen en el mismo valor.
Nota
Para este ejemplo, la misma clave que se generó para firmar los módulos se utiliza para firmar la imagen del kernel. También es posible generar y utilizar una segunda clave independiente para firmar la imagen del kernel. Se puede volver a utilizar el mismo comando OpenSSL que en la sección anterior.

Consulte la sección anterior para obtener instrucciones sobre cómo generar una nueva clave, los pasos pueden repetirse si se debe usar una clave distinta para firmar la imagen del núcleo.

Para arrancar correctamente con el arranque seguro habilitado, el gestor de arranque utilizado también debe estar firmado y el firmware UEFI o Shim debe aceptar el certificado. Esto se explicará más adelante en el manual.

Instalando un núcleo de distribución

Para construir un núcleo con parches de Gentoo desde el código fuente, escriba:

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

Los administradores de sistema que quieran evitar compilar las fuentes del núcleo localmente pueden utilizar imágenes del núcleo precompiladas:

root #emerge --ask sys-kernel/gentoo-kernel-bin
Importante
Los
Distribution Kernel
Description Dist-kernel project maintains packages providing for zero-effort kernel install and upgrades
Project email dist-kernel@gentoo.org
Packages p.g.o/dist-kernel@gentoo.org



IRC channel #gentoo-dist-kernel (webchat)
Bugs Related bugs
Lead(s) "Yes" is not recognized as a Boolean (true/false) value. none
No lead election date set
Member(s)
Subproject(s)
(and inherited member(s)) 		(none)
Parent Project Gentoo
Project listing


The Distribution Kernel project aims to maintain sys-kernel/*-kernel packages. These kernel packages have three goals:

  1. Covering kernel maintenance wholly within packages (install via emerge, upgrade as part of @world upgrade), without requiring additional actions from the user or resorting to non-portable hacks.
  2. Providing a default configuration that works for most of diverse systems, for users who are not interested in configuring their own kernel from scratch.
  3. Supporting different bootloaders and /boot layouts (LILO, GRUB, systemd-boot, EFI stub…) with minimal effort, including deploying self-built kernel binary packages over a fleet of heterogeneous systems.

Current packages

The following packages are provided:

The project currently maintains two LTS branches (5.4 and 5.10), plus newer branches that are marked stable at the time. Usually, the last EOL version is also kept for a short time.

Trying it out

Consejo
If using out-of-source kernel modules like x11-drivers/nvidia-drivers or sys-fs/zfs, add USE="dist-kernel" to /etc/portage/make.conf for automatic rebuilds!

Simply, either run

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

or

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

depending on your preference for from-source builds or prebuilt binaries. You need to use the non-bin if you wish to customise your config.

For updating the bootloader's configuration files:

It is possible to use a hook in /etc/kernel/install.d/ to automatically update other bootloaders or run arbitrary commands at the point of kernel installation.

See the AMD64 Handbook for more details.

Signed kernel modules

The modules-sign global USE flag can be used to automatically sign the compiled kernel modules. When the flag is enabled the MODULES_SIGN_HASH, MODULES_SIGN_KEY (and optionally MODULES_SIGN_CERT) environment variables can be set to control the used key (or pkcs11 URI) and hashing algorithm (default: SHA512). When MODULES_SIGN_KEY is unset the kernel build system will automatically generate a new key.

ARCHIVO /etc/portage/make.confmake.conf
MODULES_SIGN_KEY="..."
MODULES_SIGN_HASH="..."

As of version 6.4.13 the modules in the pre-built kernel packages (e.g. sys-kernel/gentoo-kernel-bin) are pre-signed though enforcing of valid module signatures is not enabled by default for these kernels. Enforcing can be enabled with the module.sig_enforce=1 kernel command line argument, or by enabling Secure Boot. For these kernels the key that was used to sign the in-tree modules is not available to sign out-of-tree modules. In this case, if module signature enforcing is enabled, any out-of-tree modules must be signed with a different key, and the certificate belonging to this key must be inserted into the kernel's keychain using Shim, see the Signed kernel module support and Shim article for more details.

Secure Boot

The secureboot global USE flag can be used to automatically sign the generated kernel images for use with Secure Boot. When the flag is enabled the SECUREBOOT_SIGN_KEY and SECUREBOOT_SIGN_CERT must be used to specify which key (or pkcs11 URI) and certificate should be used. When using Secure Boot it is required that the kernel modules are also signed, see the above section for more information on this.

ARCHIVO /etc/portage/make.confmake.conf
SECUREBOOT_SIGN_KEY="..."
SECUREBOOT_SIGN_CERT="..."

As of version 6.4.13 the kernel image in the pre-built kernel packages (e.g. sys-kernel/gentoo-kernel-bin) is pre-signed. The certificate belonging to this signature can be found in /usr/src/linux-x.y.z-gentoo-dist/certs/signing_key.x509. As with other kernel packages, this certificate must be accepted by the UEFI firmware or Shim in order to boot with Secure Boot enabled.

Nota
To successfully boot with Secure Boot enabled any bootloaders involved in the boot-chain must also be signed. Additionally the firmware must be configured to accept the used certificate, or alternatively Shim can be used as pre-loader.

Generic UKI

As of version 6.6.9 it is possible to install a generic Unified Kernel Image alongside the kernel with the generic-uki USE flag on amd64 and arm64 systems. As with the plain kernel images and kernel modules, this UKI is pre-signed in sys-kernel/gentoo-kernel-bin. To use the generic UKI ensure that the used implementation of installkernel does not overwrite the pre-generated initramfs or UKI.

Debian's installkernel

For sys-kernel/installkernel[-systemd] this means that no initramfs or UKI generating plugins should be installed in /etc/kernel/preinst.d, this will be the case unless custom plugins were installed.

Systemd's kernel-install

sys-kernel/installkernel[systemd] should be configured to a) use the uki layout and b) not call any initrd_generator or uki_generator. These variables should be set to none, or any other value that is not an installed initramfs or uki generator. This is the case by default unless /etc/kernel/install.conf has been manually altered.

For example, to use the generic UKI:

ARCHIVO /etc/kernel/install.conf
layout=uki
initrd_generator=none
uki_generator=none

To use only the generic initramfs, and generate a custom UKI with, for example, ukify:

ARCHIVO /etc/kernel/install.conf
layout=uki
initrd_generator=none
uki_generator=ukify
Advertencia
This is an experimental feature! It is know to work on systemd systems via systemd-boot or EFI Stub booting. It will likely not work on systems using openrc and/or musl due to the inclusion of systemd and other executables built against glibc in the prebuilt initramfs. Issues have also been observed trying to boot this generic UKI with GRUB. Additionally, the generic UKI requires that the systems UEFI implementation is 64 bit, which may not be the case on older systems despite the system having a 64 bit CPU, on these systems the generic initramfs image may still be used but a custom UKI must be built as described above. When trying the generic UKI or initramfs for the first time, always ensure that an alternative method of booting the system is available.

Using custom initramfs and UKI generators

To use initramfs generators other then the default dracut, disable the initramfs USE flag. Then install an appropriate plugin for the used installkernel implementation:

Debian's installkernel

For sys-kernel/installkernel[-systemd] initramfs and UKI plugins are installed in /etc/kernel/preinst.d. The plugin must place the generated initramfs and/or UKI as an initrd or uki.efi file respectively, in the same location as the kernel image.

Systemd's kernel-install

For sys-kernel/installkernel[systemd] initramfs and UKI plugins are installed in /etc/kernel/install.d, the file name must have the suffix .install. The plugin must place the generated initramfs and/or UKI as an initrd or uki.efi file respectively, in ${KERNEL_INSTALL_STAGING_AREA}. Additionally it should respect the ${KERNEL_INSTALL_INITRD_GENERATOR} and/or ${KERNEL_INSTALL_UKI_GENERATOR} variables.

Modifying kernel configuration

Nota
By default, a rather full-featured config is used. These steps are only necessary if a customized configuration is required.
Advertencia
To customize, use the from-source packages sys-kernel/gentoo-kernel or sys-kernel/vanilla-kernel, and not the the -bin variant(s).

The modern versions of Distribution Kernels support two mechanisms for changing the kernel configuration: savedconfig and/or config snippets.

savedconfig
Replaces the entire package-provided config with an administrator-supplied config file. This approach is probably a better choice for those desiring to build an entirely custom kernel.
config snippets
Uses the /etc/kernel/config.d directory to hold configuration file "snippets" that will be merged on top of the package-provided configuration file. This approach offers a convenient method for use-cases that change some specific config options (I.E. enable or disable a certain feature entirely), but would like to continue receiving new changes from the package-provided config file.

Preparing a modified kernel config

The easiest way to modify the current kernel configuration is to run one the configuration UIs in the kernel build tree. To do that, select a kernel ebuild and run it up to the configure phase. For example:

root #ebuild /var/db/repos/gentoo/sys-kernel/gentoo-kernel/gentoo-kernel-5.9.8.ebuild configure
 * linux-5.9.tar.xz BLAKE2B SHA512 size ;-) ...                          [ ok ]
 * genpatches-5.9-8.base.tar.xz BLAKE2B SHA512 size ;-) ...              [ ok ]
 * genpatches-5.9-8.extras.tar.xz BLAKE2B SHA512 size ;-) ...            [ ok ]
 * kernel-x86_64-fedora.config.5.9.2 BLAKE2B SHA512 size ;-) ...         [ ok ]
 * Starting with 5.7.9, Distribution Kernels are switching from Arch
 * Linux configs to Fedora.  Please keep a backup kernel just in case.
>>> Unpacking source...
>>> Unpacking linux-5.9.tar.xz to /tmp/portage/sys-kernel/gentoo-kernel-5.9.8/work
[...]
make[1]: Leaving directory '/tmp/portage/sys-kernel/gentoo-kernel-5.9.8/work/modprep'
>>> Source configured.

Note the directory used by make. Enter it and run a kernel configuration tool such as nconfig or menuconfig:

root #cd /var/tmp/portage/sys-kernel/gentoo-kernel-5.9.8/work/modprep
root #make nconfig

After saving changes, the new config will be written to the .config file (in the modprep directory).

Using savedconfig

To use savedconfig, put the kernel config into an appropriate /etc/portage/savedconfig directory. The filename can either match the package name, or name with version. For example, creating the following file will apply the same configuration anytime a version of the gentoo-kernel package is emerged:

root #cp /var/tmp/portage/sys-kernel/gentoo-kernel-5.9.8/work/modprep/.config /etc/portage/savedconfig/sys-kernel/gentoo-kernel

Afterward, enable the savedconfig USE flag on the relevant kernel package, then re-emerge the package:

root #echo "sys-kernel/gentoo-kernel savedconfig" >> /etc/portage/package.use
root #emerge --ask sys-kernel/gentoo-kernel

Note that the default Gentoo kernel configuration will not used if savedconfig has been enabled. When using an outdated configuration file, unset symbols (a.k.a newly added symbols) will take the upstream kernel's default values rather than Gentoo's default configuration. It is important to note there could be differences between the two.

Using /etc/kernel/config.d

Consejo
To easily generate .config snippets, run diff --changed-group-format="%>" --unchanged-group-format="" .config.old .config | tee -a /etc/kernel/config.d/my-kernel.config in /var/tmp/portage/sys-kernel/gentoo-kernel-5.9.8/work/modprep.

To use the config.d approach, put a config override file into /etc/kernel/config.d directory. Make sure that the file has .config suffix. All files present in that directory will be merged in lexical order to the default Gentoo config.

For example:

ARCHIVO /etc/kernel/config.d/50test.config
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000

Note that the 'is not set' comments unset options.

Using different option files for different kernel versions or variants is not supported via the config.d configuration method at the moment.

Project docs

See also

Actualización y limpieza

Una vez instalado el núcleo, el administrador de paquetes lo actualizará automáticamente a versiones más recientes. Las versiones anteriores se conservarán hasta que se solicite al administrador de paquetes que limpie los paquetes obsoletos. Para recuperar espacio en disco, los paquetes obsoletos se pueden eliminar ejecutando periódicamente emerge con la opción --depclean:

root #emerge --depclean

Alternativamente, para limpiar específicamente versiones antiguas del núcleo:

root #emerge --prune sys-kernel/gentoo-kernel sys-kernel/gentoo-kernel-bin
Consejo
Por diseño, emerge solo elimina el directorio de compilación del núcleo. No elimina los módulos del núcleo ni la imagen del núcleo instalada. Para limpiar completamente los núcleos antiguos, se puede usar la herramienta app-admin/eclean-kernel.

Tareas posteriores a la instalación/actualización

Una actualización de un núcleo de distribución puede activar la reconstrucción automática de los módulos externos del núcleo instalados por otros paquetes (por ejemplo: sys-fs/zfs-kmod o x11-drivers/nvidia-drivers). Este comportamiento automatizado se activa con el indicador USE dist-kernel. Cuando sea necesario, este mismo indicador también activará la regeneración de initramfs.

Se recomienda encarecidamente activar este indicador globalmente a través de /etc/portage/make.conf cuando se utiliza un nucleo de distribución:

ARCHIVO /etc/portage/make.confActivar USE=dist-kernel
USE="dist-kernel"
Reconstrucción manual de initramfs o de la Imagen de Núcleo Unificada

Si es necesario, active manualmente tales reconstrucciones, después de una actualización del núcleo, ejecutando:

root #emerge --ask @module-rebuild

Si se necesita algún módulo del núcleo (por ejemplo, ZFS) en el inicio temprano, reconstruya el initramfs también a través de:

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

Después de instalar con éxito un núcleo de distribución, es momento de pasar a la siguiente sección: Configuración del sistema.


Retrieved from "https://wiki.gentoo.org/index.php?title=Handbook:Parts/Installation/Kernel/Dist-Kernel/es&oldid=1356839"