<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Pveversion on Homelab.es</title><link>https://homelab-es.com/tags/pveversion/</link><description>Recent content in Pveversion on Homelab.es</description><generator>Hugo -- gohugo.io</generator><language>es</language><copyright>© 2026</copyright><lastBuildDate>Thu, 16 Apr 2026 08:00:00 +0200</lastBuildDate><atom:link href="https://homelab-es.com/tags/pveversion/index.xml" rel="self" type="application/rss+xml"/><item><title>pveversion -v en Proxmox: dónde veo paquetes raros antes de actualizar un cluster</title><link>https://homelab-es.com/posts/pveversion-v-proxmox-paquetes-desalineados/</link><pubDate>Thu, 16 Apr 2026 08:00:00 +0200</pubDate><guid>https://homelab-es.com/posts/pveversion-v-proxmox-paquetes-desalineados/</guid><description>&lt;p>Hay comandos que parecen un trámite y luego están los que te evitan una noche de mierda. &lt;code>pveversion -v&lt;/code> está en el segundo grupo.&lt;/p>
&lt;p>Yo lo uso antes de actualizar un nodo Proxmox, antes de reiniciarlo y también cuando algo ya huele raro y quiero saber si el problema viene de una capa más aburrida de lo que me gustaría admitir. Porque sí, en homelab nos encanta echarle la culpa a Ceph, a Corosync, al storage compartido o a esa VM caprichosa que siempre aparece en el momento menos elegante. Pero muchas veces el drama empieza antes, en algo tan poco glamuroso como una versión que no cuadra, un kernel viejo todavía dando vueltas o un paquete medio roto que nadie miró con calma.&lt;/p></description></item></channel></rss>