Magisk-Flash fehlgeschlagen? Erst das Boot-Image diagnostizieren, dann zurücksetzen

Ein Gerät, das nach einem Magisk-Flash nicht mehr startet, ist ein Diagnoseproblem, kein Fall für einen Reset. Sechs Dinge verursachen das üblicherweise, das beobachtete Symptom grenzt sie meist auf ein oder zwei ein, und keines davon behebst du durch Löschen deiner Daten. Gehe die Tabelle unten durch, bevor du etwas Destruktives erwägst.

Die sechs möglichen Ursachen

Das sind Kandidaten, keine Urteile. Es können mehrere gleichzeitig zutreffen, und welche verantwortlich ist, hängt von Gerät, Firmware-Build und dem ab, was du geflasht hast.

1. Ein Boot-Image vom falschen Build. Das Image stammt aus einer Firmware, die nicht zu der auf dem Gerät installierten passt, und sei es nur um einen Sicherheitspatch-Stand.
2. Du hast die falsche Partition gepatcht. Auf manchen Geräten liegt das Ramdisk in boot, auf anderen in init_boot. Wer die falsche patcht, bekommt ein Gerät, das nicht startet.
3. Eine Anforderung von Verified Boot oder vbmeta wurde nicht erfüllt. Die Verifizierungskette des Geräts hat das veränderte Image abgelehnt, oder der vbmeta-Zustand passt nicht zu dem, was geflasht wurde.
4. Der Bootloader ist gesperrt oder wurde wieder gesperrt. Ein gesperrter Bootloader lädt kein verändertes Boot-Image, und Flashen auf ihm erzeugt eigene Fehler.
5. Der falsche Slot. Auf A/B-Geräten ging das Image in den inaktiven Slot, oder der aktive Slot hat sich zwischen den Schritten geändert.
6. Ein Modul oder ein Konflikt nach dem Start. Der Patch hat funktioniert, das Gerät ist gestartet, und etwas, das danach läuft, hat es zum Absturz gebracht.

Beachte, was nicht auf der Liste steht: deine Nutzerdaten. Keine dieser sechs Ursachen liegt in der Datenpartition, und keine wird durch deren Löschen behoben.

Tabelle zum Ausschließen der Ursache

Suche die Zeile, die zu deiner Beobachtung passt.

Diese Tabelle leistet, was eine nummerierte Liste von Lösungen nicht kann. Das Symptom grenzt die Kandidaten ein, bevor du eine Stunde mit der falschen Ursache verlierst.

Das passende Build

Bei dieser Ursache lohnt sich der meiste Aufwand, denn sie lässt sich am leichtesten falsch machen, während man glaubt, alles richtig gemacht zu haben.

Ein gepatchtes Boot-Image stammt von einem bestimmten Firmware-Build. Die richtige Quelle ist die Firmware für deine genaue Modellnummer und deine genaue Build-Nummer, einschließlich des Sicherheitspatch-Stands. Nicht dasselbe Handymodell einer anderen Region. Nicht dieselbe Versionsnummer von vor einem Monat. Sondern genau das Build, das gerade auf dem Gerät installiert ist.

Hier passieren Fehler:

• Modellvarianten. Derselbe Marketingname deckt oft mehrere Hardwarevarianten mit unterschiedlicher Firmware ab. Eine Snapdragon- und eine Exynos-Version desselben Handys sind hier verschiedene Geräte. Auch Providervarianten unterscheiden sich.
• Region. Die Firmware desselben Modells unterscheidet sich je nach Region, und die Images sind nicht austauschbar.
• Build-Abweichung. Das Gerät hat nach oder vor dem Download der Firmware ein Update bekommen. Maßgeblich ist die Build-Nummer auf dem Gerät.
• Umgepackte Uploads. Ein Image von einem Filehoster ist eine Unbekannte. Nutze die Firmware-Verteilung des Herstellers und prüfe Prüfsummen, wo sie veröffentlicht sind.

Prüfe das installierte Build in Settings unter About phone, bevor du etwas herunterlädst. Startet das Gerät nicht, ist die Build-Nummer eventuell im Bootloader oder im Download-Modus sichtbar. Fotografiere sie.

Unsere Liste rootbarer Geräte zeigt, welche Varianten welcher Modelle funktionierende Root-Wege haben und wo die Fallen bei den Varianten liegen.

boot.img und init_boot.img sind nicht austauschbar

Das erwischt auch Leute, die schon erfolgreich gerootet haben, denn die Regel hat sich mitten in der Android-Geschichte geändert.

