[How-To] Nexus 7 Factory Image Flashen

coolfranz · 2014-02-05T13:26:50+0100

Nein, einfach das aktuelle Factory Image auf 4.4.2 (KOT49H) flashen. Fertig.

Zum Flashen an die Anleitung halten. Musst vorne weg nur ne Anleitung suchen, wie du ADB/ Fastboot unter Linux zum laufen bringst.

4.2.14 ist das Datum... musste mir öfters schon was anhören... deswegen gibts von mir auch immer den Link mit dem Hinweis sich von dort das aktuellste Image zu besorgen. Ich füg mal Doppelpunkte ein, damit es eindeutiger wird.

linuxnutzer · 2014-02-05T15:17:50+0100

Danke, vielleicht schreibst du einfach beim Datum "vom" dazu.

Die sig dateien wären nur wichtig wenn man bei einem geschlossenen Bootloader flashen will

Das verstehe ich noch zu wenig, Hat ein gerootetes Nexus automatisch einen offenen Bootloader?

adb / fastboot bekomme ich schon hin. Ich habe ja im Thread https://www.android-hilfe.de/forum/...m-installieren-unter-ubuntu-linux.335585.html schon mal berichtet, wie es bei mir geklappt hat.

Code:

~/Downloads/nakasig-kot49h$ ls -1
bootloader-tilapia-4.23.img
flash-all.bat
flash-all.sh
flash-base.sh
image-nakasig-kot49h.zip
radio-tilapia-1231_0.18.0_0409.img

Da ist also auch ein Shell-Script dabei.

Code:

cat flash-all.bat 
PATH=%PATH%;"%SYSTEMROOT%\System32"
fastboot oem unlock
fastboot erase boot
fastboot erase cache
fastboot erase recovery
fastboot erase system
fastboot erase userdata
fastboot flash bootloader bootloader-tilapia-4.23.img
fastboot reboot-bootloader
ping -n 10 127.0.0.1 >nul
fastboot flash radio radio-tilapia-1231_0.18.0_0409.img
fastboot reboot-bootloader
ping -n 10 127.0.0.1 >nul
fastboot -w update image-nakasig-kot49h.zip

echo Press any key to exit...
pause >nul
exit

Ich sehe bei dem Shell-Script eventuell nur das Problem des Pfades, also den vollen Pfad bei fastboot eingeben und vorher testen, ob überhaupt das Nexus angesprochen werden kann.

Code:

cat flash-all.sh 
#!/bin/sh
fastboot oem unlock
fastboot erase boot
fastboot erase cache
fastboot erase recovery
fastboot erase system
fastboot erase userdata
fastboot flash bootloader bootloader-tilapia-4.23.img
fastboot reboot-bootloader
sleep 10
fastboot flash radio radio-tilapia-1231_0.18.0_0409.img
fastboot reboot-bootloader
sleep 10
fastboot -w update image-nakasig-kot49h.zip

Sehe ich es also richtig, dass für ein _ungerootetes_ Nexus 7 nur notwendig ist, die o.a. Befehle auszuführen und es egal ist, was vorher auf dem Nexus 7 installiert ist?

coolfranz · 2014-02-05T15:40:11+0100

Das verstehe ich noch zu wenig, Hat ein gerootetes Nexus automatisch einen offenen Bootloader?

