Snapdragon unter Linux: Von Triumph über Warnung zu einem Achtungserfolg mit Hilfe eines Stonking Stingrays und einer OpenCloud

Ein Arbeitgeberwechsel hinterlässt manchmal Fallout. In meinem Fall – vom klassischen IT-Lösungsanbieter zu einer deutschen Open-Source-Schmiede – trug er das Logo von Lenovo. So begann es hier.

Ich hatte diesen Text als Triumph geplant. „Totgesagter ARM-Laptop läuft unter Linux besser als das Internet behauptet", meine Geschichte lag griffbereit, und die erste Hälfte davon stimmte sogar. Am Ende ist ein ganz anderer Text daraus geworden, ein ehrlicherer. Wer 2026 ein Snapdragon-Notebook unter Linux als Arbeitsgerät erwägt, dem rate ich ab. Nicht weil nichts ginge, sondern weil das Falsche regelmäßig zuverlässig kaputtgeht, sobald man sich darauf verlässt. Und je länger ich mich damit beschäftigt habe, desto klarer wurde, dass es dabei am Ende nicht nur um Reife geht, sondern um eine unbequemere Frage: wem dieses Gerät eigentlich gehört.

Der Aufbau: mehr Erfolge, als zu erwarten waren

Das Gerät war ein Lenovo ThinkPad T14s Gen 6 mit Snapdragon X Elite, 32 GB RAM, als günstiges Übergangsgerät gedacht, das ohnehin bald wieder verkauft wird. Drauf kam zuerst Ubuntu 26.04 LTS ARM64, verschlüsselt mit LUKS, ohne Bastel-Kompromisse. Der Anspruch war schlicht: einmal sauber installieren, dann arbeiten. Warum Ubuntu? Es gibt derzeit nur noch 2 belastbare Anläufe Linux auf ARM zu bringen. SUSE hat letztes Jahr die Snapdragon-Ambitionen beerdigt, fedora ist möglich, aber umständlicher, Ubuntu hat sich hier als professionell gepflegte Distribution angeboten. An der Stelle meinen ganz persönlichen Dank an Canonical. Die jetzt mittlerweile aktuelle Version 26.10 - Stonking Stingray rocks!

Und der Anfang war verblüffend gut. Reihenweise Komponenten, die diverse Kompatibilitätslisten als „tot" oder „in Arbeit" führten, liefen bei mir auf Anhieb: die interne Kamera lieferte ein sauberes Bild, der HDMI-Ausgang gab ein Signal aus, die GPU-Beschleunigung funktionierte (Editor und Terminal liefen flüssig, die gefürchtete Grafik-Regression traf mein Gerät nicht), Suspend und Resume klappten über Deckel und Kommandozeile. Selbst die Sensorik, von der Standardwerkzeuge behaupteten, es gäbe keine, entpuppte sich als 59 sauber benannte Temperaturzonen im Kernel, alles drin, pro CPU-Kern, für die GPU, sogar für die Kameras. Der Akku zeigte 39 Ladezyklen, also quasi Neuzustand, und hielt gemessene neun bis zwölf Stunden unter gemischter Last, bei rund sieben Watt Durchschnittsverbrauch.

Ich habe alles dokumentiert, jede getestete Komponente, jede widerlegte Annahme. Das Gerät bestand sogar den Härtetest: zwei Tage Konferenz, geschätzt zwanzig Suspend-Resume-Zyklen am Tag, Fremd-WLAN, kein einziger Ausfall. An dieser Stelle hätte der Triumph-Text gestanden.

Der Bruch: wo es anfängt zu bröckeln

Der erste Riss war leise. Der USB-C-DisplayPort-Ausgang funktionierte schlicht nicht. Kein Bild, kein erkanntes Display, im Systemlog nicht einmal ein Ereignis beim Anstecken. Kein Beinbruch, dachte ich, HDMI geht ja. Ein Blick in die Community-Foren zeigte: Auf genau diesem Modell kämpfen andere mit demselben Problem noch auf neueren Kerneln. Es war also kein Fehler meiner Installation, sondern der Stand der Plattform.

