El instalador de Proxmox no falló. Lo más probable es que fallara ese PC monstruo.

Cuando el USB no es el villano

Hay un ritual conocido cuando un servidor recién montado se niega a instalar un sistema operativo: culpar al USB. Lo vuelves a grabar, pruebas otra herramienta y otro puerto, pasas por BalenaEtcher, luego Rufus, luego Ventoy, y quizá te quedas mirando la BIOS como si te hubiera traicionado en lo personal. Por eso este caso resultaba tan desesperante. El mismo USB con el instalador de Proxmox funcionaba perfectamente en otra máquina que estaba al lado, un equipo mucho más modesto con placa ASUS TUF Z790, un i5-12500, 64GB de RAM, un SSD más pequeño y una GPU de gama media más reciente. Pero en la vistosa torre ProArt Z790 con un i9-14900K, 128GB de RAM Corsair, un SSD de 1TB, una RTX 4090, una fuente de 1000W, la última BIOS y la última ISO de Proxmox, el instalador se comportaba como si el hardware estuviera embrujado.

Los síntomas eran feos de esa manera en que solo un sistema inestable sabe serlo. A veces llegaba al instalador, a veces empezaba a instalar, y una vez casi llegó al final y se congeló en el 91 por ciento, el tipo de fallo que parece pensado para que desconfíes de cada componente que acabas de comprar. El dueño cambió los módulos de RAM por otros de un Lenovo P360, quitó la RTX 4090, rehízo el instalador con varias herramientas y siguió teniendo cuelgues parecidos. Ahí cambió la conversación. Aquello ya no olía a un USB de Proxmox defectuoso. Olía a inestabilidad de hardware disfrazada de Proxmox.

La respuesta más importante fue directa al grano: kernel panics aleatorios, "kernel stack is corrupted", patrones de error que cambian y congelaciones durante la instalación apartan la sospecha del instalador y la dirigen hacia la propia máquina. Nadie quiere oír eso después de montar una torre de gama alta. Los bugs de software y los medios defectuosos molestan, pero el hardware nuevo e inestable duele en lo personal. Convierte un montaje limpio en la escena de un crimen donde cada pieza pasa a ser sospechosa, de la placa base, la CPU, la RAM y los valores por defecto de la BIOS a la GPU, la fuente y el SSD. Hasta el cable de corriente empieza a parecer culpable.

El 14900K es un motor de cohete con letra pequeña

El i9-14900K era el sospechoso obvio, y no porque a la gente le caigan mal las CPU rápidas. Esa generación arrastra un historial. Puede que la inestabilidad de Raptor Lake ya no ocupe titulares, pero no desapareció solo porque el sector dejara de refrescar la pestaña. Los chips Intel de gama alta de 13.ª y 14.ª generación se hicieron famosos por cuelgues extraños, comportamientos de voltaje raros, valores por defecto de las placas, dudas sobre degradación y la incómoda sensación de que "de serie" no siempre significaba "seguro". Pon uno de esos chips en una placa ASUS llena de ajustes de rendimiento y un panic del instalador de Linux no es lo más raro que puede pasar.

Varias personas señalaron el comportamiento de la BIOS antes que cualquier otra cosa. Las placas ASUS suelen exponer un bosque de funciones de overclocking y mejora, y algunas pueden venir activadas por defecto o activarse sin que el usuario se dé cuenta del todo de qué cambió. MultiCore Enhancement, el overclocking automático, límites de potencia agresivos, perfiles de memoria y supuestos de voltaje pueden producir un sistema que pasa la prueba básica de "enciende", pero se desmorona bajo carga real. Que el entrenamiento de la RAM termine bien solo demuestra que el sistema pasó por la puerta, no que la fiesta de dentro sea estable.

El plan de restablecimiento propuesto era de una sensatez brutal: actualizar la BIOS, cargar los valores por defecto, desactivar ASUS MultiCore Enhancement o cualquier OC automático, usar los ajustes Intel Default o Baseline, desactivar XMP, poner la RAM a velocidad JEDEC, probar con un solo módulo, quitar la RTX 4090 y probar nomodeset si los drivers de vídeo están metidos en el lío. Es un consejo poco glamuroso, la lista aburrida de quien se ha quemado suficientes veces como para saber que "la última BIOS" y "una configuración segura" son cosas distintas.

También había una posibilidad más oscura: que la propia CPU estuviera mal, degradada o sencillamente no pudiera funcionar estable con los ajustes que elegía la placa. Una persona dijo que si la máquina seguía dando panic con los valores de Intel y XMP desactivado, la CPU o la placa pasaban a ser muy sospechosas, con el 14900K primero en la fila. Otra dijo que quizá al dueño le había "tocado un chip malo en la lotería del silicio" y necesitaba más voltaje para tener estabilidad, aunque ese compromiso trae más calor y más incomodidad. A nadie le gusta pagar precio de buque insignia para descubrir que el chip necesita niñera.

Los errores de memoria no siempre gritan enseguida

La RAM era el otro gran sospechoso, y merecía la atención. El sistema tenía 128GB de memoria Corsair, algo que queda genial en una ficha técnica y en la práctica puede volverse caprichoso, sobre todo en plataformas DDR5 con kits de gran capacidad. Poner dos módulos de otra estación de trabajo fue buen instinto, pero no cerró el caso. La inestabilidad de memoria es traicionera: puede pasar el entrenamiento, arrancar e incluso completar un par de pasadas de prueba antes de enseñar los dientes. Un comentarista describió un sistema que aguantó dos pasadas completas de test de memoria y solo empezó a fallar en la tercera o más tarde. La RAM no era defectuosa; la frecuencia era demasiado ambiciosa para la plataforma hasta que la bajaron bastante.

Por eso importaba el consejo de "pasa memtest durante un día". Eso significa varias pasadas durante 12 horas o más, mejor aún más tiempo, y no cinco minutos o una pasada mientras te haces un café. Intentas pillar ese cambio de bit raro que solo aparece cuando la temperatura, los tiempos y la carga coinciden justo de la peor manera, y comprobar que la RAM enciende las luces no te dice nada sobre eso. Kernel stack corruption es exactamente el tipo de frase que hace que la gente que sabe de memoria se incorpore en la silla. No garantiza que la RAM sea la culpable, pero hace imposible ignorarla.

La prueba con un solo módulo tampoco es superstición. Reduce la carga sobre el controlador de memoria, baja la complejidad y ayuda a aislar si hay un DIMM, una ranura, un perfil de tiempos o una configuración de capacidad implicados. Con XMP apagado y velocidades JEDEC activadas, el sistema debería ser aburrido. Si aun así da panic en ese estado mínimo, la culpa se desplaza hacia la CPU, la placa, el almacenamiento o la alimentación. Si de repente se porta bien, puede que el "equipo monstruo" simplemente viniera de fábrica funcionando demasiado cerca del límite.

Aquí es donde chocan el hardware de consumo y lo que se espera de un servidor. Proxmox es un hipervisor y quiere una estabilidad aburrida y duradera. Una torre para juegos o creación de contenido quiere rendimiento, frecuencias turbo, trucos de entrenamiento, memoria muy rápida y hasta la última gota de fanfarronería del silicio. Las dos metas pueden convivir, pero no de forma automática. Un sistema puede ser excelente para una captura de benchmark y aun así ser un sitio pésimo para montar infraestructura hasta que se dome cada función de rendimiento "útil".

Puede que la GPU sea inocente, pero la pila de vídeo acaba metida en el lío

La RTX 4090 salió pronto del equipo, y fue la decisión correcta. Siempre que un instalador de Linux suma rarezas gráficas, tiene sentido simplificar la ruta de vídeo. Quitar la GPU dedicada no lo resolvió, eso sí, lo que complicó el panorama. Una persona notó que al menos uno de los panics parecía implicar a la GPU o al subsistema de vídeo, en concreto DRM, y propuso la prueba contraria: desactivar la GPU integrada de Intel en la BIOS y usar solo la RTX 4090. Puede sonar a perseguir fantasmas, pero los problemas de la pila de vídeo durante un instalador pueden ser reales, sobre todo con hardware nuevo y un soporte del kernel que va al límite.

Por eso salieron nomodeset y las instalaciones en modo texto. A veces lo que tropieza con un driver es el instalador gráfico, aunque el sistema de fondo se pueda salvar. Probar el instalador en modo texto de Proxmox, probar otra versión de Proxmox o instalar primero Debian y añadir Proxmox encima son formas razonables de separar "el instalador gráfico odia mi hardware" de "la máquina no puede ejecutar Linux de forma estable". Una persona contó que un instalador solo de texto le sacó de una experiencia parecida. Otra propuso instalar Debian 13 sin entorno de escritorio y luego instalar Proxmox VE desde ahí.

Aquí hay una trampa, porque superar el instalador no resuelve el problema. Si la causa de fondo es inestabilidad de CPU, RAM, voltaje, placa, SSD o alimentación, un instalador en modo texto quizá solo esquive el primer cuelgue. La máquina puede seguir dando panic más tarde con carga de VMs, presión de E/S, copias de seguridad, actualizaciones o un reinicio cualquier martes, así que una instalación correcta puede dar una falsa tranquilidad. Lo que importa es si el sistema aguanta pruebas de estrés fuera de Proxmox.

