Cómo un corte de luz y un initramfs roto tumbaron mi servidor Proxmox

Se supone que los cortes de luz deberían ser aburridos. Se apagan las luces, vuelve la corriente y quizá el reloj del microondas parpadea a las 12:00 como si estuviéramos en 1998 otra vez. En un homelab, sin embargo, pueden volverse mucho más dramáticos, como cuando tu servidor arranca con una pantalla negra y un mensaje de error críptico que suena demasiado tranquilo para la gravedad de la situación.

Exactamente así empezó esta semana.

Tras un breve corte de electricidad en casa, mi servidor Proxmox volvió a la vida… a medias. La BIOS cargó, GRUB apareció en pantalla y el kernel comenzó a iniciar. De repente todo se detuvo con un mensaje que básicamente decía: «root filesystem not mounted». No había terminal, ni pantalla de inicio de sesión, ni una consola de recuperación amigable: solo un sistema que se negaba rotundamente a dar un paso más.

Si utilizas Proxmox en casa, esta historia puede resultarte incómodamente familiar.

La falsa tranquilidad del «ayer funcionaba»

Uno de los aspectos más desesperantes de los fallos de arranque es lo injustos que parecen. Nada había cambiado: ni actualizaciones, ni discos nuevos, ni retoques nocturnos. El servidor se apagó porque se fue la luz, y ahora no quería volver a arrancar.

Como es natural, mi primera reacción fue la negación. Reinicié otra vez y obtuve el mismo error. Probé con un kernel anterior desde el menú de GRUB, con idéntico resultado. En ese punto empiezas a negociar con la máquina. Quizá solo necesite un reinicio más, o tal vez el problema se arregle solo.

No lo hará. Cuando Linux te dice que no puede montar el sistema de archivos raíz, no está exagerando. Falta algo verdaderamente importante, está roto o resulta ilegible, y una vez que llegas a ese callejón sin salida, no hay atajo elegante posible sin arremangarse.

Errores de arranque que no dicen casi nada

«Root fs not mounted» suena explícito hasta que comprendes la cantidad de cosas distintas que puede significar.

• ¿Ha muerto el disco?
• ¿Está corrupto el sistema de archivos?
• ¿Ha cambiado el UUID?
• ¿Le faltan drivers al kernel?
• ¿Está dañado initramfs?

Al sistema le da igual cuál de ellos sea y no te ayudará a acotarlo. Esa labor te toca a ti.

El primer paso tangible consistió en arrancar desde un entorno live. Vale cualquier ISO live de Linux, pero el propio instalador de Proxmox sirve perfectamente para tareas de rescate y, una vez dentro, por fin puedes comprobar lo que ve la máquina.

Los discos estaban ahí y las particiones se veían normales. Los pools de ZFS se importaron de forma limpia y no había corrupción evidente en el sistema de archivos, lo que descartaba los peores temores. Entonces, ¿por qué el sistema era incapaz de arrancar?

initramfs: un archivo pequeño con una enorme responsabilidad

Si nunca antes has tenido que pensar en initramfs, enhorabuena. Significa que ha venido haciendo su trabajo sin rechistar.

initramfs es un sistema de archivos minúsculo y temporal que se carga en memoria durante los primeros compases del arranque. Su único cometido es cargar los drivers y módulos que el kernel necesita para localizar y montar tu verdadero sistema de archivos raíz. Si le falta un controlador de almacenamiento, un módulo del sistema de archivos o cualquier otra pieza crítica, el kernel se topa con un muro y se rinde.

Un corte de energía durante una actualización es una de las formas más fáciles de corromperlo. Y una vez que initramfs se rompe, los síntomas son exactamente los de un sistema inservible, aunque tus discos estén en perfecto estado.

La solución que «debería ser fácil» y no lo fue

En teoría, el arreglo es simple: regenerar initramfs. Desde un chroot o un terminal de rescate ejecutas el comando habitual para reconstruirlo para los kernels instalados y, en la mayoría de los casos, la historia termina ahí.

