La actualización al kernel 7.0 tumbó todos los contenedores LXC de un host Proxmox

El reinicio que convirtió la confianza en pánico

Seguramente conoces el silencio que sigue al reinicio de un servidor. Los ventiladores se calman, vuelve la página de inicio de sesión, el panel empieza a llenarse y durante unos segundos crees que los dioses de las actualizaciones hoy estaban generosos. Entonces notas lo raro: la VM arranca, pero todos los contenedores LXC están muertos. Ni uno solo quiere arrancar.

Por eso esta historia de la actualización al kernel 7.0 tocó una fibra. Un usuario de homelab lanzó la actualización, reinició el host Proxmox y de pronto todos los contenedores daban errores mientras la máquina virtual pasaba como si nada. El problema duele en lo personal porque se supone que los contenedores son la parte ligera, eficiente y sin complicaciones de la pila. Ahí es donde la gente aparca el DNS, los paneles, las herramientas multimedia, la automatización, los gestores de contraseñas, el monitoreo y todos los pequeños servicios que hacen que un homelab esté vivo. Cuando se paran todos a la vez, puede parecer que toda la casa está rota.

La solución resultó ser sorprendentemente sencilla: reinstalar lxc-pve y pve-container y luego reiniciar el host. Es una buena noticia, pero llega cuando ya se te ha caído el alma a los pies. Cuando aparece el error por primera vez no dice: "Tranquilo, con reinstalar un paquete se arregla". Parece que el kernel dio un salto, la capa de contenedores tropezó y ahora estás entre los escombros intentando recordar qué servicios importaban más.

Los LXC viven más cerca del radio de la explosión

Un comentarista soltó una frase que explica por qué este tipo de fallo resulta tan verosímil: los LXC se ejecutan sobre el kernel del host. Ese es el trato. Una VM completa trae su propio kernel invitado y una frontera más sólida frente a las piezas móviles del host, mientras que un contenedor se apoya directamente en el kernel del host y en la fontanería de espacio de usuario que lo rodea. Por eso los contenedores son rápidos y eficientes, y también por eso una actualización a nivel de host puede darles un golpe en plena cara.

Los LXC son utilísimos, pero es verdad que viven más cerca del radio de la explosión cuando el host cambia. Una actualización mayor del kernel hace algo más que subir un número en segundo plano. Puede tocar lo que se espera de los cgroups, los namespaces, AppArmor, el comportamiento de los montajes, los binarios de LXC, las herramientas de contenedores de Proxmox y todo lo que los usuarios no piensan hasta que falla. Así que cuando la VM sigue arrancando y los contenedores no, estás viendo a la arquitectura enseñar los dientes.

Alguien bromeó con que siempre parece que los LXC son los que sufren con las actualizaciones. Es un poco injusto, pero fácil de entender. Para los usuarios de homelab, los LXC suelen acabar siendo el sitio por defecto para meter todo lo pequeño, así que cuando se rompen parece que toda la capa de comodidad se ha venido abajo de golpe. Tu VM puede estar bien, claro, pero la docena de cositas que hacen el día a día más llevadero están ahora atascadas detrás de un mensaje de error y una sensación de hundimiento.

Los logs eran un lío, y los consejos también

La resolución de problemas empezó donde suele empezar, con los logs. Alguien sugirió revisar /var/log/syslog, lo que enseguida se convirtió en un pequeño drama propio porque el sistema no tenía ese archivo. El usuario probó tail -n 50 /var/log/syslog y recibió "No such file or directory". Luego se dio cuenta de que también faltaba /run/pve, y entonces todo parecía menos un problema de un solo contenedor y más que la fontanería de tiempo de ejecución de Proxmox se había torcido.

Ahí el hilo se dividió entre los hábitos de siempre y los valores por defecto modernos. Una persona dijo que sigue instalando rsyslog en todas partes porque es lo primero que mira. Otra le respondió seca que /var/log/syslog desapareció hace tiempo en muchas instalaciones y mandó a la gente hacia journalctl. El consejo más tranquilo y más útil fue ejecutar journalctl -b, journalctl -f o journalctl -xef y luego volver a intentar arrancar el contenedor. Otra persona pidió pct config 101 y pct start 101 --debug, justo el tipo de par de diagnósticos aburridos que hace avanzar las cosas.

