Root mit Updates / unroot

[Oliver500]

Hallo zusammen,

ich bin (noch) nicht Besitzer eines Shiftphones, versuche mir aber einen gedanklichen "Plan" zurecht zu legen, wie ich ein solches Phone später einrichten und nutzen könnte. Ich würde ein solches Phone zum einen rooten wollen, zum anderen sollten aber trotz root noch sowohl Sicherheits- und Betriebssystemupdates (automatisch) aufgespielt werden können. Das Shift-OS würde ich nicht gegen ein anderes ROM austauschen wollen. Allerdings sollten vor einem solchen Update installierte Apps, die ihre Daten und Einstellungen nicht in einem Cloud-Service speichern, diese auch nach einem solchen Update beibehalten. Meine wichtigste Frage wäre also erst einmal: Funktionieren unter dem Shift-OS Sicherheits- und Betriebssystemupdates auch nach dem Rooten über Magisk (Austausch der Boot-Partition) weiterhin ganz normal? Und dann die Frage zu den App-Daten: Bleiben diese bei solchen Aktualisierungen stets erhalten oder gäbe es da Probleme? Letztendlich würde ich ein solches Phone ganz normal aktualisieren wollen, aber trotzdem root nutzen wollen.

Dann noch eine Frage zu einem späteren "un-root", falls das mal notwendig sein sollte: Könnte man die Boot-Partition vor dem Rooten so sichern, dass sie später ggf. wieder geflasht werden kann, um das Rooten rückgängig zu machen? Könnte man dazu die TWRP-Recovery mittels Fastboot einmalig über "fastboot boot twrp.img" starten und dann über TWRP die ungerootete Boot-Partition sichern? Falls das funktionieren würde: Könnte man nach dem Zurück-Flashen der ungerooteten Boot-Partition zum Schluss den Bootloader auch wieder über fastboot sperren, ohne dass es bei weiteren Shift-OS-Updates dann zu Problemen kommt, und hätte man dann das Phone wieder in einem unmodifizierten Zustand?

Ich bin für jede Antwort und Information zu diesen Punkten dankbar, auch falls ich hier vollkommen auf dem Holzweg sein sollte.

 

[danielp]

Hallo Oliver500, willkommen im Forum!

Meine wichtigste Frage wäre also erst einmal: Funktionieren unter dem Shift-OS Sicherheits- und Betriebssystemupdates auch nach dem Rooten über Magisk (Austausch der Boot-Partition) weiterhin ganz normal? Und dann die Frage zu den App-Daten: Bleiben diese bei solchen Aktualisierungen stets erhalten oder gäbe es da Probleme?

Ja und ja!
Ein mit Magisk gerootetes System kannst du normal mit ShiftOS Updates versorgen. Man muss nur darauf achten das man nach dem Update Root nicht verliert indem man nach dem Update aber vor dem Reboot den inaktiven Slot patcht in den dann nach dem Reboot gewechselt wird.
Die App Daten bleiben bei ShiftOS Updates erhalten. Trotzdem Backups, Backups, Bachups und habe ich es schon erwähnt Backups.

Könnte man die Boot-Partition vor dem Rooten so sichern, dass sie später ggf. wieder geflasht werden kann, um das Rooten rückgängig zu machen? Könnte man dazu die TWRP-Recovery mittels Fastboot einmalig über "fastboot boot twrp.img" starten und dann über TWRP die ungerootete Boot-Partition sichern? Falls das funktionieren würde: Könnte man nach dem Zurück-Flashen der ungerooteten Boot-Partition zum Schluss den Bootloader auch wieder über fastboot sperren, ohne dass es bei weiteren Shift-OS-Updates dann zu Problemen kommt, und hätte man dann das Phone wieder in einem unmodifizierten Zustand?

Es gibt kein voll funktionfsfähiges TWRP Recovery für das Shift6mq nur ein halbes und ein LineagOS Recovery. Vielleicht erfüllt das seinen Zweck.

Wenn du nach einem Update nicht den inaktiven Slot patcht solltest du Root auch wieder los sein und dann auch theoretisch den Bootloader wieder schließen können.

 

[Oliver500]

Hallo danielp und vielen Dank für die Informationen!

Man muss nur darauf achten das man nach dem Update Root nicht verliert indem man nach dem Update aber vor dem Reboot den inaktiven Slot patcht in den dann nach dem Reboot gewechselt wird.

Wie muss man sich das denn überhaupt mit diesen Slots A/B vorstellen? Wird ein Update immer in den gerade inaktiven Slot geflasht und dann der Status beider Slots gewechselt, sodass der gerade aktive Slot zum inaktiven Slot wird und umgekehrt? Und wie müsste man denn vorgehen, um etwas im inaktiven Slot zu patchen, und was genau muss da gepatcht werden? (Müsste man über fastboot die boot-Partition des noch inaktiven Slots mit einer durch Magisk gepatchten Version der gerade aktualisierten Boot-Partition dieses inaktiven Slots ersetzen?)