In der Regel: Ja (man kann den dann aber auch nachher wieder schließen z.B. - erkennen tust du einen offenen Bootloader daran, dass beim einschalten (wenn das Google Logo angezeigt wird) unten im Bildschirm ein offenes Schloss zu sehen ist.

Ich würde die Befehle der Reihe nach von Hand eingeben. Einige kannst du dir sparen wenn der Bootloader offen ist.

Code:

fastboot erase boot
fastboot erase cache
fastboot erase recovery
fastboot erase system
fastboot erase userdata
fastboot flash bootloader bootloader-tilapia-4.23.img
fastboot reboot-bootloader

Warten bis Reboot (in den Bootloader) vollständig ist

Code:

fastboot flash radio radio-tilapia-1231_0.18.0_0409.img

Warten bis Reboot (in den Bootloader) vollständig ist

Code:

fastboot -w update image-nakasig-kot49h.zip

Nach dem richtigen Reboot dann per Fastboot noch das CWM flashen und im CWM dann die Superuser .zip und du hast wieder Root Rechte.

linuxnutzer · 2014-02-06T00:14:49+0100

Ich berichte, wie ich ein Nexus 7 2012 32G 3G/UMTS mit Android 4.4 unter Linux, Ubuntu 12.04 Precise, geflasht habe:

Ausgegangen wurde von einem gerooteten 4.3 Build: JWR66V wie ich es bei https://www.android-hilfe.de/forum/...m-installieren-unter-ubuntu-linux.335585.html beschrieben habe.

Meine Voraussetzungen, ob notwendig kann ich nicht sagen:
Voll geladenes Tablet, Original Asus-Kabel
Aktuelles Android SDK (Download von http://dl.google.com/android/adt/adt-bundle-linux-x86_64-20131030.zip via Android SDK | Android Developers )
USB-Debugging vor dem Ausschalten aktiviert, vermutlich überflüssig, da ja ausgeschaltet wurde.

Mit Power + Lautstärke runter das Nexus in den Fastboot-Modus versetzt.
USB-Kabel mit dem PC verbunden.

Alle folgenden Befehle wurden als root ausgeführt! Das bedingt bei Ubuntu, dass man vorher dem User root ein Passwort geben muss (sudo passwd root). Ob alles auch mit sudo läuft, habe ich nicht probiert. Bei anderen Herstellern findet man aber Hinweise, dass ein Unterschied sein soll.

Ich habe bewusst die vollen Pfade verwendet um aus dieser Richtung keine Probleme zu erhalten. Im Pfad findet man auch die md5sum des heruntergeladenen Paketes.

Nach "reboot-bootloader" haben ich über 10 Sekunden gewartet. Im Script findet man ein "sleep 10".

Code:

precise:~$ su -
Passwort:

Code:

root@precise:~# /install/androidins/adt-bundle-linux-x86_64_99b51a4f0526434b083701a896550b72/adt-bundle-linux-x86_64-20131030/sdk/platform-tools/fastboot oem unlock
...
(bootloader) Bootloader is already unlocked
OKAY [  0.020s]
finished. total time: 0.020s

Code:

root@precise:~# /install/androidins/adt-bundle-linux-x86_64_99b51a4f0526434b083701a896550b72/adt-bundle-linux-x86_64-20131030/sdk/platform-tools/fastboot erase boot
erasing 'boot'...
OKAY [  0.122s]
finished. total time: 0.122s

Code:

root@precise:~# /install/androidins/adt-bundle-linux-x86_64_99b51a4f0526434b083701a896550b72/adt-bundle-linux-x86_64-20131030/sdk/platform-tools/fastboot erase cache
******** Did you mean to fastboot format this partition?
erasing 'cache'...
OKAY [  0.160s]
finished. total time: 0.160s

Code:

root@precise:~# /install/androidins/adt-bundle-linux-x86_64_99b51a4f0526434b083701a896550b72/adt-bundle-linux-x86_64-20131030/sdk/platform-tools/fastboot erase recovery
erasing 'recovery'...
OKAY [  0.028s]
finished. total time: 0.028s

Code:

root@precise:~# /install/androidins/adt-bundle-linux-x86_64_99b51a4f0526434b083701a896550b72/adt-bundle-linux-x86_64-20131030/sdk/platform-tools/fastboot erase system
******** Did you mean to fastboot format this partition?
erasing 'system'...
OKAY [  0.469s]
finished. total time: 0.469s

Code:

root@precise:~# /install/androidins/adt-bundle-linux-x86_64_99b51a4f0526434b083701a896550b72/adt-bundle-linux-x86_64-20131030/sdk/platform-tools/fastboot erase userdata
******** Did you mean to fastboot format this partition?
erasing 'userdata'...
OKAY [ 20.842s]
finished. total time: 20.843s

Code:

root@precise:~# /install/androidins/adt-bundle-linux-x86_64_99b51a4f0526434b083701a896550b72/adt-bundle-linux-x86_64-20131030/sdk/platform-tools/fastboot flash bootloader /install/androidins/nexus7_install_44/nakasig-kot49h_fa034d967e0400363e8a5b315d6a20ba/bootloader-tilapia-4.23.img
sending 'bootloader' (3911 KB)...
OKAY [  0.477s]
writing 'bootloader'...
FAILED (remote: (InvalidState))
finished. total time: 0.709s

Code:

root@precise:~# /install/androidins/adt-bundle-linux-x86_64_99b51a4f0526434b083701a896550b72/adt-bundle-linux-x86_64-20131030/sdk/platform-tools/fastboot reboot-bootloader
rebooting into bootloader...
OKAY [  0.020s]
finished. total time: 0.020s

# mindestens 10 Sekunden warten

Code:

root@precise:~# /install/androidins/adt-bundle-linux-x86_64_99b51a4f0526434b083701a896550b72/adt-bundle-linux-x86_64-20131030/sdk/platform-tools/fastboot flash radio /install/androidins/nexus7_install_44/nakasig-kot49h_fa034d967e0400363e8a5b315d6a20ba/radio-tilapia-1231_0.18.0_0409.img
sending 'radio' (16384 KB)...
OKAY [  1.941s]
writing 'radio'...
OKAY [  1.171s]
finished. total time: 3.112s

Code:

root@precise:~# /install/androidins/adt-bundle-linux-x86_64_99b51a4f0526434b083701a896550b72/adt-bundle-linux-x86_64-20131030/sdk/platform-tools/fastboot reboot-bootloader
rebooting into bootloader...
OKAY [  0.020s]
finished. total time: 0.020s

# mindestens 10 Sekunden warten

Code:

root@precise:~# /install/androidins/adt-bundle-linux-x86_64_99b51a4f0526434b083701a896550b72/adt-bundle-linux-x86_64-20131030/sdk/platform-tools/fastboot -w update /install/androidins/nexus7_install_44/nakasig-kot49h_fa034d967e0400363e8a5b315d6a20ba/image-nakasig-kot49h.zip
archive does not contain 'boot.sig'
archive does not contain 'recovery.sig'
archive does not contain 'system.sig'
--------------------------------------------
Bootloader Version...: 4.23
Baseband Version.....: 1231_0.18.0_0409
Serial Number........: xxxxxxxxxxxxxxxxx
--------------------------------------------
checking product...
OKAY [  0.030s]
checking version-bootloader...
OKAY [  0.020s]
checking version-baseband...
OKAY [  0.021s]
sending 'boot' (4992 KB)...
OKAY [  0.602s]
writing 'boot'...
OKAY [  0.212s]
sending 'recovery' (5532 KB)...
OKAY [  0.672s]
writing 'recovery'...
OKAY [  0.228s]
erasing 'system'...
OKAY [  0.116s]
sending 'system' (625578 KB)...
OKAY [ 73.567s]
writing 'system'...
OKAY [ 34.947s]
erasing 'userdata'...
OKAY [  4.985s]
formatting 'userdata' partition...
Creating filesystem with parameters:
    Size: 30063722496
    Block size: 4096
    Blocks per group: 32768
    Inodes per group: 8192
    Inode size: 256
    Journal blocks: 32768
    Label: 
    Blocks: 7339776
    Block groups: 224
    Reserved block group size: 1024
Created filesystem with 11/1835008 inodes and 159204/7339776 blocks
sending 'userdata' (139157 KB)...
writing 'userdata'...
OKAY [ 29.175s]
erasing 'cache'...
OKAY [  0.079s]
formatting 'cache' partition...
Creating filesystem with parameters:
    Size: 464519168
    Block size: 4096
    Blocks per group: 32768
    Inodes per group: 7088
    Inode size: 256
    Journal blocks: 1772
    Label: 
    Blocks: 113408
    Block groups: 4
    Reserved block group size: 31
Created filesystem with 11/28352 inodes and 3654/113408 blocks
sending 'cache' (9052 KB)...
writing 'cache'...
OKAY [  1.752s]
rebooting...

finished. total time: 146.506s
root@precise:~#

Jetzt werde ich mir 4.4 ungerootet ansehen und danach wird gerootet.

coolfranz · 2014-02-06T00:20:22+0100

endlich ;-)

so schlimm wars ja nicht...

linuxnutzer · 2014-02-06T00:36:59+0100

Nein so schlimm ist es überhaupt nicht. Manchmal fehlen nur ein paar Informationen und ich bin ein gebranntes Kind, dass auch mal was schiefgehen kann, auch wenn man alles richtig gemacht hat. Jetzt muss ich noch zum Rooten nachlesen oder hat sich da nichts geändert und es läuft so wie ich bei https://www.android-hilfe.de/forum/...m-installieren-unter-ubuntu-linux.335585.html beschrieben habe. Dann muss ich nur mehr die richtigen Dateien runterladen, bin mir aber nicht sicher, ob ich nicht ein Monat warten soll, weil dann die Garantie vorbei ist.

Mein Problem ist ja ein ganz anderes, ich bin mir nicht sicher, ob sich der Speicher verabschiedet. Siehe https://www.android-hilfe.de/forum/google-nexus-7-2012.696/wie-flash-speicher-testen.534902.html bwz. die Merkwürdigkeit bei https://www.android-hilfe.de/forum/...szustand-loescht-nicht-alle-daten.534690.html

Um ein e2fsck auszuführen brauche ich aber wieder root, also stellt sich die Frage, ob ich einfach mit dem Rooten warten soll bis die Garantie vorbei ist oder den Nachweis mit e2fsck führen soll, dass der Speicher was hat.

coolfranz · 2014-02-06T00:45:31+0100

Tipp 1: bei jedem Beitrag steht rechts oben die Nummer und "permalink". Rechtsklick und du kannst den Link zum Beitrag kopieren - spart erheblich Zeit.

Auch nach suchen komm ich im Moment mit deinen Mega Posts nicht zurecht... Fakt ist, wenn man mit ADB/ Fasboot umgehen kann und die Sachen laufen (was bei dir nun wohl definitv der Fall ist) ist "rooten" kein Ding mehr.
Wie gesagt CWM und SuperSU von den entsprechenden Seiten laden und flashen. Fertig.

Zum Speicher habe ich keine Ahnung... zumindest bei der Früherkennung... und ist hier auch eigentlich OT.

Wie wärs aber, wenn du einfach rootest, die Tests machst und im Falle eines negativen Ergebnisses einfach das Stock Image wieder flashst, den Bootloader dicht machst und das Gerät einschickst?

linuxnutzer · 2014-02-06T01:07:37+0100

coolfranz schrieb:
Du hast ein Nexus 7 3G mit veränderten Systemdateien, weswegen das Google Ota fehl schlägt.

Was musst du machen? Ganz einfach von https://developers.google.com/android/nexus/images?hl=de das aktuelle Factory Image laden (Stand 4.2.14: 4.4.2) und flashen. Befehle sind etwas anders als in der Anleitung und wegen des 3G Moduls einer mehr. Dazu am besten die Datei Flash-all.bat mit dem Texteditor öffnen, da stehen die alle drin.

Zum Root: der ist dann natürlich (wie alle Daten) weg. Zum wieder bekommen den Bootloader zum Abschluss nicht schließen, sondern noch dass CWM Revovery von hier: ClockworkMod ROM Manager - Recoveries flashen. Damit dann wiederum die Super Su .zip flashen: [2014.01.20] SuperSU v1.91 - xda-developers

Da habe ich schon noch eine Frage, was du mit " den Bootloader zum Abschluss nicht schließen" gemeint hast. Nach dem letzten Schritt "fastboot -w update" erfolgte ein Neustart, da hätte ich nichts weiter flashen können.

Ich muss also jetzt für mein Nexus 3G entweder http://download2.clockworkmod.com/recoveries/recovery-clockwork-6.0.4.3-tilapia.img oder http://download2.clockworkmod.com/recoveries/recovery-clockwork-touch-6.0.4.3-tilapia.img installieren. Ist das Geschmackssache oder ist die Touch-Variante nicht so stabil?

wenn ich bei [2014.01.20] SuperSU v1.91 - xda-developers lese, dann gibt es da mehrere Möglichkeiten und da steht: "Note that if you are already rooted, installing through Play is by far the easiest way to install SuperSU !"

Für mich stellt sich die Frage, welcher Schritt das Rooten bedeutet?

Nach der 4.4.2-Installation ist das Schloss beim Start _offen_!

Ich nehme an, ich brauche zum Rooten zuerst ein "fastboot-linux flash recovery recovery-clockwork-6.0.4.3-tilapia.img" und installiere damit http://download.chainfire.eu/381/SuperSU/UPDATE-SuperSU-v1.91.zip?retrieve_file=1 Ich verstehe nicht, wann man das aus dem Playstore installieren könnte?

Wie wärs aber, wenn du einfach rootest, die Tests machst und im Falle eines negativen Ergebnisses einfach das Stock Image wieder flashst, den Bootloader dicht machst und das Gerät einschickst?

Wie geht das bitte, Link?

coolfranz · 2014-02-06T01:26:04+0100

Da habe ich schon noch eine Frage, was du mit " den Bootloader zum Abschluss nicht schließen" gemeint hast. Nach dem letzten Schritt "fastboot -w update" erfolgte ein Neustart, da hätte ich nichts weiter flashen können.

Nochmal in den Bootloader booten und

Code:

fastboot oem lock
[\code] 

eintippen. Ist dann bis auf die neuere Android Version (die auch per OTA hätte kommen können) so als hättest du nie was an dem Gerät gemacht. Bei einem erneuten Unlock wird aber "for security reasons" der komplette Speicher gelöscht/ formatiert.

[quote]Ich muss also jetzt für mein Nexus 3G entweder http://download2.clockworkmod.com/re....3-tilapia.img oder http://download2.clockworkmod.com/re....3-tilapia.img installieren. Ist das Geschmackssache oder ist die Touch-Variante nicht so stabil?[/quote]

Geschmackssache. Ich persönlich steh nicht so aufs herumgehämmer auf den Volume Tasten, weswegen ich, wo möglich, die Touch Version installiert habe.

[quote]wenn ich bei [2014.01.20] SuperSU v1.91 - xda-developers lese, dann gibt es da mehrere Möglichkeiten und da steht: "Note that if you are already rooted, installing through Play is by far the easiest way to install SuperSU !"[/quote]

Yeah, as you just installed a factory image, you are not rooted! Install the .zip via CWM recovery! Easiest way to do this is enabling the sideload in your CWM and push the su.zip via ADB to your tablet.
Future SuperSU Updates then can easily be installed via Play Store.

[quote]Für mich stellt sich die Frage, welcher Schritt das Rooten bedeutet?
[/quote]

Das installieren der SU.zip. Wie du im Protokoll (im CWM) sehen wirst, wird dabei eine Datei in /system/xbin eingefügt. Damit wird es möglich (in Verbindung mit der SuperSU.apk einzelnen Aps Superuser Rechte zu gewähren).
Genau genommen ist das erst "rooten" denn mit einem Custom Recovery allein kannst du Apps noch keine Root Rechte geben. 

[quote]Nach der 4.4.2-Installation ist das Schloss beim Start _offen_!
[/quote]

Ja, der Bootloader muss dann (! optional - um die beste Sicherheit zu haben sollte der geschlossen werden) nach dem Neustart in einem extra Schritt geschlossen werden.

Genau das sagt auch Google auf der Seite, wo es die Factory Images zum Download gibt:
[quote]After restoring a factory image, it is recommended that you lock the bootloader, for security reasons.
[/quote]




[quote]Ich nehme an, ich brauche zuerst ein "fastboot-linux flash recovery recovery-clockwork-6.0.4.3-tilapia.img" und installiere damit http://download.chainfire.eu/381/Sup...etrieve_file=1 Ich verstehe nicht, wann man das aus dem Playstore installieren könnte?[/quote]

In deinem Fall gar nicht!

Du flashst das Custom Recovery:

[code]fastboot-linux flash recovery recovery-clockwork-6.0.4.3-tilapia.img[\code]

Neustart in den Bootloader

"Reboot Recovery"

dann am besten die Su.zip per ADB aufs Gerät bringen... dazu im Recovery install .zip via sideload oder so suchen (weiß ich im Moment nicht so auswendig wo das ist - wirst du aber nach spätestens 30s finden)

Dann mit dem PC per
[code]adb sideload "su.zip"[\code]

die Datei aufs Gerät übertragen und die Installation bestätigen


Anschließen neu starten und evtl. das automatische Flashen des Stock Reoverys beim Start unterbinden, so dass du nach dem Neustart immer noch das CWM auf dem Gerät drauf hast (die Option wird dir automatisch beim Neustarten angeboten).

linuxnutzer · 2014-02-06T10:32:15+0100

Vorbemerkung: Unter Linux nennt sich der Befehl nur fastboot und nicht fastboot-linux. Beim Posting davor bitte berücksichtigen.

Ich schreibe nun, wie ich unter Ubuntu Linux 12.04 Precise das Nexus 7 2012 32G 3G gerootet habe. Nachdem ich für "never change a running system" bin, habe ich mich mit "sideload" nicht auseinander gesetzt, sondern es so gemacht:

https://play.google.com/store/apps/details?id=de.fun2code.android.webdrive bzw. die Lite-Version installieren
UPDATE-SuperSU-v1.91.zip auf das Nexus kopieren (Ort merken!)

Nexus aus

Mit Power + Lautstärke runter das Nexus in den Fastboot-Modus versetzt.
USB-Kabel mit dem PC verbunden.

Ich gehe davon aus, dass verstanden wurde, was ich unter https://www.android-hilfe.de/forum/...image-flashen.313796-page-7.html#post-7170367 geschrieben habe.

Weil ich mit der Touch-Version irrtümlich wo ankam, habe ich die "Tasten-Version installiert": http://download2.clockworkmod.com/recoveries/recovery-clockwork-6.0.4.3-tilapia.img

Vermutlich kann man statt "su -" auch "sudo" vor allen Befehlen in der Konsole verwenden.

Code:

~$ su -
Passwort:

Code:

root@precise:~# /install/androidins/adt-bundle-linux-x86_64_99b51a4f0526434b083701a896550b72/adt-bundle-linux-x86_64-20131030/sdk/platform-tools/fastboot flash recovery /install/androidins/nexus7_install_44/recovery-clockwork-6.0.4.3-tilapia.img
sending 'recovery' (7316 KB)...
OKAY [  0.863s]
writing 'recovery'...
OKAY [  0.373s]
finished. total time: 1.236s

Volume down in Recovery Mode, mit Power bestätigen. Hier aufpassen, dass man nicht bootet. Ist mir passiert, also habe ich recovery-clockwork-6.0.4.3-tilapia.img noch einmal darüber installiert. Bei 4.3 (hier geht es ja um 4.4!) war es zwingend notwendig, dass man sofort nach der cwm-Installation SuperSU installierte und ich wollte nicht testen, ob das bei 4.4 auch so ist.

Ich habe dann auch das USB-Kabel abgezogen war, weil es zum PC sehr kurz ist und so bequemer war

install zip
UPDATE-SuperSU-v1.91.zip suchen und auswählen

reboot system now

Wieder in den Fastboot-Mode, Kabel anstecken nicht vergessen ;-)