Die Dokumentation des Android Open Source Project beschreibt die Änderung direkt: Geräte, die mit Android 13 erschienen sind, haben ein neues Image init_boot mit dem generischen Ramdisk, während Geräte, die von Android 12 auf 13 aktualisiert wurden, dieselbe Architektur wie unter Android 12 nutzen.

Daraus folgt in der Praxis:

Die Falle: Ein Gerät mit Android 14 kann in jeder der beiden Zeilen stehen, je nachdem, womit es ausgeliefert wurde. Die aktuell installierte Android-Version verrät dir nicht, welche gilt. Entscheidend ist die Version, mit der das Gerät erschienen ist.

Die Installationsdokumentation von Magisk erklärt, wie du herausfindest, was für dein Gerät gilt, und nennt Ausnahmen bei manchen Geräten. Lies sie für dein konkretes Gerät, statt von der Android-Version auf der Packung auszugehen.

Wer das falsch macht, bekommt einen sauber wirkenden Flash und ein Gerät, das nicht startet. Genau deshalb gehört das weit nach oben auf die Ausschlussliste.

Die Frage nach vbmeta

Android Verified Boot prüft die Integrität dessen, was der Bootloader gleich lädt. Ein verändertes Boot-Image stimmt nicht mit den erwarteten Hashes überein, und wie das Gerät darauf reagiert, hängt von der Implementierung des Herstellers ab.

Manche Geräte verlangen, dass der Verifizierungszustand für ein verändertes Image angepasst wird, andere nicht. Bei manchen erzwingt die Änderung dieses Zustands beim nächsten Start aus Sicherheitsgründen das Löschen der Daten. Dieses Verhalten ist geräteabhängig und weder zwischen Herstellern noch zwischen Modellen desselben Herstellers einheitlich.

Wegen dieser Unterschiede nennt dieser Artikel keinen vbmeta-Befehl zum Ausführen. Falsche Verifizierungs-Flags auf einem Gerät, das sie nicht brauchte, können dich deine Daten kosten, und gar keine auf einem Gerät, das sie brauchte, erzeugen genau den Bootloop, den du beheben willst. Ermittle die Anforderung für dein genaues Modell aus der Dokumentation des Herstellers oder einer gerätespezifischen Quelle, bevor du daran etwas änderst.

Warnung vor destruktiver Aktion: Auf manchen Geräten löst das Flashen von vbmeta mit deaktivierter Verifizierung beim nächsten Start ein vollständiges Löschen der Nutzerdaten aus. Das ist nicht rückgängig zu machen. Prüfe das Verhalten deines Geräts, bevor du es ausführst.

Zurück zu einem startfähigen Zustand

Ist das Gerät im Fastboot und hast du das richtige Original-Boot-Image für das installierte Build, macht das Zurückspielen die Änderung rückgängig. Dabei wird nur die Boot-Partition beschrieben. Die Nutzerdaten bleiben unberührt.

Die Voraussetzungen der Reihe nach:

1. Das Gerät startet im Fastboot und ein Computer erkennt es. Falls nicht, beginne hier.
2. Du hast das ungepatchte Original-Image für das genau installierte Build, aus der Verteilung des Herstellers.
3. Du weißt, in welche Partition es gehört, laut Tabelle oben.
4. Du weißt, welcher Slot aktiv ist, falls das Gerät A/B-Slots nutzt.

Fehlt etwas davon, höre auf und beschaffe das Fehlende, statt zu improvisieren. Ein ungefähr passendes Image in eine ungefähr passende Partition zu flashen, macht aus einem rettbaren Zustand einen schlechteren.

Wenn das Modul das Problem ist

Wurde das Gerät erfolgreich gerootet, lief normal und hat erst nach der Installation eines Moduls in eine Neustartschleife geraten, ist die Diagnose einfach, und die Lösung hat mit dem Boot-Image gar nichts zu tun.

Root-Frameworks bieten Wege, mit deaktivierten Modulen zu starten, damit du das Problemmodul entfernen kannst. Die Dokumentation von Magisk beschreibt eine Tastenfolge beim Start, mit der das System ohne Module hochfährt. KernelSU dokumentiert einen eigenen Rettungsweg, unter anderem das Ausführen seines Kommandozeilen-Tools aus einer Recovery-Shell, um Module aufzulisten, zu deaktivieren oder zu deinstallieren.

Beide Wege betreffen nur das Modulverzeichnis und lassen die Nutzerdaten in Ruhe. Nutze die aktuelle Dokumentation der Root-Lösung, die du tatsächlich installiert hast, denn dieses Verhalten hat sich über Versionen geändert, und ältere Forenanleitungen beschreiben womöglich einen Mechanismus, den es nicht mehr gibt.