Das zweite Aha-Erlebnis war unbequemer. Über Nacht zugeklappt verlor das Gerät 85 Prozent Akku. Der Schlafmodus ist auf dieser Plattform kein echter Tiefschlaf, sondern ein wacher Dämmerzustand, der munter Energie weiter verbrät. Einen echten Ruhezustand mit Wegschreiben auf die Platte gibt es nicht, der Kernel bietet ihn schlicht nicht an. Die Konsequenz ist eine eigene Betriebsregel, die man sich merken muss: für lange Pausen herunterfahren, nicht zuklappen. Apple und sogar Microsoft lösen dasselbe Problem auf demselben oder vergleichbaren Chips elegant über eine fein abgestimmte Zusammenarbeit mit der Firmware. Unter Linux fehlt diese letzte Meile.

Und dann kam der Abend, der aus dem ersten Triumph eine vorsichtige Warnung machte.

Ein ganz normales Update, und nichts geht mehr

Ich startete das Gerät neu, und es bootete nicht. Statt des Anmeldebildschirms eine kryptische Zeile: error: invalid device tree. Dieselbe Meldung, die wochenlang harmlos als kosmetischer Schönheitsfehler durchgelaufen war, hatte sich in einen harten Abbruch verwandelt. Der Grund: Im Hintergrund war der Bootloader auf eine neue Version aktualisiert worden, und die reagiert auf einen seit jeher vorhandenen, eigentlich belanglosen Fehler jetzt bockig statt nachsichtig. Ein Update hatte etwas kaputt gemacht, das vorher lief.

Es wurde schlimmer, bevor es besser wurde. Beim Versuch, den Fehler zu umgehen, erschien die eigentliche Ursache: EFI stub: Exit boot services failed. Das ist, wie sich herausstellte, ein dokumentierter Firmware-Bug genau dieses Laptop-Modells, beschrieben ausgerechnet von dem Kernel-Entwickler, dem das Gerät seine Linux-Tauglichkeit überhaupt verdankt. Die Firmware scheitert sporadisch beim Übergang zum Kernelstart. Sporadisch heißt: mal bootet es, mal nicht, mit identischer Konfiguration. Der Workaround ist, es schlicht mehrfach zu versuchen oder über das Boot-Menü von Hand zu starten. Man lässt das kurz sacken: Ein verkauftes, aktuelles Premium-Notebook hat einen Firmware-Fehler, der den Start zum Glücksspiel macht, und die Lösung lautet „nochmal probieren".

Ein Kernel-Update später bootete das Gerät wieder zuverlässig. Der Fix funktionierte. Und im selben Zug war dann plötzlich der bisher funktionierende HDMI-Ausgang kaputt: Das Bild auf dem externen Monitor sofort korrumpiert, und beim Abziehen fror der ganze Rechner ein. Der Ausgang, der von Anfang an eine meiner stolzen „läuft doch"-Trophäen gewesen war, ausgerechnet der. Das Ergebnis war so ... mittel.

Was dieser Monitor-Ärger genau ist, hat sich erst später geklärt, auf einem neueren Kernel, und es ist hartnäckiger als ein simples „HDMI kaputt". Beide Bildschirme gleichzeitig laufen tadellos. Schalte ich aber auf „nur externer Monitor" — reiße also die interne Anzeige ab —, zerfällt das Bild sofort in Grafikmüll, und ziehe ich dann im falschen Moment das Kabel, hängt das ganze System, bis nur noch der harte Neustart hilft. Kein Kabel, kein Mesa, keine Hardware: Es ist der proprietäre Qualcomm-Display-Treiber, der am Umbau der Bildschirm-Pipeline scheitert, genau an der Stelle, an der das System einen Monitor abschaltet und einen anderen allein neu hochfährt. Und so sehr das nervt, es ist zugleich die ehrlichste Momentaufnahme der Plattform: Auf dem allerersten Kernel tauchte der USB-C-Displayausgang gar nicht erst auf, inzwischen ist er immerhin angelegt, nur verbindet er noch nichts. Es wird besser, Kernel für Kernel. Nur eben nicht in dem Tempo, in dem man einen Monitor ansteckt.

