Blackwell trifft auf Proxmox: Wenn „offene“ Nvidia-Treiber sich trotzdem weigern zu laden
Es gibt eine besondere Art von Frustration, die nur auftaucht, wenn eigentlich alles funktionieren sollte.
Die Hardware sitzt richtig. Das BIOS sieht sauber aus. Secure Boot ist deaktiviert. Nouveau ist auf der Blacklist. Der Installer wird fertig. Der Fortschrittsbalken erreicht 100 Prozent. Für einen kurzen Moment denkt man, man wäre fertig.
Dann lässt Proxmox den Hammer fallen: Das Kernel-Modul kann nicht geladen werden.
Genau das ist der Moment, den viele Leute in letzter Zeit erlebt haben, nachdem sie Nvidias neue Blackwell-basierte GPUs – wie die 5060 und 5060 Ti – in Proxmox-9.1-Systeme gesteckt haben. Auf dem Papier soll das die einfache Ära sein. Nvidia bietet jetzt „offene" Kernel-Module an. Proxmox dokumentiert, welche Treiberversionen zu verwenden sind. Kernel-Regressionen sind angeblich verstanden. Und trotzdem stehen wir hier und starren auf ein nvidia.ko, das sich weigert zu existieren.
Das ist nicht eine einzelne Person, die einen Schritt übersieht. Das ist ein Muster.
Das Versprechen „offener" Nvidia-Treiber
Blackwell-GPUs kamen mit einer leisen, aber wichtigen Verschiebung. Nvidias neuere Karten setzen stark auf den MIT/GPL-„offenen" Kernel-Treiberpfad statt auf das klassische proprietäre Modul, mit dem sich Linux-Nutzer jahrelang herumgeschlagen haben.
Theoretisch sollte das ein Gewinn sein. Bessere Kernel-Kompatibilität. Weniger DKMS-Kopfschmerzen. Weniger Reibung, wenn Kernel sich schnell weiterentwickeln – und das tut Proxmox definitiv.
Und um fair zu sein: Viele Leute betreiben 50er-Serien-Karten völlig problemlos. Manche tun das sogar auf neueren Kerneln, als Proxmox offiziell absegnet. Dieselben Treiber. Derselbe Installer. Dieselbe MIT/GPL-Option ausgewählt.
Genau das macht die Fehlschläge so verwirrend.
Wenn „unterstützt" nicht „funktioniert" bedeutet
In den Fällen, die immer wieder auftauchen, sieht die Geschichte meist gleich aus:
Eine frische Proxmox-9.1-Installation. Eine Blackwell-GPU. Nvidias empfohlenes Runfile aus der 580er-Treiberserie. Der Installer schließt ohne offensichtliche Fehler ab. Dann weigert sich das Modul zu laden.
modprobe nvidia liefert nichts Hilfreiches zurück. lsmod zeigt weder nouveau noch nvidia, nichts konkurriert um das Gerät. Die Logs erzählen jedoch eine unheilvollere Geschichte:
request_mem_region failed for 64M @ 0xd0000000
Diese Zeile ist der eigentliche Bösewicht.
Sie deutet meist darauf hin, dass bereits ein anderer Treiber die Speicherregion der GPU besitzt. Nouveau ist der übliche Verdächtige, aber in diesen Setups ist es bereits auf der Blacklist und aus der initramfs verschwunden. Secure Boot ist deaktiviert. Es lauert kein rivatv-Relikt im Hintergrund. Trotzdem sondiert der Nvidia-Treiber das Gerät und prallt ab.
An diesem Punkt schlägt der Installer hilfreich die üblichen Ursachen vor – falsche Kernel-Header, nicht passende GCC-Version, nicht unterstützte GPU –, von denen keine wirklich erklärt, was da passiert.
Kernel-Roulette rettet nicht immer
Einer der ersten Instinkte ist, dem Kernel die Schuld zu geben. Proxmox selbst weist auf Probleme mit neueren Kernel-Zweigen hin, und viele Nutzer downgraden sofort von 6.17 auf 6.14. Bei manchen funktioniert das.
Bei anderen ändert sich nichts.
Der Treiber kompiliert gegen den richtigen Kernel. Die Header passen. Das System ist definitiv in dieselbe Kernel-Version gebootet, gegen die gebaut wurde. Und trotzdem bekommt /lib/modules/$(uname -r) niemals ein brauchbares nvidia.ko.
An diesem Punkt wird aus „Linux-Troubleshooting" etwas Existenzielleres. Man hat jeden Punkt abgehakt. Man hat die Docs befolgt. Das System stimmt einem in jedem einzelnen Faktum zu – und weigert sich trotzdem zu kooperieren.
VFIO macht die Sache komplizierter, als sie sein sollte
Gräbt man etwas tiefer in den Logs, taucht immer wieder ein weiterer Hinweis auf: VFIO-Meldungen, verwoben mit Nvidias Fehlern.
Das ist wichtig.
Viele Proxmox-Nutzer installieren Nvidia-Treiber nicht nur für die Bildschirmausgabe. Sie wollen GPU-Sharing für Container, CUDA-Workloads oder Passthrough-Experimente. VFIO mischt früh mit, und in manchen Setups sieht es so aus, als würde es sich Teile des Geräts schnappen, bevor der Nvidia-Treiber überhaupt eine faire Chance bekommt.
Selbst wenn man die GPU nicht explizit an eine VM durchreicht, können Proxmox' Konfiguration und Boot-Reihenfolge VFIO früher als erwartet ins Treiber-Rennen schicken.
Das Ergebnis ist eine bizarre Pattsituation, in der scheinbar niemand die GPU besitzt, der Nvidia-Treiber sich aber trotzdem nicht die Speicherregionen sichern kann.
Die MIT/GPL-Wahl ist nicht mehr optional
Eines ist klar: Blackwell-Karten funktionieren mit dem alten proprietären Kernel-Modul einfach nicht. Wer bei der Installation nicht die MIT/GPL-Option wählt, sitzt von Anfang an fest.
Die meisten Leute in dieser Situation wählen sie korrekt aus. Der Installer fragt danach. Sie wählen den offenen Treiber. Es schlägt trotzdem fehl.
Das ist wichtig, weil es den naheliegendsten Fehler ausschließt und unterstreicht, wie eng der eigentliche Problemraum ist.
Warum manche Systeme funktionieren und andere nicht
An diesem Punkt wird die Sache unangenehm.
Leute mit nahezu identischen Setups berichten von völlig unterschiedlichen Ergebnissen. Dieselbe GPU. Dieselbe Proxmox-Version. Derselbe Treiber-Build. Eine Maschine bootet sauber mit verfügbarem CUDA. Eine andere trifft jedes Mal auf denselben Kernel-Fehler.
Der Unterschied liegt oft an der Systemgeschichte.
Langlebige Proxmox-Hosts mit Jahren an Kernel-Upgrades, Hardware-Wechseln und übrig gebliebenen Konfigurationsdateien scheinen anfälliger für diese Probleme zu sein. Frische Installationen verhalten sich besser. Nicht immer – aber oft genug, um das Muster zu bemerken.
Das ist keine befriedigende Antwort, aber eine vertraute. Linux-Systeme sammeln State an. Initramfs-Hooks, modprobe-Konfigurationen und Bootloader-Fragmente bleiben lange bestehen, nachdem ihr ursprünglicher Zweck erfüllt ist.
Irgendwann taucht eine neue GPU auf und stolpert über etwas Unsichtbares.
Die Neuinstallation, die niemand machen will
Mehrere Leute, die gegen diese Wand gelaufen sind, geben irgendwann dasselbe zu: Das System braucht wahrscheinlich eine saubere Neuinstallation.
Nicht, weil Proxmox kaputt ist. Nicht, weil Nvidias Treiber unbrauchbar sind. Sondern weil das Zusammenspiel aus schnelllebigen Kerneln, VFIO und Nvidias Übergang zu offenen Modulen sehr wenig Spielraum für historischen Ballast lässt.
Das ist eine brutale Schlussfolgerung für einen Hypervisor. Proxmox-Maschinen sind keine Laptops, die man mal eben an einem Sonntagnachmittag plattmacht. Sie betreiben Storage, VMs, Netzwerke und Workloads, die über Jahre gewachsen sind.
Und trotzdem ist für manche Blackwell-Nutzer eine Neuinstallation das Einzige, was modprobe nvidia endlich zum Schweigen bringt.
Das ist der Preis des Lebens an der Spitze
Nichts davon bedeutet, dass Blackwell-GPUs eine schlechte Wahl für Proxmox sind. Sobald sie tatsächlich funktionieren, scheinen sie sogar gut zu funktionieren. Es gibt Multi-GPU-Setups, die 30er-, 40er- und 50er-Serien-Karten mischen und dabei problemlos Inferenz-Jobs und Container-Workloads betreiben.
Aber es bedeutet, dass die Ära der „offenen Treiber" die Komplexität von Nvidia unter Linux nicht magisch weggezaubert hat. Sie hat die Problemstellen verschoben, nicht beseitigt.
Proxmox bewegt sich schnell. Kernel bewegen sich schneller. Nvidia steckt mitten im Übergang zwischen Treibermodellen. VFIO ist mächtig, aber gnadenlos. Stapelt man das alles übereinander, bekommt man genau diese Art von Fehlschlag: still, verwirrend und zutiefst nervig.
Wo das Proxmox-Nutzer zurücklässt
Wer plant, eine Blackwell-GPU in einen Proxmox-9.1-Host zu stecken: Die Lektion lautet nicht „Lass es sein". Sie lautet „Geh mit offenen Augen rein".
Fangen Sie sauber an, wenn möglich. Gehen Sie die VFIO-Konfiguration bewusst an. Prüfen Sie doppelt, welchen Kernel Sie tatsächlich booten. Rechnen Sie damit, dass ein erfolgreich abgeschlossener Installer nicht bedeutet, dass der Treiber auch lädt.
Und falls Sie nach all den richtigen Schritten trotzdem auf diesen gefürchteten Kernel-Modul-Fehler stoßen, gehen Sie nicht davon aus, dass Ihnen etwas Offensichtliches entgangen ist. Manchmal ist das System einfach nur verheddert.
Das ist die unbequeme Wahrheit, wenn man brandneue Hardware auf einem Hypervisor betreibt, der selbst im Sprint vorwärtsstürmt. Die Zukunft kommt früh an – aber nicht immer höflich.