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, und 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, und Kernel-Regressionen sind angeblich verstanden. Und trotzdem stehen wir hier und starren auf ein nvidia.ko, das sich weigert zu existieren. Es passiert zu vielen Leuten, als dass es an einem einzelnen übersehenen Schritt liegen könnte.
Das Versprechen „offener“ Nvidia-Treiber
Mit Blackwell hat sich bei Nvidia etwas Wichtiges verschoben. 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 und weniger Reibung, wenn Kernel sich schnell weiterentwickeln, was Proxmox definitiv tut. 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, mit denselben Treibern, demselben Installer und derselben ausgewählten MIT/GPL-Option. 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, und lsmod zeigt weder nouveau noch nvidia, es konkurriert also nichts 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, und 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, also falsche Kernel-Header, nicht passende GCC-Version oder 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 brauchen die Nvidia-Treiber für mehr als die Bildschirmausgabe, etwa für GPU-Sharing in Containern, 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, und 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, während frische Installationen sich besser verhalten. Das gilt 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. Kaputt sind dabei weder Proxmox noch Nvidias Treiber. Das Zusammenspiel aus schnelllebigen Kerneln, VFIO und Nvidias Übergang zu offenen Modulen lässt einfach sehr wenig Spielraum für historischen Ballast.
Für einen Hypervisor ist das eine harte Schlussfolgerung. 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.
Die Ära der „offenen Treiber“ hat die Komplexität von Nvidia unter Linux aber nicht magisch weggezaubert. Sie hat die Problemstellen verschoben statt beseitigt. Proxmox bewegt sich schnell, Kernel bewegen sich schneller, Nvidia steckt mitten im Übergang zwischen Treibermodellen, und VFIO ist mächtig, aber gnadenlos. Stapelt man das alles übereinander, bekommt man genau diese Art von Fehlschlag: leise, verwirrend und zutiefst nervig.
Wo das Proxmox-Nutzer zurücklässt
Wer plant, eine Blackwell-GPU in einen Proxmox-9.1-Host zu stecken, muss es deshalb nicht sein lassen, sollte aber mit offenen Augen reingehen. Fangen Sie sauber an, wenn möglich, gehen Sie die VFIO-Konfiguration bewusst an, prüfen Sie doppelt, welchen Kernel Sie tatsächlich booten, und rechnen Sie damit, dass ein erfolgreich abgeschlossener Installer nichts darüber sagt, ob 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 gehört dazu, wenn man brandneue Hardware auf einem Hypervisor betreibt, der selbst im Sprint vorwärtsstürmt. Die Zukunft kommt früh an, nur nicht immer höflich.