Proxmox-Installer streikt: Wenn die Hardware schuld ist

Wenn der USB-Stick nicht der Übeltäter ist

Es gibt ein vertrautes Ritual, wenn ein frisch gebauter Server die Installation des Betriebssystems verweigert: Man gibt dem USB-Stick die Schuld. Man schreibt das Image neu, probiert andere Ports und Tools aus, wechselt von BalenaEtcher zu Rufus und Ventoy und starrt schließlich das BIOS an, als hätte es einen persönlich verraten. Genau das machte diesen Fall so frustrierend. Derselbe Proxmox-Installer auf dem USB-Stick funktionierte auf einem anderen Rechner im selben Raum einwandfrei: einem deutlich moderateren ASUS-TUF-Z790-System mit einem i5-12500, 64GB RAM, kleinerer SSD und einer aktuellen Mittelklasse-GPU. Auf dem auffälligen ProArt-Z790-Tower mit einem i9-14900K, 128GB Corsair-RAM, 1TB SSD, RTX 4090, 1000W Netzteil, aktuellem BIOS und aktueller Proxmox-ISO verhielt sich der Installer jedoch so, als spuke es in der Hardware.

Die Symptome zeigten genau jene Widersprüchlichkeit, die für instabile Hardware typisch ist. Manchmal startete der Installer gar nicht, manchmal begann die Installation, und einmal blieb das System kurz vor Schluss bei 91 Prozent hängen. Das ist die Art von Fehler, bei der man an jeder einzelnen neu gekauften Komponente zweifelt. Der Besitzer tauschte RAM-Module aus einem Lenovo P360 aus, baute die RTX 4090 aus, erstellte das Installationsmedium mit verschiedenen Tools neu und landete trotzdem bei ähnlichen Abstürzen. Ab diesem Punkt änderte sich die Richtung der Fehlersuche: Das sah nicht mehr nach einem defekten Proxmox-Stick aus, sondern nach Hardware-Instabilität im Gewand eines Installationsfehlers.

Die treffendste Antwort brachte es auf den Punkt: Willkürliche Kernel-Panics, Meldungen über „kernel stack is corrupted“, wechselnde Fehlerbilder und Einfrieren während der Installation deuten weg vom Installer und direkt auf das System selbst. Niemand hört das gerne, nachdem er viel Geld in einen High-End-Rechner investiert hat. Software-Bugs und fehlerhafte Medien sind ärgerlich, aber instabile neue Hardware trifft einen persönlich. Der saubere Neubau wird zum Tatort, an dem plötzlich jedes Teil verdächtig ist: Mainboard, CPU, RAM, BIOS-Standardwerte, GPU, Netzteil und SSD. Selbst das Netzkabel gerät ins Visier.

Der 14900K ist ein Raketentriebwerk mit Vorbehalt

Der i9-14900K war der naheliegende Hauptverdächtige, und das nicht ohne Grund. Diese Prozessorgeneration bringt eine Vorgeschichte mit. Die Diskussionen um die Instabilität von Raptor Lake mögen aus den Schlagzeilen verschwunden sein, gelöst haben sie sich dadurch nicht. Die High-End-Chips der 13. und 14. Generation von Intel wurden berüchtigt für unerklärliche Abstürze, aggressive Spannungen, problematische Mainboard-Standards, Alterungserscheinungen und das ungute Gefühl, dass Werkseinstellungen nicht automatisch stabil bedeuten. Setzt man eine solche CPU auf ein ASUS-Board voller Tuning-Optionen, ist eine Kernel-Panic beim Linux-Installer kein überraschendes Ergebnis.

Mehrere Nutzer verwiesen als erstes auf das Verhalten des BIOS. Mainboards von ASUS bringen zahlreiche Übertaktungsfunktionen mit, von denen etliche ab Werk aktiv sind oder unbemerkt scharf geschaltet werden. MultiCore Enhancement, automatische Übertaktung, aggressive Power-Limits, Speicherprofile und optimierte Spannungen führen schnell zu einem Rechner, der zwar startet, unter echter Last aber zusammenbricht. Dass das RAM-Training erfolgreich durchläuft, beweist lediglich, dass das System POST überstanden hat, nicht aber, dass es stabil arbeitet.

