-
PROHARDVER!
Ezt a fórumot azért hoztuk létre,hogy ne zavarjuk azon felhasználókat, akik még csak most ismerkednek a tablettel, vagy akár az Android rendszerrel.
Új hozzászólás Aktív témák
-
#200
Orionhilles
senior tag
Aryes
#199
Orionhilles
senior tag
-
#195
rasky
senior tag
Orionhilles
#193
rasky
senior tag
válasz
Orionhilles
#193
üzenetére
A rootolás nem nyitja a bootloadert? Mert pl Moto G esetén, csak nyitás után lehetett rootolni.
-
#193
Orionhilles
senior tag
_Soma77_
#192
Orionhilles
senior tag
válasz
_Soma77_
#192
üzenetére
Simán elképzelhető: fastboot oem <titkos parancs>
Successful, now your bootloader is unlocked
Kedves <én>!
Bootloader nyitással, rootolással és hasonlókkal még nem próbálkoztunk, így erre válaszolni nem tudunk. A particionálásról pedig értesültünk és továbbítottuk a fejlesztőknek, akik dolgoznak a hiba javításán.
Köszönettel,
Op3ndott.No, nem baj, majd próbálkozzatok csak nyugodtan!
-
#192
_Soma77_
tag
Orionhilles
#191
_Soma77_
tag
válasz
Orionhilles
#191
üzenetére
reméljük, előbb-utóbb mindennek meglesz a módja
vagy már meg is van, csak még nem tudunk róla -
#190
_Soma77_
tag
Orionhilles
#189
_Soma77_
tag
válasz
Orionhilles
#189
üzenetére
attól mert zárt, az még nem feltétlenül jelenti azt, hogy nem lehet kinyitni...
![;]](//cdn.rios.hu/dl/s/v1.gif)
általában minden szoftveres mókolás garanciavesztéssel jár, de aki ilyenre adja a fejét, az ezzel alapból tisztában van szóval az a kérdés, ki lehet-e nyitni egyáltalán. -
#189
Orionhilles
senior tag
Orionhilles
senior tag
Rossz hír: zárt bootloader
Ráírtam az Op3n Dott-ra, és a szokásos:
Kedves <én>!A tablet bootloadere zárt. Bármilyen szoftveres beavatkozás sajnos garanciavesztéssel jár.
Köszönettel,
Op3ndott.:'(
-
#184
_Soma77_
tag
Orionhilles
#182
_Soma77_
tag
válasz
Orionhilles
#182
üzenetére
link javítva
-
_Soma77_
tag
mai házi csapatmunkánk eredményei (köszönet a kollégáknak!!!):
- külső 16GB-s SD kártya Ext4-re formázva
- recovery-be belépve, adb shell-en keresztül dd-vel teljes belső tárhely tartalom image-ként lehúzva (8GB)dd if=/dev/block/mmcblk0 of=/external_sd/soma_backup.img
Ez az image be-mountolható, így látszik a /system stb...
mount /dev/block/mmcblk1p1 /external_sd
- kollégám kitotózta az $OS$ magic-es boot.img szerkezetét:
OSIP header [link]
master boot rekord (MBR)
signature
és végül a partíció tartalmaa szívás az, hogy az image aláírt kell hogy legyen
a jó hír, hogy egy orosz PDA fórumon találtunk egy XImgTool nevű csodatool-t, ami image-eket ki-be csomagol éééés aláír is! [link]
jó hír, hogy a ki és visszacsomagolás ugyan olyan $OS$ magic-es képfájlt eredményez! 
- találtunk egy másik tool-t is, ami ramdisket is kicsomagolja, ezt még próbálgatni kell (nem próbáltuk ki, hogy aláír-e pl.) [link]
- akinek van Total Commander win alatt, érdemes feltetelíteni az adb-plugin-t, szépen browse-olható vele a tab ADB interface-en kersztül... [link]
Most itt tartunk jelenleg...
-
R0GERIUS
tag
válasz
R0GERIUS
#178
üzenetére
UPDATE 3: Sajna nem nyersen a méret a hiba.
Átirtam a kódot, így megfelene a méret, de nem stimmel, továbbra sem nyitható meg.
Lehet, hogy maga a blokkok pozíciója más?
Az sok mindent megmagyarázna...UPDATE 4: El van számolva.
Az eredeti szkript, ami értelmes fájlokat nyert ki, az onnan kezdi leválasztani, ahol a fájlban megtalálja ezt: 1F 8B (magic number)
Itt is megvan ez a szám, csak 1000-el elcsúszva...
Át kell paraméterezni a program által kiolvasott blokkokat. -
R0GERIUS
tag
válasz
R0GERIUS
#177
üzenetére
UPDATE 2: korai volt a lelkesedés.
Valahogy a két dolgot össze kellene házasítani.
Itt jó a a repack és ott az unpack.
Amúgy a hiba amit dob a ramdiskhez: túl korai archívumvég. Azaz nem jól kezeli a végét a ramdisk-nek és az elejét zImage-nek...
Ha viszont a tool-al oda vissza csinálom akkor 100% ugyanolyan image-t ad, de ha a másik által kibányászott ramdisk-et és kernel képet használom, akkor elég sok eltérés van benne.Ezzel a tool-al kicsomagolt ramdisk 0-38C000-ig tart, míg a rendes ramdisk-nek 38C020-ig, tehát valóban a mérettel van a gond. Valahogy azt kellene korrigálni, és valószínűleg megvan.
-
R0GERIUS
tag
válasz
_Soma77_
#175
üzenetére
IGEEEEN!
Habár nincs megoldva a header probléma, de 100%-ig ugyanolyan repacket sikerült készíteni.
Ha valaki átdobja, hogy miket kell módosítani a recovery.img-ben, illetve a boot.img-ben, akkor megnézném, hogy mennyi az eltérés.
Ha megtartja a header-t és csak a lényeges részeket írja felül, akkor van egy használható img tool.
Talált eszköz: [link]
UPDATE: Nálam a kibontott ramdisk az szerintem hibás. Lehet, hogy repack-re lesz majd csak alkalmas?
Mondjuk az is elég lenne... -
R0GERIUS
tag
válasz
_Soma77_
#175
üzenetére
A header mérete már a standard-ra sem stimmel.
Viszont leginkább azért nem jut semmire, mert ez elméletileg az mkbootimg-nek felel meg, amivel a következő a gond:
"mkbootimg cross-compiled for ARM will run into issues as described in this question."
Azaz az mkbootimg ARM-hez van igazítva, így nem sok mindenben tudunk rá támaszkodni. (Leszámítva a fájlok kinyerését, mert arra alkalmas.)
Főként nem header területén, hiszen esetlegesen a blokk hosszai is eltérhetnek, de ha nem is, akkor is teljesen más a header elrendezése (megkockáztatom: teljesen máshogy dolgozhat).
A blokkhossz számláló tényleg nem stimmel, de ha még jó is lenne, nem sokra megyünk vele x86-os Android alatt. -
_Soma77_
tag
válasz
R0GERIUS
#164
üzenetére
csak nem hagy nyugodni ez a header história...
írtam egy kis progit (Eclipse alatt, mingw alatt fordul) amely a leírt [struktúrába] kibontja a header tartalmát.
ráengedve egy hagyományos (ANDORID! magic-es) image-re, szépen hozza az adatokat.
viszont a "nem standard" image-ekre (amilyen a miénk is) nem sok adatot hoz...pl. boot.img
ami aggaszt, hogy az egész struktúra mérete összesen 608 byte (feltételezve, hogy az "unsigned" típus 4 byte-os "unsigned int"-et takar), holott a header 2048 byte (0x0000-0x800-ig terjedő terület az image-ben)...
hol a hiányzó 1440 byte (=180 unsigned int?)
-
Sziasztok! Egész este abban mesterkedtem, hogy hogy lehetne a gigászi /log partíciót valahogy felhasználni vmi hasznosabbra, mint amire most van használva (semmire). Megpróbáltam egy üres mappát symlinkelni a belső sd kártyára, de hiába adtam mindenféle írási/olvasási jogot neki, csak root joggal lehet megnyitni. Van erre vmi megoldás szerintetek, vagy hülyeség az egész?
-
#173
Drótszamár
őstag
Orionhilles
#171
Drótszamár
őstag
válasz
Orionhilles
#171
üzenetére
Innen szedi az infókat: https://d25qsa734cg2i4.cloudfront.net/update.xml
Frissítés #1:
https://d25qsa734cg2i4.cloudfront.net/v1.01_20141102-ota-inc.zipFrissítés #2:
https://d25qsa734cg2i4.cloudfront.net/v1.02_20141103-ota-inc.zipEgyelőre nem túl sok, majd még átnézem tüzetesebben.
-
#172
Drótszamár
őstag
Orionhilles
#171
Drótszamár
őstag
válasz
Orionhilles
#171
üzenetére
Köszi. Lássuk mi van benne -
#171
Orionhilles
senior tag
Drótszamár
#170
Orionhilles
senior tag
válasz
Drótszamár
#170
üzenetére
-
#170
Drótszamár
őstag
Orionhilles
#169
Drótszamár
őstag
válasz
Orionhilles
#169
üzenetére
You need permission
-
#169
Orionhilles
senior tag
Drótszamár
#168
Orionhilles
senior tag
válasz
Drótszamár
#168
üzenetére
com.softwinner.update
-
#168
Drótszamár
őstag
Orionhilles
#167
Drótszamár
őstag
válasz
Orionhilles
#167
üzenetére
Az update szerverre akarok bekukkantani, de még nem tudom hogy. Hátha van valami érdekesség ott.
Először ki kéne találni milyen adatokat kell megadni a webservice-nek hogy válaszra bírjuk.
Az adatforgalom titkosított, így a csomagok elfogása zsákutcának tűnik egyelőre. Csak a domain látszódik.
A frissítést az Autoupdate csinálja. Az apk nevét nem tudom sajna. Mivel lehet megnézni?
Azt kéne leszedni, ráengedek egy apk visszafejtőt, hátha vannak benne érdekes stringek.Megpróbálom a forgalmat átterelni saját apache szerverre, remélem úgy látszanak a küldött adatok.
-
#167
Orionhilles
senior tag
Drótszamár
#166
Orionhilles
senior tag
válasz
Drótszamár
#166
üzenetére
Írd le, hogy mit és hogyan, szívesen megcsináljuk/om
-
#166
Drótszamár
őstag
Drótszamár
őstag
Egyelőre haszontalan mellékinfó:
Innen próbálja leszedni a frissítést a tab: https://d25qsa734cg2i4.cloudfront.net/
Mivel https ezért nem látom a küldött adatot, így csak egy AccessDenied hibaüzenetet dob a webservice.
Lehet hogy az apk-ból kinyerhetők a login infók. -
_Soma77_
tag
-
R0GERIUS
tag
válasz
_Soma77_
#157
üzenetére
Ha találsz hozzá olyan kitömörítőt, akkor fogjuk csak megtudni.
Ehhez a nem működő szkriptet kellene úgy szerkeszteni, hogy ne keresse az "ANDROID" részt.
Ezt elméletileg a szkriptben az ANDROID !ANDROID-ra való cserélésével talán meg is lehetne csinálni...
Érdemes lenne megnézni azt, hogy a legtöbb x86-on, hogyan oldották meg ezt a problémát... -
#162
Orionhilles
senior tag
Orionhilles
senior tag
fastboot getvar secure parancsra semmit dob, üres a visszajött érték (nem tudom, hogy milyen a bl állapota
), getvar productra válaszolt eddig:clovertail ( nem mondod.... ) -
#161
lacafaca
addikt
Orionhilles
#159
lacafaca
addikt
válasz
Orionhilles
#159
üzenetére
tényleg...franc
-
_Soma77_
tag
lehet, hogy vakvágány, de....
valaki írta korábban, hogy ez a gép egy Teclast klón. Nem egy Teclast 89 mini véletlenül?
[speckója] elégge hasonló.a baj csak annyi, hogy ez a gép is 16GB-os --- ahogy az Op3n Dott eredeti gépe is.
van hozzá root-olt ROM [link] innen [link]
a partíciós tábla (partition.tbl) is elég hasonló felosztást mutat.
talán érdemes ezt a szálat is nyomozni egy kicsit...
-
R0GERIUS
tag
válasz
_Soma77_
#149
üzenetére
Szerintem a fejlécnek nincs köze hozzá, hogy min lett generálva.
A Moto-sok azzal próbálkoztak, hogy a szkriptbe beírták a változó negáltját, de az se egy túl biztos módszer.
A hexá-s nekem biztosabbnak tűnik, hisz mivel egyszer ki tudtuk bontani, így elég könnyen megmodható, hogy meddig tartanak az egyes részek (header, cpio, kernel).
Amúgy ez a '$OS$' jelölés az android helyett az elején inkább indefinit. Sok helyen (szkriptekben) így jelölik, esetlegesen a din. adatot, azaz hogy pl. olvassa ezt az adatot, és nem fix adat.
Bár elég ronda dolog ez egy header-ben. -
R0GERIUS
tag
válasz
_Soma77_
#149
üzenetére
Nézz rá a #145-re.
Úgy néz ki, hogy az összes x86-osnál nem standard a header, és nem működnek a szabvány módszerek erre nézve.
Ahogy utaltam is rá: sajnos valószínűleg ezen a vonalon kell elindulni...
A hexeditoros módszer jónak tűnt elsőre, de sajna nincs időm kipróbálni. -
_Soma77_
tag
válasz
R0GERIUS
#143
üzenetére
megnéztem a linken szereplő eljárást is, leszedtem a tool-okat, de a "unmkbootimg" nem ette meg a mi képfáljainkat.
az általam korábban használt perl szkriptek egyébként a leírtak alapján dolgoznak (BTW zImage helyett ...-kernel.gz file-okat gyártanak), és az image összerakás (kernel, és cpio-ba becsomagolt ramdisk összefésülése) is teljesen jónak tűnik... kicseréltem a "mkbootimg" toolt is egy frissebbre (ami a linken szerepelt), és átparamétereztem a hívást a leírtak alapján, de ugyan az lett a kimenet, mint korábban... 
nekem úgy tűnik az eredeti image fejléce alapján, hogy ez vmi OSX-es tool-lal generált dolog lehet, mert 1. nem a standard magic android header keletkezik 2. BoardConfig.mk-ból származó dolgok vannak benne (kernel szint?!), tehát ez több, mint egy sima "lapátoljunk össze egy image"-et tool mint az "mkbootimg"...
akinek van ötlete, pls jelezze!
-
_Soma77_
tag
válasz
R0GERIUS
#144
üzenetére
rákeresve a kérdéses olvasható részére a boot.img-nek, eljutottam egy BoardConfig.mk-ig, mintha innen lenne...
BOARD_KERNEL_CMDLINE := init=/init pci=noearly console=logk0 earlyprintk=nologger loglevel=0 kmemleak=off androidboot.bootmedia=sdcard androidboot.hardware=redhookbay $(cmdline_extra) ip=50.0.0.2:50.0.0.1::255.255.255.0::usb0
n vmalloc=172M androidboot.wakesrc=05 androidboot.mode=main -
_Soma77_
tag
@Adamus1117: köszi, hogy belenéztél...és köszi a tippeket is...
próbaképpen egy újonnan készített img-et kicsomagoltam majd újra becsomagoltam, és nem lett ugyanaz
na erre végképp nem számítottam, lehet, hogy vagy 1. vmit elböktem (bár többször is kipróbáltam) 2. az x86-os "anomália" okozza... 
-
R0GERIUS
tag
válasz
R0GERIUS
#144
üzenetére
Nos ezen értelmes részek még egy érdekes helyre vittek, és sikerült felfedezni valamit, de a befejezést rátok hagyom.
Alapvetően minden hiba/kellemetlenség a képfájlok kibontásában és újracsomagolásában az X86 miatt van.
Úgy néz ki, hogy ezen architektúrára épülő készülékek boot-ja és recovery-je eltér a szokványostól (ARM).
Így a keresési irány: Android x86 képfájlok kezelése.Véletlen bele is futottam XDA-n egy olyan Motorolába aminél hasonló gondoktól szenvedtek a képfájloknál (pontosan az Intel x86 miatt):
[link]
(Lehet, hogy érdemes végignézni, mert sok a hasonlóság: egyedi header, egyes részek (amit kiemeltem az előzőben) ugyanúgy szerepeltek benne...)Nem olvastam végig, de említenek egy hexa szerkesztőn alapuló megoldást:
[link]Idő hiányában nem tudok most ennél jobban belemélyedni; ezt rátok bízom.
-
R0GERIUS
tag
válasz
R0GERIUS
#143
üzenetére
Na jó; nem bírtam megálni.
A header-rel jelenleg én sem tudok mit kezdeni.
A recovery és a boot meg iszonyatosan nagy hasonlóságot mutat, ami különös...
Talán az egyik a másik backupja?
A fájlokat elnézve nem tartom lehetetlennek.A másik érdekesség az, hogy a header-nek van egy olvasható részlete:
"init=/init pci=noearly earlyprintk=nologger loglevel=0 kmemleak=off androidboot.bootmedia=sdcard androidboot.hardware=redhookbay watchdog.watchdog_thresh=60 androidboot.spid=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx androidboot.serialno=01234567890123456789012345678901 ip=50.0.0.2:50.0.0.1::255.255.255.0::usb0n vmalloc=172M ehci_hcd.use_sph=1"Az újracsomagoltból ez hiányzik.
Ezen kívül külön érdekes ez a két rész:
"androidboot.hardware=redhookbay"
A configban van pár ilyen kiterjesztésű fájl.
"androidboot.bootmedia=sdcard"
Micsoda?!?! (Vad feltételezés: USB módban innen várja a boot helyreállító fájlját?)A harmadik: a klasszikus módszertól eltérően nem készül a kibontáskor zImage, hanem helyette xxx.img-kernel.gz (meg sem említem, hogy mind a recovery, mind a boot kibontása dob egy ilyen fájlt...).
-
R0GERIUS
tag
-
#142
Drótszamár
őstag
Drótszamár
őstag
Üdv!
Úszni nem tudok, de most vettem egy ilyen tabot. Még nem frissítettem. Kell az eredeti rom?
Ha kapok egy rövid leírást, hogy hogyan kell leszedem szívesen holnap este.
4.4.2
F9.EE
3.10.20-as kernel 2014.09.10 13:41:13
1.00_20140910-es build. -
_Soma77_
tag
válasz
R0GERIUS
#139
üzenetére
az a helyzet, hogy a re-pack szkript nem ugyan olyan fejlécű image-et rak össze, mint az eredeti volt.
Örülnék, ha valaki rá tudna nézni egy kicsit közelebbről...
felraktam ide a teljes motyót, minden köztes állománnyal és szkript-tel. [link]
van két pearl szkript (unpack-bootimg.pl és unpack-bootimg2.pl), amelyek gyakorlatilag csak parancssoros hívásban térnek el egymástól...
1) system ("mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel $ARGV[0] --ramdisk ramdisk-repack.cpio.gz -o $ARGV[2]");
2) system ("mkbootimg --base 0x00200000 --pagesize 2048 --kernel $ARGV[0] --ramdisk ramdisk-repack.cpio.gz -o $ARGV[2]");...viszont mindkettő a csomagban lévő mkbootimg-t hívja.
A kimeneti image-ek (new_boot.img és new_boot2.img) csak a parancssorban különböznek (header részben), többi ugyan az...miért is lenne más?
Viszont az eredeti img és az újra-pakolt img több ponton is különbözik, főleg a fejlécben, mivel nem "ANDROID!"-dal kezdődik, hanem "$OS$"-al.
Szerintem kellene találni egy olyan "mkbootimg"-et, ami az eredetivel megegyező image-et gyárt.
Az újrapakolt image-ek elvileg(!) Android kompatibilisek, kérdés, hogy az Op3n Dott megeszi-e???
Ötlet?
-
R0GERIUS
tag
-
#135
_Soma77_
tag
Orionhilles
#134
_Soma77_
tag
válasz
Orionhilles
#134
üzenetére
ok, de még előtte kicsit gyakorlom a re-pack-ot a boot.img-n, hogy meglegyen a rutin, meg hogy lecsekkoljam, tényleg jó-e a re-pack szkript, mielőtt brick-eljük a tabodat...
-
#133
_Soma77_
tag
Orionhilles
#132
_Soma77_
tag
válasz
Orionhilles
#132
üzenetére
itt a kibontott recovery
[link] szóval mit is kellene vele csinálni? -
#128
Freddycom
őstag
Orionhilles
#126
válasz
Orionhilles
#126
üzenetére
Ne kelljen hasznalni, csak akkor jo tudni, h van ilyen lehetoseg, ha mondjuk a tescoba vissza kell kuldeni garanciaba.
A visszaallitott tab nem lesz rootolt, igaz?
Amit irtal parancsokat, azt az adb interface-en keresztul kell beirni gepen?
-
#125
Freddycom
őstag
Orionhilles
#120
válasz
Orionhilles
#120
üzenetére
Mit jelent az ep bootloader? Be tudok lepni a power+hangero fellel. Visszaallitas utan root nelkuli, igaz?
-
#123
Orionhilles
senior tag
_Soma77_
#121
Orionhilles
senior tag
válasz
_Soma77_
#121
üzenetére
A recoveryt, azt nagyon ki kellene bontani
Van egy 5letem: kibontjuk, valahogy kiszedjük belőle az aláírás ellenőrzést, repack, flash és akkor utána belőle flashelhető lesz a CWM
#122: FW DnX,IFWI, OS DnX, OS img ezekre a fájlokra gondoltam, de koszö a tool-ért lehet az is jó lesz még vmire
#124: Próba cseresznye, én írtam nekik szombat du. remélem holnap kapok választ (igaz nem kernel forrással kapcsolatban, hanem még partíciók mentésével kapcsolatban ) -
#122
Nmajkix
csendes tag
Orionhilles
#118
Nmajkix
csendes tag
válasz
Orionhilles
#118
üzenetére
ez esetleg nem jó?: [link]
-
#121
_Soma77_
tag
Orionhilles
#116
_Soma77_
tag
válasz
Orionhilles
#116
üzenetére
gratula
Freddycom boot.img-jét még nem bontottam ki, mindjárt megcsinálom, mert bár hosszra uaz, de a tartalma nem az...
kibontás után látható lesz a különbség...
Többi image-et is ki kellene bontani, nem? főleg recovery lehet érdekes....
-
#120
Orionhilles
senior tag
Freddycom
#119
-
#118
Orionhilles
senior tag
Orionhilles
senior tag
Ahogy elnézem ezek a fájlok eszköz specifikusak... Valahogy meg kellene őket szerezni, nem hiszem, hogy az Aceréi jók lennének, bár ki tudja...
-
_Soma77_
tag
-
#112
Orionhilles
senior tag
_Soma77_
#111
-
#111
_Soma77_
tag
Orionhilles
#110
_Soma77_
tag
válasz
Orionhilles
#110
üzenetére
"adb sideload revovery.zip" elvileg kiadható parancs de "adb sideload" menüpont recoveryben? azt hol kellene látnom?
Sideload nem kezd el telepíteni valamit?Ahogy mondtam, a hardcore flash-elgetést meghagynám másnak...
-
#109
_Soma77_
tag
Orionhilles
#107
_Soma77_
tag
válasz
Orionhilles
#107
üzenetére
recovery launcher mappa hol van?
-
#107
Orionhilles
senior tag
_Soma77_
#106
Orionhilles
senior tag
válasz
_Soma77_
#106
üzenetére
Ez nekünk már megvan
. A recovery launcher mappában van valahol egy update.zip (ez a CWM).
Megtennéd, hogy a tabot recoverybe indítod, ott kiválasztod az adb sideload-ot, gépen pedig beírnád, hogy adb sideload update.zip? (ez a CWM) Ha minden igaz, CWM recovery fog betöltődni -
#105
philips20
aktív tag
Orionhilles
#104
philips20
aktív tag
válasz
Orionhilles
#104
üzenetére
Akkor várjuk az igazságot
-
-
#98
Orionhilles
senior tag
Orionhilles
senior tag
Köszi a leírást!
Freddycom: köszönjük, előre is! -
#89
_Soma77_
tag
Orionhilles
#87
_Soma77_
tag
válasz
Orionhilles
#87
üzenetére
kicsomagolt dump_images (16k) bemásolva belső memóriára vagy SD-re
Total Commander-rel átmozgatás /data/local-ba (TC root joggal bír)"adb devices" - lecsekkol, hogy látszik-e a tab az ADB interface-en
(ne felejtd el engedélyezni a kérést, tabon USB debug engedélyezve kell legyen - ADB Toggle.apk segíthet)
ADB Shell megnyitás
cd /data/local
root jog kérés: su
root-ként futtatási jog (x) adás: chmod 755 dump_images
majd futtatás: ./dump_images -a
uoda menti az .img-ket (ha nem olyan bénán adod meg a külső sd-t mint én, akkor oda menti - 3. param )
(TC-vel átmozgatás vmi látszó helyre pl. külsőSD/Downloads, vagy ilyesmi, innen leszedhető)ennyi.
mások is megcsinálhatnák, hogy ugyan azokat az img-ket kaptuk-e...
-
#88
Freddycom
őstag
Orionhilles
#87
válasz
Orionhilles
#87
üzenetére
Freddycom jelentkezik a könnyebb megtalálhatóság miatt.
-
#78
philips20
aktív tag
Orionhilles
#77
philips20
aktív tag
válasz
Orionhilles
#77
üzenetére
Akkor max reggel nézheted meg
-
#76
philips20
aktív tag
Orionhilles
#75
philips20
aktív tag
válasz
Orionhilles
#75
üzenetére
Ezeket kitöl kérdezed ?
-
#75
Orionhilles
senior tag
R0GERIUS
#74
Orionhilles
senior tag
Rákérdeztem, és azt írta, hogy ő nem ismer ilyen módszert...
Azt meg kellene valakinek próbálni, hogy a cwm launcherben lévő cwm.zip-et (ha jól dereng) fel kellene próbálni flashelni gyári recovery alól. Mi történik?
(lehet, hogy nem bírok magammal és én leszek az az egyén...) -
#74
R0GERIUS
tag
Orionhilles
#72
R0GERIUS
tag
válasz
Orionhilles
#72
üzenetére
... a legtöbb fenti dolog is az korrekt forrásjelölés és fordítás hiányában.
Jobban belegondolva, az MBR-es rész egy baromság, mert a legtöbb UNIX alapú rendszer (és azt hiszem az Android sem kivétel) GPT-t használ...
Még mindig az a kérdés, hogy zárt-e a BL?
Csak ezt majd hogyan lehet ellenőrizni minimális kockázattal... -
#73
philips20
aktív tag
Orionhilles
#72
philips20
aktív tag
válasz
Orionhilles
#72
üzenetére
Ja, akkor nem derülki hogy elötte milyen volt
-
#71
philips20
aktív tag
Orionhilles
#70
philips20
aktív tag
válasz
Orionhilles
#70
üzenetére
Nézdmeg először frissités nélkül, ha még nem frissitetted.
-
#70
Orionhilles
senior tag
R0GERIUS
#69
Orionhilles
senior tag
"... És az MBR tölti be"
Ez az említett önjavító metódus, ezek szerint valószínűleg zárt bl, de holnap du megnézem, remélem nem, mert akkor felesleges az eddig bele ölt munka.....
Azon filózok, hogy valamelyik frissítés patcheli a bootloadert, lehet hogy az is zárja le az addig nyitottat? -
#69
R0GERIUS
tag
Orionhilles
#64
R0GERIUS
tag
válasz
Orionhilles
#64
üzenetére
Valamilyen RSA szignózást említ a leírás, így van valami köze.
Lehet, hogy nyers csomag amit a folyamat közben szignóz?
Mindenesetre itt arra gondol (szerintem), hogy hiába írja felül a recovery part. tartalmát, mert az igazi el van rejtve és az MBR tölti be (nem 100%). -
#67
R0GERIUS
tag
Orionhilles
#64
R0GERIUS
tag
válasz
Orionhilles
#64
üzenetére
Ránéztem a kirakott fájlra, de az 4.6 KB-os, és kitömörítve van egy kiterjesztés nélküli "dump_images" fájl, ami 16 KB-os.
Biztos ez az? Minek kellene itt lennie? -
#65
philips20
aktív tag
Orionhilles
#64
philips20
aktív tag
válasz
Orionhilles
#64
üzenetére
Már irta valaki hogy akármit csinál a gyárira áll vissza
-
#64
Orionhilles
senior tag
R0GERIUS
#62
Orionhilles
senior tag
Nem, dehogy!
I warn in advance that the image is signed and can not permanently replace the stock using CWM recovery, even not visible (they are hidden in the reserved section of memory and link to them in the MBR)."Ez nekem sántít.. Cwm nem lehet aláírva, így nem is értem... Ha flashelem recovery partícióra akkor :
Nyitott bl esetén ott marad.
Zárt bl esetén a gyári felülírja (önjavító metódus) vagy tégla lesz belőle
De recovery partícióra flashelte droidboot alól??? Vagy csak ideiglenes cwm-mel próbálkozott? -
#62
R0GERIUS
tag
Orionhilles
#51
R0GERIUS
tag
válasz
Orionhilles
#51
üzenetére
Ez esetben, akkor növelni kellene a cache-t?
Akkor a helynövelés szinte ki van zárva.. -
#60
philips20
aktív tag
Orionhilles
#59
philips20
aktív tag
válasz
Orionhilles
#59
üzenetére
Már nem tudom hol olvastam, de nagyon biztossk voltak benne, hogy emiatt ennyi
-
-
#55
philips20
aktív tag
Orionhilles
#54
philips20
aktív tag
válasz
Orionhilles
#54
üzenetére
Olyasmit írtak valahol, hogy azért van 2gb a rendszernek mert az 5.0 as androidnak az a követelménye, ezáltal valószinűleg lesz rá uj rendszer. Bár ez csak feltételezés, lehet hogy csak pancserek voltak a fejlesztők
-
#52
DJGABI
addikt
Orionhilles
#51
DJGABI
addikt
válasz
Orionhilles
#51
üzenetére
"large otas"
szép és jó, de erre a kínai vacakra jött két ~20 megás frissítés, aztán ennyi. meg fentebb vannak a példák, más gyártó meg tudta oldani...
-
#51
Orionhilles
senior tag
Orionhilles
senior tag
as for re partitioning let me get back to you when i have more time it is possible but takes a little time to explain one thing to notewhile your log partition is quite large cache should always be equal to the size of system this seems to be extremely important on intel android devices when large otas are applied
Cache mérete akkor kell legyen mint a system! Ez fontos, főleg (F) OTA esetén.
Image mentések:https://www.androidfilehost.com/?fid=95864024717074616 a tool linkje, aki tudja tesztelje le kérem! Nekem jelenleg nem lehetséges ez. Előre is köszönöm -
#50
R0GERIUS
tag
Orionhilles
#49
R0GERIUS
tag
válasz
Orionhilles
#49
üzenetére
A Google fordító legendásan pocsék, én is max. azért néztem át, mert hátha tartanak valahol.
(Viszont leginkább sehol sem tartanak...)
Reméljük bejön. -
#49
Orionhilles
senior tag
R0GERIUS
#48
-
R0GERIUS
tag
válasz
philips20
#45
üzenetére
Van is ha ez igaz (Google fordító: nyelvfelismerés-angol):
"I suppose the classic problem of the loss of security in the root, then I warn in advance that the image is signed and can not permanently replace the stock using CWM recovery, even not visible (they are hidden in the reserved section of memory and link to them in the MBR)."
(Forrás: [link] ) -
#46
INMOTEP
őstag
Orionhilles
#44
INMOTEP
őstag
válasz
Orionhilles
#44
üzenetére
Szépen fordít [link] Amint beilleszted a forditani kivánt szöveget ,már le is van fordítva
-
#45
philips20
aktív tag
Orionhilles
#44
philips20
aktív tag
válasz
Orionhilles
#44
üzenetére
Biztos lesz valami fordítás, ha lesz valami érdrkes
-
R0GERIUS
tag
Egy kis érdekesség:
3 trigger valamelyike szerint szokták root-olni az Intel-es eszközöket:
a) oem startftm
b) oem backup_factory
c) oem stop_partitionAz erre vonatkozó XDA-s topic [link] (1. és 2. post) szerint nem csak az "oem stop_partition", hanem az "oem backup_factory" is működik.
Mivel viszont annyira nem vagyok benne a témában, így nem tudom, hogy ez mennyire lényeges... -
#40
R0GERIUS
tag
Orionhilles
#38
R0GERIUS
tag
válasz
Orionhilles
#38
üzenetére
Akkor ezek szerint "találd ki magad" nevű játékot kell játszani az oem parancsokért, mert nem találtam olyat amivel kilistázható lenne az összes.
-
DJGABI
addikt
másik topicban téma volt, fastboot/droidboot módban bootloader-t próbáltam csekkolni, hogy most akkor lokkolt-e vagy sem. fastboot oem *-ra "unknown oem command"-ot dob.
tárhely témában: Asus Memo Pad 7 (ME70c) -re érdemes ráguglizni, ugyan ez a SoC, elvileg 8 gigás és meg tudták csinálni hogy maradjon 5 giga hely. Illetve találtam egy ilyet is: [link] csak szerencsétlen teszkóék cseszték el ennyire a particionálást...
-
#35
KyeX
csendes tag
Orionhilles
#34
KyeX
csendes tag
válasz
Orionhilles
#34
üzenetére
Az frankó, akkor reggel, köszi
A rendes topicban linkeltem képeket, a rendes frisítésnél is elakadt, úgyhogy gondolom alapból problémás a gép -
#33
KyeX
csendes tag
Orionhilles
#32
KyeX
csendes tag
válasz
Orionhilles
#32
üzenetére
Dettó, de bekapcsolásnál mindig az jön már be, nem tudom bekapcsolni. Viszont hangerő le + bekapcsra egy pillanatra megjelenik az op3n dott logo, érdekes.
Usbről lehet flashelni a motyót, vagy kuka? -
#31
KyeX
csendes tag
Orionhilles
#29
KyeX
csendes tag
válasz
Orionhilles
#29
üzenetére
Nálam pont ez történt. Innen hogy tudtad visszahozni?
-
#30
Orionhilles
senior tag
Orionhilles
#28
Orionhilles
senior tag
válasz
Orionhilles
#28
üzenetére
img fájlok:jól haladnak, vasárnap gyakorlatban is leteszteltem a dolgokat
.
Keeperv85 nélkül nem haladnék/haladnánk ilyen jól, nagy köszönet illeti! -
#29
Orionhilles
senior tag
Orionhilles
senior tag
Más: Említettétek, hogyha droidboot helyett USB fogad, akkor az valszeg' sz*r.
droidboot módban indítottam, itt reboot recovery, update from sideload, itt hosszan nyomtam a power gombot és megjelent az USB-s ikon .Elmélet: lehet, hogy az a tab, ami nem frissít, az amikor flashelné a frissítést, akkor update helyett sideload parancsot kap?
-
#28
Orionhilles
senior tag
Orionhilles
#27
Orionhilles
senior tag
válasz
Orionhilles
#27
üzenetére
partition_table=gpt
create -z /dev/block/mmcblk0
create /dev/block/mmcblk0
boot -p /dev/block/mmcblk0
reload /dev/block/mmcblk0
add -b 40 -s 51200 -t efi -u 80868086-8086-8086-8086-000000000000 -l reserved -T 0 -P 0 /dev/block/mmcblk0
add -b 51240 -s 16384 -t efi -u 80868086-8086-8086-8086-000000000001 -l panic -T 0 -P 0 /dev/block/mmcblk0
add -b 67624 -s 16384 -t data -u 80868086-8086-8086-8086-000000000002 -l factory -T 0 -P 0 /dev/block/mmcblk0
add -b 84008 -s 32768 -t data -u 80868086-8086-8086-8086-000000000003 -l misc -T 0 -P 0 /dev/block/mmcblk0
add -b 116776 -s 32768 -t data -u 80868086-8086-8086-8086-000000000004 -l config -T 0 -P 0 /dev/block/mmcblk0
add -b 149544 -s 131072 -t data -u 80868086-8086-8086-8086-000000000005 -l cache -T 0 -P 0 /dev/block/mmcblk0
add -b 280616 -s 51200 -t data -u 80868086-8086-8086-8086-000000000006 -l logs -T 0 -P 0 /dev/block/mmcblk0
add -b 331816 -s 76800 -t data -u 80868086-8086-8086-8086-000000000007 -l system -T 0 -P 0 /dev/block/mmcblk0
add -b 408616 -s $calc($lba_end-2048000) -t data -u 80868086-8086-8086-8086-000000000008 -l data -T 0 -P 0 /dev/block/mmcblk0
reload /dev/block/mmcblk0
Az első b-t nem bántottam, valaki szintén nézze át,de szerintem jó.
Most már img fájlok megszerzése a cél. (system, és talán recovery pipa feltéve, ha jó lesz a CWM mint állandó recovery; maradt a boot és fastboot. ) -
#27
Orionhilles
senior tag
Pizzafutar
#26
Orionhilles
senior tag
válasz
Pizzafutar
#26
üzenetére
Vagyis, újra számolom az - s-t pl. : 1,500 MB*512 byte?
-b ket szintén újra számolom (az elsőt, azt hogyan számoljam ki?)
Valahogy kinyerem/megszerzem a fastboot, boot, recovery img fájlokat.
4 bin fájl segítségével elvileg újrapartícionálom, OSIP-ba ezek szépen beíródnak.
És ha minden igaz, akkor meg is lennénk? -
#26
Pizzafutar
aktív tag
Orionhilles
#25
Pizzafutar
aktív tag
válasz
Orionhilles
#25
üzenetére
Két fajta blokk méret van: a blokk eszközé, ami 512 byte. A fájlrendszernek is van egy blokk mérete - pontosabban: allocation unit a neve - ami 4096. A df ez utóbbit mutatja.
Particionáláshoz a fizikai blokkmérettel kell számolnod: 512
-
#25
Orionhilles
senior tag
Pizzafutar
#24
Orionhilles
senior tag
válasz
Pizzafutar
#24
üzenetére
Akkor mivel számoljak/junk??? 512byte vagy 4096Kilobyte? Én a df kimenet miatt gondoltam/gondolom amit.
Filesystem Size Used Free Blksize
/dev 484.4M 132.0K 484.3M 4096
/sys/fs/cgroup 484.4M 12.0K 484.4M 4096
/mnt/secure 484.4M 0.0K 484.4M 4096 -
#24
Pizzafutar
aktív tag
Orionhilles
#22
Pizzafutar
aktív tag
válasz
Orionhilles
#22
üzenetére
Nálam pedig az 1-es maradt le az elejéről, azaz a size itt is 15.237.120 . Ez 512 byte-al mint block mérettel számolva 7440 MB. Valójában ekkora a belső mmc mérete.
-
#23
Orionhilles
senior tag
Orionhilles
senior tag
A reserved.img tartalmazza a (fast)boot.img-t és recovery.img-t. Ezt kellene kihámozni belőle,de semmi ötletem sics, hogy hogyan szedjem ki...
Grand X In mélyvíz topik: Fontos továbbá megjegyezni, hogy ebben a készülékben felhagyott a ZTE a hagyományosnak tekinthető Yaffs2 img formátummal minden szinten, helyét az EXT4 (ennek éppen ideje volt) és egy új az Inteltől kapott bináris fájlformátum az OSII (OSIP) vette át. Egyetlen kivétellel (Motorola Razr I) a Medfield telefonokban nincsen boot és recovery partíció, ami azt jelenti, hogy a klasszikus értelmemben vett fstab felosztást el is lehet felejteni.
Itt is hasonló van....
-
#22
Orionhilles
senior tag
Orionhilles
#21
Orionhilles
senior tag
válasz
Orionhilles
#21
üzenetére
Nekem nem annyi.... 15237120 a kimenet a cat /sys/class/block/mmcblk0/size parancsra.
És ha 2048-cal osztom, akkor 7440-et kapok. -
#21
Orionhilles
senior tag
Pizzafutar
#20
Orionhilles
senior tag
válasz
Pizzafutar
#20
üzenetére
Az sd-nél igen itt meg 4096KB vagyis 4MB.) Lemaradt egy nulla ^^.
Köszönöm ma akkor folytatom, hátha. -
#20
Pizzafutar
aktív tag
Orionhilles
#19
Pizzafutar
aktív tag
válasz
Orionhilles
#19
üzenetére
A block méret SD kártya esetében nem 512 byte?
/ $ cat /sys/class/block/mmcblk0/size
A 5237120
512 byte-al számolva jön ki a nem egészen 8GB.A b-t úgy kapod meg, hogy az előző b-hez hozzáadod az előző s-t.
-
#19
Orionhilles
senior tag
Orionhilles
senior tag
partition_table=gpt
create -z /dev/block/mmcblk0
create /dev/block/mmcblk0
boot -p /dev/block/mmcblk0
reload /dev/block/mmcblk0
add -b 40 -s 409600 -t efi -u 80868086-8086-8086-8086-000000000000 -l reserved -T 0 -P 0 /dev/block/mmcblk0
add -b 335912 -s 131072 -t efi -u 80868086-8086-8086-8086-000000000001 -l panic -T 0 -P 0 /dev/block/mmcblk0
add -b 352296 -s 131072 -t data -u 80868086-8086-8086-8086-000000000002 -l factory -T 0 -P 0 /dev/block/mmcblk0
add -b 417832 -s 262144 -t data -u 80868086-8086-8086-8086-000000000003 -l misc -T 0 -P 0 /dev/block/mmcblk0
add -b 679976 -s 262144 -t data -u 80868086-8086-8086-8086-000000000004 -l config -T 0 -P 0 /dev/block/mmcblk0
add -b 942120 -s 1048576 -t data -u 80868086-8086-8086-8086-000000000005 -l cache -T 0 -P 0 /dev/block/mmcblk0
add -b 2514984 -s 131072 -t data -u 80868086-8086-8086-8086-000000000006 -l logs -T 0 -P 0 /dev/block/mmcblk0
add -b 3039272 -s 6144000 -t data -u 80868086-8086-8086-8086-000000000007 -l system -T 0 -P 0 /dev/block/mmcblk0
add -b 6185000 -s $calc($lba_end-131072) -t data -u 80868086-8086-8086-8086-000000000008 -l data -T 0 -P 0 /dev/block/mmcblk0
reload /dev/block/mmcblk0Az értékeket úgy kaptam, hogy partíció méret*blokk méret
pl.: system: 1500*496 = 6144000
Most már "csak" a -b -ket kell módosítani, viszont itt nálam megáll a tudomány. Help meHa az megvan, akkor droidboot alól flashejük szépen az előzőleg lementett .img fájlokat (boot,fastboot,recovery,system) és mormolunk egy imát hátha...... ha minden jól megy/ment akkor örülünk
-
#18
pcnet
addikt
Orionhilles
#15
pcnet
addikt
válasz
Orionhilles
#15
üzenetére
Én vállalom a sört, úgyis jövök neked eggyel a flash palyerért.
-
#17
embe
nagyúr
Orionhilles
#15
embe
nagyúr
válasz
Orionhilles
#15
üzenetére
Ne mondj életkort,mert sírni fogok!
-
#16
mazsi
senior tag
Orionhilles
#8
mazsi
senior tag
válasz
Orionhilles
#8
üzenetére
Teljesen reálisan osztod fel. A factory lehet picit nagyobb, ha beesne 50-60 MB-os frissítés véletlenül. A log meg mindenhol 16-32 MB, ha jó emlékszem.
-
#12
Pizzafutar
aktív tag
Orionhilles
#7
Pizzafutar
aktív tag
válasz
Orionhilles
#7
üzenetére
Szia,
Ez nyilvánvalóbb:
b - partíció kezdő blokk címe.
s - partíció mérete, blokk
t - típusa: effi vagy adat -
#11
raziel01
veterán
Orionhilles
#8
raziel01
veterán
válasz
Orionhilles
#8
üzenetére
Systemnek miért nem elég a gyári 1,5 GB?
-
#10
embe
nagyúr
Orionhilles
#8
embe
nagyúr
válasz
Orionhilles
#8
üzenetére
Ööö szerintem szóhoz sem jutunk. Ha sikerül akkor egy nagy virtuális sör lesz a jutalmad!
-
#9
scream
veterán
Orionhilles
#8
scream
veterán
válasz
Orionhilles
#8
üzenetére
Jó volna.
-
#8
Orionhilles
senior tag
Orionhilles
senior tag
5leteket kérek az új partíció felosztásra:
-Mekkora legyen a
-cache? sztem 256/512 MB jó; most 1,5 GB
-log? sztem max 100MB elég; most 990MB
-factory? 122MB/52KB van használatban -> lesz 32 MB
-system lesz 1,5 GB a 2 GB helyett
-data jelenleg 2 GB ebből ha minden igaz akkor lesz ->2GB+1GB+800MB+90MB+500MB vagyis: 4,39 ~4,4 GB
Ehhez mit szóltok???? -
#7
Orionhilles
senior tag
Orionhilles
#5
Orionhilles
senior tag
válasz
Orionhilles
#5
üzenetére
Lejárt a szerk. idő.
A két tab UUID-jei azonosak.
Most már csak rá kell jönnöm/jönnünk, hogy: add -b 3039272 -s 3145728 -t data -u 80868086-8086-8086-8086-000000000007 -l system -T 0 -P 0 /dev/block/mmcblk0a -b
-s
-TMi is?
s, size?
b, block?
T, mint?????a size az miben van megadva?
a block pedig most nem biztos, hogy b, mint block ..... -
#6
Zsoleszhun
addikt
Zsoleszhun
addikt
Láttunk már ugyanolyan hardverrel szerelt telefonok/tabletek között portolt romokat, szerintem előbb-utóbb erre is lesz
-
#5
Orionhilles
senior tag
Orionhilles
senior tag
PARTÍCIÓKRÓL MINDENT
ls -al /dev/block/platform/intel/by-guid/
lrwxrwxrwx root root 2015-01-01 15:47 80868086-8086-8086-8086-000000000000 -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2015-01-01 15:47 80868086-8086-8086-8086-000000000001 -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2015-01-01 15:47 80868086-8086-8086-8086-000000000002 -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2015-01-01 15:47 80868086-8086-8086-8086-000000000003 -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2015-01-01 15:47 80868086-8086-8086-8086-000000000004 -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2015-01-01 15:47 80868086-8086-8086-8086-000000000005 -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2015-01-01 15:47 80868086-8086-8086-8086-000000000006 -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 2015-01-01 15:47 80868086-8086-8086-8086-000000000007 -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2015-01-01 15:47 80868086-8086-8086-8086-000000000008 -> /dev/block/mmcblk0p9ls -al /dev/block/platform/intel/by-label/
lrwxrwxrwx root root 2015-01-01 15:47 cache -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2015-01-01 15:47 config -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2015-01-01 15:47 data -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2015-01-01 15:47 factory -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2015-01-01 15:47 logs -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 2015-01-01 15:47 misc -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2015-01-01 15:47 panic -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2015-01-01 15:47 reserved ->/dev/block/mmcblk0p1
lrwxrwxrwx root root 2015-01-01 15:47 system -> /dev/block/mmcblk0p8vis.:cache
/dev/block/mmcblk0p6
80868086-8086-8086-8086-000000000005
config
/dev/block/mmcblk0p5
80868086-8086-8086-8086-000000000004
data
/dev/block/mmcblk0p9
80868086-8086-8086-8086-000000000008
factory
/dev/block/mmcblk0p3
80868086-8086-8086-8086-000000000002
logs
/dev/block/mmcblk0p7[
80868086-8086-8086-8086-000000000006
misc
/dev/block/mmcblk0p4
80868086-8086-8086-8086-000000000003
panic
/dev/block/mmcblk0p2
80868086-8086-8086-8086-000000000001
reserved
/dev/block/mmcblk0p1
80868086-8086-8086-8086-000000000000
system
/dev/block/mmcblk0p8
80868086-8086-8086-8086-000000000007
-
#3
embe
nagyúr
Orionhilles
#1
embe
nagyúr
válasz
Orionhilles
#1
üzenetére
Örülök a kezdeményezésnek.
Hátha egy használható romot összehoztok. -
#2
INMOTEP
őstag
Orionhilles
#1
INMOTEP
őstag
válasz
Orionhilles
#1
üzenetére
Várom az ötleteket énis
-
#1
Orionhilles
senior tag
Orionhilles
senior tag
Ez a téma lehetőleg a tab újrapartícionálásával ill. egyéb mélyebb módosításokkal fog foglalkozni.
Tablet EREDETI partícionálása:
df kimenet:
Filesystem Size Used Free Blksize
/dev 484.4M 132.0K 484.3M 4096
/sys/fs/cgroup 484.4M 12.0K 484.4M 4096
/mnt/secure 484.4M 0.0K 484.4M 4096
/mnt/asec 484.4M 4.0K 484.4M 4096
/mnt/obb 484.4M 0.0K 484.4M 4096
/factory 122.0M 44.0K 121.9M 4096
/system 1.9G 820.3M 1.1G 4096
/cache 1.5G 2.4M 1.5G 4096
/config 122.0M 52.0K 121.9M 4096
/data 2.0G 1.8G 242.2M 4096
/logs 991.9M 1.3M 990.6M 4096
/mnt/shell/emulated 2.0G 1.8G 242.2M 4096
/storage/emulated 484.4M 0.0K 484.4M 4096
/mnt/media_rw/sdcard1 7.3G 5.6G 1.7G 4096
/storage/sdcard1 7.3G 5.6G 1.7G 4096
/storage/emulated/0 2.0G 1.8G 242.2M 4096
/storage/emulated/0/Android/obb 2.0G 1.8G 242.2M 4096
/storage/emulated/legacy 2.0G 1.8G 242.2M 4096
/storage/emulated/legacy/Android/obb 2.0G 1.8G 242.2M 4096Egy másik Intel Atomos tab Acer Iconia A1-830 partition.tbl fájlának tartalma:
partition_table=gpt
create -z /dev/block/mmcblk0
create /dev/block/mmcblk0
boot -p /dev/block/mmcblk0
reload /dev/block/mmcblk0
add -b 40 -s 335872 -t efi -u 80868086-8086-8086-8086-000000000000 -l reserved -T 0 -P 0 /dev/block/mmcblk0
add -b 335912 -s 16384 -t efi -u 80868086-8086-8086-8086-000000000001 -l panic -T 0 -P 0 /dev/block/mmcblk0
add -b 352296 -s 65536 -t data -u 80868086-8086-8086-8086-000000000002 -l factory -T 0 -P 0 /dev/block/mmcblk0
add -b 417832 -s 262144 -t data -u 80868086-8086-8086-8086-000000000003 -l misc -T 0 -P 0 /dev/block/mmcblk0
add -b 679976 -s 262144 -t data -u 80868086-8086-8086-8086-000000000004 -l config -T 0 -P 0 /dev/block/mmcblk0
add -b 942120 -s 1572864 -t data -u 80868086-8086-8086-8086-000000000005 -l cache -T 0 -P 0 /dev/block/mmcblk0
add -b 2514984 -s 524288 -t data -u 80868086-8086-8086-8086-000000000006 -l logs -T 0 -P 0 /dev/block/mmcblk0
add -b 3039272 -s 3145728 -t data -u 80868086-8086-8086-8086-000000000007 -l system -T 0 -P 0 /dev/block/mmcblk0
add -b 6185000 -s $calc($lba_end-16384) -t data -u 80868086-8086-8086-8086-000000000008 -l data -T 0 -P 0 /dev/block/mmcblk0
reload /dev/block/mmcblk0Nyílj ki!
bocsi... 
vagy már meg is van, csak még nem tudunk róla ![;]](http://cdn.rios.hu/dl/s/v1.gif)
így nem mindegy, milyen platformon írják a ki-/becsomagoló tool-t... 
n vmalloc=172M androidboot.wakesrc=05 androidboot.mode=main
Új hozzászólás Aktív témák
Hirdetés
- BONTATLAN Új Magyar Magic Keyboard és Smart Keyboard iPad Pro 12.9 Azonnal Átvehető DEÁK Térnél Átve
- Xiaomi Redmi Pad Pro 8GB+256GB Silver
- Használt iPad Pro 10. 5 cellular - 64GB + Apple Smart Keyboard + Apple Smart Cover
- OnePlus Pad 2 + OnePlus Pad 2 billentyűzet + Extrák
- újszerű iPad Pro 11" (2018) Wi-Fi 64GB asztroszürke space gray Apple
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Samsung Galaxy A54 128GB, Kártyafüggetlen, 1 Év Garanciával
- ÁRGARANCIA! Épített KomPhone i9 14900KF 64GB RAM RTX 5080 16GB GAMER PC termékbeszámítással
- Bomba ár! HP Elitebook 8560W - i7-2GEN I 8GB I 500GB I 15,6" FHD I Nvidia I W10 I Garancia
- AKCIÓ! Sapphire Nitro+ RX 6800 XT 16GB videokártya garanciával hibátlan működéssel
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged