Lessons learned - Wichtig vor Flashen, Mods und Experimenten!

  • 32 Antworten
  • Letztes Antwortdatum
T

Thyrus

Gast
Inhaltsverzeichnis:

Lesson 1: Akkuladezustand bei Experimenten und flashen
Lesson 2: Nandroid und adbrecovery update.zip
Lesson 3: Wipe und Full SBFs
Lesson 4: RSD Lite 4.6 und flashen aus dem Bootloader
Lesson 5: Erstellen eines /data/temp folders
Lesson 6: Die sbf.gz Dateien VORHER entpacken
Lesson 7: Die typischen Fehlermeldungen (beim ausführen einer update.zip)
Lesson 8: Die typischen Fehlermeldungen (beim ausführen eines flash Versuches ueber RSD LITE)
Lesson 9: Die typischen Fehlermeldungen (beim starten des Milestone)


Lessons learned und Fixes:
Das nachfolgende Kapitel beschäftigt sich mit den „lessons-learned“ der letzten Wochen. Es dient dazu, das Risiko eines bricks, der nicht mehr zu recovern ist, zu minimieren. Ich habe versucht, das zu untersuchen und auch meine „lessons learned“ hier zu beschreiben.

Generell möchte ich empfehlen, das diese „lessons learned“ von allen befolgt werden, denn dadurch ist gesichert, immer einen Plan B zu haben und das Risiko zu minimieren, vor einem „oh shit“ Problem zu stehen

An wen richtet sich das:
-Je mehr man experimentiert, flasht, moddet etc, desto höher ist das Risiko eines Problems, daher – je experimentierfreudiger, desto mehr sollte man diese „lessons learned“ beherzigen
-Selbst einige „zweifelhafte Apps“ können solche Situationen hervorzaubern. Daher auch hier – am besten vorbereitet sein

Was meine ich mit "Experimenten"?
Die meisten von uns modden und experimentieren schon relativ fleissig.

Die Installation und Neuinstallation von Apps aus dem Markt ist prinzipiell ungefährlich. Daher müssen alle diese Lessons Learned nicht vor jedem Test einer App aus dem Markt durchgeführt werden, das wäre sinnlos (ausser es ist klar eine app für ein falsches Gerät, wie z.B. DroidRootHelper)

Sobald es aber an irgendwelche Modifikationen angeht, die Root erfordern (daher auch hier im ROOT Forum gesposted und nicht in generellen MS Forum), sollte man diese lessons learned kennen und nach Möglichkeit beherzigen.

Die Faustregel hier:

- Ein unerfahrener User, der zum ersten Mal oder nur sporadisch Root-erfordernde Modifikationen (egal ob script, Metamorph oder einfaches kopieren von Systemdateien) versuchen möchte, oder zum ersten Mal ein sbf flashen möchte oder zum ersten Mal den "root versucht", sollte die meisten, wenn nicht alle dieser lessons-learned beherzigen.
- Ein "Profi" wie unsere Modder zb, die 100te Male in der Woche einen Brick provoziere können, kennen diese lessons-learned meist schon, oder sie haben es im Gespür durch ihre Erfahrung, wie "sicher" sie sein wollen und können die potentiellen Probleme einschätzen.
- Sobald man das MS aber flashen muss, sollte man zumindest die lessons learned 1 und 2 beherzigen. Auch ich fand mich vor kurzem in einer Situation wieder, wo ich im BL nicht mehr flashen konnte durch den Akku status von 5%. Ich dachte mir "ha, was solls, ich weiss ja was ich tue", habe das MS dann nur solange an das Ladegerät gehängt, bis ich die 15% wieder hatte (um den BL pass zu bekommen) und habe geflasht. Was ist passiert - eine brick. Flashen war nix mehr (Akku unter 15%, laden auch nicht weil er im Moto M haengen blieb, und die nandroid update.zip hatte ich auch nicht mehr drauf, weil ich mit der 2.1 beta root update-zip gespielt hatte :) Mir blieb nur der Weg ueber den 2ten Akku eines MS, welches sich gerade in meiner Nähe befand weil ein Freund mich gebeten hatte, das für ihn zu erledigen :)

