"title":"Actualización del sistema Proxmox | ProxMenux Documentation",
"description":"Ejecuta la secuencia oficial de upgrade de Proxmox (apt update + apt full-upgrade -y) y añade la higiene de repos, comprobación de paquetes esenciales, escaneo de sanity de LVM, autoremove/autoclean y preguntar antes de reiniciar que la guía de upgrade también recomienda. Detecta la versión mayor en ejecución automáticamente.",
"ogTitle":"Actualización del sistema Proxmox | ProxMenux Documentation",
"ogDescription":"apt full-upgrade / dist-upgrade oficial envuelto con higiene de repos, autoremove y un preguntar antes de reiniciar inteligente."
"description":"Wrapper que delega en un único worker seguro (<code>update-pve-safe.sh</code>) que detecta la versión mayor de Proxmox por sí mismo. Los repositorios configurados se leen a través de la API de Proxmox y se mantienen como están; en un host sin suscripción activa cuyo único repositorio de Proxmox es Enterprise se pregunta antes de cambiar a sin suscripción. Se actualizan todos los paquetes, se recompilan los drivers DKMS gestionados por ProxMenux si aterriza un kernel nuevo y el prompt de reinicio solo se dispara cuando el kernel realmente cambió. También lanzable desde el botón <em>Update Now</em> de la cabecera del dashboard de ProxMenux Monitor cuando se detectan actualizaciones pendientes.",
"body":"Lleva el host al último nivel de parches de su versión mayor actual. <strong>No</strong> hace el salto entre versiones mayores — para PVE 8 → PVE 9 mira <link>Actualizar PVE 8 a PVE 9</link>."
},
"official":{
"heading":"La recomendación oficial de Proxmox",
"intro":"La guía de upgrade de la propia Proxmox para un host en ejecución (dentro de la misma versión mayor) es ejecutar:",
"code":"apt update && apt full-upgrade -y",
"outro":"Esa única línea es el comando oficial en cualquier release actual de Proxmox. La parte difícil no es el upgrade en sí; es asegurar que los repositorios están limpios, que están habilitados los correctos y que el host queda en un estado razonable después."
},
"onTop":{
"heading":"Qué hace ProxMenux encima — verificado contra el script",
"intro":"Esta opción ejecuta <strong>exactamente</strong> el comando apt de arriba, envuelto con la higiene de repos, la recompilación DKMS de los drivers gestionados por ProxMenux y la limpieza post-upgrade que la guía oficial de upgrade también recomienda. Todo lo de abajo mapea 1:1 a <code>scripts/utilities/proxmox_update.sh</code> y al único worker seguro <code>scripts/global/update-pve-safe.sh</code> — nada implícito, cada paso está en el código:",
"<strong>Detecta la versión mayor de PVE</strong> desde dentro del worker (<code>pveversion | grep -oP ''pve-manager/\\K[0-9]+''</code>) y adapta las URLs base de repo Proxmox / Debian (bookworm en PVE 8, trixie en PVE 9). No hay reparto a scripts worker por versión — un único worker seguro maneja ambas.",
"<strong>Mantiene los repositorios configurados.</strong> <code>ensure_repositories</code> lee los repositorios a través de la API de repositorios de Proxmox, junto con el estado de la suscripción. Un host con suscripción activa, o que ya usa el repositorio sin suscripción o el de test, se deja sin cambios. En un host sin suscripción activa cuyo único repositorio de Proxmox es Enterprise se pregunta si se cambia a sin suscripción; al rechazarlo, la actualización se detiene sin modificar ninguna fuente.",
"<strong>Ejecuta el upgrade no interactivamente</strong> con <code>DEBIAN_FRONTEND=noninteractive</code> y <code>--force-confdef --force-confold</code> — si un archivo de configuración que ya modificaste también cambió upstream, tu versión se queda en su sitio. Sin sobrescrituras silenciosas de configuraciones propias.",
"<strong>No fuerza utilidades opcionales.</strong> El worker seguro no empuja <code>zfsutils-linux</code>, <code>chrony</code>, <code>ifupdown2</code> ni paquetes similares al host — una instalación de Proxmox que optó por no tener alguno de ellos conserva su elección. La ausencia de paquetes la surface los flujos de instalación de alto nivel, no la ruta de actualización.",
"<strong>Recompilación DKMS antes del prompt de reinicio.</strong> Cuando el upgrade dejó staged un kernel nuevo, el wrapper llama a <code>pmx_rebuild_dkms_after_kernel</code> para recompilar cada driver que ProxMenux instaló vía DKMS contra la versión del kernel entrante — así los módulos están listos antes de que la caja vuelva a arrancar. La detección de reinicio usa <code>/var/run/reboot-required</code> cuando <code>needrestart</code> está presente, y como fallback una comparación por <code>dpkg-query</code> entre el kernel en ejecución y el paquete <code>proxmox-kernel-*-pve-signed</code> / <code>pve-kernel-*-pve</code> más nuevo instalado cuando no lo está — señal que sobrevive a los muchos hosts Proxmox que se entregan sin <code>needrestart</code>."
"body":"El mismo upgrade que Proxmox te dice que ejecutes, más la limpieza de repos, la comprobación de paquetes esenciales, el escaneo de sanity de LVM, el autoremove/autoclean después y un preguntar antes de reiniciar solo cuando toca."
},
"confirm":{
"heading":"Diálogo de confirmación",
"intro":"Seleccionar la opción abre un resumen de lo que va a hacer el worker, requiriendo una confirmación explícita:",
"imageAlt":"Diálogo de confirmación de Actualización del sistema Proxmox listando higiene de repos, actualizaciones de paquetes, limpieza"
"intro":"Un único worker (<code>scripts/global/update-pve-safe.sh</code>) maneja tanto PVE 8 como PVE 9. Detecta la versión mayor internamente y usa el codename propio de cada versión (<code>bookworm</code> o <code>trixie</code>) para sus fuentes base. Las etapas son:",
"<strong>Comprobaciones previas.</strong> Verifica al menos ~1 GB libres en <code>/var/cache/apt/archives</code>. Aborta pronto con un mensaje claro cuando falla, para que la ejecución no muera a mitad de una transacción apt.",
"<strong>Comprobación de repositorios.</strong> <code>ensure_repositories</code> lee los repositorios y el estado de la suscripción. En un host con un repositorio de Proxmox utilizable no cambia nada; en un host sin suscripción activa y solo con el repositorio Enterprise pregunta antes de cambiar a sin suscripción, y detiene la actualización cuando la respuesta es no.",
"<strong>Apt update con auto-recuperación de GPG.</strong> Ante un <code>NO_PUBKEY</code> de cualquier repo (los propios o uno de terceros), el worker importa la clave que falta y vuelve a intentar automáticamente antes de fallar.",
"<strong>Actualizaciones pendientes + conteo de seguridad.</strong> Reporta cuántos paquetes van a cambiar y cuántos de esos vienen de la suite de seguridad, para que el diálogo de confirmación tenga números reales que mostrar.",
"<strong>Diálogo de confirmación.</strong> El wrapper pide un sí explícito antes de tocar apt.",
"<strong>apt full-upgrade.</strong> Se ejecuta con <code>DEBIAN_FRONTEND=noninteractive</code> y <code>--force-confdef --force-confold</code> para que cualquier archivo de configuración que personalizaste mantenga su contenido actual cuando upstream también lo cambió. Nunca sobrescribe silenciosamente configs editados por el usuario.",
"<strong>Comprobación de sanity LVM.</strong> <code>lvm_repair_check</code> refresca los metadatos de VG cuando discos en passthrough a VMs guest (DSM, TrueNAS, appliances de almacenamiento) vuelven con cabeceras PV antiguas.",
"<strong>Recompilación DKMS de los drivers gestionados por ProxMenux.</strong> Cuando el upgrade dejó staged un kernel nuevo, <code>pmx_rebuild_dkms_after_kernel</code> lee <code>components_status.json</code> para los drivers que ProxMenux instaló (actualmente <code>nvidia_driver</code> → módulo <code>nvidia</code>, <code>coral_driver</code> → módulo <code>gasket</code>), instala los headers de kernel correspondientes (<code>proxmox-headers-<newkver></code> cuando está disponible, si no <code>pve-headers-<newkver></code>) y ejecuta <code>dkms autoinstall -k <newkver></code>. Si <code>dkms status</code> no muestra los módulos construidos contra el kernel nuevo, el worker cae a reejecutar cada instalador con <code>--auto-reinstall</code>. Cualquier fallo se registra pero no aborta la actualización — llegas al prompt de reinicio en todos los casos.",
"<strong>Post-limpieza.</strong> <code>apt-get autoremove</code> + <code>apt-get autoclean</code> antes de devolver el control al wrapper."
"heading":"Limpieza post-actualización y reinicio",
"intro":"Tras salir el worker, el wrapper ejecuta:",
"code":"apt-get autoremove -y # drop unused dependencies pulled in by old packages\napt-get autoclean # drop downloaded .deb files no longer in the index",
"afterCode":"Después comprueba si hace falta un reinicio. Dos señales disparan el prompt:",
"items":[
"<code>/var/run/reboot-required</code> existe (creado por el hook post-install del paquete del kernel)",
"El log del upgrade contiene entradas de <code>linux-image</code> (el kernel se actualizó de verdad)"
],
"outro":"Si alguna es cierta, un diálogo whiptail pregunta <em>\"Some changes require a reboot to take effect. Do you want to restart now?\"</em>. Decline para seguir corriendo en el kernel antiguo hasta que elijas reiniciar manualmente (p. ej. durante una ventana de mantenimiento planificada)."
},
"end":{
"heading":"Qué ves al final",
"intro":"Cuando el worker termina, el terminal muestra la salida de la limpieza y (si el kernel cambió) el preguntar antes de reiniciar:",
"imageAlt":"Resumen de finalización de Actualización del sistema Proxmox con salida de limpieza y preguntar antes de reiniciar"
},
"calloutDeclineReboot":{
"title":"Decline el reinicio solo si sabes por qué",
"body":"Correr en un kernel antiguo tras actualizar <code>linux-image-*</code> significa que estás en un sistema medio actualizado: userspace nuevo, kernel viejo. La mayoría del tiempo las cosas funcionan, pero los módulos ZFS, grupos IOMMU, KSMBD y cualquier driver fuera del árbol solo cuadran con el kernel para el que fueron construidos — un desajuste produce fallos oscuros. Reinicia en el primer momento razonable."
"heading":"Cómo trata el worker seguro al repositorio Enterprise",
"intro":"Proxmox entrega los hosts con el repositorio Enterprise habilitado por defecto. Sin una suscripción activa, ese repositorio devuelve 401 en <code>apt-get update</code>. El worker seguro cambia los repositorios solo en ese caso, solo tras preguntar, y a través de la API de repositorios de Proxmox — la misma que hay detrás de <em>Nodo → Actualizaciones → Repositorios</em>. Lo que ocurre en cada caso:",
"Con una <strong>suscripción activa</strong>, los repositorios se dejan sin cambios y Enterprise dirige la actualización.",
"Con el <strong>repositorio sin suscripción o el de test ya habilitado</strong>, los repositorios se dejan sin cambios, sea lo que sea lo que haya configurado a su lado.",
"<strong>Sin suscripción activa y solo con el repositorio Enterprise</strong>, un diálogo ofrece el cambio. Al aceptar, se deshabilita la fuente Enterprise, se habilita la de sin suscripción y se refrescan las listas de paquetes; el cambio queda registrado en la vista <em>Changes</em> de Audit & Report. Al rechazarlo, la actualización se detiene sin modificar ninguna fuente.",
"Las <strong>fuentes Enterprise de Ceph</strong>, cuando existen, se deshabilitan en el mismo cambio sin elegir otro canal de Ceph; un host que usa Ceph configura su canal por separado.",
"Cuando la ejecución <strong>no tiene un terminal en el que preguntar</strong>, no se modifica ninguna fuente y la actualización se detiene con un mensaje que remite a <em>Nodo → Actualizaciones → Repositorios</em>."
"outro":"Las fuentes de Debian y cualquier otro archivo de repositorios nunca se editan desde la ruta de actualización. Una fuente que mezcla Enterprise con otros componentes en la misma entrada no se cambia: la actualización se detiene y pide separarla desde la vista de repositorios de Proxmox."
"calloutTitle":"En clústeres: actualiza un nodo a la vez",
"calloutBody":"En un clúster Proxmox, ejecuta esta opción en <strong>un nodo a la vez</strong> y espera a que el reinicio se complete antes de pasar al siguiente. Migra primero los guests fuera del nodo para evitar una interrupción de servicio en todo el clúster. Versiones menores mezcladas (p. ej. 8.4.1 y 8.4.5) funcionan bien durante horas; kernels en ejecución mezclados pueden producir comportamientos inesperados en guests gestionados por HA."
},
"doesnt":{
"heading":"Qué no hace",
"items":[
"<strong>Salto de versión mayor.</strong> 8 → 9 es una operación aparte — mira <link>Actualizar PVE 8 a PVE 9</link>.",
"<strong>Backup.</strong> Sin snapshots, sin rollback. Las operaciones de apt no son transaccionales. Combínalo con tu disciplina normal de backups (PBS, vzdump, snapshots ZFS).",
"<strong>Actualizaciones de contenedores / VMs.</strong> Solo se actualiza el host; los guests se quedan en paz.",
"<strong>Actualizaciones de firmware.</strong> Microcódigo de CPU, firmware de NIC, BIOS — fuera de alcance."
"body":"El repositorio Enterprise está habilitado y el host no tiene suscripción activa. El worker ofrece el cambio a sin suscripción antes de <code>apt-get update</code>; si se rechazó, ejecuta de nuevo la actualización y acéptalo, o deshabilita la fuente Enterprise en <em>Nodo → Actualizaciones → Repositorios</em> y habilita la de sin suscripción."
"title":"dist-upgrade se queda colgado en \"Configuring grub-pc\"",
"body":"Un prompt de dpkg está preguntando en qué dispositivo(s) instalar GRUB. El wrapper pasa <code>--force-confold</code> para archivos de configuración pero la instalación del cargador de arranque es un prompt aparte. Usa <kbd>Tab</kbd> + <kbd>Space</kbd> para seleccionar todos tus discos de arranque, después OK. Mejor evitarlo seleccionando los discos de arranque una vez con <code>dpkg-reconfigure grub-pc</code> de antemano."
},
{
"title":"El kernel se actualizó pero los nuevos módulos faltan para un driver fuera del árbol",
"body":"Los drivers que ProxMenux instaló vía DKMS (actualmente <code>nvidia_driver</code> y <code>coral_driver</code>) se recompilan automáticamente al final del upgrade contra la versión del kernel entrante, usando <code>dkms autoinstall -k <newkver></code> y, si hace falta, un fallback a cada instalador con <code>--auto-reinstall</code>. Confirma con <code>dkms status</code>. Los módulos fuera del árbol de terceros que no están en el registro <code>components_status.json</code> de ProxMenux (drivers de NIC propios, paquetes DKMS instalados a mano, …) siguen necesitando un <code>dkms autoinstall</code> manual — el worker seguro solo toca lo que instaló originalmente."
"title":"El preguntar antes de reiniciar no apareció pero estoy seguro de que el kernel cambió",
"body":"Tienen que coincidir dos señales (<code>/var/run/reboot-required</code> y <code>linux-image</code> en el log del upgrade). Si el archivo marcador se borró pero el log se está parseando mal, reinicia manualmente con <code>shutdown -r now</code>. Para confirmar que hubo una actualización de kernel: <code>grep linux-image /var/log/apt/history.log</code>."
"code":"scripts/utilities/proxmox_update.sh # este script (wrapper)\nscripts/global/update-pve-safe.sh # único worker seguro (PVE 8 + PVE 9)\nscripts/global/repository-functions.sh # ensure_repositories\nscripts/global/repository_policy.py # lee y cambia los repositorios a través de la API de Proxmox\nscripts/global/utils-install-functions.sh # pmx_rebuild_dkms_after_kernel\n/usr/local/share/proxmenux/components_status.json # registro de drivers DKMS gestionados por ProxMenux\n/etc/apt/sources.list.d/proxmox.sources # fuente sin suscripción, escrita por Proxmox al aceptar el cambio\n/var/run/reboot-required # se lee para decidir el prompt de reinicio\n# Fallback de reinicio cuando needrestart no está instalado:\n# dpkg-query -W 'proxmox-kernel-*-pve-signed' 'pve-kernel-*-pve' vs. uname -r"