Wäre es auch möglich, einfach die Root-Anleitung neu zu durchlaufen, nachdem das Update aufgespielt und bereits neu gestartet wurde? Sprich, eine neue boot.img aus der soeben frisch installierten Version erzeugen, auf das Phone kopieren, und mit Magisk patchen, dann zurück kopieren und mittels fastboot auf das Smartphone in den jetzt aktiven Slot in die Boot-Partition flashen. Oder würde das weitere Komplikationen mit sich bringen?

Es gibt kein voll funktionfsfähiges TWRP Recovery für das Shift6mq nur ein halbes und ein LineagOS Recovery. Vielleicht erfüllt das seinen Zweck.

Mir war nicht bewusst, dass TWRP in seiner letzten aktuellen Version nicht auf dem Shift6mq funktioniert, da sich im Internet ja auch Anleitungen finden, die suggerieren, TWRP zusammen mit LineageOS installieren zu können. Das "Dirty-TWRP", was du oben verlinkt hast, scheint aber auch die Boot-Partition sichern und wiederherstellen zu können. Von daher wäre es für diesen Zweck ja geeignet. Gäbe es hier noch einen alternativen Weg, um eine boot.img zu erzeugen (sofern ich oben alles richtig verstanden habe, und das erforderlich wäre)? Das erneute Flashen der boot.img nach dem Patchen durch Magisk ginge ja dann mit fastboot. Falls alternativ auch ein erneutes rooten nach dem erfolgten Backup und einem Neustart möglich wäre, erübrigt sich wohl das extrahieren einer neuen boot.img, oder?

Sorry, dass ich diese vielen Fragen stelle, und so genau darauf eingehe, aber vielleicht hilft es ja auch dem ein oder anderen, der versucht, root + Updatemechanismus sinnvoll miteinander zu kombinieren.

 

[@Lhotze]

Praktisch funktioniert das sichern der Boot-Partition mit dem TWRP. Die originale Boot-Partition bekommt man aber auch aus dem entpackten ShiftOS-Image.
Praktisch setzt jedes Betriebssystem-Update, unabhängig ob du es aus der Update-Anwendung oder dem Recovery installierst dein Boot-Image wieder auf Auslieferung.

Deine Vermutung mit den Slots und den Wechseln nach Updates ist voll zutreffend.

Daher muss nach jedem Update das Magisk nachgepatcht werden.

Der umständliche Weg ist, jedesmal das Stock Boot-Image zu extrahieren, mit Magisk zu patchen und über Fastboot zu installieren.

Der einfache Weg ist (wenn das System bereits gerootet wurde) ein Betriebssystem-Update aus dem laufenden System über die Update-App anzustoßen, nach Beendigung das System nicht neuzustarten, die Magisk-App zu öffnen und Root in den inaktiven Slot zu patchen. Dann Neustart und man hat sein Root behalten.

Bei Systemen wie LineageOS gibt es mittlerweile sogar ein Script, welches das direkt automatisch macht. Hab aber keine Ahnung, ob ShiftOS das auch unterstützt.

Greetz

 

[Oliver500]

Hallo und vielen Dank für deine Antwort!

Die originale Boot-Partition bekommt man aber auch aus dem entpackten ShiftOS-Image.

Ich hatte mir einmal die Images von https://downloads.shiftphones.com/axolotl heruntergeladen, kann aber aus den Inhalten nicht direkt die Partitions-Images ableiten. Wie ließe sich denn aus diesen Images die Partitions-Images extrahieren, um sie mit Magisk zu patchen / mit fastboot zu flashen?

Praktisch setzt jedes Betriebssystem-Update, unabhängig ob du es aus der Update-Anwendung oder dem Recovery installierst dein Boot-Image wieder auf Auslieferung.

Aber ich nehme an, für den Fall, dass des Update aus der Update-Anwendung heraus durchgeführt wurde, immer das Boot-Image des zum Updatezeitpunkt (noch) inaktiven Slots?

Daher muss nach jedem Update das Magisk nachgepatcht werden.

Meinst du hier das Patchen des Boot-Images bzw. der Boot-Partition oder einen Patch, der für den Betrieb von Magisk selbst benötigt wird?

Der einfache Weg ist (wenn das System bereits gerootet wurde) ..., die Magisk-App zu öffnen und Root in den inaktiven Slot zu patchen.