Los logs que compartió no tranquilizaban a nadie. Había timeouts del socket del monitor, mensajes de que no se podía obtener el PID del CT 101 y una queja de pvestatd porque no podía crear un archivo temporal de métricas en /run/pve, ya que el directorio no existía. Eso último hace levantar una ceja. Cuando falta el directorio de tiempo de ejecución de Proxmox, puede que los contenedores que no arrancan sean solo el síntoma más visible. Es como culpar al interruptor de la luz cuando medio cuadro eléctrico se está portando raro.

La solución era sencilla, y eso hacía el fallo más extraño

La solución final fue casi irritantemente sencilla: apt install --reinstall lxc-pve pve-container, seguido de un reinicio del host. No hubo que volver a un kernel anterior, no se perdió ningún contenedor, no hubo que reconstruir el nodo entero desde las copias de seguridad ni migrar a medianoche a otra máquina. El usuario reinstaló los paquetes de contenedores, reinició y los LXC muertos volvieron.

Una solución así satisface e inquieta a la vez. Satisface porque el usuario salió limpio, e inquieta porque sugiere que algo en la ruta de actualización dejó componentes importantes de los contenedores en mal estado. Quizá un paquete no se instaló bien, o un paso posterior a la instalación no llegó a ejecutarse. Quizá la actualización desde la interfaz web ocultó un aviso que el usuario habría visto en una terminal, o las piezas de tiempo de ejecución necesitaban un buen refresco y no lo tuvieron hasta que la reinstalación lo forzó. El hilo no demuestra una causa única y ordenada, pero da a los administradores un patrón útil: si llega el kernel 7.0 y los LXC se niegan a arrancar mientras las VMs van bien, no des por hecho de inmediato que tus contenedores están perdidos.

Aquí hay una lección más amplia. Algunos de los fallos de infraestructura que más miedo dan resultan ser problemas aburridos del estado de los paquetes. Parecen corrupción profunda o un bug catastrófico porque ocurren en la base de tu pila. Un servicio roto molesta, mientras que una capa de contenedores rota parece una crisis existencial. La solución puede ser un solo comando, pero aun así necesitas encontrar la calma para probarlo.

Importa cómo se hizo la actualización desde la interfaz web

Hubo un detalle que se coló casi sin que nadie lo viera: el usuario actualizó desde la interfaz web. Eso no está mal en sí mismo. Proxmox ofrece una interfaz gráfica por algo, y mucha gente la prefiere. Aun así, las actualizaciones mayores tienen la costumbre de hacer que los puristas de la terminal suenen menos pesados. En una shell ves en tiempo real las preguntas, los conflictos de paquetes, los paquetes retenidos, los avisos y los mensajes posteriores a la instalación. Una interfaz gráfica puede hacer que el proceso parezca más limpio, y a veces más limpio significa menos evidente.

Nadie tiene que temer a la interfaz gráfica, pero cuanto mayor es la actualización, más visibilidad quieres. Quienes preguntaban cómo se había hecho la actualización intentaban averiguar si algo se había saltado, ocultado, interrumpido o quedado a medio actualizar. Las actualizaciones del kernel, los paquetes de Proxmox, el espacio de usuario de LXC, las herramientas de gestión de contenedores y los directorios de tiempo de ejecución tienen que encajar. Cuando no encajan, el panel te dice que los contenedores no arrancan, pero no siempre te dice qué capa se olvidó de ponerse los zapatos.

Aquí es donde los administradores con experiencia se vuelven un poco supersticiosos, de una forma útil. Actualizan desde una consola o una sesión SSH dentro de tmux o screen, leen la salida de apt y se aseguran de que no haya paquetes retenidos. Revisan pveversion -v. Reinician cuando ellos deciden y no porque el sistema les haya obligado, y prueban un contenedor que no sea crítico antes de celebrar. Nada de esto es glamuroso, y poder dormir tranquilo tampoco lo es.

Los tres estados de ánimo de la comunidad: diagnosticar, bromear y torcer el gesto

La conversación fue por tres carriles emocionales. El primero era práctico: ejecuta comandos de depuración, revisa journalctl, inspecciona la configuración del contenedor, encuentra el error real. Es la mejor cara de las comunidades técnicas. Alguien llega estresado y unos desconocidos empiezan a acotar el problema sin necesidad de una charla TED.