Also auch an die "alten Hasen (nein, nicht du sanni :)) - better save than sorry :)



Falls ihr eigene Lessons learned habt, die euch wichtig erscheinen, nehme ich dir gerne mit Quelle hier auf :)
 
Zuletzt bearbeitet von einem Moderator:
  • Danke
Reaktionen: milestone2709, TexasHol, Balu381 und 25 andere
Lesson 1: Akkuladezustand bei Experimenten und flashen


-Immer das Handy vor dem flashen auf mindestens 50%, idealerweise 100% laden!
-Keine Experimente mit Apps/Fixes/Mods etc. bei geringer Akku-Kapazität – denn wenn was schief geht, braucht ihr die Batterie :)


Warum:
RDS lite verhindert bei einem Akkuladestand unter 15% den Flashvorgang im Bootloader (message: battery low, cannot flash).
Das ist ein SEGEN und Fluch zugleich.

Segen daher dass man eben nicht wahrend des flashens ein Problem hat und das MS ohne Strom abschaltet.

Fluch daher, das, wenn eben der erste Vorgang noch durchgegangen ist, aber trotzdem irgendetwas schiefgegangen ist und das MS im Motorola Logo hängen bleibt. In der Recovery und im Bootloader Modus lädt das MS nicht auf, da hier Dienste zum laden des Akkus noch nicht geladen wurden. Schlimmstenfalls ist es so, dass man den 2ten Flash etc nicht mehr durchführen kann, weil nun die Akkuleistung unter 15% abgesunken ist.

Workaround und fixes:
-Akku ausleihen von einem User/Freund, um das Handy zu flashen und zu „entbricken“
-Ladestation mit separatem Akkuladegerät kaufen (damit der Akku auch ohne MS geladen werden kann), z.B:
Dockingstation m Akkuschacht f Motorola Milestone bei eBay.de: Motorola (endet 28.01.10 08:44:43 MEZ)
-2ten Akku kaufen, volladen und fuer solche Fälle parat haben
Suche in Ebay nach "BP6X", aber am besten den Orginalakku, denn der ist auch vorgeladen

EDIT: hot-off-the press, Zitat des Users "Kugeldichrund"

Kugeldichrund schrieb:
hallo ich nochmal :)
also vorhin ist das externe ladegerät aus hong kong gekommen und konnte nun mein milestone wieder flashen. also lag nur daran, dass der bateriestand beim erstmaligen flashen nur viertelst aufgeladen war.

kugeldichrund
 
Zuletzt bearbeitet von einem Moderator:
  • Danke
Reaktionen: milestone2709, MartN und tunake
Lesson 2: Nandroid Backups und die update.zip

-VOR dem flashen ein Nandroid Backup ziehen und die dazugehörige update.zip der adbcevory auf die SD Karte kopieren
-IMMER ein Nandroid-backup und die update.zip der adbrecovery auf der SD karte behalten

Links:
How-To:
https://www.android-hilfe.de/forum/...-adbrecovery-und-nandroid-tutorial.16973.html

adbrecovery:
[Release] ADBRecovery

Warum:
- Ich habe in der letzten Zeit mehrere User , die warum auch immer bei Experimenten im Bootlogo hängen bleiben (M-Logo)
- Meist kann man das durch das flashen eines SBF beheben
- JEDOCH bringt das nicht immer den gewünschten Effekt (ca 5% der Fälle)
- Durch ein Nandroid Backup auf der SD Karte kann, insofern die Recovery noch gestartet werden kann, dieses Backup benutzt werden oder eben auch nur Teile davon (z.b die recovery selber)
- Hinsichtlich lessons learned2:
Problem: Wenn mal was schief geht und man nur noch den BL und/oder die recovery starten kann, so kann man ohne adbrecovery nicht mehr auf die SD Karte zugreifen. Die adbrecovery update.zip auf der SK Karte ermöglicht das jedoch. Wenn man sie draufhat, so ist das ein Segen und daher kann ich nur empfehlen, sie IMMER drauf zu lassen. Wenn man sie braucht ist man froh das gemacht zu haben :)