Meinst du hier das (direkte) Patchen der Boot-Partition des zu diesem Zeitpunkt noch inaktiven Slots, der ja zu diesem Zeitpunkt ein neues (ungerootetes) Boot-Image enthält? Falls ja, kann Magisk zu diesem Zeitpunkt diese noch inaktive Boot-Partition in ihrer neuen "Version" direkt selbst patchen / verändern ohne den Umweg über irgendeine Image-Datei?

 

[@Lhotze]

Ich hatte mir einmal die Images von https://downloads.shiftphones.com/axolotl heruntergeladen, kann aber aus den Inhalten nicht direkt die Partitions-Images ableiten. Wie ließe sich denn aus diesen Images die Partitions-Images extrahieren, um sie mit Magisk zu patchen / mit fastboot zu flashen?

Die sind noch mal extra in der Payload.bin eingepackt. Hier ist ne Anleitung, wie man die extrahiert. Im Root Thread des 6mq sind auch Bootimages (gepatcht und ungepatcht) zu finden. Vll passt ja auch eines davon mit deiner Version zusammen

Aber ich nehme an, für den Fall, dass des Update aus der Update-Anwendung heraus durchgeführt wurde, immer das Boot-Image des zum Updatezeitpunkt (noch) inaktiven Slots?

Genau

Meinst du hier das Patchen des Boot-Images bzw. der Boot-Partition oder einen Patch, der für den Betrieb von Magisk selbst benötigt wird?

Magisk patcht immer das Boot-Image. Das meine ich auch.

Meinst du hier das (direkte) Patchen der Boot-Partition des zu diesem Zeitpunkt noch inaktiven Slots, der ja zu diesem Zeitpunkt ein neues (ungerootetes) Boot-Image enthält? Falls ja, kann Magisk zu diesem Zeitpunkt diese noch inaktive Boot-Partition in ihrer neuen "Version" direkt selbst patchen / verändern ohne den Umweg über irgendeine Image-Datei?

Genau so ist es.
Aus dem aktiven System wird das inaktive neue Boot-Image gepatcht um Root zu bekommen.

Greetz

 

[Oliver500]

Super, vielen Dank für deine Hilfe und die Informationen! Ich denke, damit werde ich klarkommen. Und auch vielen Dank für den Link zur Dokumentation des Payload Dumper Tools. Da scheint es mir ja fast einfacher zu sein, über das angesprochene "Dirty-TWRP" das ungerootete boot.img selbst zu erstellen, als es aus der BIN-Datei zu extrahieren (oder es über den Thread herunterzuladen - sofern es denn im Fall einer neuen Version dort schon zur Verfügung steht ).

Auf jeden Fall vielen Dank an Euch für die Hilfe und Infos! Jetzt konnte ich einige Zusammenhänge hierzu besser verstehen. Da steht der Anschaffung und Umsetzung jetzt wohl nichts mehr im Wege. Ich hoffe, es wird alles klappen.

 

[Oliver500]

Sorry, mal noch eine ganz dumme Frage zu den gepatchten Boot-Images, die man ab hier herunterladen kann: Dort ist angegeben, man solle "die gleiche Magisk Version nutzen" (wie die, mit der es gepatchet wurde). Ist das denn von Belang? Das (gepatchte) Image wird doch in diesem Fall über fastboot geflasht und kommt nicht meht mit der Magisk-App "in Kontakt" - oder brauchen die Boot-Partition und Magisk "einander"?

 

[@Lhotze]

Das Boot-Image wird gepatcht und geflashed. Das läuft dann jedesmal beim Start als verändert mit. Gleichzeitig braucht man die Magisk-App als Verwalter von Root im laufenden System. Ohne die Magisk-App kein funktionierendes Root.

Sofern nichts extra dabeisteht sind zumindest die Images die ich reingestellt haben mit 23.2 gepatcht. Aktuell ist gerade 24.2.
Ist aber kein großes Ding. Kannst das mit 23.2 gepatchte Image Installieren und die 24.2 apk von GitHub nutzen. Die wird dich dann schon auffordern das Boot-Image upzudaten. Macht es dann weitestgehend automatisch.

Greetz

 

[Oliver500]

Ja, dass die Magisk-App dann der "Verwalter" der Root-Rechte ist, war mir bekannt. Aber dass es da dann zwischen den beiden Abhängigkeiten gibt, war mir noch nicht ganz klar. Ok, wenn die App das Boot-Image es automatisch aktualisiert, wäre das ja kein Problem. Besten Dank!

 

[Revan335]

Ich mach es so.
Alles auf SD/PC laden.

Dann per fastboot das neue LOS Recovery per adb/fastboot flashen. Bei mir ein Linux statt Win/M$.
Dann ins Recovery. LOS
Per adb LOS flashen.
Reboot to Recovery. Da man dann im neuen Slot ist.
Per adb OpenGApps, Magisk, F-Droid Privileg Extension OTA flashen.
Boot LOS.

Da es leider noch keine Backup Funktion in LOS oder ein voll funktionierendes TWRP gibt, kann ich vorher leider kein Image sichern. @amartinz

 

[Oliver500]

Hallo Revan335,

danke für die Infos. Da würden mich abgesehen von den Details mal folgende Zusammenhänge interessieren:

Dann per fastboot das neue LOS Recovery per adb/fastboot flashen.

LOS steht für Lineage-OS?

Reboot to Recovery. Da man dann im neuen Slot ist.

Ist die Recovery nicht je Slot A/B ebenfalls unterschiedlich, sprich: Nur eine Recovery, egal welcher Slot gerade aktiv ist? Oder startest du dadurch in die neue Recovery, da diese ebenfalls geflasht wurde?

Da es leider noch keine Backup Funktion in LOS oder ein voll funktionierendes TWRP gibt, kann ich vorher leider kein Image sichern.

Mit vollständigen Backups über TWRP habe ich leider schlechte Erfahrungen machen müssen, weshalb ich seitdem davon Abstand nehme. Konkret konnte nach einer Rücksicherung das Profil der App "Signal" nicht mehr verwendet werden und musste neu erzeugt werden (Verlust sämtlicher Chatverläufe, Kontaktgruppen etc.). Möglicherweise lag dies auch an der damals verwendeten TWRP-Version und/oder daran wie Daten der App abgelegt / verschlüsselt / mit dem aktuellen System in Verbindung gebracht wird (irgendein Schlüssel-Speicher?), sodass es nach einer TWRP-Rücksicherung unbrauchbar war. Seitdem scheint mir ein TWRP-Backup keine 1:1 verlässliche Sicherungsvariante mehr zu sein.

 

[danielp]

Mit vollständigen Backups über TWRP habe ich leider schlechte Erfahrungen machen müssen, weshalb ich seitdem davon Abstand nehme. Konkret konnte nach einer Rücksicherung das Profil der App "Signal" nicht mehr verwendet werden und musste neu erzeugt werden (Verlust sämtlicher Chatverläufe, Kontaktgruppen etc.).

Bei Signal ist es extrem ratsam die interne Backup Funktion zu verwenden. Manche Apps schließen zurecht andere Optionen aus.
Signal verwendet den Android Keystore. Wenn du das Backup von TWRP wiederherstellen willst müsstest du auch den dort enthaltenen Schlüssel sichern und wiederherstellen damit es funktioniert. Es klappt aber ist tricky! Siehe hier!

 

[Oliver500]

Danke @danielp, das würde aber doch bedeuten, wenn ich es richtig verstanden habe, dass mittels TWRP eben nicht eine 100%ige 1:1 Kopie bzw. Sicherung erzeugt werden kann, die sich verlässlich wiederherstellen lässt - da es Ausnahmen wie Signal gibt, deren Daten nach Restore möglicherweise nicht so wiederhergestellt werden (können), dass sie wieder verwendet werden können. (oder?) Deshalb habe ich mich von TWRP-Backups verabschiedet, da ich mich nicht zu 100% darauf verlassen kann, dass nach einem Restore wieder alles wie zuvor funktioniert.

Wenn ich auf einem PC-System eine 1:1 Festplattensicherung oder -kopie durchführe, kann ich diese so wiederherstellen, dass sich zum ursprünglichen Zustand kein Unterschied ergibt - besonders auf der selben Hardware. Offenbar läuft das bei TWRP etwas anders ab. Aber auch hier müsste doch gelten: Werden alle Partitionen gesichert und alle Partitionen 1:1 wiederhergestellt, warum sollte das System dann nicht 1:1 so laufen wie vorher. Anhand des von dir verlinkten Artikels müsste das auch für die Signal-Daten gelten, wenn (entsprechend der dortigen Angaben)...

• es sich beim Restore um das selbe Gerät handelt, auf dem auch die Sicherung erstellt wurde
• der Sperrcode des Sperrbildschirms identisch ist zum Sperrcode, der aktiv war, als die Sicherung durchgeführt wurde

Trotzdem war eine Rücksicherung nicht ohne Verlust des Profils möglich. Ich meine mich zu erinnern, dass die damalige Aussage war, dass bei der verwendeten TWRP-Version der Android Key Store überhaupt nicht mitgesichert wurde.

 

[danielp]

Gut möglich das es in diesem Fall funktioniert haben könnte wenn der Keystore gesichert worden wäre.

Beschäftige mich nicht mit TB und TWRP, habe nur theoretisches Wissen. Deswegen der Link!