Code:

root@precise:~# /install/androidins/adt-bundle-linux-x86_64_99b51a4f0526434b083701a896550b72/adt-bundle-linux-x86_64-20131030/sdk/platform-tools/fastboot oem lock
...
(bootloader) Bootloader is locked now.
OKAY [  1.454s]
finished. total time: 1.455s
root@precise:~#

Danach habe ich eine App probiert die root-Rechte verlangt, zB https://play.google.com/store/apps/details?id=com.cleanmaster.mguard

Interessiert war noch, als ich mich oben im Recovery verdrückt hatte, dass ich da irgendwo landete, das mir eine Option root anbot, die nicht mehr rückgängig gemacht werden kann. Kennt das wer und hat man dann wirklich root? Da nichts zu einer Installation von UPDATE-SuperSU-v1.91.zip zu sehen war, habe ich das nicht verfolgt.

coolfranz · 2014-02-06T10:39:25+0100

Passt auch... viele Wege führen zum Root.

Zum Sideload: ist eigentlich kein Hexenwerk, sondern nur ein ADB Befehl um eine Datei zum Flashen aufs Gerät zu schieben. Damit spart man sich den Umweg mit Neustart und Drive etc. Wenn man mit CMD / Linux Shell umgehen kann ist das der einfachere Weg.

