Vigyázz MÉLYVÍZ!
Mielőtt bárki nekilátna bármit is csinálni, itt az alkalom a mentésre!!!
Nem vicc, a félig működő rendszert is KÖTELEZŐ lementeni.
Természetesen mindenki a saját felelősségére fogadja meg eme tanácsot, avagy sem...
A leírás nem csak MT6589-es platformra vonatkozik.
Újabban a 6582 és 6572-es platformon is jelentkezett már eme (általában user error) jelenség.
Bevezető:
Többször előfordult már olyan eset, amikor új ROM telepítése után bekapcsoláskor kellemetlen meglepetéssel találkozott valaki:
Invalid IMEI.
Az IMEI átírása jogellenes tevékenység, a más telefonról beszerzett IMEI használata azonnali hálózati tiltást eredményez, ez miatt a felelősség kérdése fontos; ráadásul mintkét telefont tiltják ez miatt így saját magadnak és másnak is kárt okozhatsz vele.
Ez a módszer sértetlen nvram esetén alkalmazható, nem hozható összefüggésbe az imei árírásával.
Fontos az, hogy a körülményeket tisztázzuk: abban az esetben lehet így eljárni, ha ROM csere után tűnik el , és bebizonyosodik, hogy a protect_s partíció sérült (formázódott, írodott felül).
Mostanában az MT6589(M/T)-es 4 magosok esetén van ilyen.
Tisztázni kell többek között:
- a telefonon lévő recovery milyen. A recovery-be a csatolási pontok hogyan kerültek bele.
- az új, feltelepített ROM honnan származik; még fontosabb az, hogy a telepítőszkriptjében mi van (/META-INF/com/google/android/updater-script). Ez lehet ugyanis a kulcsa az IMEI eltűnésének. Nem állítom hogy csak ez, de lehet egy potenciálisan elsődleges ok.
- meg kell vizsgálni, hogy a recovery csatolási pontjai és a telepítő szkript csatolási pontjai milyenek: melyik hova csatolja a /system, /data stb... partíciókat.
HA a leírtakat nem tudod értelmezni, akkor inkább ne kezdj bele, nehogy több kárt csinálj magadnak.
Ez esetben kérj segítséget a fórumon!
Folytatva a hiba lehetséges okára vonatkozó okfejtést:
Rengeteg ROM-ban még mindig az MT6577 esetén használatos partíciószámozást használják a formázáskor.
A /system partíció helyei (sztendert partíciókiosztás esetén):
MT6577 : /dev/block/mmcblkp03
MT6589 : /dev/block/mmcblkp05
Ettől azonban gyártónkként eltérhet(!) a partíciókiosztás.
Ennek ellenőrzése a /proc/dumchar_info fájl tartalmának megnézésével történhet, ott egyértelműen tükröződik a partíciók és a blokkeszköz kiosztásának mibenléte. Magyarul onnan lehet tudni, hogy melyik partíció hol helyezkedik el.
Tovább bonyolódik, hogy az MT6589 esetén a gyári recovery-kben található partíciókiosztás legtöbb esetben az MT6577-es recovery-kkel azonos, és a gyári frissítések szépen fel is mennek vele.
Más azonban a helyzet a módosított ROM-oknál és módosított recovery-knél.
Ha telepítőszkriptben ezt látod
format("ext4", "EMMC", "/dev/block/mmcblk0p3");
mount("ext4", "EMMC", "/dev/block/mmcblk0p3", "/system");
A dumchar_info tartalma viszont ez:
ebr1 0x0000000000080000 0x0000000000080000 2 /dev/block/mmcblk0p1
pmt 0x0000000000400000 0x0000000000100000 2 /dev/block/mmcblk0
pro_info 0x0000000000300000 0x0000000000500000 2 /dev/block/mmcblk0
nvram 0x0000000000500000 0x0000000000800000 2 /dev/block/mmcblk0
protect_f 0x0000000000a00000 0x0000000000d00000 2 /dev/block/mmcblk0p2
protect_s 0x0000000000a00000 0x0000000001700000 2 /dev/block/mmcblk0p3
seccfg 0x0000000000020000 0x0000000002100000 2 /dev/block/mmcblk0
uboot 0x0000000000060000 0x0000000002120000 2 /dev/block/mmcblk0
bootimg 0x0000000000600000 0x0000000002180000 2 /dev/block/mmcblk0
recovery 0x0000000000600000 0x0000000002780000 2 /dev/block/mmcblk0
sec_ro 0x0000000000600000 0x0000000002d80000 2 /dev/block/mmcblk0p4
misc 0x0000000000080000 0x0000000003380000 2 /dev/block/mmcblk0
logo 0x0000000000300000 0x0000000003400000 2 /dev/block/mmcblk0
ebr2 0x0000000000080000 0x0000000003700000 2 /dev/block/mmcblk0
expdb 0x0000000000a00000 0x0000000003780000 2 /dev/block/mmcblk0
android 0x0000000022600000 0x0000000004180000 2 /dev/block/mmcblk0p5
cache 0x0000000007e00000 0x0000000026780000 2 /dev/block/mmcblk0p6
usrdata 0x000000003ae00000 0x000000002e580000 2 /dev/block/mmcblk0p7
fat 0x000000016eda0000 0x0000000069380000 2 /dev/block/mmcblk0p8
Akkor jó eséllyel teljesen más partíciót formázott meg és kezdett el írni a telepítőszkript, mint a valós /system.
Ez legtöbb esetben pedig a protect_s. Ha ezt sikerül visszaállítani, akkor általában nyert ügy lesz belőle.
Hogyan lehet visszaállítani a protect_s-t a malőr után?
1, Ha van MRKDroidTools-os mentés, akkor CWM szkriptet lehet belőle készíteni.
2, Ha van Flashtool-os vagy dd-s mentés, akkor ADB-n keresztül dd paranncsal (root jog kell hozzá).
(Elméletileg flashtool-lal is, de ezt még nem próbáltam; és itt nem a sztenderd „download”-os megoldás lehet a nyerő, hanem a direkt memóriacímre írás, hiszen a scatter-ben __NODL__ előtaggal szerepel a protect_s)
3, Ha nincs mentés...
Hogy jön ide a recovery?
A módosított recovery-k (legalábbis amiket Bruno Martins, Carliv fordítanak forrásból, illetve amiket ezekből én szoktam portolni) vagy a dumchar_info fájl tartalmát használják fel, vagy az emmc@<partíció> bejegyzéseket tartalmazzák a recovery ramdisk-jében a /etc/recovery.fstab fájlban.
Ennek a tartalmát „csak úgy” nem lehet megnézni, a recovery-t ki kell bontani mtktools-zal (NEM MTKDroidTools !)
Lásd másik bejegyzésemet.
Lássunk neki...
0, tedd a telefont repülőgép üzemmódba!
Ez egy fontos lépés, nehogy a sikeres visszaállítás után az esetleges nem saját IMEI miatt rögtön tiltson a hálózat!
1, CWM szkript készítése
Csak szakértőknek ajánlott, aki ismeri úgyis megcsinálja magának...
2, dd-vel történő visszaállítás
A dumchar_info fájltól függően az értékek változhatnak, de egyetlen (na jó igazából kettő) parancs segítségével visszarakható a mentés adb shellből:
su -
dd if=/storage/sdcard0/dd-backup/protect_s.img of=/dev/block/mmcblk0 bs=1024 seek=23552
Természetesen feltételezem, hogy a protect_s.img már a /storage/sdcard0/dd-backup/ könyvtárban van!
Továbbá a seek utáni érték a blokkeszköz azonkezdőcíme, ahonnan szeretnénk kezdeni a visszaírást.
Vigyázz! A dd parancs nem ellenőriz, nem kérdez, csak végrahajt. Ha rossz értéket adsz meg, akkor még azt is tönkreteszed ami eddig volt!
3, Ha nincs mentés...
Ez esetben használni fogjuk az MTKDroidTools programot.
Előtte azonban nézd meg egy arra alkalmas fájlkezelővel, hogy a /protect_s könyvtárban mi van.
Ha ez van benne:
app
lost+found
Akkor tuti, hogy a telepítő ide akarta tenni a /system partíciót... csakhogy nem sikerült neki, mivel ez csak 10MB-os (ezért is végezhet olyan nagyon hamar a telepítés...)
Ezen a partíción ilyennek kellene lenni a könyvtárszerkezetnek:
lost+found
md
Ezt a könyvtárstruktúrát kell visszaálíltani. Minden olyan könyvtárat, ami ezen a kettőn kívül van, azt törölni fogjuk.
Mielőtt azonban az alábbi parancsokat elvégzed, fontos tudni, hogy attól függően változthatnak a parancsok, hogy mit tartalmaz a protect_s könyvtár!
A telefont kösd össze a számítógéppel usb kábellel. Kapcsold be az usb hibakeresést (usb debug)
Indítsd el az MRKDroidTools-t. Szerezz root jogot. Ha megvan akkor indítsd el az ADB terminal-t.
su -
cd /protect_s
rm -R app <-- nyílván, ha több máskönyvtár is van, akkor azokat is kell törölni
mkdir md
chmod 777 md
reboot
Ekkor a telefon újraindul, és ha az nvram nem sérült, akkor szépen visszaíródik az, aminek lennie kell eredetileg is a protect_s-ben.
Ellenőrizd a *#06# kóddal az imei-t.
Ha végeztél, és az IMEI a telefonod sajátja, akkor kikapcsolhatod a repülőgép módot.
Ha nem a saját imei-d jelenik meg de legalább van, akkor már át tudod írni az MTKDroidtools-zal a sajátodra, ámbár ez megint nem túl szerencsés, mert egy factory reset után újra visszaíródik az, előző állapot. Ez akkor szokott lenni, amikor az nvram sérült, vagy nem a telefonod sajátját tette rá valaki.
Hasznos linkek:
secro fájl MT6572-re
secro fájl MT6582-re
secro fájl MT6589-re