Heißt aber dann auch das TWRP zuverlässig ist wenn es seine Sache richtig machen würde. Vielleicht gibt es aber auch noch andere Einschränkungen die nicht erwähnt worden sind. Diese können dann mit dem temporären Aufheben des Screenlocks und damit dem entschlüsselten Keystore z. B. im Falle Signals umgangen werden können.

Aber wie immer gilt, bei eine Backupstrategie sollte auch die Wiederherstellung umfassen. Also sollte beides vorher (und auch nachher) getestet werden ob es auch funktioniert. Dann spart man sich einiges an Ärger wenn man zwar ein regelmäßiges Backup hat, es aber nicht wiederherstellen kann.

 

[Revan335]

@Oliver500
Genau, LOS -> LineageOS

Ja, pro Slot ein Recovery.
Durch den Reboot vom Recovery ins Recovery wird der Slot gewechselt.
Bspw. Slot A LOS flashen. Reboot ins Recovery und man ist im nun aktiven Slot B.

Ja, dass scheint leider so zu sein. Aber wie schon gesagt wurde gibt es bei bspw. Signal ne eigene Backup Funktion.
Ist bei TitaniumBackup TB leider auch so, wenn man dort nen Backup von bspw. Signal macht.

So mach ich das für die einzelnen:
fastboot flash recovery /Pfad/Shift6mq/lineage-18.1-202200309-recovery-axolotl.img
adb sideload /Pfad/Shift6mq/lineage-18.1-20220309-nightly-axolotl-signed.zip
adb sideload /Pfad/Shift6mq/open_gapps-arm64-11.0-pico-20220215.zip
adb sideload /Pfad/Shift6mq/Magisk-v24.1.zip
adb sideload /Pfad/Shift6mq/org.fdroid.fdroid.privileged.ota_2130.zip

Im Recovery ist das der Punkt Apply update -> Apply from ADB
Bei SD ist es natürlich anders. Dann braucht man kein ADB. Sondern wählt die Dateien über Apply update -> Coose from disk aus.

Viele Grüße

Revan335

 

[Oliver500]

Hallo zusammen,

ich habe mein neues Shift6mq mittlerweile erhalten und habe es auch bereits erfolgreich rooten können. Für die Informationen aus diesem Thread, den angepinnten Anleitungen in den Foren und Eure Hilfe hierzu nochmal vielen Dank! Dabei ist bei mir aber noch die ein oder andere Frage aufgekommen. Der Bootloader ist ja nun entsperrt, was eine Warnmeldung beim Start des Phones nach sich zieht. Die Recovery befindet sich meines Wissens noch im Originalzustand. Wäre es möglich, nach dem nun erfolgten Rootvorgang den Bootloader wieder zu schließen, oder ist das nicht zu empfehlen bzw. hätte das Konsequenzen? Und falls es möglich wäre: Wie verhält es sich, wenn ein OTA-Update installiert wird und vor dem nächsten Neustart die Boot-Partition mit Magisk wieder gepatcht werden muss, um root nicht zu verlieren? Müsste der Bootloader für diesen Vorgang wieder offen sein (und müsste somit dementsprechend VOR dem OTA-Update wieder geöffnet werden)? Und btw: Ist eigentlich der "Bootloader" und die "Boot-Partition", die gepatcht wird, ein und dasselbe?

Andere Frage: Ist es eigentlich auch möglich für den Fall, dass das gesamte System nicht mehr startet, dieses komplett neu zu flashen, ohne dies in den Einstellungen im System zu tun (Notfallplan)? Es wird in diesem Artikel zum Wechsel der A/B-Slots ein Flashtool QFIL für Qualcomm-basierte Smartphones erwähnt. Wäre das ein gangbarer Weg und wie würde das damit ablaufen? Oder gäbe es für einen solchen Fall eine einfachere Lösung?

Beste Grüße und vielen Dank für Eure Hilfe.

 

[@Lhotze]

ist das nicht zu empfehlen

Definitiv nicht

hätte das Konsequenzen

Krasse, das Gerät wäre danach ein fast nicht wiederherzustellender Backstein.

Es gibt eine spezielle Partition, die das System auf Herstellerintegrität prüft. Die wäre bei Root nicht mehr gegeben.
Bei einem sperren des Bootloaders startet das System nicht mehr und man kann den Bootloader im schlimmsten Fall nicht mal mehr öffnen um den Fehler rückgängig zu machen.

Theoretisch kann man das umgehen, indem man die Prüfpartition (deren Namen mir gerade nicht einfallen mag ) verändert. Ich weiß nur nicht, ob es da eine allgemeine Veränderung bedarf oder eine spezielle. Und ausprobieren will ich es because of reasons nicht.
So sehr stört mich die Warnung nun auch nicht. Sind ja nur 2 Sekunden mehr Bootzeit .