Das ist der Kern der Sache, und er passierte an einem einzigen Abend in Reinform: Der Fix für Problem A gebar Problem B. Man repariert den Start und verliert den Bildschirmausgang. Das ist kein Pech, das ist die Signatur einer Plattform, die noch mitten im Aufbau steckt. Oder in diesem Fall im reverse engineering.

Die eigentliche Lehre: nicht ARM, sondern die Front

Es wäre bequem, jetzt „ARM ist schuld" zu schreiben. Das wäre falsch. Die richtige Diagnose ist unbequemer und nützlicher: Das Problem ist nicht ARM gegen x86, sondern frische Hardware auf Community-Kerneln gegen herstellergepflegte, zertifizierte, closed Stacks.

Der Beweis liegt auf dem eigenen Schreibtisch. Als Nachfolgegerät kommt ein x86-Notebook mit brandneuem Intel-Chip. Und ausgerechnet für dieses Silizium finden sich im Netz dieselben Horror-Berichte: tote Grafikeinheit, kein Ton, „dead in the water, bis der Kernel nachzieht". Dieselbe Krankheit, anderes Logo. Was den Unterschied macht, ist nicht die Architektur, sondern ob jemand die Frontier-Zähmung für dich erledigt und eingefroren hat. Bei zertifizierten Geräten mit offiziellem Hersteller-Image tut genau das jemand. Bei einem selbst installierten Ubuntu auf fabrikfrischem Silizium tust du es selbst, an jedem Abend, jedes Update aufs Neue.

Und damit hängt die zweite Lehre zusammen, die jeder kennt, der Server betreibt, und die man trotzdem immer wieder neu lernt: Ein Update ist auf unreifer Hardware kein Fortschritt, sondern ein Tauschgeschäft. „Neuester Kernel" ist nicht „bester Kernel". Bei reifer Hardware darf man Updates blind vertrauen. Hier ist jedes Update ein D20-Würfelwurf, bei dem man etwas gewinnen und gleichzeitig etwas anderes verlieren kann. Wer ein Gerät zum Arbeiten braucht, kann sich diesen Würfelwurf nicht leisten.

Und darunter liegt die eigentliche Frage: Souveränität

Bis hierher klingt das nach einem Reifeproblem, und Reifeprobleme heilt üblicherweise die Zeit. Aber unter der Unreife liegt etwas, das die Zeit nicht heilt, weil es kein Bug ist, sondern eine Design-Entscheidung. Dieses Gerät wurde als geschlossene Plattform für genau ein genauso geschlossenes Betriebssystem entworfen, gebaut und getestet: Windows. Alles andere sind seitens der Hersteller unerwünschte Gäste.

Man kann das an den eigenen Pannen ablesen, sie sind keine Zufälle, sondern Symptome. Der Firmware-Fehler, der den Start zum Glücksspiel machte, scheitert deshalb nur unter Linux, weil die Firmware geschlossen ist und nur gegen den Startablauf von Windows designed und erprobt wurde. Für Windows funktioniert sie, für alles andere ist sie eine nicht wirklich vertrauenswürdige Blackbox mit Macken, um die herum eine Handvoll enthusiastischer Entwickler von außen navigieren muss. Niemand außerhalb des Herstellers kann in diese Firmware hineinsehen, sie prüfen oder reparieren. Auch eine Canonical (leider) nicht. Man besitzt diese Firmware nicht, man kann sie allenfalls misstrauisch beäugen.

