Flash di Magisk non riuscito? Diagnostica la boot image prima di cancellare tutto

Un dispositivo che non si avvia dopo il flash di Magisk è un problema di diagnosi, non di ripristino. Sei fattori causano comunemente il problema; il sintomo che hai visto di solito restringe il campo a una o due cause e nessuna si risolve cancellando i dati. Segui la tabella per esclusione qui sotto prima di prendere in considerazione qualsiasi operazione distruttiva.

Le sei cause possibili

Sono ipotesi, non verdetti. Ne possono valere più d’una insieme, e quella responsabile dipende dal tuo dispositivo, dalla build del firmware e da ciò che hai flashato.

1. Una boot image di un’altra build. L’immagine viene da un firmware che non corrisponde a quello installato sul dispositivo, anche solo per un livello di patch di sicurezza.
2. Hai patchato la partizione sbagliata. Su alcuni dispositivi la ramdisk si trova in boot, su altri in init_boot. Patchare quella sbagliata produce un dispositivo che non si avvia.
3. Non è stato rispettato un requisito di verified boot o di vbmeta. La catena di verifica del dispositivo ha rifiutato l’immagine modificata, oppure lo stato di vbmeta non corrisponde a ciò che è stato flashato.
4. Il bootloader è bloccato, o è stato ribloccato. Un bootloader bloccato non carica una boot image modificata, e flashare in quelle condizioni produce errori propri.
5. Lo slot sbagliato. Sui dispositivi A/B l’immagine è finita nello slot inattivo, oppure lo slot attivo è cambiato tra un’operazione e l’altra.
6. Un modulo o un conflitto dopo l’avvio. La patch ha funzionato, il dispositivo si è avviato e qualcosa in esecuzione dopo l’avvio lo ha mandato in crash.

Nota cosa non c’è in quell’elenco: i tuoi dati utente. Nessuna di queste sei cause nasce nella partizione dei dati e nessuna si risolve cancellandola.

Tabella per esclusione delle cause

Trova la riga che corrisponde a ciò che hai osservato davvero.

Quella tabella fa il lavoro che un elenco numerato di soluzioni non può fare: il sintomo restringe le ipotesi prima che tu perda un’ora su quella sbagliata.

Corrispondenza esatta della build

È la causa a cui dedicare più tempo, perché è la più facile da sbagliare credendo di aver fatto tutto bene.

Una boot image patchata deriva da una build specifica del firmware. La fonte corretta è il firmware per il tuo numero di modello esatto e il tuo numero di build esatto, che comprende il livello di patch di sicurezza. Non lo stesso modello in un’altra regione. Non lo stesso numero di versione di un mese prima. La build esatta installata ora sul dispositivo.

Dove si sbaglia:

• Varianti di modello. Lo stesso nome commerciale copre spesso più varianti hardware distinte, con firmware diversi. Una versione Snapdragon e una Exynos dello stesso telefono, per questo scopo, sono dispositivi diversi. Le varianti degli operatori sono un altro caso ancora.
• Regione. Il firmware dello stesso modello cambia da regione a regione e le immagini non sono intercambiabili.
• Build che cambia. Il dispositivo ha ricevuto un aggiornamento dopo (o prima) che scaricassi il firmware. Conta il numero di build presente sul dispositivo.
• Caricamenti riconfezionati. Un’immagine presa da un servizio di file hosting è un’incognita. Usa la distribuzione del produttore e verifica i checksum quando sono pubblicati.

Prima di scaricare qualsiasi cosa, controlla la build installata in Settings, sotto About phone. Se il dispositivo non si avvia, il numero di build può comparire nella schermata del bootloader o della modalità download. Fotografalo.

Il nostro elenco dei dispositivi rootabili indica quali varianti di quali modelli hanno un percorso di root funzionante e dove stanno le trappole delle varianti.

boot.img e init_boot.img non sono intercambiabili

Questo punto mette in difficoltà anche chi ha già rootato con successo, perché la regola è cambiata nel corso della storia di Android.