Die vorgeschlagene Rücksetzung war pragmatisch: BIOS aktualisieren, Werkseinstellungen laden, ASUS MultiCore Enhancement und automatisches OC abschalten, Intel Default oder Baseline Settings wählen, XMP deaktivieren, den Speicher mit JEDEC-Takt betreiben, mit nur einem Riegel testen, die RTX 4090 ausbauen und bei Problemen mit Grafiktreibern nomodeset nutzen. Das ist kein glamouröser Rat, sondern die Checkliste erfahrener Admins, die wissen, dass ein aktuelles BIOS noch lange keine sichere Konfiguration bedeutet.

Es gab auch eine unangenehmere Möglichkeit: Die CPU selbst könnte beschädigt, degradiert oder schlicht unfähig sein, mit den Vorgaben des Boards stabil zu arbeiten. Ein Nutzer merkte an, dass bei anhaltenden Panics trotz Intel-Defaults und deaktiviertem XMP Prozessor oder Mainboard ganz oben auf der Verdachtsliste stehen, mit dem 14900K an erster Stelle. Ein anderer meinte, der Erbauer habe vielleicht Pech in der Silizium-Lotterie gehabt und brauche für Stabilität mehr Spannung, was jedoch wieder mehr Abwärme und Bauchschmerzen bedeutet. Niemand zahlt Spitzenpreise, um den Prozessor danach mühsam bändigen zu müssen.

Speicherfehler melden sich nicht immer sofort

Der Arbeitsspeicher war der zweite große Verdächtige. Das System war mit 128GB Corsair-Speicher bestückt. Was auf dem Datenblatt beeindruckend aussieht, macht in der Praxis oft Probleme, besonders bei DDR5-Plattformen mit Vollbestückung oder hoher Kapazität. Zwei Riegel aus einer anderen Workstation einzusetzen, war der richtige Reflex, lieferte aber noch keinen Freispruch. Speicherinstabilität ist tückisch: Sie übersteht oft das Booten und sogar die ersten Testdurchläufe, bevor Fehler auftreten. Ein Nutzer beschrieb ein System, das zwei komplette Durchläufe von Memtest fehlerfrei bestand und erst im dritten Durchgang Fehler warf. Das RAM selbst war nicht defekt, aber die Taktrate war für die Plattform zu hoch, bis man sie deutlich senkte.

Deshalb lautete der Rat: Memtest mindestens einen ganzen Tag laufen lassen. Das bedeutet mehrere Durchläufe über 12 Stunden oder länger, nicht nur fünf Minuten neben dem Kaffeekochen. Es geht darum, jene seltenen Bitkipper zu finden, die nur bei bestimmter Temperatur, Last und Taktung auftreten. Wenn die RGB-Beleuchtung des RAMs leuchtet, sagt das über Stabilität nichts aus. Eine beschädigte Kernel-Stack-Struktur lässt Speicherexperten sofort aufhorchen. Es beweist nicht zwingend defekten Arbeitsspeicher, macht ihn als Fehlerquelle aber unvermeidlich.

Der Test mit einem einzelnen Riegel hat handfeste Vorteile: Er entlastet den Speicher-Controller, reduziert die Komplexität und grenzt ein, ob ein einzelnes Modul, eine Speicherbank, ein Timing-Profil oder die Gesamtkapazität die Ursache ist. Mit abgeschaltetem XMP und Standard-JEDEC-Takt sollte das System brav laufen. Stürzt es auch in diesem Minimalzustand ab, wandert der Verdacht weiter zu CPU, Board, Datenträger oder Netzteil. Läuft es plötzlich stabil, war der Rechner schlicht ab Werk zu scharf eingestellt.

Hier prallen die Welten von Heimanwender-Hardware und Server-Anforderungen aufeinander. Proxmox ist ein Hypervisor und verlangt kompromisslose Stabilität. Ein Gaming- oder Creator-PC zielt dagegen auf Spitzenleistung, Boost-Taktraten, Speicher-Tweaks und jedes Quäntchen Rechenpower. Beides lässt sich kombinieren, aber nicht automatisch ab Werk. Ein PC kann in Benchmarks glänzen und trotzdem als Plattform für Virtualisierung ungeeignet sein, solange die aggressiven Leistungsfeatures nicht gebremst werden.