Hier aufpassen, dass man nicht bootet. Ist mir passiert, also habe ich recovery-clockwork-6.0.4.3-tilapia.img noch einmal darüber installiert. Bei 4.3 (hier geht es ja um 4.4!) war es zwingend notwendig, dass man sofort nach der cwm-Installation SuperSU installierte und ich wollte nicht testen, ob das bei 4.4 auch so ist.

Vollständigkeit halber: sollte nichts mit dem Root zu tun haben. Sollte sich auch "unter 4.3" schon leicht unterdrücken lassen.

Kommt aufs Recovery an. Seit längerer Zeit bietet das CWM Recovery einem beim Neustarten an das Flashen des Stock Recoveries zu unterdrücken.

Das Stock Android führt beim Start ein Skript aus, dass das Stock Recovery wiederherstellt, falls festgestellt wird, wenn da ein anderes Recovery läuft.

Früher bei Nexus S, als CWM noch bei Version 4 oder 5 war und es diese Möglichkeit der autom. Deaktivierung noch nicht gab musst man das Recovery fast immer 2 mal flashen.

1. Recovery flashen
2. Su.zip
3. starten und Root Rechte nutzen, um das Skript zu entfernen/ umbenennen
4. Recovery noch mal flashen

Wieder in den Fastboot-Mode