Dasselbe beim Selbstverständnis der Hardware. Ein gewöhnlicher PC beschreibt sich dem Betriebssystem über halbwegs standardisierte Mechanismen selbst. Dieses Gerät tut das nur in einem halbdokumentierten Dialekt, den der ebenfalls geschlossenen Windows Treiber Stack versteht. Damit Linux überhaupt weiß, was es vor sich hat, muss ihm die Hardware von Hand beschrieben werden, ich habe beim Update zugesehen, wie das System eine Datei namens x1e78100-lenovo-thinkpad-t14s.dtb installierte, deren einziger Zweck es ist, dem Kernel zu erklären, was dieses Laptop ist. Diese Beschreibung hat jemand mühsam von Hand geschrieben, Modell für Modell, weil der Hersteller das Wissen über seine eigene Hardware nicht offen herausgibt. Auf einer wirklich offenen Maschine beschreibt sich die Hardware selbst. Hier beschreibt die Community sie nach. Zeile für Zeile.

Und der Chip selbst ist keine CPU, sondern ein Golem aus proprietären Bausteinen: die Grafikeinheit, die KI-Einheit, der Bildprozessor der Kamera, das Modem, jedes davon ein vernageltes Kästchen von Qualcomm, meist ohne (offene) Dokumentation. Wo dafür überhaupt Treiber existieren, existieren sie, weil jemand sie über Reverse Engineering mühsamst nachgebaut hat, oder weil Qualcomm sich entschieden hat, diesmal beizutragen. Genau dieses „entschieden" ist der Punkt.

Denn hier kippt die ganze naive Intuition, mit der ich in das Experiment gegangen war. Insgeheim hatte ich ARM als eine Art Ausbruch gedacht, weg vom Wintel-Block, ein Schritt Richtung Unabhängigkeit. Das Gegenteil ist wahr. Ein kommerzielles ARM-Laptop gehört zum am wenigsten souveränen, was man kaufen kann, stärker verriegelt als der durchschnittliche x86-Rechner, weil es die Bauart der Handywelt erbt: Der Hersteller besitzt die Startkette, signiert die Firmware und behandelt das Betriebssystem als sein Produkt, nicht als deine Wahl. Fairnesshalber - Apple ist hier mit Apple Silicon schlimmer als Qualcomm. Die Offenheit, die ich genossen habe, ist Etappe für Etappe geliehen, nicht besessen. Sie existiert, solange Qualcomm freundlicherweise weiter beiträgt und eine Handvoll bezahlter Entwickler weitermacht. Nimm eines von beidem weg, und die Plattform ist extrem schnell obsolet. Souveränität, die am Wohlwollen eines Herstellers und der Freizeit einiger weniger hängt, ist keine Souveränität, sondern ein Mietverhältnis ohne Mieterschutz.

Ehrlichkeitshalber: sauber ist die andere Seite auch nicht. Auch mein neuer x86-Rechner trägt eine obskure Intel-Management-Engine, die niemand einsehen kann, und einen proprietären nvidia-Grafiktreiber obendrauf. Souveränität ist ein Spektrum, kein Schalter. Aber x86 hat offene Standards, eine Maschine, die sich in einer gemeinsamen Sprache selbst beschreibt, für manche Modelle sogar quelloffene Firmware, und eine so große Gemeinschaft, dass die Grundfunktionen keinen Nachbau brauchen. Und der wirklich souveräne Horizont auf den ich hoffe, wie offene Firmware, RISC-V-CPUs, ist noch eine ganz andere, weitere Reise. Der Punkt ist nicht „x86 gut, ARM böse". Der Punkt ist, dass ausgerechnet die Geräteklasse, die sich als Zukunft verkauft, unter der Haube ein versiegeltes Windows-Gerät ist, auf dem alternative Betriebssystem wenn überhaupt geduldet werden.

Das Urteil

Das Gerät allein läuft. Verschlüsselt, kühl, leise, ausdauernd, mit funktionierendem Bildschirm, GPU und Suspend, mit vollständiger Entwicklungsumgebung. Als abgeschlossenes System auf dem Schreibtisch ist es beeindruckend. Ich will es irgendwie mögen. Das liegt aber auch am Betriebssystem, zugegebenermaßen, ich mag Ubuntu sehr.