Die GPU ist vielleicht unschuldig, die Grafiktreiber mischen trotzdem mit

Die RTX 4090 frühzeitig auszubauen, war die richtige Entscheidung. Sobald ein Linux-Installer grafische Probleme zeigt, sollte man den Anzeigepfad vereinfachen. Das Entfernen der dedizierten Grafikkarte löste das Problem allerdings nicht, was die Diagnose verkomplizierte. Ein Beobachter bemerkte, dass mindestens ein Panic-Log auf das Grafik-Subsystem und DRM hinwies, und schlug den umgekehrten Test vor: Die integrierte Intel-Grafik im BIOS abschalten und ausschließlich die RTX 4090 nutzen. Das mag kurios klingen, aber Treiberprobleme bei frischer Hardware im Linux-Installer sind real, vor allem wenn Kernel und Komponenten ganz neu sind.

Aus diesem Grund kamen nomodeset und textbasierte Installationen ins Gespräch. Manchmal stolpert schlicht der grafische Installer über einen Treiber, während das Basissystem eigentlich lauffähig wäre. Den Proxmox-Textinstaller auszuprobieren, eine andere Proxmox-Version zu testen oder zuerst Debian aufzusetzen und Proxmox anschließend nachzuinstallieren, sind probate Wege, um Treiberprobleme von echter Hardware-Instabilität zu trennen. Ein Nutzer berichtete, dass ihn erst der reine Textmodus ans Ziel brachte. Ein anderer empfahl, zunächst Debian 13 ohne Desktop-Umgebung zu installieren und Proxmox VE darauf aufzubauen.

Hier lauert jedoch eine Falle: Die Installation erfolgreich abzuschließen, behebt die Ursache noch nicht. Wenn CPU, RAM, Spannungsversorgung, Mainboard oder SSD instabil sind, weicht der Textinstaller dem ersten Absturz lediglich aus. Die Maschine kann später unter Last durch VMs, I/O-Druck, Backups, Updates oder bei einem simplen Neustart erneut abstürzen. Eine geglückte Installation wiegt einen dann in falscher Sicherheit. Entscheidend ist, ob das System auch abseits von Proxmox stabil unter Last bleibt.

Daher war der Rat klug, ein Live-System wie SystemRescue zu starten und Stresstests durchzuführen. Stürzt auch eine unabhängige Linux-Umgebung ab, ist Proxmox als Schuldiger schnell vom Tisch. CPU und Arbeitsspeicher belasten, Datenträger prüfen, Temperaturen überwachen und sicherstellen, dass das Board die Intel-Vorgaben einhält: Bricht das System dabei zusammen, war der Installer nur der Bote, der die schlechte Nachricht überbrachte.

Fehlersuche verlangt Werkstatt-Disziplin statt Bastler-Hektik

Einer der besten Kommentare traf genau den Kern: Unregelmäßige und wechselnde Fehler sind am schwersten zu finden, deshalb darf man immer nur einen Parameter auf einmal ändern. Das klingt banal, geht im Frust aber oft unter, wenn Nutzer sechs Dinge gleichzeitig verändern. Es werden RAM-Module getauscht, die GPU entfernt, BIOS-Werte verstellt, der USB-Stick neu beschrieben, Ports gewechselt und der Installermodus umgestellt, bis niemand mehr weiß, was eigentlich gewirkt hat. Methodisches Vorgehen wirkt trocken, führt aber zum Ziel.

Das funktionierende Zweitsystem war ein großer Vorteil. Damit stand ein erwiesenermaßen funktionierendes Installationsmedium bereit und es gab kompatible Teile zum Gegentesten. Beim Komponententausch braucht es Disziplin: Fehler reproduzieren, genau ein Teil oder eine Einstellung ändern und erneut testen. Klappt es, wird die Änderung rückgängig gemacht, um zu prüfen, ob der Fehler wiederkehrt. Nur so unterscheidet man Ursache von Zufall. Auch das Netzteil gehört auf den Prüfstand: Die Angabe von 1000W schützt nicht vor defekten Kabeln, schlechten Steckverbindungen oder Lastspitzen. Moderne High-End-CPUs und Grafikkarten stellen extreme Anforderungen an die Stromversorgung.