Code:

root@precise:~# /install/androidins/adt-bundle-linux-x86_64_99b51a4f0526434b083701a896550b72/adt-bundle-linux-x86_64-20131030/sdk/platform-tools/fastboot oem lock
...
(bootloader) Bootloader is locked now.
OKAY [  1.454s]
finished. total time: 1.455s
root@precise:~#

Ok. Oftmals gut, Wenn du wieder was dran machen willst musst du halt wissen, dass da dann ein Factory Reset einhergeht....ich habe z.B.bei meinem n7 aus Bequemlichkeit den Bootloader offen - nutze es aber auch fast ausschließlich zuhause.

Interessiert war noch, als ich mich oben im Recovery verdrückt hatte, dass ich da irgendwo landete, das mir eine Option root anbot, die nicht mehr rückgängig gemacht werden kann. Kennt das wer und hat man dann wirklich root? Da nichts zu einer Installation von UPDATE-SuperSU-v1.91.zip zu sehen war, habe ich das nicht verfolgt.

Entweder war das wie oben erwähnt das unterdrücken des Stock Recovery flashs.

Oder die Option, die dir anbietet bei "gerooteten" Geräten sicherzustellen, das der Root auch erhalten bleibt wenn man was anderes flasht/ sonstwas macht. Kann auch sein, dass der mit dem Flash der neueste Su.zip etwas durcheinander kommt.
Normal ist das aber für den Fall, wenn man ein Stock OTA per CWM installiert, Root geht dabei normal verloren - damit wird versucht eben das zu verhindern (Eine ähnliche Option bietet die Super SU Pro App ja auch an).

Ich persönlich flash da halt einfach (so wie früher) das CWM noch mal eben neu - meistens gibts dann eh ne neuere Version...

linuxnutzer · 2014-02-06T10:55:01+0100

Ich möchte mich bei dir nochmals bedanken, du machst das echt verständlich und nachvollziehbar. Nachdem ich bei Samsung schon extreme Merkwürdigkeiten erlebt habe, ziehe ich mittlerweile unter Android das vor, das schon einmal funktioniert hat. [Solution] Win7 Adb driver failing to install in adb sideload - xda-developers hat mich zB abgeschreckt. Das ist zwar Windows, aber ich hatte ja eine funktionierende Alternative.

coolfranz · 2014-02-06T11:09:57+0100

linuxnutzer schrieb:
Ich möchte mich bei dir nochmals bedanken, du machst das echt verständlich und nachvollziehbar.

Bitte, freut mich

Nachdem ich bei Samsung schon extreme Merkwürdigkeiten erlebt habe, ziehe ich mittlerweile unter Android das vor, das schon einmal funktioniert hat.

