# ¿Cómo compilar tu kernel Linux sin romper el arranque? > Compilar tu kernel Linux recorta superficie de ataque y acelera el arranque. Una herramienta lo hace sin root y sin dejarte sin sistema si falla. > Por José Maldonado · Tecnología · 2026-11-09 Compilar el propio kernel ha pasado de rito de iniciación a decisión con números detrás. Un config genérico de distribución arrastra miles de controladores que tu máquina nunca va a cargar, y cada uno de ellos es superficie que no usas, pero que está ahí. El proyecto [personal-kernel-builder](https://github.com/yukiteruamano/personal-kernel-builder) lleva esa idea al extremo práctico: parte de un config reducido a un portátil concreto y pasa de unas 3.450 opciones de módulo a unas 440, una reducción de caso 90%, sin perder funcionalidad. Lo interesante no es el recorte, sino cómo evita los dos accidentes clásicos de esta tarea. El primero es compilar como root, que convierte cualquier error en un problema del sistema entero. El segundo es quedarse sin arranque por haber reemplazado el kernel que estabas usando. La herramienta resuelve ambos con una separación estricta de permisos y con una negativa explícita a sobrescribir el kernel en ejecución. La contrapartida existe y conviene saberla antes de empezar: este método está pensado para Slackware, y su diseño de firma de módulos cierra la puerta a cualquier controlador que no venga del árbol del kernel. Si dependes del driver propietario de NVIDIA o de módulos que se recompilan solos tras cada actualización, esta guía te sirve para entender el método, no para adoptar la herramienta tal cual. ## ¿Qué ganas y qué pierdes al compilar tu propio kernel? La ganancia inmediata es superficie de ataque. Un kernel que solo conoce tu chipset, tu disco y tu tarjeta de red no puede cargar un driver para hardware que no tienes, lo que reduce las vulnerabilidades que te afectan. La segunda ganancia es tiempo de arranque y memoria: menos módulos que sondear significa menos trabajo en el camino crítico. Ahí está la parte que decide una adopción, una máquina concreta tiene un conjunto de hardware concreto y todo lo demás sobra. El trabajo real consiste en distinguir qué necesita tu equipo para llegar al escritorio de lo que nunca va a usar. El coste también es concreto. Cada actualización de seguridad del kernel deja de llegar sola y pasa a depender de que tú recompiles. Y la reproducibilidad se rompe si no guardas el config. Después de todo, dentro de seis meses no recordarás por qué marcaste una opción y no otra, debes mantener todo a mano. ![Un vistazo al proyecto personal-kernel-builder](https://content.observatorioblockchain.com/wp-content/uploads/2026/11/persona-kernel-builder-github.webp) *Un vistazo al proyecto personal-kernel-builder* La herramienta ataca ese segundo problema con un archivo de configuración versionado por máquina y copias de seguridad con retención, siete por defecto. Es la parte menos vistosa del proyecto y la que decide si vuelves a compilar dentro de un año o abandonas a la tercera semana. ## ¿Merece compilar tu kernel en 2026? Depende de qué estés comprando. Si buscas rendimiento medible en escritorio, la respuesta honesta es que el salto suele ser pequeño y difícil de atribuir, porque el trabajo pesado lo hacen los drivers y el planificador, no la lista de módulos. Si buscas control, reducción de superficie y entender qué corre en tu equipo, el cálculo cambia. En ese caso, compilar el kernel te permite ganar un nivel de seguridad enorme. Por ejemplo, el fallo de MPTCP, se puede evitar simplemente si el módulo no es compilado. Un solo cambio, y te estás protegiendo de uno de los bugs remotos más peligrosos de Linux. Hay un tercer escenario donde el interés crece: el goteo de fallos en el kernel y la dificultad de absorberlos a tiempo. La propia avalancha de CVE en el kernel se ha convertido en un tema de gestión, como muestra el [recuento de vulnerabilidades que el kernel no da abasto a parchear](https://observatorioblockchain.com/ciberseguridad/kernel-linux-avalancha-cve-triaje-ia/). Quien compila su kernel decide qué versión corre y cuándo actualiza, y eso es una decisión de seguridad además de una decisión técnica. ## ¿Qué necesitas antes de empezar? La herramienta se instala como paquete de Slackware, aunque la puedes usar en cualquier otra distro, y trabaja sobre el árbol de fuentes que esa distribución ya mantiene en el sistema. Antes de tocar nada, comprueba que tienes espacio, que sabes qué kernel está arrancando ahora y que conservas una entrada de GRUB con la que volver. La tabla siguiente resume el mínimo con el que se puede empezar. Requisito Detalle Por qué importa Distribución base Slackware con \`kernel-source\` instalado La construcción parte de \`/usr/src/linux\` Usuario constructor Una cuenta sin privilegios, definida con \`–builder\` Es quien compila y posee el config Acceso root Solo para \`init\`, \`install\`, \`uninstall\` y \`adopt\` Instalar y retirar entradas de arranque Espacio en \`/tmp\` Suficiente para una copia completa de las fuentes El build ocurre en una copia privada Kernel de reserva Una entrada de GRUB que funcione La red de seguridad si el nuevo no arranca Versión de WSL o initrd \`USE\_INITRD=no\` por defecto, o \`–initrd\` Cambia qué drivers van compilados dentro El detalle del usuario constructor no es cosmético. Todo el trabajo pesado ocurre en una copia de las fuentes dentro de \`/tmp/personal-kernel-builder-\`, un directorio que un reinicio borra. Esa copia es del usuario, no de root, y ahí está la primera mitad de la protección. ## El método en cinco pasos El orden importa más que la prisa, y hay un paso que la herramienta se niega a hacer por ti. Esta secuencia sigue el flujo documentado por el proyecto, con la instalación del paquete ya hecha. 1. Como root, inicializa el perfil con un nombre y el usuario que va a construir: \`personal-kernel-builder init –name nombre –builder usuario –config seed/config-maquina\`. Ese \`–config\` puede ser el config de ejemplo del repositorio o uno propio. 2. Como usuario constructor, adapta el config a la versión de fuentes instalada con \`personal-kernel-builder config olddefconfig\`. Así las opciones nuevas de la versión quedan resueltas sin arrastrar las de un kernel anterior. 3. Ejecuta \`personal-kernel-builder check\` y luego \`build\`, que compila, firma los módulos y sustituye el sufijo de versión por el nombre que elegiste. Aquí es donde aparece el resultado en forma de kernel propio. 4. Como root y antes de reiniciar, lanza \`install\`, que solo copia el build ya preparado y fija la entrada por defecto de GRUB. Root no ejecuta la compilación en ningún momento. 5. Arranca el kernel nuevo y ejecuta \`verify\`. Si la comprobación sale bien y el sistema se comporta, retira el kernel antiguo con \`uninstall\` para no acumular entradas. El punto cuatro es el que más gana con la separación de permisos. Instalar es un acto de root, pero compilar no lo es, y el proyecto lo mantiene así de forma deliberada: root nunca ejecuta \`make\` sobre el árbol de un usuario. ## ¿Cómo recortar el config a tu hardware? Recortar no consiste en apagar cosas hasta que arranque. Consiste en saber qué necesita tu máquina para llegar al escritorio y dejar eso dentro del kernel, en lugar de confiar en que se cargue a tiempo. El proyecto formaliza esa distinción con dos listas en su archivo de configuración: las opciones sin las cuales el equipo no arranca y los módulos que la verificación debe encontrar después. El ejemplo del ThinkPad ilustra el criterio. Para el disco y el sistema de archivos, las opciones van compiladas dentro (\`BLK\_DEV\_NVME=y\`, \`XFS\_FS=y\`), no como módulo. Para la gráfica y la red, el módulo basta. Y el soporte de portátil entra por vías concretas: \`THINKPAD\_ACPI\`, \`AMD\_PMC\`, \`X86\_AMD\_PSTATE=y\` y el conjunto \`TYPEC\_UCSI\` y \`UCSI\_ACPI\` para el USB-C. La lista de verificaciones tiene un detalle que ahorra diagnósticos falsos: \`amd\_pmc\` solo carga cuando el estado de suspensión de la BIOS está configurado como «Windows and Linux», es decir, s0ix. Si tu equipo usa S3, la verificación lo omite en lugar de marcar un fallo que no existe. Otro tanto con la batería, que se comprueba solo si la máquina la tiene. Para partir de tu propia configuración y no de la del repositorio, la herramienta ofrece un \`diff\` contra el config que \`/boot/config\` está apuntando. Es la forma más rápida de ver qué has cambiado y de reconstruir el razonamiento meses después. ## Firmando los módulos Aquí está la decisión de diseño que más consecuencias tiene. Cada build genera su propia clave, firma los módulos y borra la clave privada al terminar. Con la firma obligatoria activada, el kernel solo acepta módulos firmados con esa clave, y como la clave ya no existe, nadie más puede firmar nada para ese kernel. El beneficio es que un módulo ajeno no puede colarse en tu kernel. El precio es que tampoco puede entrar el que sí querías: los controladores fuera del árbol quedan fuera por definición. Si tu equipo necesita uno de ellos, este método no es para ti, y es mejor descubrirlo antes de compilar que después de reiniciar. La misma decisión explica la negativa a reemplazar el kernel que está en ejecución. Instalar un build nuevo encima del que está corriendo dejaría al sistema sin poder cargar ningún módulo hasta el reinicio, porque la clave cambió. La herramienta rechaza la operación y te obliga a arrancar desde otro kernel primero, o a forzar el reemplazo y reiniciar de inmediato. ## Arrancar sin initrd, la parte que rompe arranques Con el valor por defecto, el kernel arranca sin imagen intermedia. Eso significa que los controladores del disco raíz y del sistema de archivos tienen que estar compilados dentro, y que GRUB no puede buscar el disco por identificador. La herramienta resuelve lo segundo con una opción de instalación que desactiva el uso de UUID, pero lo primero es responsabilidad de tu config. Si prefieres la vía tradicional, la instalación con \`–initrd\` genera la imagen intermedia para el tipo de sistema de archivos de la raíz. Sigue siendo más frágil que el arranque directo cuando cambias hardware, porque la imagen hay que regenerarla, pero es la opción conservadora si tu equipo tiene particularidades. ### ¿Y si el kernel nuevo no arranca? La respuesta corta es que tengas otra entrada de GRUB antes de empezar, y la herramienta está construida asumiendo que la tienes. El kernel de la distribución sigue en el menú, y la instalación añade el nuevo sin eliminar el anterior. Retirar el viejo es un acto separado y posterior, que solo deberías ejecutar cuando el nuevo lleve un tiempo funcionando. Hay un segundo escenario más silencioso: arranca pero algo no funciona. Suele ser un módulo que falta o una opción que debería ir dentro del kernel. La verificación del proyecto y el diff contra el config de referencia te dicen qué cambió. ## Lo que este método no te da y por qué importa Conviene decirlo sin rodeos: esto no es una guía universal de compilación de kernels. La herramienta es de Slackware y su empaquetado lo refleja, así que quien use Arch, Debian o Fedora aplicará el método con su propio utillaje y sin estas comodidades. Lo trasladable son tres ideas: compilar sin root, no sobrescribir el kernel en ejecución y fijar por escrito qué opciones necesita tu máquina. Ese último punto sobrevive al cambio de distribución. Un config comentado y versionado vale más que un script, porque explica decisiones que en un año nadie recuerda. Quien haya leído el [repaso de lo que entró en Linux 7.3 para gráficas y planificación](https://observatorioblockchain.com/tecnologia/igalia-linux-7-3-v3d-sched-ext-amdgpu/) sabe que el kernel cambia lo bastante cada pocos meses como para que la memoria falle. Y quien haya seguido el [caso del módulo que desbloqueaba núcleos tensor en una RTX 4090](https://observatorioblockchain.com/tecnologia/rtx-4090-tensor-cores-modulo-kernel/) entiende el otro extremo del problema: un módulo fuera del árbol puede darte algo que el kernel oficial no ofrece, y este método lo prohíbe por diseño. No hay una respuesta buena para todos, solo una decisión informada sobre qué prefieres controlar y qué prefieres delegar.