Boot-Partition muss nach jedem Update neu gepatcht werden. Bootloader und Boot-Img sind nicht das gleiche.
Das QFIL scheitert an der Firehose-Datei. Selbermachen geht nicht, bin aber davon überzeugt, dass der Shift-Support das Gerät in diesem Fall, dass nur noch der EDL-Modus geht retten kann.

Greetz

 

[Oliver500]

@Lhotze, erstmal vielen Dank für deine Antwort! Das mit dem Bootloader wieder schließen war "nur" eine Frage, die sich mir in dem Zusammenhang gestellt hat. Wenn es solche Konsequenzen hätte, werde ich das natürlich auch nicht anstreben. Es reicht mir, wenn dieser wieder geschlossen werden könnte, nachdem man die offizielle Boot.img wieder geflasht und somit root wieder entfernt hätte.

Das QFIL scheitert an der Firehose-Datei. Selbermachen geht nicht, bin aber davon überzeugt, dass der Shift-Support das Gerät in diesem Fall, dass nur noch der EDL-Modus geht retten kann.

Was ist denn eine "Firehose-Datei"? Und was ist mit EDL-Modus gemeint?

Gäbe es keine Möglichkeit, die offizielle Shift-OS-Firmware, die ja heruntergeladen werden kann, auf das Smartphone zu flashen, ohne in das System booten zu müssen?

 

[@Lhotze]

SHIFT6mq - Frage / Question - Fastboot-Loop

Hallo zusammen, ich habe die Anleitung aus https://forum.shiftphones.com/threads/bootloader-unlock-root-custom-recoveries-roms.3207/ für das rooten durchgeführt und es hat alles wunderbar geklappt. Ich hatte Magisk und war Root meines Geräts mit der ShiftOS-Version "SHIFT6MQ.SOS.3.3.L.20210709"...

forum.shiftphones.com

und folgende...

Greetz

 

[Oliver500]

SHIFT6mq - Frage / Question - Fastboot-Loop

Hallo zusammen, ich habe die Anleitung aus https://forum.shiftphones.com/threads/bootloader-unlock-root-custom-recoveries-roms.3207/ für das rooten durchgeführt und es hat alles wunderbar geklappt. Ich hatte Magisk und war Root meines Geräts mit der ShiftOS-Version "SHIFT6MQ.SOS.3.3.L.20210709"...

forum.shiftphones.com

und folgende...

Das ist sehr interessant, hatte diesen Thread noch gar nicht wahrgenommen. In diesem Post schreibst du, dass man über die werksseitige Recovery das reguläre Firmware-Image installieren könnte, um den Fehler zwischen Kernel und System auszugleichen. Akzeptiert die stock-Recovery die herunterladbaren Firmware-Pakete für einen Flash-Vorgang, und wird dabei Kernel, Recovery und System neu installiert? Und funktioniert dies auch bei gesperrtem Bootloader, sofern die Recovery startet?

Ich nehme mal an, das, was wir "Laien" als "boot-Partition" kennen, ist der von dir genannte Kernel?

 

[@Lhotze]

Ich nehme mal an, das, was wir "Laien" als "boot-Partition" kennen, ist der von dir genannte Kernel?

Ja genau

Akzeptiert die stock-Recovery die herunterladbaren Firmware-Pakete für einen Flash-Vorgang, und wird dabei Kernel, Recovery und System neu installiert? Und funktioniert dies auch bei gesperrtem Bootloader, sofern die Recovery startet

Die gesamten systemrelevanten Daten werden neuinstalliert. Allerdings auf der inaktiven von zwei Partitionen. Heißt die Integritätsprobleme wären weiterhin vorhanden, da das "kaputte" System nicht neu beschrieben wird. Man müsste quasi nach nem Update im Recovery, welches jetzt gewechselt hat ein erneutes Update durchführen, welches jetzt das "kaputte" System überschreibt.
Dieser Umweg müsste so gemacht werden, da man mit geschlossenem Bootloader die Partitionen nicht manuell wechseln kann.
Ein Update sollte klappen, da die Signatur der Update-Datei dem Recovery bekannt ist.

Aber: Der oben verlinkte Fall ist der Erste dieser Art, der im Forum beschrieben wird. Kann genausogut sein, dass der fehlgeschlagene Integritätscheck automatisch die Nutzung des Recovery's unterbindet und es deswegen nicht startet. Will es nicht ausprobieren .
Der Vorschlag ist somit rein theoretisch in der Annahme, dass in diesem Fall das Recovery aus einem anderen Grund als dem fehlgeschlagenen Integritätscheck nicht startet und es normalerweise funktionieren sollte.

Greetz

 

[Oliver500]