Aber ein Arbeitsgerät ist kein abgeschlossenes System. Man schließt einen Monitor an, ein Dock, eine Kamera. Man installiert Updates, weil man Sicherheitslücken nicht offen lässt. Und genau da fällt dieses Gerät durch: Der eine externe Ausgang ist tot, der andere friert nach einem Update den Rechner ein, und das nächste Update kann jederzeit die nächste funktionierende Sache zerlegen. Ein Werkzeug, dem man nicht trauen kann, sobald man es an die reale Welt anschließt, ist kein Werkzeug, sondern ein Versprechen.

Deshalb keine Erfolgsgeschichte, sondern eine nüchterne Warnung an alle die das Risiko eingehen wollen: Snapdragon unter Linux ist 2026 als Arbeitsplattform noch nicht so weit. Nicht, weil die Leute dahinter schlecht arbeiten, ganz im Gegenteil, was da zwischen Qualcomm, Linaro, den Kernel-Entwicklern und Lenovos Upstream-Beiträgen zum Kernel entstanden ist, ist beachtlich, und es wird von Kernel zu Kernel besser. Sondern weil „besser werden" und „verlässlich sein" zwei massiv divergierende Zustände sind, und dieses Gerät ist noch im ersten.

Für ein Souveränitätsprojekt wiegt aber die zweite Diagnose leider schwerer als die erste. Unreife ist ein Zustand auf Zeit, den nächste Kernel heilen (können). Gast auf einer versiegelten Maschine zu sein, ist kein begrenzter Zustand, sondern eine unveränderbare Eigenschaft. Diese heilt kein Update, sondern höchstens eine strategische Entscheidung des Herstellers. Ich bin ausgezogen, um unabhängiger zu werden, und habe ein Gerät gefunden, das mich abhängiger macht, nur eben von jemand anderem.

Was ich mitnehme

Für den, der lernen und verstehen will, ist so ein Snapdragon-Laptop unter Linux ein fantastisches, dankbares Spielfeld. Man versteht am Ende Bootloader-Interna, Device-Trees, Firmware-Eigenheiten und die Anatomie eines guten und eines schlechten Kernel-Updates besser als aus jedem Buch. Als Lehrmeister war das Gerät bis heute schon für mich jeden Euro wert.

Für den, der ein Notebook braucht, das einfach läuft, wenn man es aufklappt und einen Monitor ansteckt, gilt das glatte Gegenteil: Kauf reife oder zertifizierte Hardware, lass die Frontier-Zähmung jemand anderen machen. Verwechsle das Vergnügen am Basteln nicht mit einem Produktivgerät. Ich habe beides in einem Gerät gesucht und nur das eine bekommen.

Das Gerät geht jetzt zurück in seinen Windows-Auslieferungszustand und wird verkauft. Ein paar Monate früher als geplant, weil es die Frage, ob man sich darauf verlassen kann, selbst negativ beantwortet hat. Die Antwort war nein. Das ist kein schlechtes Ergebnis. Es ist nur leider ein ganz anderes, als ich am Anfang des Projektes schreiben wollte.

Postskriptum, Oktober 2026: Das Warn-Gerät hat einen Zweck gefunden

Zwei Monate später hat sich das Ende dieser Geschichte selbst umgeschrieben, schöner, als ich es ursprünglich konnte. Das Gerät ist nicht verkauft. Es steht noch hier, und es arbeitet.

Der Anlass war eine Lücke, über die ich beim Einrichten gestolpert war: Für OpenCloud, den souveränen (selbst gehosteten) Cloud-Dienst, auf den ich setze, gibt es keinen nativen Client für ARM-Linux. Es gibt ihn für x86-Linux, für Windows, für Android, für iOS, nur nicht für die Architektur in diesem Laptop. Und das ist, ich sage es deutlich, kein Versäumnis, sondern eine richtige Entscheidung. Ein Unternehmen muss marktwirtschaftlich handeln und seine begrenzten Ressourcen dahin lenken, wo die Nutzer sind. Der ARM-Linux-Markt ist winzig. Es wäre unvernünftig, dafür einen weiteren Build-Zweig dauerhaft zu pflegen. Jede nüchterne Produktplanung käme zum selben Schluss, und sie hätte recht.