Por eso era buen consejo arrancar otro entorno live, como SystemRescue, y pasar pruebas de estrés. Si un entorno Linux que no es Proxmox también se cuelga, la acusación contra Proxmox se derrumba rápido. Estresa la CPU y la memoria, prueba el almacenamiento, vigila las temperaturas y comprueba si la placa respeta el comportamiento baseline de Intel. Si el sistema se cae antes de que Proxmox entre siquiera en escena, el instalador era solo el mensajero al que culpaban del incendio.

Lo doloroso es probar como un mecánico y no como un gamer

Uno de los mejores comentarios tenía el tono emocional justo: los problemas intermitentes e inconsistentes son los más difíciles de rastrear, así que cambia una sola cosa cada vez. Suena obvio hasta que la frustración toma el control y la gente cambia seis cosas a la vez. Cambian la RAM, quitan la GPU, tocan la BIOS, regraban el USB, cambian de puerto, cambian el modo del instalador y de pronto nadie sabe qué ayudó de verdad. Las pruebas metódicas son aburridas porque funcionan.

Tener al lado un sistema que funcionaba era un regalo. Significaba que había un instalador que se sabía bueno, y quizá un montón de piezas buenas para comparar. Eso sí, el intercambio de piezas tiene que ser disciplinado: confirma el fallo, cambia una pieza o un ajuste y prueba. Si sale bien, deshaz el último cambio para ver si el fallo vuelve. Así se separa la casualidad de la causa. Tampoco pases por alto la fuente de alimentación. Una etiqueta de 1000W no descarta por arte de magia rarezas en la entrega de energía, cables malos, conexiones malas o inestabilidad transitoria, y las CPU y GPU de gama alta pueden ser invitados maleducados en la mesa de la corriente.

El almacenamiento también merecía un vistazo. Si el sistema a veces entra en la instalación y se congela muy avanzado el proceso, no hay que descartar el SSD ni la ruta del USB solo porque el USB funcionó en otra parte. Lo más probable es que el medio de instalación esté bien porque funcionó en otra máquina, pero el SSD de destino, el controlador de almacenamiento de la placa, el firmware o el cableado aún pueden provocar el caos. Verifica el disco, prueba otro SSD si tienes uno a mano y usa otra ranura M.2 si la placa comparte líneas o tiene manías de firmware. Al depurar infraestructura, lo que parece probable tras la primera pasada importa menos que descartar lo que todavía puede hacerte daño.

La sugerencia menos útil fue el clásico volantazo de "usa Ubuntu Server y Docker y listo". Puede valer para alguien que ha decidido que Proxmox es demasiado, pero no explica por qué una máquina recién estrenada suelta kernel panics. Un sistema sano debería instalar Proxmox y Debian, ejecutar una imagen de rescate live y superar los test de memoria. Si el hardware no puede con eso, cambiar la pila de software es redecorar una casa con los cimientos agrietados.

El instalador era el detector de humo

En esta historia hay tres bandos principales. El primero dice que probablemente esto no tiene nada que ver con Proxmox: el mismo USB funciona en otro sitio, los patrones de error cambian y la corrupción de la pila del kernel grita inestabilidad. El segundo dice que no hay que ignorar las rutas propias del instalador, así que prueba el modo texto, nomodeset, distintas versiones de Proxmox, instalar Debian primero y alternar entre iGPU y dGPU. El tercero dice que dejes de adivinar y tortures la máquina con pruebas hasta que el componente o el ajuste malo confiese. Los tres pueden tener razón, pero van en orden: primero estabiliza el hardware, luego esquiva las manías del instalador y después confía en la plataforma.

Lo más probable es que el villano sea una combinación de ajustes y no una sola pieza dramática, con el 14900K, los valores por defecto de la ASUS Z790, la capacidad de la DDR5, el comportamiento de la alimentación y quizá rarezas de gráficos o almacenamiento interactuando en el peor momento posible. La solución puede ser tan simple como los ajustes baseline de Intel y XMP apagado, o puede acabar en un RMA de la CPU o la placa. Nadie quiere ese final, pero los panics aleatorios en un equipo de gama alta recién montado no son algo que se pueda justificar sin más.

El dueño ya había dado un paso de diagnóstico importante sin darse cuenta de lo valioso que era: demostró que el instalador funciona en otra máquina. Eso acota la historia. El USB de Proxmox no está maldito y la ISO no está rota a simple vista, mientras que el problema sigue al sistema ProArt Z790 con el 14900K, y esa es la pista que importa.

Un kernel panic durante la instalación parece un software que se viene abajo. En este caso se parece más a un software que revela la verdad. Proxmox no mató el equipo; cargó peso sobre el suelo y enseñó qué tablas podían estar podridas. El siguiente paso son los ajustes baseline de la BIOS, sin XMP, un solo módulo de RAM, una instalación en modo texto, pruebas de estrés independientes, pasadas largas de memtest, comprobación de discos y la disposición a sospechar de la pieza cara antes que de cualquier otra cosa, en lugar de probar otra herramienta más para grabar el USB.