La documentazione dell’Android Open Source Project descrive direttamente il cambiamento: i dispositivi lanciati con Android 13 hanno una nuova immagine init_boot che contiene la ramdisk generica, mentre quelli aggiornati da Android 12 ad Android 13 mantengono la stessa architettura che avevano con Android 12.

La regola pratica che ne deriva:

La trappola è che oggi un dispositivo con Android 14 può trovarsi in una riga o nell’altra, a seconda di come era uscito. La versione di Android installata ora non dice quale caso valga: conta la versione con cui il dispositivo è stato lanciato.

La documentazione di installazione di Magisk spiega come stabilire quale caso vale per il tuo dispositivo e segnala che su alcuni hardware esistono eccezioni. Leggila per il tuo dispositivo preciso, invece di dedurlo dalla versione di Android indicata sulla scatola.

Sbagliare questo punto produce un flash dall’aspetto pulito e un dispositivo che non si avvia, ed è proprio per questo che sta in alto nell’elenco delle esclusioni.

La questione vbmeta

Android Verified Boot controlla l’integrità di ciò che il bootloader sta per caricare. Una boot image modificata non corrisponde agli hash attesi, e la reazione del dispositivo dipende dall’implementazione del produttore.

Alcuni dispositivi richiedono di modificare lo stato di verifica perché un’immagine modificata si avvii, altri no. Su alcuni, cambiare quello stato forza una cancellazione dei dati al riavvio successivo, come misura di sicurezza. Questi comportamenti dipendono dal dispositivo e non sono coerenti tra produttori, e nemmeno tra modelli dello stesso produttore.

Questa variabilità è il motivo per cui l’articolo non ti dà un comando vbmeta da eseguire. Usare i flag di verifica sbagliati su un dispositivo che non ne aveva bisogno può costarti i dati, e non usarne su uno che li richiedeva produce il bootloop che stai già cercando di risolvere. Trova il requisito per il tuo modello esatto, nella documentazione del produttore o in una fonte specifica per il dispositivo, prima di toccare qualsiasi cosa.

Avviso su un’azione distruttiva: su alcuni dispositivi, flashare vbmeta con la verifica disattivata fa cancellare tutti i dati utente al riavvio successivo. È irreversibile. Verifica il comportamento del tuo dispositivo prima di eseguirlo.

Tornare a uno stato avviabile

Se il dispositivo è in fastboot e hai la boot image originale corretta per la build installata, ripristinarla annulla la modifica. Quell’operazione scrive solo nella partizione boot e non tocca i dati utente.

I requisiti, in ordine:

1. Il dispositivo entra in fastboot e un computer lo rileva. In caso contrario, parti da qui.
2. Hai l’immagine originale, non patchata, per la build installata esatta, dalla distribuzione del produttore.
3. Sai in quale partizione va messa, secondo la tabella qui sopra.
4. Sai quale slot è attivo, se il dispositivo usa slot A/B.

Se manca anche uno solo di questi punti, fermati e procurati ciò che manca, senza improvvisare. Flashare un’immagine più o meno corretta in una partizione più o meno corretta è il modo in cui uno stato recuperabile diventa peggiore.

Quando il problema è il modulo

Se il dispositivo ha ottenuto il root, ha funzionato normalmente ed è entrato in ciclo solo dopo l’installazione di un modulo, la diagnosi è semplice e la soluzione non riguarda affatto la boot image.

I framework di root offrono modi per avviare con i moduli disattivati, così puoi rimuovere quello responsabile. La documentazione di Magisk descrive una sequenza di tasti durante l’avvio che fa partire il sistema con i moduli disattivati. KernelSU documenta un proprio percorso di recupero, che include l’esecuzione del suo strumento da riga di comando da una shell di recovery per elencare, disattivare o disinstallare i moduli.

Entrambi gli approcci agiscono sulla cartella dei moduli e lasciano intatti i dati utente. Usa la documentazione attuale della soluzione di root che hai installato davvero, perché questo comportamento è cambiato tra le versioni e le vecchie istruzioni dei forum possono descrivere un meccanismo che non esiste più.