Genau hier liegt das Argument für offene Software, das pragmatischste, das ich kenne, weil es ohne Ideologie auskommt. Weil OpenCloud offen ist, war das Nein der vernünftigen Produktplanung nicht das Ende der Sache, sondern nur deren (vielleicht zeitweises) Ende für das Unternehmen. Ich musste nicht warten, bis sich eine Tabellenkalkulation zu meinen Gunsten dreht, musste niemanden überzeugen, musste nicht verzichten. Ich habe das totgesagte Gerät genommen, mir eine eigene Build-Kette gebaut und einen ARM64-Build veröffentlicht — für mich und für jeden anderen, der ihn vielleicht braucht. Das Unternehmen muss keinen Build tragen, den es nicht wirtschaftlich rechtfertigen kann. Die Community trägt ihn, und die Gemeinschaft war in diesem Fall ein Mensch mit einem Laptop den er ausmustern wollte an einem verlängerten Wochenende.

Das ist die leise Superkraft quelloffener Software: Sie entkoppelt „einer Firma ihre Ressourcen wert" von „möglich und umsetzbar". Bei proprietärer Software ist das Nein des Herstellers endgültig; sagt seine Kalkulation nein, bleibt es nein, für immer. Bei offener Software ist das "Nein" des Herstellers nur das "heute nicht ich" des Herstellers. Das Recht, selbst ja zu sagen, bleibt bei dir. Wie großartig ist das denn?

Und das Gerät? Die Maschine, die ich als Arbeitsgerät für unzuverlässig erklärt habe, ist für diese Aufgabe genau die Richtige. Genau wegen ihres etwas schrulligen Charakters. Ein Bastel- und Dev-Gerät muss nicht verlässlich den Alltag tragen, es muss meins sein, um darauf zu experimentieren. Genau das hatte ich im letzten Absatz geschrieben, bevor ich wusste, wie wahr es werden würde. Ariel - so heißt der kleine Racker - geht nicht zu eBay. Ariel ist jetzt der Build-Host für meine ARM-Targets.

Die Warnung über die Hardware bleibt Wort für Wort stehen. Aber die eigentliche Lehre war am Ende gar keine spezifische über ARM. Sie war, dass Souveränität nichts ist, das man kauft, sondern etwas, das man behält.

Die Fähigkeit, die eigenen Lücken selbst zu schließen. Dass die Hardware ein auf Good-Will verliehenes Windows-Gerät ist, war das Problem. Dass Software offen ist, ist die Antwort.

Postskriptum zum Postskriptum: als Autor tappt man in die eigene Falle

Ich sollte ehrlich sein: Kaum war dieser Text über „jedes Update ist ein Tauschgeschäft, der neueste Kernel ist nicht der beste“ fertig, habe ich auf genau diesem Gerät das neueste Non-LTS-Ubuntu 26.10 installiert, die Version, die ausdrücklich näher an der Front läuft. Und prompt kassierte ich eine Kernel-Regression, die das Bluetooth abschaltete.

Man kann einen Artikel über eine Falle schreiben und am selben Abend hineintreten. Ich bin der Beweis. Stupid me.

Der Unterschied, und das ist dann doch die versöhnliche Pointe, liegt in der weichen Landung. Ich musste nicht darauf warten, dass irgendjemand die Regression für mich repariert. Beim Start im Bootmenü den vorherigen Kernel ausgewählt, Bluetooth war zurück, weiterarbeiten. Ubuntu lässt den alten Kernel als Rückfallposition noch liegen, ich war wirklich ziemlich dankbar in diesem Moment.

Die Front ist wackelig. Aber wenn ein neuer Kernel etwas zerlegt, muss man nicht zwangsläufig mit ihm fallen. Man tritt einen Schritt zurück, lächelt über die eigene Hybris und macht weiter.

Auch das gehört zur vollständigen Bilanz.