Manual de Gentoo: X86/Instalación/Núcleo
Opcional: Instalar firmware y/o microcódigo
Firmware
Sugerido: Linux Firmware
En muchos sistemas, se requiere firmware no FOSS para el funcionamiento de ciertos dispositivos. El paquete sys-kernel/linux-firmware contiene firmware para muchos dispositivos, pero no para todos.
La mayoría de las tarjetas inalámbricas y GPU,s. requieren firmware para funcionar.
root #emerge --ask sys-kernel/linux-firmwareLa instalación de determinados paquetes de firmware suele requerir la aceptación de las licencias de firmware asociadas. Si es necesario, visite la sección de manejo de licencias del Manual para obtener ayuda sobre cómo aceptar licencias.
Carga de Firmware
Los archivos de firmware suelen cargarse junto con el módulo del núcleo correspondiente. Esto significa que el firmware debe integrarse en el núcleo mediante CONFIG_EXTRA_FIRMWARE si el módulo del núcleo está configurado como Y en lugar de M. En la mayoría de los casos, integrar un módulo que requiere firmware puede complicar o interrumpir la carga.
Microcódigo
Además del específico para el hardware de gráficos y las interfaces de red, las CPUs también pueden requerir actualizaciones de firmware. Normalmente, este tipo de firmware se conoce como microcódigo. A veces se necesitan revisiones más recientes del microcódigo para parchear la inestabilidad, los problemas de seguridad u otros errores diversos en el hardware de la CPU.
Las actualizaciones de microcódigo para las CPUs de AMD se distribuyen dentro del paquete sys-kernel/linux-firmware mencionado anteriormente. El microcódigo para CPUs Intel se puede encontrar dentro del paquete sys-firmware/intel-microcode, que deberá instalarse por separado. Consulte el artículo sobre Microcódigo para obtener más información sobre cómo aplicar actualizaciones de microcódigo.
sys-kernel/installkernel
Installkernel puede usarse para automatizar la instalación del núcleo, la generación de initramfs, la generación de unified kernel image y/o la configuración del gestor de arranque, entre otras cosas. sys-kernel/installkernel implementa dos métodos para lograr esto: el installkernel tradicional, originado en Debian, y el kernel-install de systemd. La elección de uno u otro depende, entre otros factores, del gestor de arranque del sistema. Por defecto, el kernel-install de systemd se usa en los perfiles de systemd, mientras que el installkernel tradicional es el predeterminado para otros perfiles.
Cargador de arranque
Ahora es el momento de pensar qué cargador de arranque desea el usuario para el sistema. Si no está seguro, siga la subsección 'Diseño tradicional' a continuación.
GRUB
Los usuarios de GRUB pueden usar kernel-install de systemd o el installkernel tradicional de Debian. El indicador USE systemd alterna entre estas implementaciones. Para ejecutar automáticamente grub-mkconfig al instalar el núcleo, active el indicador USE grub.
/etc/portage/package.use/installkernelsys-kernel/installkernel grub
root #emerge --ask sys-kernel/installkernelsystemd-boot
Al usar systemd-boot (anteriormente gummiboot) como gestor de arranque, se debe usar kernel-install de systemd. Por lo tanto, asegúrese de que los indicadores USE systemd y systemd-boot estén habilitados en sys-kernel/installkernel y, a continuación, instale el paquete correspondiente para systemd-boot.
En sistemas OpenRC:
/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/installkernelEn sistemas systemd:
/etc/portage/package.use/systemdsys-apps/systemd boot
sys-kernel/installkernel systemd-boot
root #emerge --ask sys-apps/systemd sys-kernel/installkernelLa línea de comando del núcleo que se utilizará para los nuevos núcleos debe especificarse en /etc/kernel/cmdline, por ejemplo:
/etc/kernel/cmdlinequiet splash
Módulo EFI
Técnicamente, los sistemas informáticos basados en UEFI no necesitan cargadores de arranque secundarios para arrancar los núcleos. Estos cargadores existen para extender la funcionalidad del firmware UEFI durante el proceso de arranque. Dicho esto, usar un cargador de arranque secundario suele ser más sencillo y robusto, ya que ofrece una mayor flexibilidad para modificar rápidamente los parámetros del núcleo durante el arranque. Cabe destacar que las implementaciones de UEFI difieren considerablemente entre proveedores y modelos, y no se garantiza que un firmware determinado cumpla con la especificación UEFI. Por lo tanto, no se garantiza que el arranque con módulo Stub funcione en todos los sistemas basados en UEFI; por lo tanto, el indicador USE está enmascarado el la rama estable y se deben aceptar las palabras clave pruebas para que installkernel utilice esta función.
/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 /efiEsquema tradicional, otros cargadores de arranque (por ejemplo, (e)lilo, syslinux, etc.)
El esquema tradicional con /boot (p. ej., (e)LILO, syslinux, etc.) se usa por defecto si los indicadores USE grub, systemd-boot, efistub y uki no están habilitados. No se requiere ninguna acción adicional.
Initramfs
Un initial ram-based file system, o initramfs, puede ser necesario para que un sistema arranque. Diversos casos pueden requerirlo, pero los más comunes incluyen:
- Núcleos donde los controladores de almacenamiento/sistema de archivos son módulos.
- Diseños con /usr/ o /var/ en particiones separadas.
- Sistemas de archivos raíz cifrados.
Los núcleos de distribución están diseñados para usarse con un initramfs, ya que muchos controladores de almacenamiento y sistemas de archivos se construyen como módulos.
Además de montar el sistema de archivos raíz, un initramfs también puede realizar otras tareas como:
- Ejecución de file system consistency check fsck, una herramienta para comprobar y reparar la consistencia de un sistema de archivos en caso de apagado incorrecto del sistema.
- Proporcionar un entorno de recuperación en caso de fallos tras el arranque.
Installkernel puede generar automáticamente un initramfs al instalar el núcleo si el indicador USE dracut o ugrd está habilitado:
/etc/portage/package.use/installkernelsys-kernel/installkernel dracut
root #emerge --ask sys-kernel/installkernelOpcional: Imagen de núcleo unificada
Una Imagen de Núcleo Unificada (UKI) combina, entre otras cosas, el núcleo, el initramfs y la línea de comandos del núcleo en un único ejecutable. Dado que la línea de comandos del núcleo está integrada en la imagen del núcleo unificada, se debe especificar antes de generar la imagen del núcleo unificada (ver más abajo). Tenga en cuenta que cualquier argumento de la línea de comandos del núcleo proporcionado por el gestor de arranque o el firmware durante el arranque se ignora cuando se inicia con el arranque seguro habilitado.
Una imagen de núcleo unificada requiere un módulo cargador. Actualmente el único disponible es systemd-stub. Para habilitarlo:
En sistemas systemd:
/etc/portage/package.use/ukisys-apps/systemd boot
root #emerge --ask sys-apps/systemdEn sistemas OpenRC:
/etc/portage/package.use/ukisys-apps/systemd-utils boot kernel-install
root #emerge --ask sys-apps/systemd-utilsInstallkernel puede generar automáticamente una imagen de núcleo unificada usando dracut o ukify habilitando el indicador respectivo y el indicador USE uki.
Para dracut:
/etc/portage/package.use/ukisys-kernel/installkernel dracut uki
/etc/dracut.conf.d/uki.confuefi="yes"
kernel_cmdline="argumentos-para-la-linea-comando-del-núcleo"
root #emerge --ask sys-kernel/installkernelPara ukify:
/etc/portage/package.use/ukisys-apps/systemd boot ukify # Para sistemas systemd
sys-apps/systemd-utils kernel-install boot ukify # Para sistemas OpenRC
sys-kernel/installkernel dracut ukify uki
/etc/kernel/cmdlineargumentos-para-la-linea-comandos-del-núcleo
root #emerge --ask sys-kernel/installkernelTenga en cuenta que, si bien dracut puede generar tanto initramfs como una imagen de núcleo unificada, ukify solo puede generar esta última y, por lo tanto, el initramfs debe generarse por separado con dracut.
En los ejemplos de configuración anteriores (tanto para Dracut como para ukify), es importante especificar al menos un parámetro root= adecuado para la línea de comando del núcleo a fin de garantizar que la Imagen Unificada del Núcleo pueda encontrar la partición raíz. Esto no es necesario para sistemas basados en systemd que siguen la Especificación de Particiones Descubribles (DPS); en ese caso, el initramfs integrado podrá encontrar dinámicamente la partición raíz.
Imagen del Núcleo Unificada Genérica (solo systemd)
El Template:Paquete preconstruido puede instalar opcionalmente una imagen del núcleo unificada genérica preconstruida que contiene un initramfs genérico que puede arrancar la mayoría de los sistemas basados en systemd. Se puede instalar habilitando el indicador USE generic-uki y configurando installkernel para no generar un initramfs personalizado o una imagen del núcleo unificada:
/etc/portage/package.use/ukisys-kernel/gentoo-kernel-bin generic-uki
sys-kernel/installkernel -dracut -ukify -ugrd uki
Arranque Seguro
Si sigue esta sección y compila manualmente su propio núcleo, asegúrese de seguir los pasos descritos en Firma del núcleo
La imagen genérica del núcleo unificada distribuida opcionalmente por sys-kernel/gentoo-kernel-bin ya está prefirmada. La forma de firmar una imagen del núcleo unificada generada localmente depende de si se utiliza dracut o ukify. Tenga en cuenta que la ubicación de la clave y el certificado debe ser la misma que SECUREBOOT_SIGN_KEY y SECUREBOOT_SIGN_CERT como se especifica en /etc/portage/make.conf.
Para 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"
Para ukify:
/etc/kernel/uki.conf[UKI]
SecureBootPrivateKey=/path/to/kernel_key.pem
SecureBootCertificate=/path/to/kernel_key.pem
Configuración y compilación del núcleo
Usar dist-kernel en el primer arranque puede ser una buena idea, ya que proporciona un método muy sencillo para descartar problemas del sistema y de configuración del núcleo. Tener siempre un núcleo funcional al que recurrir puede acelerar la depuración y aliviar la ansiedad cuando al actualizar el sistema ya no arranca.
Ahora es el momento de configurar y compilar las fuentes del núcleo. A efectos de instalación, se presentarán tres estrategias para la gestión del núcleo; sin embargo, en cualquier momento posterior a la instalación, se puede cambiar de estrategia.
Durante la fase de instalación de Gentoo, solo se debe instalar un tipo de núcleo, es decir, Template:Paquete o Template:Paquete.
Clasificadas de menor a mayor complicación:
- Propuesta de automatización total: núcleos de la distribución
- Un Núcleo de la Distribución se usa para configurar, compilar e instalar automáticamente el núcleo Linux, sus módulos asociados y (opcionalmente, pero habilitado por defecto) un archivo initramfs. Las actualizaciones futuras del núcleo están completamente automatizadas, ya que se manejan a través del administrador de paquetes, como cualquier otro paquete del sistema. Es posible proporcionar un archivo de configuración del núcleo personalizado si es necesaria la personalización. Este es el proceso menos complicado y es perfecto para los nuevos usuarios de Gentoo debido a que funciona de forma inmediata y ofrece una participación mínima por parte del administrador del sistema.
- La manera completamente manual
- Las nuevas fuentes del núcleo se instalan a través del administrador de paquetes del sistema. El núcleo se configura, compila e instala manualmente utilizando eselect kernel y una serie de comandos make. Las futuras actualizaciones del núcleo repiten el proceso manual de configuración, compilación e instalación de los archivos del núcleo. Este es el proceso más complejo, pero ofrece el máximo control sobre el proceso de actualización del núcleo.
- Estrategia híbrida: Genkernel
- Aquí usamos el término híbrido, pero tenga en cuenta que las fuentes de dist-kernel y del manual incluyen métodos para lograr el mismo objetivo. Las nuevas fuentes del núcleo se instalan a través del administrador de paquetes del sistema. Los administradores del sistema pueden usar la herramienta genkernel de Gentoo para configurar, compilar, e instalar automáticamente el núcleo Linux, sus módulos asociados y (opcionalmente, pero no habilitado por defecto) un archivo initramfs archivo. Es posible proporcionar un archivo de configuración del núcleo personalizado si es necesaria la personalización. La configuración, compilación e instalación futuras del núcleo requieren la participación del administrador del sistema en la forma de ejecutar eselect kernel, genkernel y potencialmente otros comandos para cada actualización. Esta opción solo debe considerarse para usuarios que saben que necesitan genkernel
El eje alrededor del cual se construyen todas las distribuciones es el núcleo Linux. Es la capa entre los programas del usuario y el hardware del sistema. Aunque el manual proporciona a sus usuarios varias fuentes posibles del núcleo, hay disponible una lista más completa y con descripciones más detalladas en la Página de descripción general del núcleo.
Tareas de instalación del núcleo como copiar la imagen del núcleo a /boot o la Partición del Sistema EFI, generar un initramfs y/o Imagen unificada del núcleo, que actualiza la configuración del gestor de arranque, se puede automatizar con installkernel. Es posible que los usuarios deseen configurar e instalar sys-kernel/installkernel antes de continuar. Consulte la Sección de instalación del núcleo a continuación para obtener más información.
Distribution kernels
Distribution Kernels are ebuilds that cover the complete process of unpacking, configuring, compiling, and installing the kernel. The primary advantage of this method is that the kernels are updated to new versions by the package manager as part of @world upgrade. This requires no more involvement than running an emerge command. Distribution kernels default to a configuration supporting the majority of hardware, however two mechanisms are offered for customization: savedconfig and config snippets. See the project page for more details on configuration.
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"
# 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"
# Optionally, to use custom signing keys.
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem" # Only required if the MODULES_SIGN_KEY does not also contain the certificate.
MODULES_SIGN_HASH="sha512" # Defaults to sha512.
# Optionally, to boot with secureboot enabled, may be the same or different signing key.
SECUREBOOT_SIGN_KEY="/path/to/kernel_key.pem"
SECUREBOOT_SIGN_CERT="/path/to/kernel_key.pem"
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.
Installing a distribution kernel
To build a kernel with Gentoo patches from source, type:
root #emerge --ask sys-kernel/gentoo-kernelSystem administrators who want to avoid compiling the kernel sources locally can instead use precompiled kernel images:
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.
Upgrading and cleaning up
Once the kernel is installed, the package manager will automatically update it to newer versions. The previous versions will be kept until the package manager is requested to clean up stale packages. To reclaim disk space, stale packages can be trimmed by periodically running emerge with the --depclean option:
root #emerge --depcleanAlternatively, to specifically clean up old kernel versions:
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.
Post-install/upgrade tasks
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.
It is highly recommended to enable this flag globally via /etc/portage/make.conf when using a distribution kernel:
/etc/portage/make.confEnabling USE=dist-kernelUSE="dist-kernel"
Manually rebuilding the initramfs or Unified Kernel Image
If required, manually trigger such rebuilds by, after a kernel upgrade, executing:
root #emerge --ask @module-rebuildIf any kernel modules (e.g. ZFS) are needed at early boot, rebuild the initramfs afterward via:
root #emerge --config sys-kernel/gentoo-kernel
root #emerge --config sys-kernel/gentoo-kernel-bin
After installing the Distribution Kernel successfully, it is now time to proceed to the next section: Configuring the system.
Instalar las fuentes del núcleo
Al instalar y compilar el núcleo para sistemas basados en x86, Gentoo recomienda el paquete sys-kernel/gentoo-sources.
Elija una fuente del núcleo adecuada e instálela usando emerge:
root #emerge --ask sys-kernel/gentoo-sourcesEsto instalará las fuentes del núcleo Linux en /usr/src/ usando la versión específica del kernel en el nombre de la ruta. No creará un enlace simbólico de forma automática a no ser que el indicador USE symlink esté habilitado en el paquete de fuentes del núcleo elegido.
Es una convencion que se mantenga el enlace simbólico /usr/src/linux, de modo que se refiera a las fuentes que correspondan con el núcleo que se está ejecutando actualmente. Sin embargo, este enlace simbólico no se creará por defecto. Una manera fácil de crear el enlace simbólico es utilizar el módulo kernel de eselect.
Para obtener más información sobre la finalidad del enlace simbólico y cómo administrarlo, consulte Kernel/Upgrade.
Primero, enumere todos los núcleos instalados:
root #eselect kernel listAvailable kernel symlink targets: [1] linux-6.6.21-gentoo
Para crear un enlace simbólico llamado linux, use:
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
Alternativa: Configuración manual
En caso de que se lo haya perdido, esta sección requiere las fuentes del núcleo estén instalafas. Asegúrese de obtener las fuentes del núcleo relevantes, luego regrese aquí para el resto de la sección.
Configurar manualmente un núcleo suele considerarse uno de los procedimientos más difíciles que debe realizar un administrador de sistemas. Y nada es menos cierto: después de configurar algunos núcleos, ¡nadie recuerda lo difícil que fue! Hay dos maneras en que un usuario de Gentoo puede administrar un sistema de núcleo manual, las cuales se listan a continuación:
Proceso modprobed-db
Una forma muy sencilla de administrar el núcleo es instalar primero sys-kernel/gentoo-kernel-bin y usar sys-kernel/modprobed-db para recopilar información sobre las necesidades del sistema. modprobed-db es una herramienta que monitoriza el sistema mediante crontab para agregar todos los módulos de todos los dispositivos a lo largo de su vida útil y garantizar que todo lo que el usuario necesita sea compatible. Por ejemplo, si se agrega un mando de Xbox después de la instalación, modprobed-db agregará los módulos que se compilarán la próxima vez que se recompile el núcleo. Puede encontrar más información sobre este tema en el artículo Modprobed-db.
Proceso manual
Este método permite al usuario tener control total sobre la construcción de su núcleo con la mínima ayuda de herramientas externas que desee. Algunos podrían considerarlo una complicación sin más.
Sin embargo, con esta elección una cosa sí es cierta: es vital conocer el sistema para configurar manualmente un núcleo. La mayor cantidad de información se puede obtener instalando sys-apps/pciutils que contiene la orden lspci:
root #emerge --ask sys-apps/pciutilsDentro de la jaula chroot, se pueden ignorar con tranquilidad las advertencias sobre pcilib (como pcilib: cannot open /sys/bus/pci/devices) que pudiera mostrar lspci.
Otra fuente de información sobre nuestro sistema consiste en ejecutar lsmod para ver los módulos del nucleo que ha usado el CD de instalación y tener así buenas indicaciones sobre qué habilitar.
Ahora vaya al directorio de origen del núcleo.
root #cd /usr/src/linux
El núcleo cuenta con un método para autodetectar los módulos que se utilizan actualmente en el CD de instalación, lo que ofrece un excelente punto de partida para que el usuario configure los suyos propios. Esto se puede activar con:
root #make localmodconfigAhora es el momento de configurar usando nconfig:
root #make nconfigLa configuración del núcleo Linux tiene muchas, muchas secciones. Veamos primero una lista con algunas opciones que deben ser activadas (en caso contrario Gentoo no funcionará o no funcionará adecuadamente sin ajustes adicionales). También tenemos la guía Gentoo de configuración del núcleo en la wiki de Gentoo que también podría ayudar.
Habilitar las opciones requeridas
Al usar sys-kernel/gentoo-sources, se recomienda encarecidamente que se habiliten las opciones de configuración específicas de Gentoo. Ésto asegura que estén disponibles un mínimo de características del núcleo requeridas para el funcionamiento adecuado:
Gentoo Linux --->
[*] 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
Naturalmente, la elección en las últimas dos líneas depende del sistema de inicio seleccionado (OpenRC vs. systemd). No está de más tener habilitado el soporte para ambos sistemas de inicio.
Al usar sys-kernel/vanilla-sources, las selecciones adicionales para los sistemas de inicio no estarán disponibles. Es posible habilitar el soporte, pero va más allá del alcance del manual.
Activación del soporte para componentes típicos del sistema
Asegúrese de que todos los controladores que son vitales para el arranque del sistema (como los controladores SATA, la compatibilidad con dispositivos de bloque NVMe, la compatibilidad con sistemas de archivos, etc.) estén compilados dentro del núcleo y no como un módulos; de lo contrario, es posible que el sistema no pueda arranque por completo.
A continuación seleccione con exactitud el tipo de procesador. Se recomienda habilitar las funcionalidades MCE (si están disponibles) de manera que los usuarios puedan ser informados de cualquier problema en este hardware. En algunas arquitecturas (como x86_64) estos errores no son presentados a través de dmesg sino de /dev/mcelog. Para ello se requiere el paquete app-admin/mcelog.
A continuación seleccione Maintain a devtmpfs file system to mount at /dev de modo que los archivos de dispositivo críticos estén disponibles cuanto antes en el proceso de inicio (CONFIG_DEVTMPFS y 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
Verificar que se ha activado el soporte de disco 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)
Verifique que se haya habilitado el soporte básico para NVMe:
Device Drivers --->
<*> NVM Express block device
Device Drivers --->
NVME Support --->
<*> NVM Express block device
No está de más habilitar el siguiente soporte NVMe adicional:
[*] 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
Vaya ahora a File Systems y seleccione el soporte para los sistemas de archivos que se vayan a usar en el sistema. No compile como módulo el sistema de archivos que vaya a utilizar para el sistema de archivos raíz, de lo contrario su sistema Gentoo podría no conseguir montar la partición raíz. También deberá seleccionar Virtual memory y /proc file system. Selecionar una o más de las siguientes opciones según las necesidades del sistema:
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)
Si está usando PPPoE para conectarse a Internet, o está usando un módem telefónico, habilite las siguientes opciones (CONFIG_PPP, CONFIG_PPP_ASYNC y CONFIG_PPP_SYNC_TTY):
Device Drivers --->
Network device support --->
<*> PPP (point-to-point protocol) support
<*> PPP over Ethernet
<*> PPP support for async serial ports
<*> PPP support for sync tty ports
Las dos opciones de compresión no están de más aunque no son necesarias, como tampoco lo es la opción PPP sobre Ethernet, que sólo podría utilizarse cuando se configure un núcleo en modo PPPoE.
No olvide incluir el soporte en el núcleo para su tarjeta de red (Ethernet o inalámbrica).
Muchos sistemas también tienen varios núcleos de microprocesador a su disposición, así que es importánte activar Symmetric multi-processing support (CONFIG_SMP):
Processor type and features --->
[*] Symmetric multi-processing support
En sistemas multi-núcleo, cada núcleo cuenta como un procesador.
Si utiliza dispositivos de entrada USB (como un teclado o un ratón) u otros, no olvide activarlos también:
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
<*> Unified support for USB4 and Thunderbolt --->
Opcional: módulos del núcleo firmados
Para firmar automáticamente los módulos del núcleo, habilite 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) --->
Opcionalmente, cambie el algoritmo hash si lo desea.
Para exigir que todos los módulos estén firmados con una firma válida, habilite CONFIG_MODULE_SIG_FORCE también:
[*] 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) --->
Para usar una clave personalizada, especifique la ubicación de esta clave en CONFIG_MODULE_SIG_KEY. Si no se especifica, el sistema de compilación del núcleo generará una clave. Se recomienda generar uno manualmente. Esto se puede hacer con:
root #openssl req -new -nodes -utf8 -sha256 -x509 -outform PEM -out kernel_key.pem -keyout kernel_key.pemOpenSSL hará algunas preguntas sobre el usuario para el que se genera la clave; se recomienda completar estas preguntas lo más detalladamente posible.
Guarde la clave en un lugar seguro; como mínimo, solo el usuario root debe poder leerla. Verifique esto con:
root #ls -l kernel_key.pem-r-------- 1 root root 3164 Jan 4 10:38 kernel_key.pem
Si esto genera algo distinto a lo anterior, corrija los permisos con:
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
Para firmar también módulos del núcleo externos instalados por otros paquetes a través de linux-mod-r1.eclass, habilite el indicador USE modules-sign globalmente:
/etc/portage/make.confHabilitar el firmado de módulosUSE="modules-sign"
# Opcional, cuando se usen claves 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" # sha512 es el predeterminado
MODULES_SIGN_KEY y MODULES_SIGN_CERT pueden apuntar a 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 configuran con el mismo valor.
Opcional: firmar la imagen del núcleo (Arranque Seguro)
Al firmar la imagen del núcleo (para usar en sistemas con Secure Boot habilitado), se recomienda configurar las siguientes opciones de configuración del núcleo:
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
[*] 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) --->
Security options --->
[*] Integrity subsystem
[*] Basic module for enforcing kernel lockdown
[*] Enable lockdown LSM early in init
Kernel default lockdown mode (Integrity) --->
[*] 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
Donde ""imagen"" es un marcador de posición para el nombre de la imagen específica de la arquitectura. Estas opciones, de arriba a abajo: exige que la imagen del núcleo en una llamada kexec deba estar firmada (kexec permite reemplazar el núcleo in situ), exige que los módulos del núcleo estén firmados, habilita el bloqueo modo integridad (evita la modificación del núcleo en tiempo de ejecución) y habilita varios claveros.
En arquitecturas que no admiten de forma nativa la descompresión del núcleo (por ejemplo, arm64 y riscv), el núcleo debe construirse con su propio descompresor (zboot):
Device Drivers --->
Firmware Drivers --->
EFI (Extensible Firmware Interface) Support --->
[*] Enable the generic EFI decompressor
Después de la compilación del núcleo, como se explica en la siguiente sección, se debe firmar la imagen del núcleo. Primero instale app-crypt/sbsigntools y luego firme la imagen del núcleo:
root #emerge --ask app-crypt/sbsigntoolsroot #sbsign /usr/src/linux-x.y.z/ruta/a/kernel-image --cert /ruta/a/kernel_key.pem --key /ruta/a/kernel_key.pem --out /usr/src/linux-x.y.z/ruta/a/kernel-imagePara este ejemplo, la misma clave que se generó para firmar los módulos se utiliza para firmar la imagen del núcleo. También es posible generar y utilizar una segunda clave especial distinta para firmar la imagen del núcleo. Se puede volver a utilizar el mismo comando OpenSSL que en la sección anterior.
Luego proceda con la instalación.
Para firmar automáticamente los ejecutables EFI instalados por otros paquetes, habilite el indicador USE secureboot globalmente:
/etc/portage/make.confHabilitar el Arranque SeguroUSE="modules-sign secureboot"
# Opcionalmente, para usar claves 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 predeterminado es sha512
# Opcionalmente, para iniciar con el arranque seguro 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"
SECUREBOOT_SIGN_KEY y SECUREBOOT_SIGN_CERT pueden apuntar a 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 configuran con el mismo valor.
Al generar una Imagen del núcleo unificada con
ukify de systemd, la imagen del núcleo se firmará automáticamente antes de incluirla en la imagen del núcleo unificada y no es necesario firmarla manualmente.
Para las arquitecturas x86, verificar que la opción 64-bit kernel está no activa/desactivada (CONFIG_64BIT=N), y a continuación seleccione la familia de procesadores apropiados para el o los procesadores del sistema.
Se puede determinar la familia del procesador revisando la salida de las dos órdenes siguientes:
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
Compilar e instalar
Una vez hecha la configuración, es el momento de compilar e instalar el núcleo. Salga de la configuración e inicie el proceso de compilación:
root #make && make modules_installEs posible habilitar las construcciones en paralelo usando make -jX siendo
X un número entero que representa el número de tareas en paralelo que el proceso de construcción tiene permitido lanzar. Esto es similar a las instrucciones acerca de /etc/portage/make.conf mencionadas anteriormente, con la variable MAKEOPTS.Cuando finalice la compilación del núcleo, copie la imagen del núcleo a /boot/. Esto se realiza con la orden make install:
root #make installEsto copiará la imagen del núcleo en /boot/ junto con el archivo System.map y el archivo de configuración del núcleo.
Deprecated: Genkernel
Genkernel solo debe ser considerado por usuarios con una necesidad que solo Genkernel puede satisfacer. Para otros, se recomienda usar el núcleo de distribución o compilar manualmente el suyo propio, ya que simplificará considerablemente el mantenimiento de un sistema Gentoo. Un ejemplo de por qué genkernel es más difícil de administrar es la falta de integración con sys-kernel/installkernel. Esto significa que el usuario no obtendrá el mismo nivel de automatización que ofrecen los otros métodos; por ejemplo, las imágenes unificadas del kernel deberán crearse manualmente al usar Genkernel.
Los usuarios que aún deseen utilizar Genkernel deben consultar el artículo Genkernel para obtener más información.
Módulos del núcleo
Listado de módulos del núcleo disponibles
Es opcional el hacer un listado manual de los módulos que se necesitan para el hardware. udev normalmente cargará todos los módulos para el hardware que se detecte al ser conectado, en la mayoría de los casos. Sin embargo, no es perjudicial que se enumeren los módulos que se cargarán automáticamente. Los módulos no se pueden cargar dos veces; se cargan o se descargan. A veces, el hardware exótico requiere ayuda para cargar sus controladores.
Los módulos que deben cargarse durante cada arranque se pueden agregar a los archivos /etc/modules-load.d/*.conf en el formato de un módulo por línea. En cambio cuando se necesitan opciones adicionales para los módulos, deben indicarse en los archivos /etc/modprobe.d/*.conf.
Para ver todos los módulos disponibles para una versión de núcleo en concreto, lance la siguiente orden find. No olvide sustituir "<versión del núcleo>" con la versión apropiada del núcleo a buscar:
root #find /lib/modules/<versión del núcleo>/ -type f -iname '*.o' -or -iname '*.ko' | lessForzar la carga de módulos concretos del núcleo
Para forzar la carga del núcleo para que cargue el módulo 3c59x.ko (que es el controlador para una familia de tarjetas de red 3Com específica), edite /etc/modules-load.d/network.conf e ingrese el nombre del módulo dentro de él.
root #mkdir -p /etc/modules-load.d
root #nano -w /etc/modules-load.d/network.conf
Tenga en cuenta que el sufijo del archivo .ko del módulo es insignificante para el mecanismo de carga y no se incluye en el archivo de configuración:
/etc/modules-load.d/network.confForzar la carga del módulo 3c59x3c59x
Continúe la instalación con Configuring the system.