Hay reinicios que dan pereza y hay reinicios que me ponen de mal humor antes de empezar. Los segundos suelen ser los de Proxmox cuando sé que el nodo lleva varios kernels instalados, una tanda de paquetes reciente y un contexto de arranque que no tengo fresco en la cabeza.
No porque Proxmox arranque mal. Suele arrancar bastante bien. El problema es otro. El problema es que en homelab es facilísimo pensar que conocer el kernel en uso ya es suficiente. No lo es.
Antes de reiniciar un nodo me gusta saber tres cosas.
- qué kernel está corriendo ahora mismo
- qué kernels siguen realmente disponibles para arrancar
- qué mecanismo de arranque usa ese host, o al menos si
proxmox-boot-toolpinta algo ahí
Si no tengo eso claro, el reinicio deja de parecerme una tarea rutinaria. Y cuanto más rutinaria te parece una tarea con kernel y bootloader de por medio, más boletos compras para una sorpresa tonta.
por qué me fijo tanto en proxmox-boot-tool#
Porque es una de esas piezas que se quedan medio invisibles hasta que hace falta. Según la documentación oficial de Proxmox, el sistema puede usar systemd-boot o GRUB según cómo se instaló el host y cómo está montado el disco. En instalaciones EFI con ZFS raíz suele entrar en juego proxmox-boot-tool para mantener sincronizadas las particiones EFI y copiar ahí los kernels que deben seguir siendo arrancables. En otros escenarios, sobre todo con GRUB clásico o instalaciones que vienen de Debian, la historia puede ser distinta.
Eso para mí tiene una consecuencia muy práctica. No doy por hecho que todos mis nodos arrancan igual ni que todos responden igual a las herramientas de boot.
Y ahí es donde proxmox-boot-tool me resulta útil incluso cuando no me gusta la respuesta que devuelve. A veces precisamente por eso.
una salida real que me gusta revisar antes de tocar reboot#
Esta captura sale de una comprobación real en un nodo del lab. Está saneada en nombres, pero la salida es representativa de lo que me interesa mirar.
Aquí hay varias pistas muy buenas en muy pocas líneas.
La primera es uname -r. Kernel en uso, sin poesía. Eso me da el punto de partida.
La segunda es el bloque de proxmox-boot-tool kernel list. Esta parte me gusta bastante porque me enseña qué kernels considera arrancables o, mejor dicho, cuáles mantiene seleccionados el mecanismo de Proxmox cuando esa herramienta sí forma parte del flujo.
En esta salida veo algo muy razonable. El kernel en uso, los dos últimos instalados y otro de una serie anterior. Eso encaja bastante con el criterio que describe Proxmox en su wiki, donde explica que por defecto suele mantener el kernel actual, el recién instalado, los dos más recientes y, si aplica, uno reciente de la serie anterior.
La tercera pista es pveversion -v. No solo me da la versión del kernel activo, también me recuerda qué kernels siguen instalados como paquetes. Cuando comparo ambas fotos, entiendo mejor si la selección que veo tiene sentido.
la advertencia que no trato como drama, pero tampoco ignoro#
La segunda captura es casi más interesante que la primera.
Ese E: /etc/kernel/proxmox-boot-uuids does not exist no es el tipo de mensaje que me haga pulsar el boton rojo. Pero tampoco lo barro debajo de la alfombra.
Mi lectura es esta. El nodo no parece estar usando el flujo de ESP sincronizadas que proxmox-boot-tool status espera encontrar, al menos no de la forma estándar. Eso puede pasar por varios motivos razonables.
- el host arranca con GRUB clásico
- es una instalación sobre Debian o una migración que no usa ese mecanismo
- se quedó a medio camino de una conversión y conviene revisar
La documentación oficial es clara en algo importante. Cuando sí usas este sistema, la lista de ESP sincronizadas queda en /etc/kernel/proxmox-boot-uuids. Si el fichero no existe, yo no concluyo automáticamente que el nodo esté roto. Concluyo algo más útil. No debo asumir que este host participa en el modelo de arranque sincronizado de proxmox-boot-tool.
Y esa conclusión ya me cambia el tono del mantenimiento.
por qué ese matiz importa tanto antes de reiniciar#
Porque una cosa es saber qué kernel corre ahora y otra muy distinta saber qué pasará cuando el host vuelva a subir.
Si el nodo usa el flujo de ESP sincronizadas, proxmox-boot-tool me ayuda mucho a entender qué kernels están preparados para boot y a pinchar una versión concreta si necesito fijarla. Si el nodo no usa ese flujo, intentar razonar como si sí lo usara es una forma bastante tonta de meterse en un jardín.
Yo prefiero detectar esa diferencia antes.
En casa tenemos una costumbre peligrosa. Cuando una herramienta existe y funciona bien en un nodo, damos por sentado que el resto del cluster va por el mismo camino. Y no siempre. Hay labs que han crecido a golpe de nodo nuevo, migración, reinstalación parcial y decisiones tomadas con más prisa que método. El resultado es que dos hosts Proxmox pueden parecer hermanos desde la web y, debajo, arrancar con lógicas distintas.
proxmox-boot-tool me ayuda justo a destapar ese detalle.
cómo leo kernel list cuando la salida viene limpia#
La parte bonita del comando es proxmox-boot-tool kernel list.
Ahí no busco cantidad. Busco contexto.
quiero ver el kernel actual#
Parece una tontería, pero me gusta confirmar que el kernel que está corriendo forma parte de la selección mantenida. Si no está, ya tengo una pregunta incómoda antes de reiniciar.
quiero ver margen razonable hacia atrás#
Me tranquiliza ver un par de kernels recientes y, si aplica, alguno de una serie anterior. No porque quiera vivir congelado en el pasado, sino porque me gusta tener una red de seguridad mínima si un reinicio me obliga a pensar en fallback.
quiero saber si he fijado algo a mano#
En la captura, Manually selected kernels: None. Eso me gusta porque simplifica la lectura. Cuando sí hay un kernel fijado a mano, me interesa recordarlo antes de hacer cualquier suposición sobre qué versión debería entrar por defecto.
Aquí proxmox-boot-tool me parece honestísimo. No intenta ser más listo que tú. Te enseña la lista y listo. El que tiene que interpretar si esa lista cuadra con tu intención eres tú.
el error más común con los kernels en Proxmox#
Confiar demasiado en uname -r.
Lo digo porque yo mismo he caído ahí. Ves el kernel actual, confirmas que el host está arriba y piensas que ya tienes la foto. No, solo tienes el presente. Te falta el siguiente arranque.
En mantenimiento serio me importa más la pregunta futura que la pasada. No quiero solo saber con qué levantó este nodo. Quiero saber con qué podría volver a levantar mañana después de un cambio, una limpieza de kernels o una actualización algo más pesada.
Eso es lo que hace rentable mirar proxmox-boot-tool kernel list y pveversion -v juntos.
dónde encaja esto en mi preflight real#
Yo no hago una liturgia absurda antes de cada reboot, pero sí sigo una secuencia bastante estable.
uname -rproxmox-boot-tool statusproxmox-boot-tool kernel listpveversion -vapt list --upgradablesi el reinicio viene ligado a updates
Con eso suelo tener bastante claro si estoy delante de un host aburrido, que es justo lo que quiero, o de un host con un pequeño asterisco en la historia del arranque.
Y ese asterisco puede ser muy distinto según el nodo.
A veces la salida es perfecta y sigo. A veces me aparece el aviso de proxmox-boot-uuids, entiendo que el boot flow no va por ahí y lo siguiente ya no es reiniciar. Lo siguiente es confirmar cómo arranca realmente ese host.
cuándo me hace parar y revisar antes#
si el estado de boot no cuadra con lo que yo recordaba#
Si juraba que el nodo usaba ESP sincronizadas y status me responde que el fichero base no existe, entonces mi memoria iba peor de lo que creía. Antes de reiniciar, corrijo eso en mi cabeza.
si el listado de kernels no me da margen cómodo#
No me gusta reiniciar un nodo cuando la historia de kernels instalados y kernels seleccionados me parece rara o demasiado justa.
si voy a limpiar kernels y todavía no he entendido el arranque#
Esto es importante. Una cosa es instalar actualizaciones y otra ponerse a dejar “todo limpio”. Yo no toco limpieza fina de kernels si no tengo clarísimo cómo está arrancando ese host.
si el nodo es de esos que llevan años acumulando decisiones#
Todos tenemos alguno. El host que fue migrado, tocado, rehecho a medias o instalado sobre una base distinta al resto. En esos nodos proxmox-boot-tool no lo miro por rutina. Lo miro porque no me fío del folclore que me cuento a mí mismo sobre cómo está montado.
qué haría si quiero usar de verdad el flujo de ESP sincronizadas#
Aquí conviene separar dos casos.
Si el host ya debería usar ese flujo y algo no cuadra, entonces revisaría el esquema de arranque con calma y me apoyaría en la guía oficial de Proxmox sobre host bootloader y ESP sincronizadas.
Si el host nunca lo usó, no haría una conversión improvisada solo porque me salió una advertencia una madrugada. La propia documentación explica que proxmox-boot-tool puede inicializar una partición EFI y dejarla sincronizada, pero eso es trabajo de mantenimiento consciente, no un gesto rápido para quitar un warning.
Mi postura aquí es bastante clara. Los warnings de boot se interpretan. No se maquillan.
lo que me ha enseñado mirar esto con frecuencia#
La lección más útil es que el arranque de un nodo no debería ser un detalle decorativo en el homelab. Nos preocupamos mucho por contenedores, VMs, Ceph, HA, redes y dashboards. Luego llega el reinicio y recordamos que todo eso depende de que el host vuelva a arrancar exactamente como creemos.
A mí proxmox-boot-tool me ha servido para bajar la conversación a tierra. Menos épica, más comprobación.
También me ha recordado algo que vale para casi todo en Proxmox. Las herramientas que parecen más aburridas suelen ser las que mejor separan un mantenimiento limpio de un mantenimiento confiado de más.
mi conclusión#
Antes de reiniciar un nodo Proxmox yo ya no me quedo con uname -r. Quiero además ver qué kernels siguen seleccionados para boot y si proxmox-boot-tool forma parte del juego en ese host o no.
Cuando la salida es limpia, me da mucha tranquilidad. Cuando sale la advertencia de proxmox-boot-uuids, no entro en pánico, pero tampoco actúo como si nada. Lo tomo como una señal de que ese nodo necesita una lectura más precisa de su arranque antes de que yo haga el listo con kernels, pines o limpiezas.
No me parece una paranoia. Me parece mantenimiento adulto.
Y en un cluster casero, donde cada nodo puede arrastrar una pequeña biografía técnica distinta, entender cómo va a arrancar mañana vale bastante más que saber cómo arrancó ayer.
referencias#
- Host Bootloader en la wiki oficial de Proxmox VE
- Administración del host en Proxmox VE
- Post relacionado: Actualizar Proxmox sin ir a ciegas: el preflight real que hago antes de un apt full-upgrade
- Post relacionado: Cómo reviso la salud de un cluster Proxmox en dos minutos antes de tocar nada
- Post relacionado: pvesm status en Proxmox: cómo leo el almacenamiento de verdad y qué señales no ignoro