Manual:Partes/Instalación/Núcleo
Readers should not try to follow instructions directly from the Handbook:Parts namespace (which is THIS page!). The sections displayed below are used as a skeleton for transcluding information into the computer architecture specific handbooks and are therefore lacking critical information.
Please visit the Handbook list to read instructions for a relevant computer architecture.
Opcional: Instalar firmware y/o microcódigo
Firmware
Firmware para Linux
Antes de comenzar a configurar las secciones del núcleo, es conveniente tener en cuenta que algunos dispositivos físicos requieren la instalación de firmware adicional, a veces no compatible con FOSS, en el sistema antes de que funcionen correctamente. Este suele ser el caso de las interfaces de red inalámbrica que se encuentran comúnmente en las computadoras de escritorio y portátiles. Los chips de video modernos de proveedores como AMD, Nvidia e Intel, a menudo también requieren archivos de firmware externos para ser completamente funcionales. La mayoría del firmware para dispositivos hardware modernos se puede encontrar en el paquete sys-kernel/linux-firmware.
Se recomienda tener instalado el paquete sys-kernel/linux-firmware antes del reinicio inicial del sistema para tener el firmware disponible en caso de que sea necesario:
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.
Es importante tener en cuenta que los símbolos del núcleo que se construyen como módulos (M) cargarán sus archivos de firmware asociados desde el sistema de archivos cuando el núcleo los cargue. No es necesario incluir los archivos de firmware del dispositivo dentro de la imagen binaria del núcleo para los símbolos cargados como módulos.
Architecture specific firmware
Placeholder for architecture-specific firmware information
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.
Configuración y compilación del núcleo
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.
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
- 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.
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, por ejemplo, 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.
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.
Instalando un núcleo de distribución
Antes de instalar el paquete del núcleo, se debe agregar el indicador USE dracut para el paquete sys-kernel/installkernel en /etc/portage/package.use:
/etc/portage/package.use/installkernelHabilitar soporte para dracutsys-kernel/installkernel dracut
Es posible que los usuarios también deseen habilitar en este momento indicadores USE adicionales para sys-kernel/installkernel. Consulte la sección Instalación/Kernel#Installkernel para obtener más detalles.
Para construir un núcleo con parches de Gentoo desde el código fuente, escriba:
root #emerge --ask sys-kernel/gentoo-kernelLos 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-binOpcional: 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:
/etc/portage/make.confHabilitar módulos firmadosUSE="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.pemMODULES_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.pemroot #chmod 400 kernel_key.pemOpcional: 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:
/etc/portage/make.confHabilitar claves de firma personalizadasUSE="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"
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.
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.
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 --depcleanAlternativamente, para limpiar específicamente versiones antiguas del núcleo:
root #emerge --prune sys-kernel/gentoo-kernel sys-kernel/gentoo-kernel-binTareas posteriores a la instalación/actualización
Los núcleos de distribución pueden reconstruir módulos del núcleo instalados por otros paquetes. Portage proporciona una manera con el indicador USE dist-kernel que forma parte de linux-mod-r1.eclass y controla una dependencia de subslot en virtual/dist-kernel.
Este ajuste USE debe aplicarse globalmente si se utiliza un núcleo de distribución dentro de /etc/portage/make.conf. Al hacerlo, se permitirá que paquetes como sys-fs/zfs y x11-drivers/nvidia-drivers se reconstruyan automáticamente para un núcleo recién actualizado y, si fuera el caso, se volverá a generar el initramfs también.
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-rebuildSi 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
Instalar las fuentes del núcleo
Esta sección solo es relevante cuando se usa lo siguiente genkernel (híbrido) o configuración manual de la gestión del núcleo.
El uso de sys-kernel/installkernel no es estrictamente obligatorio, pero sí muy recomendable. Cuando se instale este paquete, el proceso de instalación del núcleo se delegará a installkernel. Esto permite instalar varias versiones diferentes del núcleo simultaneamente, así como administrar y automatizar varias tareas relacionadas con la instalación del núcleo que se describen después en el manual. Instálalo ahora con:
root #emerge --ask sys-kernel/installkernelAl instalar y compilar el núcleo para sistemas basados en amd64, 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
Introducción
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.
La configuración manual del núcleo se considera comúnmente como uno de los procedimientos más difíciles que debe realizar un administrador de sistemas. Nada es menos cierto: después de configurar algunos núcleos, ¡nadie recuerda que fuera difícil!
Sin embargo, 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 las fuentes del núcleo y ejecute make menuconfig. Esto generará una pantalla de configuración basada en menús.
root #cd /usr/src/linux
root #make menuconfig
La 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 esenciales
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 --->
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
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.
Habilitar 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 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 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 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 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 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.Architecture specific kernel configurations
Placeholder for architecture-specific kernel build information
Compiling and installing
Placeholder for instructions for building and installing the kernel sources
Alternativa: Genkernel
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.
Genkernel solo debe ser considerado por usuarios que tengan una necesidad requerida que solo Genkernel puede satisfacer, de lo contrario se recomienda usar el núcleo de distribución o compilar manualmente el suyo propio, ya que hará que el mantenimiento de un sistema Gentoo sea mucho más simple. 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 un usuario no obtendrá el mismo nivel de automatización que brindan los otros métodos, como que las imágenes unificadas del núcleo se deban crear manualmente al usar Genkernel.
Genkernel proporciona un archivo de configuración del núcleo genérico y compilará el núcleo y un initramfs, luego instalará los binarios resultantes en las ubicaciones apropiadas. Esto da como resultado un soporte de hardware mínimo y genérico para el primer arranque del sistema y permite un control de actualización adicional y personalización de la configuración del núcleo en el futuro.
Queda avisado: si bien el uso de genkernel para mantener el núcleo brinda a los administradores del sistema un mayor control de actualización sobre el núcleo del sistema, initramfs y otras opciones, "requerirán" un compromiso de tiempo y esfuerzo para materializar las futuras actualizaciones del núcleo a medida que se lanzan nuevas fuentes. Aquellos que busquen un enfoque de no intervención para el mantenimiento del núcleo deberían usar un núcleo de distribución.
Para mayor claridad, es un "concepto erróneo" creer que genkernel genera automáticamente una configuración del núcleo "personalizada" para el hardware en el que se ejecuta; utiliza una configuración del núcleo determinada que admite la mayoría del hardware genérico y maneja automáticamente los comandos make necesarios para ensamblar e instalar el núcleo, los módulos asociados y el archivo initramfs.
Grupo de licencias de software binario redistribuible
Si el paquete de firmware de linux se instaló previamente, salte a la sección instalación.
Como requisito previo, debido a que el valor USE firwmare está habilitado de forma predeterminada para el paquete sys-kernel/genkernel, el administrador de paquetes también intentará instalar el paquete sys-kernel/linux-firmware. Las licencias de software binario redistribuible deben aceptarse antes de que se instale el linux-firmware.
Este grupo de licencias se puede aceptar de forma global para cualquier paquete agregando @BINARY-REDISTRIBUTABLE como un valor ACCEPT_LICENSE en el archivo /etc/portage/make. conf. Se puede aceptar exclusivamente para el paquete de linux-firmware agregando una inclusión específica a través de un archivo /etc/portage/package.license/linux-firmware.
Si es necesario, revise los métodos para aceptar licencias de software disponibles en el capítulo Instalando el sistema base del manual, luego realice algunos cambios para las licencias de software aceptables.
Si no sabe qué decidir sobre este tema, lo siguiente funcionará:
root #mkdir /etc/portage/package.license/etc/portage/package.license/linux-firmwareAceptar licencias de binarios redistribuíbles para el paquete linux-firmwaresys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
Instalación
Además de las explicaciones y los requisitos previos, instale el paquete sys-kernel/genkernel:
root #emerge --ask sys-kernel/genkernelGeneración
Compile las fuentes del núcleo ejecutando genkernel all. Sin embargo, tenga en cuenta que genkernel compila un núcleo que admite una amplia gama de hardware para diferentes arquitecturas de computadoras, por lo que esta compilación puede tardar bastante en finalizar.
Si la partición/volumen raíz usa un sistema de archivos que no sea ext4 o XFS, puede ser necesario configurar manualmente el núcleo usando genkernel --menuconfig all para agregar soporte integrado en el núcleo para el sistema de archivos en particular (es decir, no construir el soporte al sistema de archivos como un módulo).
Los usuarios de LVM2 deben añadir
--lvm como argumento a la siguiente orden genkernel.root #genkernel --mountboot --install allUna vez finalice genkernel, se generarán e instalarán un núcleo y un sistema de archivos de inicio en ram (initramfs) en el directorio /boot. Los módulos asociados se instalarán en el directorio /lib/modules. El initramfs se iniciará inmediatamente después de cargar el núcleo para realizar la detección automática de hardware (al igual que en los entornos de imagen de disco vivo).
root #ls /boot/vmlinu* /boot/initramfs*
root #ls /lib/modules
Instalación del núcleo
Installkernel
Installkernel se puede utilizar para automatizar la instalación del núcleo, la generación de initramfs, la generación de imagen del núcleo unificada y/o la configuración del gestor de arranque, entre otras cosas. sys-kernel/installkernel implementa dos caminos para lograr esto: el installkernel tradicional que se origina en Debian y el kernel-install de systemd. Cuál elegir depende, entre otras cosas, del gestor de arranque del sistema. De forma predeterminada, el kernel-install de systemd se usa en los perfiles de systemd, mientras que el installkernel tradicional es el predeterminado para otros perfiles.
Si no está seguro, siga la subsección "Diseño tradicional" a continuación.
systemd-boot
Cuando se utiliza systemd-boot (anteriormente gummiboot) como gestor de arranque, se debe utilizar 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 luego instale el paquete relevante 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-utilsEn sistemas systemd:
/etc/portage/package.use/systemdsys-apps/systemd boot
sys-kernel/installkernel systemd-boot
root #emerge --ask sys-apps/systemdGRUB
Los usuarios de GRUB pueden usar kernel-install de systemd o el tradicional installkernel de Debian. El indicador USE systemd cambia entre estas implementaciones. Para ejecutar grub-mkconfig automáticamente al instalar el kernel, habilite el indicador USE grub.
/etc/portage/package.use/installkernelsys-kernel/installkernel grub
root #emerge --ask sys-kernel/installkernelDiseño tradicional, otros gestores de arranque (por ejemplo, lilo, etc.)
En el diseño tradicional (por ejemplo, LILO, etc.) /boot se utiliza de forma predeterminada si los indicadores grub, systemd-boot y uki no están habilitadas. No se requiere ninguna acción adicional.
Construir un initramfs
En ciertos casos es necesario construir un initramfs - un initial ram-based file system. La razón más habitual es cuando ubicaciones importantes del sistema de archivos (como /usr/ o /var/) están en particiones separadas. Con initramfs, estas particiones se pueden montar utilizando las herramientas disponibles dentro de initramfs. La configuración predeterminada del Project:Distribution Kernel requiere un initramfs.
Sin initramfs, existe riesgo de que el sistema no arranque correctamente ya que las herramientas responsables de montar los sistemas de archivos requieren información que reside en los sistemas de archivos desmontados. Un initramfs extraerá los archivos necesarios en un archivo que se utiliza inmediatamente después de que se inicie el núcleo, pero antes de que el control se entregue a la herramienta init. Los scripts en initramfs se asegurarán de que las particiones estén montadas correctamente antes de que el sistema continúe arrancando.
Si se usa genkernel, se debe usar tanto para construir el núcleo como el initramfs. Cuando se utiliza genkernel solo para generar un initramfs, es fundamental pasar
--kernel-config=/ruta/a/kernel.config a genkernel o el initramfs generado puede que no funcione con un núcleo creado manualmente. Tenga en cuenta que los núcleos creados manualmente van más allá del alcance del soporte del manual. Consulte el artículo configuración del núcleo para obtener más información.Installkernel puede generar automáticamente un initramfs al instalar el núcleo si el indicador USE dracut está habilitado:
/etc/portage/package.use/installkernelsys-kernel/installkernel dracut
Alternativamente, se puede llamar a dracut manualmente para generar un archivo initramfs. Instale sys-kernel/dracut primero, luego haga que genere un initramfs:
root #emerge --ask sys-kernel/dracutroot #dracut --kver=6.6.21-gentooEl initramfs se almacenará en /boot/. El archivo resultante se puede encontrar simplemente enumerando los archivos que comienzan con initramfs:
root #ls /boot/initramfs*Opcional: Creación de una 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 cargador de código auxiliar; actualmente el único disponible es systemd-stub. Para habilitarlo:
En sistemas systemd:
/etc/portage/package.use/systemdsys-apps/systemd boot
En sistemas OpenRC:
/etc/portage/package.use/systemd-utilssys-apps/systemd-utils boot kernel-install
Installkernel puede generar automáticamente una imagen de núcleo unificada usando dracut o ukify, habilitando el indicador respectivo. El indicador USE uki también debe estar habilitado para instalar la imagen del núcleo unificada generada en el directorio $ESP/EFI/Linux en la partición del sistema EFI (ESP).
Para dracut:
/etc/portage/package.use/installkernelsys-kernel/installkernel dracut uki
/etc/dracut.confuefi="yes"
kernel_cmdline="argumentos-para-la-linea-comandos-del-núcleo"
Para ukify:
/etc/portage/package.use/installkernelsys-apps/systemd ukify # Para sistemas systemd
sys-apps/systemd-utils ukify # Para sistemas OpenRC
sys-kernel/installkernel dracut ukify uki
/etc/kernel/cmdlineargumentos-para-la-linea-comandos-del-núcleo
Tenga 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.
Imagen del Núcleo Unificada Genérica
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/generic-ukisys-kernel/gentoo-kernel-bin generic-uki
sys-kernel/installkernel -dracut -ukify uki
Arranque Seguro
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.confuefi="yes"
kernel_cmdline="argumentos-para-la-linea-comandos-del-núcleo"
uefi_secureboot_key="/ruta/a/kernel_key.pem"
uefi_secureboot_cert="/ruta/a/kernel_key.pem"
Para ukify:
/etc/kernel/uki.conf[UKI]
SecureBootPrivateKey=/ruta/a/kernel_key.pem
SecureBootCertificate=/ruta/a/kernel_key.pem
Reconstrucción de módulos del núcleo externos
Los módulos externos del núcleo instalados por otros paquetes a través de linux-mod-r1.eclass deben reconstruirse para cada nueva versión del núcleo. Cuando se utilizan los núcleos de distribución, esto se puede automatizar habilitando el indicador dist-kernel globalmente.
/etc/portage/package.use/module-rebuild*/* dist-kernel
Los módulos del núcleo externos también se pueden reconstruir manualmente con:
root #emerge --ask @module-rebuildMó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.