Xperia 10 mit LOS 19.1 lässt sich nicht flashen

  • 20 Antworten
  • Neuester Beitrag
Diskutiere Xperia 10 mit LOS 19.1 lässt sich nicht flashen im Sony Xperia 10 Forum im Bereich Sony Forum.
DBan

DBan

Ambitioniertes Mitglied
Und weil es so schön ist - das nächste Problem.
Ich weiß nicht ob das Problem vor dem Monitor sitzt (mangelndes Wissen) oder falsche Interpretation der Symptome.

Ich wollte jetzt mal "Back to Stock-ROM".
Da funktioniert weder "Sony_Mobile_Flasher_v0.9.34.0_Linux" noch "XperiaCompanion".
XperiaCompanion würde evtl. die Firmware flashen, sagt aber "ich kann nicht weil der BL unlockt ist.
Den BL locken geht nicht (null reaktion bei fastboot flash oder sonstwas.
Auf dem Device läuft LOS 19.1 und Lineage-Recoverie.
Die einzigen Info die ich gefunden habe: Lineage-Recovery "vernagelt" Zugriffe von außen, ein TWRP mit Lineage-Recovery zu
installieren geht nicht; auch "fastboot boot twrp.img" geht nicht.

Meine Interpretation: ein mal Lineage-Recovery - immer! Lineage-Recovery!
Keine Handy-Werkstatt gefunden die bei Sony FW installieren kann.
Ich glaube das war mein letztes Sony.
Deklaration: "schöner" Briefbeschwerer der "noch" läuft aber außer LOS nichts mehr zulässt.

Meine Samsung sind ja auch "a weng" speziell - aber von dem Mist meilenweit entfernt.

Falls hier ein "Sony-Kenner" liest und eine Lösung kennt: bitte melden!
Ich bin bereit jeden "Trick" zu testen - weil schlimmer kann's nicht werden. Wenn ein echter Briefbeschwerer (tot, kein Zucken mehr) raus kommt dann ist es auch "wurscht" - ist es halt ein Ersatzteilträger!
 
Zuletzt bearbeitet:
TheMissingLink

TheMissingLink

Senior-Moderator
Teammitglied
*Info*
für die Suche den Titel angepasst
 
DBan

DBan

Ambitioniertes Mitglied
@TheMissingLink
Danke für's Handanlegen!
 
chrs267

chrs267

Dauergast
@DBan Du kannst doch über die Lineage Recovery mit ADB arbeiten. Mit ADB wiederum kannst du mit dd jede Partition flashen.
Code:
adb shell dd if=TWRP_IMG of=/dev/block/by-name/recovery
 
DBan

DBan

Ambitioniertes Mitglied
@chrs267
Das klingt erst mal gut. Teste ich morgen & berichte dann hier. Wenn damit sich TWRP flashen lässt würde mir das reichen.
Ziel wäre dann "LOS with microG". Natürlich müsste ich dann aufpassen das nicht nebenbei wieder Lineage-Recovery irgendwie
drauf kommt. (Ich bin LOS-Fan. Aber was die sich mit dem Recovery gedacht haben - schlicht "Mist".)
Erst mal danke für den Tip!
 
chrs267

chrs267

Dauergast
...oder hast du A/B Slots? Dann funktioniert das natürlich nicht und du musst das TWRP.img manuell ins boot.img patchen.
 
DBan

DBan

Ambitioniertes Mitglied
A/B. Sollte ich hinbekommen. Ich lese über ADB-Shell erst mal die Partitionen aus. Wobei ich nicht gerootet habe.
Ob da dann "dd" schreibt ??? Merke ich dann morgen.
 
chrs267

chrs267

Dauergast
@DBan Mit A/B muss das boot.img und das twrp.img entpackt werden, um die ramdisk auszutauschen. Du kannst dann nicht mit dd arbeiten, weil du keine Partition /recovery hast. Die Recovery befindet sich im boot.img.


DBan schrieb:
Wobei ich nicht gerootet habe.
Ob da dann "dd" schreibt ???
Ja klar. In der Recovery gibts kein root oder nicht, da bist du immer als root angemeldet. Sonst ließe sich ja nichts installieren oder flashen.
 
Zuletzt bearbeitet:
DBan

DBan

Ambitioniertes Mitglied
LTALabel boot_b devinfo fsmetadata mmcblk0 persist splash tzxfl_a xfl_a
TA cdt diag hyp_a mmcblk0rpmb pmic_a ssd tzxfl_b xfl_b
abl_a cmnlib64_a dip hyp_b modem_a pmic_b sti tzxflattest_a xflkeystore
abl_b cmnlib64_b dpo keymaster_a modem_b rddata storsec tzxflattest_b xflkeystorebak
apdp cmnlib_a dsp_a keymaster_b modemst1 rdimage_a system_a userdata
appslog cmnlib_b dsp_b keystore modemst2 rdimage_b system_b vendor_a
bluetooth_a ddr frp limits msadp rpm_a toolsfv vendor_b
bluetooth_b devcfg_a fsc logfs oem_a rpm_b tz_a xbl_a
boot_a devcfg_b fsg misc oem_b sec tz_b xbl_b
Das zeigt "a/b"-Device. Und keine Recovery-Partition.
chrs267 schrieb:
TWRP.img manuell ins boot.img patchen.
@chrs267
??? Meinst du mit Magisk patchen?
Ich habe von der FW das boot.img extrahiert und jetzt von Magisk patchen lassen. Ergebnis: magisk_patched-25200_boot.img

Excuse me: ein TWRP noch nie selbst gepatcht.
 
Zuletzt bearbeitet:
chrs267

chrs267

Dauergast
@DBan Die Recovery im boot.img muss durch TWRP ersetzt werden.

TWRP lässt sich nicht mit
Code:
fastboot boot TWRP
booten? Bekommst du einen Fehler angezeigt?
 
DBan

DBan

Ambitioniertes Mitglied
Ha! (für halber Sieg)
@chrs267
Mein Lieber, das Problom sitzt vor dem Bildschirm!
Ich habe nicht an Sony Flash-Modus gedacht.
Grünes Licht ist ein Zeichen für den Flash-Modus
Blaues Licht ist ein Zeichen für den Fastboot-Modus
Fastboot-Modus ist VolUp press&hold UND usb-kabel
Flash-Modus ist VolDown press&hold UND usb-kabel

Und siehe da, kaum macht man's richtig funktioniert's. Zumindest ist jetzt TWRP drauf und "LOS with microG".
Wichtig:
fastboot getvar current-slot
fastboot --set-active=b
fastboot flash boot twrp-3.6.2_9-0-kirin.img (ohne _a/_b schreibt es in den aktiven Slot)

Herzlichen Dank für deine Hilfe!

i.M. keine Lust mich weiter zu quälen (bac to FW). Mache ich vlt. irgend wann.
 
chrs267

chrs267

Dauergast
DBan schrieb:
fastboot flash boot twrp-3.6.2_9-0-kirin.img
Damit hast du jetzt /boot mit TWRP überschrieben. So lässt sich das System nicht mehr booten, sondern nur noch TWRP.
 
DBan

DBan

Ambitioniertes Mitglied
Stimmt! Ich hatte
fastboot flash boot_a twrp-3.6.2_9-0-kirin.img und
fastboot flash boot_b twrp-3.6.2_9-0-kirin.img
damit in beide boot geschrieben.
Wai (warum auch immer) ist es 1x in LOS with microG gebootet.
Mal versucht zu eruieren.
fastboot --set-active=a : es bootet LOS-Recovery
fastboot --set-active=b : es bootet LOS with microG

Kann es sein das irgendwo LOS-Recovery eine Prüfung eingebaut hat?
Weil fastboot flash boot_a twrp-3.6.2_9-0-kirin.img bleibt nicht erhalten.
Wie wird man den Mist los?

Generell: es wird wohl auf FW neu flashen hinaus laufen.
Der Sony-Flasher sagt "BL ist unlockt". Wenn ich den jetzt "re-lock" müsste des Sony-Flasher die FW neu flashen können.
Und mit dem von Sony erhaltenen Unlock-Code könnte ich dann wieder unlocken. Und die FW wäre wieder "Werkszustand",
alles was da vorher geflasht wurde wäre WEG?
 
chrs267

chrs267

Dauergast
DBan schrieb:
Kann es sein das irgendwo LOS-Recovery eine Prüfung eingebaut hat?
Weil fastboot flash boot_a twrp-3.6.2_9-0-kirin.img bleibt nicht erhalten.
Wie wird man den Mist los?
Nein, solche Prüfungen gibt es bei A/B nicht. In der Firmware unter /system/bin liegt auch kein entsprechendes Script, das eine Custom Recovery mit der von LOS überschreiben würde.

DBan schrieb:
Und die FW wäre wieder "Werkszustand",
alles was da vorher geflasht wurde wäre WEG?
Ja, alles was davor geflasht wurde und nun überschrieben ist, ist weg. Was soll denn noch erhalten sein? LOS besteht nur aus /boot, /system und /vendor. Die originale Firmware von Sony ist viel umfangreicher und überschreibt selbstverständlich jede Custom ROM.
Beitrag automatisch zusammengefügt:

@DBan Das ist doch deine Firmware, oder?
lineage-19.1-20220625-microG-kirin.zip

Hab dir ein boot.img (aus o.g. Firmware) mit TWRP (twrp-3.6.2_9-0-kirin.img) anstelle der LOS Recovery erstellt. Probier es mal aus. Magisk ist nicht enthalten, muss ggf. noch von dir gepatcht werden, falls du es benötigst.
 

Anhänge

  • boot_twrp.zip
    31,6 MB Aufrufe: 1
Zuletzt bearbeitet:
DBan

DBan

Ambitioniertes Mitglied
Screenshot_20220730-170201_Magisk.pngScreenshot_20220730-170237_Einstellungen.pngScreenshot_20220730-170330_Einstellungen.png

Slot_b; DEIN boot.img; LOS with microG; Magisk

Dein boot.img fastboot boot_a + boot_b
Jetzt muss ich etwas Anderes machen 😫
Morgen versuche ich noch Slot_a zu installieren.
Bis dahin - vorerst mal vielen Dank!
 
chrs267

chrs267

Dauergast
@DBan Was ist denn mit TWRP?? Lässt es sich starten und bleibt installiert oder...?
 
DBan

DBan

Ambitioniertes Mitglied
Dein boot_twrp bleibt (bis jetzt) im Slot_b erhalten. Arbeitet - damit dann Magisk installiert und rebootet.
Schau'n mer ma morgen 😁
So leichte Erinnerungen an mein damaliges Sony(Z1c) kommen wieder auf.
Falls Sony nichts vernünftiges (nach meinen Anforderungen) bringt bleibt das Xperia10 vorerst das letzte.
Wobei mein s10e als Daily-Driver absolut problemlos läuft (bereits auf iodeOS 3.1 upgedatet.
Was ich mit dem Xperia10 mache weiß ich noch nicht (vorerst behalten zum experimentieren) oder jemand kommt "haste was?".
Mal schauen.

Das Einzige was mich i.M. interessiert: wo ist der Unterschied
- fastboot flash boot_b twrp.img
- fastboot flash boot_b boot_twrp.img
Das ist aber i.M. zugegeben ein rein akademisches Wissen.
Motto: man wird alt wie ne Kuh - und lernt immer noch dazu.
 
chrs267

chrs267

Dauergast
DBan schrieb:
Dein boot_twrp bleibt (bis jetzt) im Slot_b erhalten. Arbeitet - damit dann Magisk installiert und rebootet.
Ich deute das als TWRP lässt sich starten und bleibt installiert.

DBan schrieb:
Das Einzige was mich i.M. interessiert: wo ist der Unterschied
- fastboot flash boot_b twrp.img
- fastboot flash boot_b boot_twrp.img
twrp.img = Recovery
boot_twrp.img = reguläres boot.img

Um den Unterschied eines A/B Gerätes zu einem herkömmlichen A-only Gerät zu verstehen, muss man den Updateprozess beider Geräte kennen.

A-only: Ein OTA-Update wird als flashbare ZIP runtergeladen und gespeichert. Ist der Vorgang abgeschlossen, bootet das Gerät in die Recovery und damit raus aus dem laufenden System. Nur von dort aus können systemrelevante Partitionen wie z.B. /system oder /vendor neu beschrieben werden, da ansonsten das System crashen würde.
In der Recovery wird das Update als flashbare ZIP erkannt > auf /cache entpackt > Partitionen werden blockweise neu beschrieben/gepatcht. Die Schritte werden anhand des Scripts unter ~/META-INF/com/google/android/updater-script abgearbeitet.
Ist das Script durchgelaufen und alles ist verifiziert, startet das System neu. Die ZIP beinhaltet klassischerweise ein boot.img und für jede weitere Partition die Dateien *.transfer.list, *.patch.dat und *.new.dat (standardmäßig mit brotli als *.br komprimiert).

A/B: Das OTA-Update wird während des laufenden Betriebes im Hintergrund installiert, warum es auch als Seamless Update von Google bezeichnet wird. Die erforderlichen Dateien werden hierbei nicht runtergeladen und zwischengespeichert, sondern nach Bedarf gestreamt und sofort auf den inaktiven Slot geschrieben. Ist der Prozess beendet, wird der Bootslot durch die Update Engine (steuert den Updateprozess bei A/B Geräten) gewechselt, sodass der inaktive Slot als aktiv markiert wird. Der folgende Neustart bootet dann das Update.
Bei diesem Updateprozess sind die Partitionen /recovery und /cache nicht mehr nötig und daher überflüssig. Dadurch, dass das Update auf den inaktiven Slot geschrieben wird, wird der der laufende Betrieb nicht gestört und das Update muss nicht von außerhalb, sprich über die Recovery als eigenständige Partition, installiert werden. Die ZIP für diese Art von Update beinhaltet immer u.a. eine payload.bin, die einen Container für die einzelnen Partitionsimages bildet. Ein Abwandlung des "CRX Package"-Formats, das z.B. für Chrome Erweiterungen genutzt wird (.crx).

Natürlich kann nicht gänzlich auf die Recovery verzichtet werden. Da aber /recovery und /boot vom Aufbau her identisch sind, hat Google sie zusammengeführt. Der Aufbau ist:
- Kernel
- dtb.img (Device Tree Blobs)
- ramdisk.img
- je nach Hersteller/Modell noch zusätzlicher Inhalt

Das ramdisk.img beinhaltet im Allgemeinen alle erforderlichen init-Scripts und Binaries, um das System oder die Recovery zu booten. Bei A-only wird dazu die entsprechende Partition mit dem entsprechenden ramdisk.img geladen. Bei A/B nur noch die Partition /boot, auf der wiederum die im ramdisk.img enthaltenen Binaries inkl. init-Scripts für das System oder eben für die Recovery ausgeführt werden.

Es gibt diverse Tools, mit denen ein boot.img ent-/gepackt werden kann, z.B. Googles unpack_bootimg/mkbootimg aus dem AOSP. Beliebter ist aber inzwischen das von Magisk erstellte Tool magiskboot(*), welches seit einiger Zeit auch zum Standard bei TWRP gehört.
Mithilfe dieses Tools wird die Stock Recovery innerhalb des boot.img durch TWRP ersetzt. Der Ablauf ist recht einfach:
Sowohl das boot.img als auch das twrp.img werden entpackt (magiskboot unpack -n IMAGE) und im Anschluss wird das boot.img mit dem ramdisk.img (twrp.img) neu gepackt, während das ursprüngliche ramdisk.img einfach ignoriert und weggelassen wird. Fertig ist das boot.img mit TWRP.


(*) Die entsprechende Binary ist nur in den flashbaren ZIPs von Magisk enthalten (bis v21.4), in späteren Versionen nur noch als Library (*.so), die nicht ohne weiteres ausgeführt werden kann. Die Binary ist auf allen Android Devices ohne root-Rechte via Terminal ausführbar (./magiskboot). Für Windows oder Linux gibt es keine entsprechende Binary.
 
DBan

DBan

Ambitioniertes Mitglied
Ich habe jetzt in BEIDEN Slot
- DEIN boot_twrp.img
- "LOS with microG"
- Magisk

Status:
- egal, welchen Slot ich als aktiv setze: es bootet in "LOS with microG" mit Magisk aktiv.
- in beiden ist TWRP startbar / nichts mehr mit Lineage-Recovery!
- Zustand ist hiermit so wie erwünscht.
- schade das es hier keinen Donate-Button gibt; mein Dank ist dir gewiss; du hast etwas gut bei mir!
😀😀😀
 
chrs267

chrs267

Dauergast
@DBan Ich musste etwas weiter ausholen, damit es auch gut verständlich ist. Aber so kennt man die Hintergründe und das kann viel Ärger ersparen. Der Systemaufbau ist ja schon bedeutend anders mit A/B Slots.
 
Ähnliche Themen - Xperia 10 mit LOS 19.1 lässt sich nicht flashen Antworten Datum
4