Module, die früh im Startvorgang eingreifen, Systemkomponenten ersetzen oder Geräteeigenschaften ändern, sind riskanter als andere. Unsere Anleitung zu Magisk-Modulen zeigt, welche Kategorien bekanntermaßen Startprobleme verursachen und was du vor der Installation prüfst.

Nicht jeder Fehlerzustand ist rettbar

Hier die Grenzen ganz offen, denn der Rest des Artikels ist optimistisch und die Grenzen sind real:

• Wurde der Bootloader gesperrt, nachdem bereits ein verändertes Boot-Image geflasht worden war, lädt das Gerät womöglich nichts mehr und nimmt auch keine neuen Flashs an. Dieser Zustand lässt sich ohne Hersteller-Tools schwer oder gar nicht beheben.
• Wurde der Flash mitten im Schreiben einer Partition unterbrochen, hängt das Ergebnis davon ab, welche Partition und wie weit der Vorgang war.
• Startet das Gerät nicht mehr im Fastboot und wird in keinem Modus erkannt, liegst du außerhalb dessen, was dieser Artikel abdeckt. Lies Soft Brick vs. Hard Brick, um den Zustand einzuordnen.
• Wird die Original-Firmware für dein genaues Build vom Hersteller nicht mehr angeboten, ist das exakte Image womöglich nicht wiederherstellbar, und die Alternativen laufen meist auf ein Löschen der Daten hinaus.

Wir behaupten nicht, dass jeder fehlgeschlagene Magisk-Flash rettbar ist. Manche sind es nicht, und ehrlich ist es, das zu sagen, bevor du Geld ausgibst, um es herauszufinden.

Häufige Fragen

Löscht das Flashen des Stock-Boot-Images meine Daten? Das Flashen der Boot-Partition berührt die Nutzerdatenpartition nicht. Daten löschen ein Reset, eine Formatierung, ein Wipe-Flag oder eine Änderung des Verifizierungszustands auf Geräten, wo das ein Löschen erzwingt. Achte auf den Vorgang, nicht auf die Beruhigung.

Kann ich einfach das gepatchte Image erneut flashen? Dasselbe Image erneut zu flashen liefert dasselbe Ergebnis. Ist das Image das Problem, hilft Wiederholen nicht. Ändere anhand der Ausschlusstabelle gezielt etwas und versuche es dann erneut.

Mein Gerät startet, aber Magisk sagt, es sei nicht installiert. Das heißt meist, dass der Flash in den inaktiven Slot ging oder das Gerät vom anderen Slot gestartet ist. Prüfe, welcher Slot aktiv ist. Es kann auch bedeuten, dass der Patch auf die falsche Partition ging, was der Abschnitt zu boot vs. init_boot behandelt.

Brauche ich TWRP oder eine Custom Recovery dafür? Nicht für das Zurückspielen des Boot-Images, das ein Fastboot-Vorgang ist. Eine Custom Recovery ist bei manchen Szenarien zum Entfernen von Modulen nützlich und bringt auf modernen Partitionslayouts eigene Kompatibilitätsfragen mit. Unsere Anleitung zur TWRP-Installation zeigt, wo sie passt und wo nicht.

Gilt das nur für Magisk? Nein. Images vom falschen Build, Partitionsverwechslungen, Verifizierungsanforderungen und Slot-Fehler betreffen jede Änderung am Boot-Image. Bei KernelSU und APatch treten dieselben Fehlerkategorien mit derselben Diagnoselogik auf, und die drei Ansätze unterscheiden sich in Punkten, die du kennen solltest, bevor du dich entscheidest.

Soll ich einfach auf Werkseinstellungen zurücksetzen und neu anfangen? Nicht als erster Schritt. Keine der sechs Ursachen liegt in der Datenpartition, ein Reset behebt also wohl keine davon. Er ist unumkehrbar und vernichtet auf einem Gerät mit dateibasierter Verschlüsselung samt den Daten auch das Schlüsselmaterial. Gehe zuerst die Tabelle durch.

---

Weiterlesen: Bootloop ohne Datenverlust beheben · Was jedes Symptom auf dem Boot-Screen bedeutet · Soft Brick vs. Hard Brick · Fastboot-Gerät wird nicht erkannt · Wichtige Magisk-Module

Quellen: Android Open Source Project, Dokumentation zur generischen Boot-Partition. Offizielle Installationsdokumentation von Magisk. Offizielle Rettungsdokumentation von KernelSU.

Zuletzt geprüft: 24. August 2026. Partitionslayouts, Verified-Boot-Anforderungen und Flash-Verfahren unterscheiden sich je nach Hersteller, Modell und Build. Gleiche vor jedem Befehl mit der offiziellen Dokumentation deines Geräts ab.