Algo se rompió tras la actualización: "después" y "por culpa de" no son lo mismo
Un reinicio es la primera prueba honesta de todo lo hecho desde el reinicio anterior. Parte de lo que se rompe no lo trajo la actualización, ya estaba ahí y nunca se había puesto a prueba.
AtlasPVE ·
Esta entrada responde a
- proxmox no arranca tras actualizar
- proxmox arrancar con el núcleo anterior
- proxmox deshacer una actualización
- proxmox pveproxy no arranca
- proxmox sin panel tras actualizar
Actualizaste, reiniciaste, algo no funciona. El primer reflejo es "la actualización lo rompió", y a veces es cierto. Pero primero hay que hacer una distinción, porque cambia el trabajo desde el principio.
"Después" y "por culpa de"
Un reinicio es la primera prueba honesta de todo lo hecho desde el reinicio anterior. Un servicio arrancado a mano y nunca añadido al inicio, un montaje que nunca se escribió en la configuración, un ajuste cambiado en caliente y nunca guardado en un archivo: todo eso lleva meses ahí y nada se había puesto a prueba hasta ese momento. El reinicio lo saca a la luz, no lo provoca.
Saberlo sirve, porque "deshacer la actualización" no resuelve ese tipo de problema, y como no lo resuelve, te manda horas en la dirección equivocada.
Primero el síntoma, luego la decisión
La pregunta real no es "cómo vuelvo atrás", es qué está roto exactamente. Hay tres familias de síntomas y apuntan a tres sitios distintos.
La máquina no arranca en absoluto. El asunto es el núcleo o la capa de arranque. La vía de vuelta es el núcleo anterior, y normalmente sigue ahí, porque las actualizaciones no borran los núcleos antiguos.
La máquina arranca pero no hay panel. Un servicio no arrancó. Mira cuál y por qué; casi siempre es una cuestión de configuración aislada, no la actualización entera.
Todo arranca pero algo se comporta distinto. Un componente cambió de verdad. Aquí es donde el instinto de volver atrás está más equivocado: el trabajo correcto es leer qué cambió.
Volver atrás no es gratis
Rebobinar el sistema de archivos raíz no deshace solo la actualización, deshace todo desde ese momento. Los ajustes cambiados entretanto, las claves de acceso añadidas, lo demás que se instaló, todo vuelve atrás. Volver es una decisión, no un botón.
Una escalera que empieza por lo más barato
Prueba primero lo más estrecho y, si funciona, no toques nada más:
Arranca con el núcleo anterior. Solo afecta al núcleo y deja el resto tal cual.
Devuelve un único paquete a su versión anterior. Su efecto se limita a ese paquete.
Rebobina el estado del sistema en su conjunto. Lo más potente y lo más caro, guardado para el final.
Escribe antes de arreglar
Anota lo que viste: la línea de error, qué servicio, a qué hora. El día en que vuelve a funcionar la razón desaparece, y si lo mismo pasa tres meses después no te quedará nada en la mano.
Qué hace Atlas
Atlas fija el núcleo en marcha antes de la actualización. Así, aunque se instale un núcleo nuevo, el reinicio te levanta con el antiguo; pasar al nuevo es un paso aparte y consciente. Cuando pasas al núcleo nuevo entra en juego la guardia de arranque: comprueba que el sistema arrancó realmente sano y vuelve sola al núcleo antiguo si no fue así.
Antes de la actualización se toma una instantánea del sistema de archivos raíz. En ZFS es barata y volver atrás lleva minutos; en sistemas sin ZFS el estado de los paquetes se guarda aparte, así que no el sistema entero pero sí el estado de instalación se puede deshacer. Se guardan las últimas cinco instantáneas previas a actualizaciones y las más antiguas se limpian.
Cuando termina la instalación se ejecuta otra comprobación: ¿están arriba los servicios críticos?, ¿se mantiene el acuerdo del clúster? Así la pregunta "¿se rompió algo?" se hace antes de que tú lo notes.
⚠️ La advertencia de arriba sigue en pie: rebobinar el sistema de archivos raíz en su conjunto deshace más que la actualización. Atlas mantiene la instantánea lista, pero la decisión de volver es tuya.
Fuentes
La documentación oficial de Proxmox. En inglés, y en este asunto es ella la que tiene la última palabra.