Esta vez no fue así. Cada intento de reconstruir initramfs fallaba, y no precisamente con un error aclaratorio. Solo obtenía unas pocas líneas avisando de que algo iba mal, seguidas de una interrupción tajante. A primera vista parecía otra dependencia rota o un paquete instalado a medias.

Aquí fue donde las cosas se pusieron interesantes.

El paquete que olvidaste que habías instalado

Meses atrás había pinchado de forma temporal una vieja GPU de NVIDIA en el servidor. Fue una prueba rápida, nada serio. Instalé un paquete auxiliar para facilitar la virtualización de GPU, hice mis comprobaciones y con el tiempo retiré la tarjeta.

Lo que al parecer no eliminé fue todo lo demás. Ese paquete auxiliar vinculado a NVIDIA se había quedado olvidado en el sistema y ahora, durante la generación de initramfs, fallaba estrepitosamente porque el hardware que esperaba simplemente ya no estaba allí.

En condiciones normales jamás te habrías dado cuenta. El sistema arrancaba bien, las actualizaciones pasaban y la vida seguía su curso, justo hasta que se cortó la corriente.

Cuando los viejos experimentos vuelven para perseguirte

Esta es la parte que más escuece. La avería no procedía de ninguna acción reciente, como una actualización arriesgada o un cambio de configuración precipitado. Venía de la deuda técnica, esa de la que te olvidas porque nunca se queja.

A initramfs le da igual la antigüedad de un paquete. Si ese software está enganchado al proceso de arranque y falla, todo tu sistema se va al suelo con él.

En cuanto se desinstalaron por completo los paquetes de NVIDIA, incluidos todos los auxiliares y dependencias junto a los principales, la reconstrucción por fin salió adelante. initramfs se regeneró sin contratiempos y los kernels se compilaron sin errores. En el siguiente reinicio, el sistema volvió a la vida como si jamás hubiera pasado nada.

Por qué los apagados limpios casi nunca provocan esto

Conviene decir con claridad que un reinicio o apagado ordenado casi nunca provoca este tipo de problemas. Los sistemas de archivos modernos son excelentes protegiéndose a sí mismos, y las actualizaciones de initramfs suelen ser atómicas.

A un corte de luz, sin embargo, el momento exacto no le importa. Si el sistema se encuentra en pleno proceso de actualizar kernels, reconstruir initramfs o modificar archivos del gestor de arranque cuando cae la energía, estás jugando a la ruleta rusa. Casi siempre sale bien, pero a veces no.

Lecciones aprendidas a las malas

Tras la tormenta, quedan varias conclusiones claras.

Primero, initramfs merece mucho más respeto del que recibe. Es pequeño, discreto y totalmente indispensable, y cuando falla, el sistema no sigue cojeando: se detiene por completo.

Segundo, los paquetes antiguos importan, en particular aquellos que se integran en partes de bajo nivel del sistema. Si has terminado con un experimento, limpia a fondo. Tu yo del futuro te lo agradecerá.

Tercero, la recuperación suele ser posible. Los fallos de arranque parecen catastróficos, pero casi siempre los datos están intactos y el sistema operativo solo necesita un empujón para salir del atasco.

Y finalmente: sí, compra un SAI. Un breve corte de luz no debería arruinarte la semana, pero sin una batería de respaldo puede hacerlo perfectamente. Combinar un SAI con una señalización de apagado adecuada es una de esas inversiones aburridas que solo resultan emocionantes el día que te salvan la vida.

Los fallos silenciosos son los que más enseñan

Hay algo especialmente frustrante en una avería que no avisa hasta que todo deja de funcionar. No recibes advertencias ni operas en modo degradado: solo te queda un servidor completamente inerte tras un pestañeo de las luces.

Esos son también los fallos que más te enseñan sobre el funcionamiento real de tu sistema: las fases iniciales del arranque y los pequeños archivos que sostienen todo el conjunto, lejos de las interfaces vistosas.

initramfs me arruinó la semana, desde luego, pero también se ganó un puesto fijo en mi lista mental de comprobación. La próxima vez que se vaya la luz, al menos sabré exactamente a dónde mirar primero.