Das ist der Vorteil an Stock Android/ Nexus. Ein laufendes Fastboot/ ADB und wenn man weiß wie man mit der Shell umgeht und man kann alles tun was flashen etc. angeht.

[Solution] Win7 Adb driver failing to install in adb sideload - xda-developers hat mich zB abgeschreckt. Das ist zwar Windows, aber ich hatte ja eine funktionierende Alternative.

Mach dir nicht so viele Gedanken. Kaputt machen kannst du da so gut wie nichts.
Treiber Probleme unter Linux sind auch eher selten...

Wenn du interesse hast, kannst ja einfach mal ins Recovery booten, Sideload aktivieren, Kabel anstecke und ein

Code:

adb devices

eintippen, dann sollte angezeigt werden, dass das Gerät im Sideload Mode ist.

linuxnutzer · 2014-02-07T18:51:06+0100

Das ist der Vorteil an Stock Android/ Nexus. Ein laufendes Fastboot/ ADB und wenn man weiß wie man mit der Shell umgeht und man kann alles tun was flashen etc. angeht.

Ja Google und Linux verträgt sich ganz gut, aber leider findet man selten genaue Dokumentationen, wie alles abläuft, darum habe ich es ja gepostet. Mit anderen Herstellern war das Rooten immer relativ risikoreich unter Linux. Ich habe schon Geräte von Samsung, LG und Lenovo gerootet und CM darauf installiert, bei allen ist es mir aber nicht geglückt und dabei auch Verrücktheiten erlebt, wie Dual-SIM, aber telefonieren ist nicht möglich.

Wenn Google-Geräte eine SD-Karte hätten, dann wären sie wirklich interessant, aber so sins sie auch nur das geringere Übel, leider.

Bei der Suche nach einem Phablet fand ich, wie Rooten bei Sony funktoniert, und das gefällt mir. Man meldet sich auf der Sony-Seite an, verzichtet auf einiges und erhält einen Code der aus der IMEI-Nr. generiert wird. Software-Gewährleistung ist sowieso so eine Sache. Was würden die Leute sagen, wenn PCs verkauft würden, wo sie keine Admin-Rechte haben. Warum kann das bei frei gekauften Android-Geräten nicht auch so sein und warum braucht es immer Klimmzüge etwas zu rooten und Schikanen wie Flash-Counter bei Samsung? Weitere Diskussion gerne in einem neuen Thread.

coolfranz · 2014-02-07T18:56:23+0100

Gehört zwar alles nicht mehr so richtig hier her, aber "rooten" bei Sony ist genau so wie beim einem Nexus Gerät (deswegen hats doch wieder etwas mit dem Thread hier zu tun).

Beim Nexus tippst du

Code:

fastboot oem unlock

ein, bestätigst das auf dem Gerät - fertig.

Bei Sony brauchst du für diesen Vorgang diesen Code da...

ab dann gehts ähnlich weiter... z.B. Recovery um dann die superuser binary und eine App zur Verwaltung der Superuser Rechte aufs Gerät zu bringen.

Es gibt nur einen Fall, wo das ganze noch einfacher ist: Oppo (kA, obs da alle Geräte sind) aber bei einigen ist der Bootloader schon offen und man spart sich im Vgl. zum Nexus das

Code:

fastboot oem unlock

Wobei die Sätze die man das beschreibt länger sind als der zusätzliche Befehl beim Nexus ;-)

linuxnutzer · 2014-02-07T19:11:34+0100

aber "rooten" bei Sony ist genau so wie beim einem Nexus Gerät.

Danke, das wusste ich nicht, hatte noch nie was von Sony mit Android. Ich dachte mit Eingabe des Codes ist das Gerät dann automatisch gerootet. So müsste es sein. Aber wenigstens gibt es so was nicht wie einen Flash-Counter wie bei Samsung. Man kommt sich ja wie ein Verbrecher vor, wenn man das Gerät mit allen Rechten nutzen möchte, für das man viel Geld ausgegeben hat.

coolfranz · 2014-02-07T19:18:50+0100

So ist es halt nicht. Und wird es auch nicht sein... Root unter Android, wie es zur Zeit existiert basiert immer auf der Ausnutzung irgendwelcher Lücken im System. (Bei Nexus/ Nexus ähnlichen Geräten nicht so direkt, da die Lücke zum Einspielen der benötigten Dateien das Custom Recovery ist, welches sich ganz einfach mit offiziellen Mitteln installieren lässt).

Ich dachte mit Eingabe des Codes ist das Gerät dann automatisch gerootet.

Nein, dann ist wie gesagt nur der Bootloader offen.

Aber wenigstens gibt es so was nicht wie einen Flash-Counter wie bei Samsung.

Im Prinzip ist das System von Samsung besser!

Beim Hersteller Code Anfordern = Garantie etc. weg. so weit so gut.

Flash Counter, zeigt der was an = Garantie weg. Problem? keines läuft exakt aufs selbe raus (Gut, die Anfrage und Generation des Codes hat man sich gespart).

Nur kannst du den Flash Counter unter Umständen wieder zurücksetzen und dann im Fall des Falls z.B. einen defekten Power Button ersetzt bekommen (der sicher nicht durch Root etc. kaputt geworden ist).

Nichts desto trotz wird das hier alles doch sehr OT. Bitte alles weiter per PN. Danke.

Partitionator · 2014-02-07T20:17:35+0100

Das hier hat euch wirklich nicht stutzig werden lassen?

Code:

root@precise:~# /install/androidins/adt-bundle-linux-x86_64_99b51a4f0526434b083701a896550b72/adt-bundle-linux-x86_64-20131030/sdk/platform-tools/fastboot flash bootloader /install/androidins/nexus7_install_44/nakasig-kot49h_fa034d967e0400363e8a5b315d6a20ba/bootloader-tilapia-4.23.img
sending 'bootloader' (3911 KB)...
OKAY [  0.477s] 
writing 'bootloader'... 
[B]FAILED (remote: (InvalidState))[/B] 
finished. total time: 0.709s