El segundo era humor cínico. "Los LXC siempre sufren con las actualizaciones" tiene forma de chiste y peso de experiencia. Otra persona actualizó después de comentar y se topó con un problema de red distinto dentro de una VM. Al principio todo parecía bien, luego la autenticación de servicios internos se rompió en un bucle raro. Un reinicio lo arregló y el problema volvió una hora después. Esa historia secundaria retrata bien la ventana real después de una actualización: el sistema arranca, pero no has terminado. Las rarezas pueden esperar. Pueden aparecer cuando los servicios empiezan a hablar entre sí, cuando caducan las cachés, cuando se ejecutan las tareas programadas o cuando la pila de red recibe tráfico suficiente como para dejar ver la grieta.

El tercer estado de ánimo era un reconocimiento silencioso. Cualquiera que lleve suficiente tiempo con un homelab conoce la sensación. Actualizas porque las actualizaciones son buenas y reinicias porque cambió el kernel, y entonces algo que habías olvidado que era crítico deja de funcionar. De repente el patio de juegos se ha convertido en infraestructura. Tiene usuarios, aunque los usuarios sean solo tú, tu familia y las luces de la casa inteligente, que ahora parecen juzgarte de una forma extraña.

Los contenedores son cómodos hasta que se convierten en el grafo de dependencias

Lo traicionero de los LXC en Proxmox es que se multiplican porque son fáciles. Levantas uno para el DNS, luego uno para el proxy inverso, otro para monitoreo, otro para herramientas de descarga, otro para una base de datos y otro para un panel, más uno para algo que probaste hace seis meses y del que ahora, no se sabe cómo, dependes. En poco tiempo la lista de contenedores deja de ser una lista de aplicaciones y se convierte en un grafo de dependencias con una interfaz amable.

Así que cuando todos los LXC fallan tras una actualización del kernel, el daño no es igual para todos los usuarios. Para una persona puede significar que la pila multimedia está caída. Para otra, el DNS local ha desaparecido y media red parece embrujada. Para alguien más es la autenticación, la automatización o la orquestación de las copias de seguridad. Por eso la respuesta a "reinstala los paquetes y ya" puede ser gratitud y fastidio a la vez. El comando es sencillo, pero lo que está en juego alrededor no lo es.

También hay una cuestión de identidad. Los usuarios de homelab suelen aprender haciendo, y Proxmox es popular porque hace que la virtualización seria parezca accesible. Las actualizaciones del kernel dejan ver la realidad de nivel profesional bajo esa superficie amable. Un hipervisor no es una tienda de aplicaciones, y los contenedores no son cajitas mágicas. El host, el estado de los paquetes y los logs importan. Y sí, a veces lo mejor es dejar de hacer clic por la interfaz gráfica, abrir una shell y preguntarle al sistema qué se ha roto de verdad.

Conclusión: no temas al kernel 7.0, pero no lo trates como un cambio de tema visual

Este incidente no demuestra que el kernel 7.0 sea un desastre. Ni siquiera demuestra que haya un bug generalizado de LXC. El usuario resolvió el problema reinstalando los paquetes de LXC y contenedores de Proxmox y reiniciando, mientras que los demás ofrecieron sobre todo pasos de diagnóstico normales. Aun así, es justo el tipo de publicación que se te queda en la cabeza antes de una actualización mayor, porque era muy creíble.

El camino sensato es aburrido. Antes de actualizar, haz copias de seguridad y comprueba que puedes restaurar los contenedores que te importan. Ejecuta la actualización en un sitio donde puedas verla. Usa journalctl en lugar de perseguir viejas suposiciones sobre syslog. Tras el reinicio, prueba las VMs y los LXC por separado. Si los contenedores fallan mientras las VMs funcionan, mira pct start <id> --debug, journalctl -b, el estado de los paquetes y si tiene sentido reinstalar lxc-pve y pve-container. No aporrees botones, no des por hecho que todos tus contenedores están muertos para siempre y no asumas que la interfaz gráfica te contó toda la historia.

Los LXC son potentes porque comparten el host, y por eso mismo los cambios en el host importan tanto. Puede que el kernel 7.0 esté bien, que Proxmox esté bien y que tus contenedores estén a una reinstalación de estar bien. Pero en el momento que sigue al reinicio, cuando la VM arranca y todos los LXC se niegan, ese "bien" puede parecer muy lejano. La infraestructura del homelab te enseña a base de pequeños desastres, y a veces la lección cabe en un solo comando.