I moduli che agganciano le prime fasi dell’avvio, sostituiscono componenti di sistema o modificano le proprietà del dispositivo comportano più rischi degli altri. La nostra guida ai moduli Magisk indica quali categorie hanno un precedente di problemi di avvio e cosa controllare prima di installarli.

Non tutti i guasti sono recuperabili

Ecco i limiti, senza giri di parole, perché il resto dell’articolo è ottimista e questi limiti sono reali:

• Se il bootloader è stato bloccato quando era già stata flashata una boot image modificata, il dispositivo può rifiutarsi di caricare qualsiasi cosa e può non accettare nemmeno nuovi flash. Questo stato può essere difficile o impossibile da risolvere senza strumenti del produttore.
• Se il flash è stato interrotto mentre scriveva una partizione, l’esito dipende da quale partizione e da quanto era avanzata la scrittura.
• Se il dispositivo non entra più in fastboot e non viene rilevato in nessuna modalità, sei fuori da ciò che l’articolo copre. Leggi soft brick e hard brick per inquadrare lo stato.
• Se il produttore non distribuisce più il firmware originale della tua build esatta, ripristinare l’immagine esatta può non essere possibile, e le alternative di solito comportano una cancellazione.

Non sosteniamo che ogni flash di Magisk fallito sia recuperabile. Alcuni non lo sono, e la cosa onesta è dirlo prima che tu spenda soldi per scoprirlo.

Domande frequenti

Flashare la boot image originale cancella i miei dati? Flashare la partizione boot non tocca la partizione dei dati utente. A cancellare i dati sono un ripristino, una formattazione, un flag di wipe o un cambio dello stato di verifica sui dispositivi in cui forza la cancellazione. Leggi l’operazione, non le rassicurazioni.

Posso rifare il flash dell’immagine patchata e riprovare? Flashare di nuovo la stessa immagine dà lo stesso risultato. Se il problema è l’immagine, ripetere non serve. Cambia qualcosa di preciso in base alla tabella per esclusione, poi riprova.

Il dispositivo si avvia ma Magisk dice di non essere installato. Di solito significa che il flash è andato nello slot inattivo, o che il dispositivo si è avviato dall’altro slot. Controlla quale slot è attivo. Può anche voler dire che la patch è stata applicata alla partizione sbagliata, caso trattato nella sezione su boot e init_boot.

Mi servono TWRP o una recovery personalizzata per risolvere? Non per ripristinare la boot image, che è un’operazione fastboot. La recovery personalizzata è utile per alcuni scenari di rimozione dei moduli e porta con sé questioni di compatibilità con i layout di partizioni moderni. La nostra guida all’installazione di TWRP spiega dove serve e dove no.

È un problema specifico di Magisk? No. Immagini di una build sbagliata, confusione tra partizioni, requisiti di verifica e slot non corrispondenti valgono per qualsiasi modifica della boot image. Le installazioni di KernelSU e APatch incappano nelle stesse categorie di guasto, con la stessa logica diagnostica, e i tre approcci differiscono in modi che vale la pena capire prima di sceglierne uno.

Dovrei limitarmi a fare un ripristino dei dati di fabbrica e ricominciare? Non come prima mossa. Nessuna delle sei cause nasce nella partizione dei dati, quindi è improbabile che un ripristino ne risolva una. È irreversibile e, su un dispositivo con crittografia basata su file, distrugge il materiale crittografico delle chiavi insieme ai dati. Prima segui la tabella.

---

Letture correlate: Risolvere un bootloop senza perdere i dati · Cosa significa ogni sintomo nella schermata di avvio · Soft brick e hard brick · Dispositivo fastboot non rilevato · Moduli Magisk essenziali

Fonti: Android Open Source Project, documentazione sulla partizione boot generica. Documentazione ufficiale di installazione di Magisk. Documentazione ufficiale di recupero di KernelSU.

Ultima verifica: 24 agosto 2026. Layout delle partizioni, requisiti di verified boot e procedure di flash variano in base a produttore, modello e build. Prima di eseguire qualsiasi comando, confronta con la documentazione ufficiale del tuo dispositivo.