Der Vorschlag ist somit rein theoretisch in der Annahme, dass in diesem Fall das Recovery aus einem anderen Grund als dem fehlgeschlagenen Integritätscheck nicht startet und es normalerweise funktionieren sollte.

Genau das war der Gedanke dabei, ja. Würde das auch nur ungern ausprobieren wollen. Es war eine theoretische Überlegung für den Fall, dass das System aus anderem Grund nicht mehr startet, und ein Update / Flashvorgang nicht mehr über die Einstellungen im System durchgeführt werden könnten. Vielen Dank!

Als nächstes muss ich mal schauen, wie es eigentlich mit dem SafetyNet nach dem Rooten bei mir aussieht. Ich habe bisher ausschließlich die Magisk-App installiert, mit dieser die Stock boot.img gepatcht und das gepatchte File dann mittels Fastboot in die Boot-Partition geflasht (den Kernel, wie ich ja jetzt gelernt habe ). Magisk war die Version 27.3, wenn mich nicht alles täuscht.

 

[Oliver500]

Wenn du nach einem Update nicht den inaktiven Slot patcht solltest du Root auch wieder los sein und dann auch theoretisch den Bootloader wieder schließen können.

Ist es denn ausreichend, wenn in dem dann aktiven Slot die Boot-Partition wieder "Original" (und ungerootet) ist, um den Bootloader wieder schließen zu können, oder muss das in dem dann inaktiven (und noch gerooteten) Slot auch so sein - sprich, wird dieser vielleicht auch durch Android beim Start geprüft, und man bekommt oben beschriebenes "Problem", um es mal vorsichtig auszudrücken?

 

[@Lhotze]

Beide Slots müssen wieder Original sein, sonst kannst du das Gerät in die Tonne treten.

Edit: Korrektur der Beschreibung durch AMartinz

Am besten bootest du mit offenem Bootloader ein frühes Recovery manuell und installierst über dieses ein komplettes System OTA. Nach der Installation wird das Gerät ausgeschaltet und direkt wieder in ein früheres Recovery manuell gebootet. Dann wird das gleiche OTA erneut installiert.
Somit hast du am Ende des Vorganges das gleiche, ursprüngliche System in beiden Slots.

Das manuelle, frühere Recovery deswegen, weil es einfach leichter ist. Andernfalls müsstest du (wegen den Versionsdaten) zwei zeitlich unterschiedliche Updatereleases installieren, was mit Aufwand verbunden ist.



Danach kann der Bootloader gefahrlos geschlossen werden.
Anleitung gibt es im Forum.
Gruß

 

[Oliver500]

Das manuelle, frühere Recovery deswegen, weil es einfach leichter ist. Andernfalls müsstest du (wegen den Versionsdaten) zwei zeitlich unterschiedliche Updatereleases installieren, was mit Aufwand verbunden ist.

Muss man denn über eine Recovery immer das OTA mit der Version installieren, was zu der Version der Recovery passt, die gerade gebootet wurde? Ich dachte, das wäre davon unabhängig. Der OTA-Flash über die gebootete Recovery müsste doch Recovery, System und Kernel (=boot) mit genau der Version des OTA-Installs ersetzen, oder?

Anleitung gibt es im Forum.

Hab ich leider so im Detail noch nicht hier gefunden. Hättest du da mal einen Link? Dann würde ich da mal einsteigen.

Wird der Slot eigentlich grundsätzlich beim Start der Recovery gewechselt, und zwar vom Start jeder beliebigen Recovery? Oder sprechen wir hier nur vom Start der Recovery nach einem OTA-Flash und/oder dem Start der Stock-Recovery?

 

[@Lhotze]

Viele Fragen ...

Das Recovery installiert ein OTA nur, wenn das OTA von dem Versionsdatum höher ist als das Recovery. Ansonsten kann man jedes nachfolgende OTA über ein Recovery installieren.
Der Slot wird nach jedem Updatevorgang, unabhängig davon ob über Recovery oder aus dem System heraus installiert gewechselt.

Natürlich ersetzt ein OTA die notwendigen Partitionen im inaktiven Slot. Inklusive Boot und Recovery. Darauf kommt es uns aber ja auch in diesem Fall an, immerhin wollen wir ja gefahrlos den Bootloader wieder schließen.

Was den Link angeht, bin ich jetzt ein kleines bisschen gehässig. Gefühlt sind alle Infos in diesem Thread in entsprechenden anderen Threads des 6mq schon sehr häufig durchgekaut worden.
Mit entsprechenden Schlagwörtern wir "Recovery", "Wechsel" oder "Bootloader" sollte eigentlich schon alles drin sein.
Für Interesse und Dazulernen haben ich immer Verständnis, aber ein bisschen gehört da Selbsteinlesen auch dazu um das Forum zu entlasten.