Es ist ja "nur" der flash den Bootloaders der fehlgeschlagen ist... :confused2:

(ich würde mal sagen Glück gehabt das dein Gerät jetzt nicht Schrott ist.)

Wenn man möglichst close to Stock bleiben will und keine custom Recovery will, kann man auch CF-Auto-Root verwenden. Wenn man es sich runtergeladen hat kann man mit

Code:

fastboot boot Name_des_enthaltenen_Images.img

starten ohne das erst eine Recovery geflasht werden muss. (CF-Auto-Root ist so etwas wie eine Custom Recovery die automatisch eine Root.zip flasht und da man sie ohne zu flashen aus dem RAM bootet bleibt die Stock Recovery unversehrt).

Den weg hier über die custom recovery ist zwar nicht schlechter, aber ich finde es so einfach bequemer.

Eine Softwarelücke wird hier übrigens nicht über einen Exploit ausgenutzt, man kann ja ganz normal über den geöffneten bootloader ein eigenes System starten, welches natürlich root rechte hat und dann grad die su-Binarys ins normale System installiert... Mit dem offenen Bootloader könnte man auch einfach pregerootete Images flashen etc.

Und das rücksetzten des flash counters wird bei Samsung auch nichtmehr so funktionieren, da ja jetzt ein efuse durchgebrannt wird, so wie ich das verstanden habe. Außerdem machen die offenen Bootloader (die sich auch nicht schließen lassen bei Samsung ein Muster sinnlos.
So wie es bei den Nexus ist ist es eigentlich ideal. (Hier scheint ja niemand Probleme mit dem flashen zu haben...).
Ich habe bei meinem Nexus auch den Bootloader immer offen. Wenn man übrigens mmcblk0boot0 bei offenem Bootloader gesichert hat, kann man den Bootloader nach dem locken damit auch wieder unlocken (ohne Factory Reset) solange man noch irgend ein System mit root rechten drauf hat. (Aber das ist auch nicht ganz ungefährlich, da man hier am Bootloader rumbastelt.
Ich könnte bei mir mit Hilfe des APX Modes auch durch den geschlossenen Bootloader flashen

Und mit adb/fastboot/apx hatte ich auf Linux auf jedenfall bei Nexen noch nie Probleme mit den Treibern... Alles funktionierte Out-of-the-Box.

coolfranz · 2014-02-08T00:52:15+0100

Es ist ja "nur" der flash den Bootloaders der fehlgeschlagen ist... (ich würde mal sagen Glück gehabt das dein Gerät jetzt nicht Schrott ist.)

Hab ich in der Tat übersehen... wobei ich die Fehlermeldung NICHT so interpretiere, als ob der Flash fehlgeschlagen wäre...
Für mich hört es sich eher so an, als wäre versucht worden den Bootloader zu flashen als das Gerät z.B. im ADB (statt im Fastboot) Mode war (invalidState). Sollte es wirklich so gewesen sein, war die Gefahr = 0.

Den weg hier über die custom recovery ist zwar nicht schlechter, aber ich finde es so einfach bequemer.

Da hast du recht. Ich persönlich spiele nicht mehr so viel an meinen Geräten rum. Funktionieren müssen diese. Da bin ich dann mittlerweile recht konservativ und flashe das Zeug einfach. Fertig.
Mit 10 Finger System und eingerichtetem ADB/Fastboot mit Umgebungsvariablen unter Windows ist das kein Thema ;-)

Eine Softwarelücke wird hier übrigens nicht über einen Exploit ausgenutzt, man kann ja ganz normal über den geöffneten bootloader ein eigenes System starten, welches natürlich root rechte hat und dann grad die su-Binarys ins normale System installiert... Mit dem offenen Bootloader könnte man auch einfach pregerootete Images flashen etc.

Sorry, wenn das Falsch rübergekommen ist, aber das war eher auf Samsung etc. bezogen. Dort ist es ja möglich zu rooten ohne den Flash Counter anzutasten/ Bootloader zu öffnen, wozu Lücken im System gefunden und ausgenutzt werden müssen.

Und das rücksetzten des flash counters wird bei Samsung auch nichtmehr so funktionieren, da ja jetzt ein efuse durchgebrannt wird, so wie ich das verstanden habe.

Kenn mich da bei den neuen Modellen (S4, N3) auch nicht mehr aus, früher war das möglich, weswegen ich auch "unter Umständen" geschrieben habe....

So wie es bei den Nexus ist ist es eigentlich ideal. (Hier scheint ja niemand Probleme mit dem flashen zu haben...).

Genau mein Reden. Ist einfach so wie man es von Android gewohnt ist (1.6... war genau so zu handhaben mit Fastboot/ADB), funktioniert und man kann es Rückgängig machen...
Das Odin rumgespiele bei Samsung gefällt mir auch nicht wirklich... und Sony/ Motorola machens auch nicht besser, da man zum Unlocken diese Codes braucht. Beim Nexus kann mans wenigstens wieder Rückgängig machen und keiner (außer des NSA) weiß bescheid.

Ich habe bei meinem Nexus auch den Bootloader immer offen.

Und öffnest damit jedem "Finder" deines Nexus Tür und Tor zu deinen Daten - das muss immer dazu gesagt werden, darauf wird meines Achtens viel zu wenig Wert gelegt (das dir das durchaus bewusst ist nehme ich an - vielen anderen, die aus diesem und jenen Grund "rooten" und den Bootloader öffnen aber wohl nicht).

Wenn man übrigens mmcblk0boot0 bei offenem Bootloader gesichert hat, kann man den Bootloader nach dem locken damit auch wieder unlocken (ohne Factory Reset) solange man noch irgend ein System mit root rechten drauf hat. (Aber das ist auch nicht ganz ungefährlich, da man hier am Bootloader rumbastelt.
Ich könnte bei mir mit Hilfe des APX Modes auch durch den geschlossenen Bootloader flashen

Wusste ich nicht, danke ;-) Die Voraussetzungen sind aber schon mal schwierig zu erfüllen. Z.B. sind die Root Rechte mit geschlossenem Bootloader nach nem OTA Update wohl futsch... und die anderen Sachen sind wohl auch noch weniger Anfänger geeignet als das Flashen eines Factory Images.

Partitionator · 2014-02-08T01:24:14+0100

coolfranz schrieb:
Für mich hört es sich eher so an, als wäre versucht worden den Bootloader zu flashen als das Gerät z.B. im ADB (statt im Fastboot) Mode war (invalidState). Sollte es wirklich so gewesen sein, war die Gefahr = 0.

Nein das ist falsch, wäre es im adb Mode und nicht im fastboot würde dort einfach stehen "waiting for device". invalidState wird, wie schon in einem meiner vorherigen Beiträge erwähnt, meist von einem fehlerhaften Bootloader Image ausgelöst. So wie es aussieht müssen die Bootloader signiert sein, die man über fastboot flasht (Gott seit dank sonst hätten diese defekten Bootloader schon weitaus mehr bricks verursacht, und ich habe es schon oft genug erlebt das jemand die CWM als bootloader flashen wollte, was dadurch glücklicher Weise geblockt wurde). Und bei diesen fehlerhaften Bootloadern stimmt diese signatur nichtmehr. Das hat dann ein invalidState zur folge. Auf dem Bildschirm des Nexus ist oben links übrigens "Signature missmatch" zu lesen.

Aber das thema mit den Bootloadern und meine Emphelung dazu hab ich ja schon in einem vorherigen Post ausführlich beschrieben

.

Da hast du recht. Ich persönlich spiele nicht mehr so viel an meinen Geräten rum. Funktionieren müssen diese. Da bin ich dann mittlerweile recht konservativ und flashe das Zeug einfach. Fertig.
Mit 10 Finger System und eingerichtetem ADB/Fastboot mit Umgebungsvariablen unter Windows ist das kein Thema ;-)