Auch der Speicherpfad verlangt Aufmerksamkeit. Wenn der Rechner manchmal weit in die Installation vordringt und erst spät einfriert, dürfen SSD und Datenpfade nicht ignoriert werden, nur weil das Medium an einem anderen PC lief. Der USB-Stick selbst ist vermutlich in Ordnung, aber die Ziel-SSD, der Controller auf dem Board, die Firmware oder das Routing der Lanes können Probleme bereiten. Datenträger verifizieren, eine andere SSD testen und einen anderen M.2-Slot ausprobieren, falls sich Schnittstellen Ressourcen teilen. Bei der Fehlersuche zählt nicht, was auf den ersten Blick plausibel wirkt, sondern was sich sicher ausschließen lässt.

Wenig hilfreich war der Vorschlag, doch einfach Ubuntu Server und Docker zu verwenden. Das mag für jemanden passen, dem Proxmox zu viel ist, erklärt aber nicht, warum ein fabrikneuer PC Kernel-Panics produziert. Ein gesundes System muss Proxmox und Debian installieren, ein Live-Rettungssystem ausführen und Speichertests überstehen. Kann die Hardware das nicht, tapeziert ein Softwarewechsel nur über ein rissiges Fundament hinweg.

Der Installer war der Feuermelder

In diesem Fall gibt es im Grunde drei Perspektiven. Die erste sagt, dass Proxmox kaum das Problem ist: Derselbe Stick läuft anderswo, die Fehlerbilder wechseln ständig und Fehler im Kernel-Stack deuten auf Hardwareprobleme hin. Die zweite rät dazu, Besonderheiten des Installers zu umgehen: Textmodus nutzen, nomodeset setzen, andere Versionen testen, Debian als Basis vorziehen und die Grafikausgabe über iGPU oder dGPU gezielt steuern. Die dritte fordert, das Rätselraten zu beenden und das System mit Stresstests so lange zu belasten, bis die fehlerhafte Komponente feststeht. Alle drei Ansätze haben ihre Berechtigung, gehören aber in eine feste Reihenfolge: Zuerst die Hardware stabilisieren, dann Installer-Hürden nehmen und erst danach der Plattform vertrauen.

Das eigentliche Problem ist selten ein einzelnes Bauteil, sondern das Zusammenspiel mehrerer Faktoren: Der 14900K, die Z790-Vorgaben von ASUS, hohe DDR5-Kapazitäten, das Verhalten der Spannungsregelung und eventuelle Eigenheiten von Grafik oder Datenträger treffen im ungünstigsten Moment aufeinander. Manchmal genügen bereits Intel-Baseline-Profile und deaktiviertes XMP, in anderen Fällen führt der Weg zur Reklamation von CPU oder Mainboard. Das ist zwar bitter, aber willkürliche Panics auf einem frischen High-End-Rechner darf man nicht schönreden.

Der Erbauer hatte bereits den wertvollsten Diagnoseschritt unternommen: Er wies nach, dass der Installer auf einem anderen PC läuft. Damit schrumpft das Problemfeld erheblich. Der Proxmox-Stick ist nicht fehlerhaft und das ISO funktioniert. Der Fehler folgt eindeutig dem ProArt-Z790-System mit dem 14900K.

Eine Kernel-Panic bei der Installation wirkt wie ein Softwareabsturz. In Wahrheit zeigt die Software hier nur den Zustand der Plattform. Proxmox hat diesen PC nicht lahmgelegt, sondern lediglich die Dielenbretter belastet und gezeigt, welche davon nachgeben. Der nächste Schritt besteht aus konservativen BIOS-Werten, deaktiviertem XMP, einem einzelnen RAM-Riegel, der Textinstallation, unabhängigen Stresstests, ausdauernden Memtest-Läufen und dem Mut, das teuerste Bauteil zu verdächtigen, statt noch ein weiteres USB-Tool auszuprobieren.