So viele herausragende 6mq Threads im Modding-Bereich gibt es auch nicht.

Bei nicht bereits erwähnten Fragen stehen wir natürlich gerne zur Verfügung, aber ich ziehe jetzt auch mal für mich ne Grenze, weil die Fragen hier so sehr Off-Topic gehen, dass wir sie bereits in spezialisierteren Threads finden.

Hoffe auf Verständnis,
Greetz

 

[Oliver500]

Ich verstehe das natürlich, dass vorausgesetzt wird, dass man sich erstmal so weit wie möglich selbst im Forum beliest, bevor man anfängt, entsprechende Fragen hier zu posten. Allerdings ist es natürlich auch so, dass man gerade als jemand, der versucht, sich in die Materie einzuarbeiten, auf diverse Beiträge in schon vorhandenen Threads stößt, die entweder weit über das eigene Wissen hinausgehen, sodass man damit so gut wie noch überhaupt nichts anfangen kann, oder aber Rückfragen von anderen Usern enthalten, die noch weiter "zurückliegen" und das Thema dann - bezüglich Informationssuche - unnötiger Weise in die Länge ziehen. Da komme ich dann bei Threads, die zig-Seiten lang sehr spezielle und individuelle Themen ausdiskutieren auch an meine persönliche Grenze der Aufnahmefähigkeit. Selbstverständlich belese ich mich gern selbst, insbesondere wenn es so hervorragende Anleitungen gibt, die dann auch in den Foren als erstes angepinnt sind. Aber wie gesagt sehe ich mich dann außerstande, aus der Fülle an (zum Teil informationslosen, zum Teil für mich persönlich viel zu "hohen") Beiträgen die für mich brauchbaren Informationen noch herauszufiltern - falls an der Stelle dann überhaupt vorhanden. Zum Teil kommen mir dann auch beim Durchlesen (oder eher Durcharbeiten) einiger Threads wieder so viele neue Fragen auf, dass mir die dort beschriebenen Informationen dann auch nicht unmittelbar weiterhelfen (zumindest nicht, bis die sich mir dabei neu stellenden Fragen nicht auch irgendwie beantwortet sind). Und Asche auf mein Haupt, wenn ich dann den Post Nummer 5876 überlesen habe, wo eben in einem Nebensatz die Antwort auf meine (theoretische) Frage enthalten war.

Da du selbst ja über all dieses Wissen verfügst, kann ich schon verstehen, dass du schnell den Eindruck bekommst, die Themen wurden schon "gefühlt sehr häufig durchgekaut". Aber für mich als relativer Anfänger sind das alles ganz neue Welten. Ich bin sehr froh, dass sich dieses Forum und die Community auf die Shift-Produkte bezieht bzw. beschränkt, und dabei so überaus wertvolle Informationen vermittelt. Das ist für mich von unschätzbarem Wert und ich danke dir tausend Mal dafür, dass du dein Wissen mit uns / mir teilst. Ich hoffe, ich kann mich dafür eines Tages erkenntlich zeigen. Und falls meine Fragen dann letztendlich doch nur eine Wiederholung bereits bestehender Threads war, möchte ich mich für diese unnötige Doppelung der Themen entschuldigen, und gelobe, nächstes Mal noch mehr darauf zu achten, bereits vorhandene Foren-Inhalten zu nutzen.

Beste Grüße

 

[@Lhotze]

Bitte nicht falsch verstehen, das sollte kein Vorwurf sein. Für die handvoll freiwilligen mit "Ahnung" ist es nur manchmal sehr aufwendig alles noch mal neu zu schreiben oder bereits geschriebenes rauszusuchen. Klar stehen wir gerne Rede und Antwort bei Fragen, aber den magischen Textbausteinkasten, der auf alle Eventualitäten vorbereitet ist, den habe ich leider noch nicht. Vll mache ich irgendwann mal ne Linktree-Sammlung übers 6mq.
Prinzipiell reicht aber der Trend von @Ene tatsächlich fast komplett aus. Und ja, da gibt es auch vermeintlich belanglose Fragen oder Abweichungen vom Thema, liegt aber leider auch in der Sache einer solchen Diskussion mit vielen Leuten die das absolute aus ihrem Gerät herausholen wollen und dabei noch lernen.

Ich hoffe, ich kann mich dafür eines Tages erkenntlich zeigen.

Sure, gib erworbenes Wissen bei Bedarf weiter

Greetz

 

[amartinz]

Das Recovery installiert ein OTA nur, wenn das OTA von dem Versionsdatum höher ist als das Recovery.

Du kannst ein FULL-OTA immer wieder installieren und es installiert dann in den anderen Slot.

Heißt 2x die selbe FULL-OTA installieren sollte beide Slots auf den selben Stand setzen.