Ich experimentiere sehr gerne mit dem Zeugs, deshalb war auch das sichern der APX-Blobs für mich praktisch Pflicht

.
Und naja via Fastboot ist ein fastboot boot cf-auto-root.img doch wesentlich bequemer als erst die recovery zu flashen, dann am Nexus mit den lautstärketasten in die recovery zu booten und dort dann ne zip zu flashen.
Ich verwende übrigens lieber die TWRP, welche ich dann nach dem root einfach aus Android raus vom Multi ROM Manager flashen lasse.

Sorry, wenn das Falsch rübergekommen ist, aber das war eher auf Samsung etc. bezogen. Dort ist es ja möglich zu rooten ohne den Flash Counter anzutasten/ Bootloader zu öffnen, wozu Lücken im System gefunden und ausgenutzt werden müssen.

Naja viele ältere/billige Samsung geräte und das S2 ab ICS, haben keine Signaturprüfung mehr in der Recovery, das bedeutet dort kann man einfach eine Temporäre CWM starten, einen Kernel flashen oder auch einfach die root Binarys flashen. -Der flash counter merkt nichts und Exploits sind dazu auch keine nötig.

Das Odin rumgespiele bei Samsung gefällt mir auch nicht wirklich...

Ja das tar basteln geht auf die Nerven

. Der flashcounter hier steht auch schon auf 11 oder 12

. Wobei ich aber von Samsung sowieso nichts halte.

Und öffnest damit jedem "Finder" deines Nexus Tür und Tor zu deinen Daten - das muss immer dazu gesagt werden, darauf wird meines Achtens viel zu wenig Wert gelegt (das dir das durchaus bewusst ist nehme ich an - vielen anderen, die aus diesem und jenen Grund "rooten" und den Bootloader öffnen aber wohl nicht).

Jaja das ist mir klar, mit so etwas habe ich mich ausfürhlich beschäftigt

. Aber wenn ich sowieso kein Muster/PIN drin hab, bringt ein geschlossener BL auch nicht viel... Eine Custom Recovery macht einen geschlossenen Bootloader übrigens auch wirkungslos...

Wegen dem wipe losen unlocken guck hier: [TOOL][HOW-TO] [N7] [grouper+tilapia] BootUnlocker Script [Flashable Zip] - xda-developers

Und falls du dein Nexus Brcksicher machen willst ist flatline das Stichwort, da sind selbst kaputte Bootloader kein Problem. Allerdings muss man die Blobs sichern solange das Gerät noch funktioniert. Und die Blobs solten nicht in flasche Hände geraten, denn sie machen einen gelockten Bootloader auch wirkungslos.
Blobs sichern: https://www.androidroot.mobi/pages/guides/tegra3-guide-nvflash-jellybean/
wiederherstellen wenn selbst wheelie scheitert: xda-developers - View Single Post - [SOLVED] Unbricking with nvflash

[How-To] Nexus 7 Factory Image Flashen

coolfranz

Enthusiast

linuxnutzer

Enthusiast

coolfranz

Enthusiast

linuxnutzer

Enthusiast

coolfranz

Enthusiast

linuxnutzer

Enthusiast

coolfranz

Enthusiast

linuxnutzer

Enthusiast

coolfranz

Enthusiast

linuxnutzer

Enthusiast

coolfranz

Enthusiast

linuxnutzer

Enthusiast

coolfranz

Enthusiast

linuxnutzer

Enthusiast

coolfranz

Enthusiast

linuxnutzer

Enthusiast

coolfranz

Enthusiast

Partitionator

Stamm-User

coolfranz

Enthusiast

Partitionator

Stamm-User

Ähnliche Themen