Workaround und fixes:

- Zugriff auf die SD Karte durch einen SD Card Reader am PC (eventuell mit Adapter)
- Zugriff auf die SD Karte durch einen microSD Adapter (wenn man bereits einen card reader fuer normale SD Karten hat)
 
Lesson 3: Wipe und Full SBFs

Auch wenn es meist nervig ist, bei größeren updates (z.B 2.0.1 auf 2.1) auf Werksteinstellungen zuruecksetzen


Warum:
Die meisten Bugs und Probleme, die bei dem update auf 2.1 beta entstanden sind, resultieren aus inkonsistenzen von user settings, Applikationen, Einstellungen etc. In 90-95 Prozent der Fällen sind diese Probleme nach einem Wipe oder einer Neuinstallation behoben.
In dem Fall, das ein Problem, force closes etc auftauchen, einen wipe durchführen.

Vorgangsweise und Workaround:
- Wenn der update durch einen update.zip erfolgt: Vor dem Update einen "wipe" durchführen
- Wenn der update durch das flashen eines sbf files erfolgt: Entweder ein "full sbf" benutzen (kein Service im Dateinamen", das ist die sicherste Variante) oder vor dem Flashen einen "wipe" durchführen

Andere Möglichkeit: Wenn man sich das Neukonfigurieren des MS ersparen möchte (Desktop icons, Apps, Email Einstellungen etc), so kann man diesen update auch ohne wipen durchführen (dh. keinen wipe vor dem ausführen der update.zip oder flashen mit einem "service.sbf" (Service im Dateinamen). Sollten dann Probleme bestehen, so kann man den "wipe" auch noch nachher durchführen.

Die sicherste Variante ist aber, den update auf einem "frischen" System per wipe oder full sbf durchzuführen, denn dann kann man sicher sein, das alles "clean" ist.
 
Zuletzt bearbeitet von einem Moderator:
Lesson 4: RSD Lite 4.6 und flashen aus dem Bootloader
- Die neueste Version von RSD Lite (4.6) benutzen
- Flashen immer aus dem bootloader mode
- RSD lite nicht in virtueller Umgebung ausführen und auch mit Admin-Rechten ausführen

Warum:
In RSD Lite 4.6 kamen einige Änderungen dazu. Einige Probleme des flashens konnten durch Nutzung von RDS Lite 4.6 behoben werden

Flashen sollte man immer aus dem bootloader mode heraus. Zwar kann man auch RSD lite ausführen, wenn das MS am USB haengt, denn RSD rebootet das MS dann im bootloader mode automatisch. Aber es gab bereits einen Fall, bei dem dieser automatische prozess NICHT abgeschlossen war, und das MS bootete nicht in den Bootloader mode und hing in einer "endlosschleife". Es konnte zwar wiederhergestellt werden, aber es war ein schwieriger Prozess.
Daher würde ich empfehlen, immer aus dem bootloader modus heraus zu flashen, um dieses mögliche Problem zu vermeiden.

RSD Lite sollte NICHT unter virtueller Umgebung (also ausführen in einer virtual machine unter MacOS, linux etc) ausgeführt werden. Es kann gutgehen, aber es kann eben auch NICHT gutgehen. Um dieses Problem zu vermeiden - nur unter WinOS (idealerweise XP 32 bit) ausführen. XP 32 Bit hat sich durch die einfachere Admin Verwaltung und 32 bit OS als beste und sicherste Möglichkeit bewiesen bisher.
Zwar funktioniert es auch unter Vista, Windows7, 64bit etc, aber hier muss man eben sicherstellen, das RSD lite mit Admin Rechten ausgeführt wird und die richtigen 64-bit treiber einbinden.

Alle Treiber und RSD Lite bekommt man hier:
Downloads - Tools & Treiber

Start in den bootloader Modus:
Zustand MS: Ausgeschaltet, Akku eingesetzt
- Mann öffnet die Tastatur, und drückt auf dem Navigationspad (D-Pad) die HOCH Taste (wenn man das MS hochkant in den Händen hält, also Tastatur schaut nach links, so ist es die D-PAD rechts taste. Diese Taste hält man gedrückt.



- Bei gedrückter D-PAD HOCH Taste nun den Powerbutton drücken. Nach 1-2 Sekunden wird das Display grau, und wenn man die Tasten loslässt, so sieht man den „bootloader Modus“
 
Zuletzt bearbeitet von einem Moderator:
Lesson 5: Erstellen eines /data/temp folders
Einen tempöraren Folder erstellen zum Permissions-setzen


Warum:
Wenn man Dateien manuell (per root explorer oder anderen file explorern) editiert, kopiert, verändert, würde ich empfehlen, das man sich einen order "Temp" oder "tmp" oder ähnlich auf der /data partition erstellt.
Da dieser ordner dann auf einer linux partition läuft, kann man die Dateien mit den korrekten permissions ausstatten, was bei einer FAT partion (z.b der SD Karte) nicht möglich ist. So kann mal alle dateien komfortabel in dieses verzeichnis legen, dort die permissions ändern, und sie von dort aus direkt in das jeweilige Verzeichnis kopieren. Wenn man den root explorer verwendet, kann man sich einen shortcut auf diesen ordner legen und das kopieren (zb eines Launchers, der framwork-res, der services.jar etc) geht damit sehr schnell (ich habe auch shortcuts zu /system/app und system/framework im root explorer mit shortcuts versehen)
Wenn man files etc per ADB oder SCRIPT kopiert, ist dies nicht notwendig da man beim kopieren die permissions definieren kann, aber fuer diejenigen unter uns, die viel mit dem root exporer arbeiten, ist das ein angenehmer workaround - und die "brick" wahrscheinlichkeit bei kopieren und überschreiben von dateien per Root Explorer ist um 50% geringer.
 
Lesson 6: auf die endung der "flash" dateien achten!
Manchmal sind die zu flashenden dateien "gepackt" - muessen entpackt werden


Warum:
Um Speicherplatz zu sparen, sind viele im Internet downloadbare Dateien gepackt. Auch die .sbf dateien koenne gepackt sein, also .sbf.zip oder .sbf.gz
Auch .gz ist ein 7zip format. Also bitte vorher sicherstellen, das die Dateien entpackt sind. "endpackte" .sbf Dateien haben unter 2.1 ca 140-150 MB, gepackt ca.90-100 MB
 
Zuletzt bearbeitet von einem Moderator:
Lesson 7: Die typischen Fehlermeldungen (beim ausführen einer update.zip)

Beim Ausführen der update.zip kommt es meist zu einer Handvoll Fehlermeldungen, die sehr typisch sind.

UPDATE.ZIP

Ein update.zip ist nichts anders als ein patch. Es hat ein binary file enthalten, welche die Änderungen VON einer BESTIMMTEN zu einer BESTIMMTEN SW Version binaer gespeichert hat. Vor dem entpacken und patchen prüft die update.zip, ob die VON Version auf dem Telefon korrekt ist. Wenn diese VON Version (oder auch O2/VF/DACh/UK lokalisierung) nicht korrekt ist, wird der Vorgang mit einer Fehlermeldung abgebrochen.

Die einzige "universelle" update.zip ist die von Sera vom 2.0/2.0.1 root und die des adbrecovery (also beide, die die exploit luecke unter 2.0/2.0.1 nutzen).

Diese sind "universell" einsetzbar, weil der "payload", das eigentliche update, nicht mehr sichtbar ist und daher auch im script nicht verarbeitet wird - ergo auch kein "check". Man kann schnell pruefen, welche Art des update zip man hat indem man folgendes tut:
variante a) "reinschauen" in das update zip. Befindet sich dort auf der Hauptebene ein .bin file, so wie zb. SHOLS_02_01.14.0_to_SHOLS_02.02.34.0_...bin, so hat dieses update eine payload. Man kann auch sehen von welcher zu welcher Version diese update.zip geeignet ist.
variante b) "reinschauen" in das updater-script in dem update.zip file (mit text editor). Findet man dort keinen "Hinweis" mehr auf das ausfuehren des .bin files, so ist dieses auch ein update "ohne" payload.
Der Hinweis sieht z.B so aus "assert(package_extract_file("SHOLS_U2_01.14.0_to_SHOLS_U2_02.34.0_.bin", "/tmp/delta.bin")"




E:can´t open/cache/recovery/command

Der Fehler ist "korrekt", und daher kein Fehler im Eigentlichen Sinn und erscheint bei jedem update.zip.

STATUS7

--install from sdcard...
finding update package...
opening update package...
verifying update package...
installing update...
cannot find update_binary
assert failed: rb_fs_patch("/tmp/delta.bin","/")
E:Error in /sdcard/update.zip (Status 7)
Installtion aborted.

Dieser Fehler erscheint, wenn man eine update.zip ausführen möchte, die für eine andere SW Version geschrieben wurde (z.b eine update.zip von DACH auf O2 oder aehnliches)
Der Fehler kann auch erscheinen, wenn man versucht, eine update.zip für DACH2.0.1-DACH2.1 auszuführen auf einer O2 2.0.1 version, man versucht dieses update schon auf einer korrekten DACH2.1 SW auszuführen oder man versucht diese Datei auf einem DACH2.0 auszuführen.

EOCD marker occurs after start of EOCD
-- Install from sdcard...
Finding update package...
opening update package...
verifing update package...
E:EOCD marker occurs after start of EOCD
E: signature verfication failed
Installation aborted

Wer sich ein wenig mit "root" auskennt, weiss das das ein Hinweis auf die exploit Lücke der alten 2.0/2.0.1 Implemenierungen handelt
https://www.android-hilfe.de/forum/root-hacking-modding-fuer-motorola-milestone.60/faq-root-fuer-das-milestone.12943.html

Dieser exploit Fehler wurde in der recovery von 2.1 (alle Versionen) behoben.

Bekommt man nun diesen Fehler, besagt er, das man eine 2.1 Version installiert hat, der diese Lücke schliest. Wenn man nun versucht, eine root update.zip auszuführen und erhält diesen Fehler, so ist die Recovery Partition geschlossen, und root daher nicht möglich. Es geht jeden damit, das man die alte 2.0.1 recovery (als sbf file) flashen kann ueber die normale 2.1 SW Version. Danach kann man die 2.0/2.0.1 update.zip wieder ausführen, da die exploit Lücke wieder offen ist.
(Punkt 4 in verlinktem Thread)
https://www.android-hilfe.de/forum/anleitungen-fuer-motorola-milestone.134/how-to-2-1-update-mit-ohne-root-fuer-einsteiger.21711.html
 
Zuletzt bearbeitet von einem Moderator:
Lesson 8: Die typischen Fehlermeldungen (beim ausführen eines flash Versuches ueber RSD LITE)

FEHLER "ERROR processing flash file (0x7100)" oder
FEHLER "ERROR processing flash file (0x700f)" oder ähnlich in RDS Lite


"Failed flashing process. Error processing flash file. (0X700F), phone connected.", oder ähnlich

so liegt das an den Administrator Rechten eurer Windows Version.

Wie der Fehler behoben werden kann, habe ich in diesem thread erklaert
https://www.android-hilfe.de/forum/anleitungen-fuer-motorola-milestone.134/how-to-fehlerbehebung-bei-brick-und-neu-flashen.17891.html



Start Knopf ausgegraut oder Milestone nicht sichtbar

Nach einigen Sekunden (eventuell sieht man die „installiere treiber“ Informationen von Windows) erscheint in RSD Lite in der liste das Telefon. Das die Daten dort eventuell nur mit N/A markiert sind, ist im Moment irrelevant. Ganz vorne sollte A853 stehen, der „codename“ des MS (wenn man aus dem laufenden Betrieb flasht), oder " S Flash Omap3430", wenn es aus dem Booloader heraus erfolgt.

Wenn das MS nicht erscheint:
- Treiber neu installieren
- Andere USB Buchse nutzen
- Versuchen das Milestone im Bootloader Modus zu flashen
 

Anhänge

  • RSD_Screenshot.png
    RSD_Screenshot.png
    7,9 KB · Aufrufe: 1.071
Zuletzt bearbeitet von einem Moderator:
Lesson 9: Die typischen Fehlermeldungen (beim starten des Milestone)


Err:A5,69,35,00,27

Bootloader
90,73
Err:A5,69,35,00,27

Problem: Der Flashvorgang ist schiefgelaufen.
Abhilfe: Neu flashen, am besten mit einer FULL SBF. (Flashen von SHOLS_U2_01.14.0_DACH_FULL1FF.sbf oder der 2.0 Variante)
Ich nehme bei solchen Problemen IMMER die 2.0 DACH FULL
https://rsddownload.motorola.com/do...0R_USASHLS00RTDACH_P001_A001_HWp2a_1FF.sbf.gz





Err:A5,69,35,00,2F
Bootloader
90.73
Err:A5,69,35,00,2F
Milestone started normal. Jedoch kommt beim Aufrufen der recovery (CAMERA+POWER ON) diese Fehlermeldung und die Recovery kann nicht gestarted werden

Problem: Recovery beschaedigt (recovery laesst sich nicht mehr oeffnen). Dies passiert normalerweise nur, wenn man mit der recovery des DROIDs versucht, Root zu erlangen (zb durch Nutzung der MS-TOEDLICHEN!! App "droid root helper" oder SPRecovery
Abhilfe: Es scheint, als koennte man durch flashen des 90.73 Bootloader das Problem wieder beheben.
Bootloader:
http://www.mediafire.com/?sharekey=1377d4bbe87a5ea4e7c82ed4b8f0c380ef262f018e4e054e38538f5672f1b9df
Thread zu dem Problem:
https://www.android-hilfe.de/forum/...60/kein-recovery-menue-mehr.22688-page-2.html


Err:A5,69,35,00,21
Bootloader
90.73
Err:A5,69,35,00,21
Milestone started nicht mehr.

Problem: Bootloader beschaedigt (recovery laesst sich nicht mehr oeffnen).
Abhilfe: Noch keine bekannt, es muss zur Reperatur eingeschickt werden. Auch flashed der Bootloader oder anderer Möglichkeiten hat keine Abhilfe geschaffen.
Dieser Fall ist bisher einmal vorgekommen.
 
Zuletzt bearbeitet von einem Moderator:
  • Danke
Reaktionen: letsdoit, dlhuss, Saubaer25 und eine weitere Person
Platzhalter Lesson 10

(bitte nicht posten)
 
Platzhalter Lesson 11

(bitte nicht posten)
 
Platzhalter Lesson 12

(bitte nicht posten)
 
Platzhalter Lesson 13

(bitte nicht posten)
 
Platzhalter Lesson 14

(bitte nicht posten)
 
Platzhalter Lesson 15

(bitte nicht posten)
 
SO, ab hier koennt ihr nun kommentare etc posten :)
 
Fein :)

es gibt 15 Lessons?

Time to take class ;)
 
Ich habe mal soviele slots reserviert :) ob es 15 werden, werden wir sehen :)
 
bist du dir sicher, das 15 überhaubt ausreichen :D
aber ich werd alles fein lesen ;) wenn ich mal die lust dazu hab :D
 

Ähnliche Themen

D
  • DHDCS
Antworten
17
Aufrufe
3.294
DAS_Original
DAS_Original
BBF-Android
Antworten
8
Aufrufe
1.681
Milestone_User
M
A
Antworten
1
Aufrufe
1.408
Diamond-X
Diamond-X
Zurück
Oben Unten