- iPhone topik
- Egy szenzor, két zoomkamera: újraírta a Huawei a mobilfotózás történetét
- Google Pixel 9 Pro XL - hét szűk esztendő
- Google Pixel topik
- Megérkezett a Google Pixel 7 és 7 Pro
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Poco M3 - felújított állomás
- Térerő gondok, tapasztalatok
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Milyen okostelefont vegyek?
-
Mobilarena
Android dual SIM szakmai mélyvíz
Az alábbi témák kitárgyalása kerülendő, mert nem ide tartozik!
Kérdésed a megfelelő topikba tedd fel:
"melyik alkalmazás, ami"
"milyen tokot vegyek"
"piros hátlap hol kapható" "honnan vegyek telefont"
Új hozzászólás Aktív témák
-
#5600
Speedcop14
csendes tag
osztszoroz
#5599
Speedcop14
csendes tag
válasz
osztszoroz
#5599
üzenetére
köszönöm szépen...tréningezek vele
-
#5599
osztszoroz
aktív tag
Speedcop14
#5598
osztszoroz
aktív tag
válasz
Speedcop14
#5598
üzenetére
SP Flash Tool release of the
V1.6_20170520 firmware
for UMIDIGI Gnézted már?driverek rendben vannak?
-
#5598
Speedcop14
csendes tag
osztszoroz
#5596
Speedcop14
csendes tag
válasz
osztszoroz
#5596
üzenetére
Szia..a pontos típus Umidigi G..találtam 2 romot is hozzá, mindkettővel próbáltam a SP Flash-el, a Vol + gombbal megy a recovery menube, de ahogy írtam is ha rámegyek a "recovery"-re csak a kis zold droid jelenik meg "no command" felirattal és villog...a Vol- gombkombinációra csak bejön a logo és semmi
-
#5597
hzx0
aktív tag
Speedcop14
#5595
hzx0
aktív tag
válasz
Speedcop14
#5595
üzenetére
Hányat droidnál Vol+ vagy vol- vagy power gombra. Nem lép tovább recovery menübe?
-
#5596
osztszoroz
aktív tag
Speedcop14
#5595
osztszoroz
aktív tag
válasz
Speedcop14
#5595
üzenetére
mi a pontos tipusa? találtál hozzá gyári romot?needromon keresgéltél már?
-
#5595
Speedcop14
csendes tag
Speedcop14
csendes tag
Sziasztok...segítséget kérnék ..egy kínai telefonnal (Umidigi) van gond..sima bekapcsolásnál csak a logo jelenik meg azután nem megy tovább..a Vol UP és bekapcsoló kombinációval megjelenik a kis men? de a recovery -re csak azzal reagál, hogy bejön a "hanyattfekv?" kis robot és "no command" üzenettel csak villog..a Vol Down és bekapcs kombinációra sajna nem jön be a men? amikor ki lehet választani a wipe-os formatot. Ilyenkor csak a logo jelenik meg és nem megy semerre
..az SP Tools nem engedi formázni így nem tudom a gyári romot (vagy mást) feltenni...sajnos kifogytam az ötletekb?l...nagyon köszönöm a segítséget el?re is! -
#5593
Shirko
tag
osztszoroz
#5592
Shirko
tag
válasz
osztszoroz
#5592
üzenetére
A DM Verity eredetileg a Xiaomi védelmi megoldása részben pont a nem feltétlen megbízható Custom romok ellen. A xiaominál van mód a bootloader nyitásához kódot kérni. (Nekem a Huaweihez is megvan az utolsó hónapban kértem, később már nem adnak.) Nézz utána, hogy a Cubotnál hogyan működik ez.
-
#5592
osztszoroz
aktív tag
osztszoroz
aktív tag
üdv mindenkinek.megérkezett a Cubot p20.szeretnék twrp-t varázsolni rá és persze root jogokat.Mivel viszonylag új a modell,nincs még mögötte közösség,sem topikok.A hovateken találtam Mediatek Auto TWRP Recovery Portert.Le is gyártotta,de nem tudom ráimádkozni a telóra.Látszólag lefut a fastbootos parancs,és az SP Flashtools-os is..mégis a stock recovery fogad.A twrp maker annyit irtelemzéskor,hogy DM-Verity védelem van a telón és patchelt boot img-dzsel lesz csak mukodoképes.Találtam adb-s és fastbootos parancssori ötleteket is.
C:\Program Files (x86)\Minimal ADB and Fastboot>adb disable-verity
disable-verity only works for userdebug builds
verity cannot be disabled/enabled - USER buildsajnos itt már ledobtam a láncot.elég reménytelennek tunik számomra a dolog.
minden ötletet előre is köszönök. 
pardon,Mélyvizbe akartam berakni..
-
mikk2000
őstag
válasz
cappa72
#5589
üzenetére
Kicsit feljebb pont írtam (kicsit részletesebben), hogy az UBIFS FAQ pár példát ír fájlrendszer létrehozásra, és látható, hogy a felhasználható fájlrendszer mérete eltér a partíció méretétől, pont olyan arányban, ahogy itt is. A példában egy 512MB-os partícióra 450MB tényleges fájlrendszer fért fel. 1GB méretnél ez már 100MB körüli eltérés, szóval én ezzel ki vagyok békülve már. Ha erre gondoltál hogy hiányosság.
-
válasz
mikk2000
#5588
üzenetére
Szia!
Igen, azt már korábban is észrevettem hogy a GUI-kat nem komázod, de a világ errefelé halad jó ideje. Egy GUI-s program sem a kisujjából szopja ki egyébként egy partíció méretét
Nincs semmi baj a gui-kal, csak ki tudja, melyik információt mivel osztja, szorozza./system 869.6M 442.5M 427.1M 4096
android 0x0000000040000000 0x00000010 1 /dev/mtd/mtd16 USER
31 16 1048576 mtdblock16Hm... ilyen eltérést még nem láttam.
Az is igaz, hogy mtd/ubifs eszköz talán az a bizonyos nehéz root-os volt nálam egyedül, ilyeneket nem néztem meg.
Szóval ez nekem új, teljes hiányosság részemről. -
mikk2000
őstag
válasz
cappa72
#5587
üzenetére
Szia
Igen, azt már korábban is észrevettem hogy a GUI-kat nem komázod, de a világ errefelé halad jó ideje. Egy GUI-s program sem a kisujjából szopja ki egyébként egy partíció méretét
De lefuttattam a df-et:
u0_a120@Rainbow:/ $ su
root@Rainbow:/ # df
Filesystem Size Used Free Blksize
/dev 491.2M 128.0K 491.1M 4096
/sys/fs/cgroup 491.2M 0.0K 491.2M 4096
/mnt/secure 491.2M 0.0K 491.2M 4096
/mnt/asec 491.2M 0.0K 491.2M 4096
/mnt/obb 491.2M 0.0K 491.2M 4096
/storage/emulated 491.2M 0.0K 491.2M 4096
/storage/emulated 491.2M 0.0K 491.2M 4096
/system 869.6M 442.5M 427.1M 4096
/data 2.1G 744.3M 1.4G 4096
/data/sdext2 1.0G 525.6M 530.5M 1024
/cache 26.2M 84.0K 26.2M 4096
/protect_f 12.0M 12.0M 0.0K 8192
/mnt/cd-rom 1.2M 1.2M 0.0K 2048
/mnt/shell/emulated 2.1G 744.3M 1.4G 4096
/mnt/media_rw/sdcard1 756.5M 329.3M 427.3M 4096
/storage/sdcard1 756.5M 329.3M 427.3M 4096
/storage/emulated/0 2.1G 744.3M 1.4G 4096
/storage/emulated/0/Android/obb 2.1G 744.3M 1.4G 4096
/storage/emulated/legacy 2.1G 744.3M 1.4G 4096
/storage/emulated/legacy/Android/obb 2.1G 744.3M 1.4G 4096
root@Rainbow:/ #Amint láthatod, ez is pontosan 869M-t ír a systemre. Terminal Emulator app kimenet másolata.
-
válasz
mikk2000
#5586
üzenetére
Nem jól értelmezed.
Így reális az 1GB-os partíción 869MB szabad.
Ettől még a partíció mérete 1GB, a 869 a diskinfo által írt méret amit felejts el.Szóval 1GB-os a system partíció, ez biztos. A diskinfo meg 869-nek látja ezt. Na itt volt az elcsúszás.
Tehát adatok:
diskinfo:
- méret: 869MB
- foglalt: 434MB/proc/partitions
- méret: 1GB
df
- foglaltság: még nem ismert.
Erre koncentrájl mármint a Linux (mert az Android is Linux kernelen alapul) / Android parancsok kimenetére.Tehát egy
dfparancs kimenete pontosabb és korrekt eredményt ad, szemben a diskinfo-val. -
mikk2000
őstag
válasz
cappa72
#5585
üzenetére
Nem hagyott nyugodni a dolog, így rákerestem erre az UBIFS-re, hogy mégis mi a nyavaja ez.
Felületesen, röviden fogalmazva azt olvasom, hogy ez egy kifejezettem flash-re tervezett fájlrendszer, ami ahhoz jobban illeszkedik, mint a merevlemezre (ext) tervezett fájlrendszerek. Így aztán ez nem úgy néz ki hogy van egy kis fejléc és csókolom, hanem kemény területeket foglal el a flashra optimalizált fájlrendszer pluszban, mivel egyes részek belső io műveletekre vannak fenntartva (megjegyzem: ahogy például az SSD-n is, persze gyártótol függ hogy a szükséges működéhez puffer eleve meg sem jelenik a tényleges használható méretben, vagy a felhasználónak kell szabadon hagynia).
Az egyik létrehozási példában írják is, hogy a 512MiB-es partícióból a tényleges használható fájlrendszer 450MiB lesz. [link]
Így reális az 1GB-os partíción 869MB szabad.Szóval akkor nem 1GB a felhasználható méret fájlok részére, hanem a fájlrendszer miatt a használható ennél kisebb. A scatter fájlban azért nincs meg a ténylegesen felhasználható méret, mert az automatikusan jön létre (számolódik ki).
Szóval ha 869MB(MiB?) a ténylegesen használható, akkor tulajdonképpen 400MB szabadítható fel a DATA partíció részére. Vicces hogy a 8-16GB-os UserData korában ilyenekkel kell bajlódni, deha megfizetnék a munkám normálisan, akkor nyilván vennék egy ilyen telót/tabot már 30 körül és kész
-
Ha jól láttam, akkor így fogalmazott:
Szóval ő csak 869MB-osnak látja a System partíciót összesen. Hova tűnik a maradék? A gyári updatében a Sytem image 400MB, tehát elvileg ennyi elég kéne legyen neki (na meg mondjuk 100MB tartalék)
A system img itt simg.
A nagy kérdés, hogy amit leírtam két parancs, annak mi a kimenete.
Mert ez lenne a tényleges korrekt összevetés: tuduk mekkora (partitions), tudjuk mennyire foglalt (df).
Minen más addig csak feltételezés.
( Partitions konkrétan 1GB-ot mutat a system-re), a 869 nem t'om honnan jön - ja de... diskinfo. én az ilyen grafikus cuccokat valahogy ilyen esetekben nem szeretem, mert GiB vagy GB nem mindegy...szerk.: Szóval 1GB-os a system partíció, ez biztos. A diskinfo meg 869-nek látja ezt. Na itt volt az elcsúszás.
Tehát adatok:
diskinfo:
- méret: 869MB
- foglalt: 434MB/proc/partitions
- méret: 1GB
df
- foglaltság: még nem ismert.A diskinfonál tényleg látszik, hogy kb 50% kihasználtságú. Ebből a programból csak ezt az infót lehet kiszedni, átparticionáláshoz ebből a programból semmit nem vennék át.
Tehát ha egy 550MB-ospartíción lenne a system, akkor akár rá is férhet biztonsággal.
Sajna az img-t már letörötltem, nem tudom a flesselhető romban mekkora a tényleges img méret.Tehát ha a scatter-t átszámolja, minden partíció marad az eredeti sorszámán, csak a mérete változik, akkor egy fw upgrade átparticionálja a telefont, így a data ~450MB-tal nagyob lesz. Elméletileg.
-
Shirko
tag
válasz
cappa72
#5583
üzenetére
mik2000 esetén az 1 GB-s partíción egy 869 MB-s fájlrendszer van aminek a fele üres. Ezért akarja a második 500 MB-t a Data-hoz adni, kiszedve közülük a Cache-t. Ha a fájlrendszert össze tudja zsugorítani mint mondjuk a Gparted resize funkciója teszi, akkor nyerne. Gparted linuxon loop eszközön is működik, de az ubifs szerintem nem megy neki. A te módszereddel létrehozott üres fájlrendszerre másolás (jogokkal) ext4 esetén működne, de te is azt mondod ez ubifs miatt már nehezebb.
-
Na de ha 890MB a system, akkor 500MB-os partícióra nem fog ráférni a rendszer.
Amúgy meg ha a scatter-t átírja, majd szerez egy olyan img-t ami nem nagyobb 500MB-nál, akkor firmware upgrade esetné a flastool elvégzi a szükséges műveleteket.
Jaja...ext4-nél egész egyszerű... (csak példa)
dd if=/dev/zero of=~/theFile.img bs=1M count=10240
mkfs.ext4 ~/theFile.imgubifs-re a Linuxot is tanítani kell, láttam ilyen bejegyzéseket, de nem próbáltam egyet sem.
-
Shirko
tag
válasz
mikk2000
#5580
üzenetére
Az a partició pontosan 1 GB. Csak a rá kicsomagolt fájlrendszer 869MB. Ez gyakori eset. A boot és recovery imigek is rendszerint kisebbek mint a rendelkezésre álló partíció. A probléma igazából az, hogy hogyan csinálsz ebből a 869 MB-s UBIFS fájlrendszerből 500 MB-ost. EXT4 esetén linux alatt még tudnám, de az UBIFS számomra ismeretlen, és nem vagyok benne biztos, hogy az ubuntu kezeli.
-
válasz
mikk2000
#5580
üzenetére
Nem lesz kisebb, csak kevesebb az információ rajta: nincs tele.
Ha telepítesz egy operációs rendszert számítógépre, akkor sem 100%-ra kihegyezve választod meg a partíció méretét amire telepíted, nem?
Itt is szimplán ez van.
Adott egy partíció, arra rákerül egy operációs rendsze, és marad még hely az adott partíción.Lásd, hogy mi van akkor, ha szinte 99,9%-ig tele van: [link] Nem lehet root-olni egszerű eszközökkel, csak (mondjuk úgy) haladóknak.
A partíciók méretéről a
cat /proc/partitions
ad infót,
ezek foglaltságáról (ami valóban csatolt partíció) pedig adf
kimenete. -
Hát ha valaki úgy szeretné megváltoztatni, hogy nem csak a méreteket, hanem a sorrendet, akkor természetesen ezt a boot-ban is be kell állítani, és a scattert is át kell írni ha flashtool-os csomagot akar létrehozni..
Ilyesmit is csináltam, amikor sd kártyás dual boot kisérletet hajtottam végre.
Igaz, ez szimplán CWM recovery-ből indítható megoldás volt, nem flashtool-os.Ebben az esetben az eredeti partíciókiosztás sorrendje a szokásos:
system
cache
dataám az sd kártyán már megvariáltam, ott a mount már ezt adta ki:
/dev/block/mmcblk1p2 /system ext4 ro,noatime,noauto_da_alloc,commit=1,data=ordered 0 0
/dev/block/mmcblk1p3 /data ext4 rw,nosuid,nodev,noatime,discard,noauto_da_alloc,data=ordered 0 0
/dev/block/mmcblk1p4 /cache ext4 rw,nosuid,nodev,noatime,discard,noauto_da_alloc,data=ordered 0 0
tehátsystem
data
cache
lett a sorrend. -
-
A rendszer ugye mbr/ebr1/ebr2 típus
Ezek mondják meg, hogy mekkora, és hol van az adott partíció (hex cím szerint).
Ám a boot-ban a mount point csak annyi, hogy mmcblkXY (XY egy szám), tehát a blokkeszköz adott sorszámú partíciója. Tehát méretet nem mond, mert az (ebből a szempontból) mindegy neki.Ha már költöztettél Linux rendszert egyik hdd-ről másikra, vagy másik partícióra (más hely, más méret is akár), akkor feltűnhetett, hogy csak a méret csak annyiban számít, hogy ne legyen kisebb. Ha nem uuid-vel csatoltad a partíciót, hanem klasszikus sdaX módon, akkor az fstabot sem kell átírni, és mégis megy, ha a partíció elnevezése ugyanaz. Persze ha más, akkor meg csak az fstab-ot kell módosítani - illetve esetleg a grub menu.lst fájlját is .
-
Shirko
tag
válasz
cappa72
#5572
üzenetére
500 MB-s system partíciót akar csinálni, arra írtam, hogy a mostani system.img-t nem tudja feltenni.
Userdata-t akarja növelni, és a cache-t áthelyezni közülük.
Az jó hír, hogy a scatter alapján a flash tools megcsinálja a partíciókat, de gondolom az fstab tartalmát nem generálja újra.
szerk.: márpedig ha a cache és a userdata helyet cserél, akkor a mountolási pontokat át kell írni. -
Szerintem is jól gondolod, hogy nem a scatter a lényeg.
Pedig az elég lényeges.
Megfelelő scatter nélkül itt nem fog menni sem a módosítás, sem a hibajavítás/felélesztés.Szerintem egy 869 MB-s fájlrendszert ír fel (csomagol ki) az 1 GB-s rendelkezésre álló helyre.
Szerintem is.Ennélfogva, ha megváltoztatod a partició méretét akkor ezt az update-t már nem fogod tudni újra feltenni,
Ha meghaladja ezt a 869MB-ot az esetleg módosított partíció, akkor fel tudja tenni, természetesen ekkor kell az új scatter, amit a módosításkor használt.Sajna mtd típus esetén nem tuom, hogy hogyan lehet/kell a módosításokat elvégezni, de a scatter fájl átírása elengedhetetlen, ha a módosításokat érvénybe szeretné valaki léptetni. Ekkor jön ugyanis képbe a firmware upgrade. Mondom: tmd esetén még nem volt dolgom
Az újabb MTK-k esetén a scatter a mindenható, ha átírod a scatter-t és firmware upgrade-et csinálsz, akkor a partíciókat is átírja az új méretre.
Régebbi MTK alapú telefonoknál, ahol az mbr/ebr1/ebr2 master/extended boot record módozat létezett (és ext4 a fájlrendszer), ott a scatter-en kívül ezeket is módosítani kellett hex editorral, és ha teljes partícióátszabást akart az ember, akkor bizony a scatter-t is módosítani kellett.
Ilyet is csináltam már (jó régen...) - összenyomtam a system-et, a cache-t, és felhútam maximálisra a data-t. -
Shirko
tag
válasz
mikk2000
#5570
üzenetére
"Szóval ő csak 869MB-osnak látja a System partíciót összesen. Hova tűnik a maradék?"
Szerintem egy 869 MB-s fájlrendszert ír fel (csomagol ki) az 1 GB-s rendelkezésre álló helyre. Ennélfogva, ha megváltoztatod a partició méretét akkor ezt az update-t már nem fogod tudni újra feltenni, ha probléma van, csak az eredeti scatter fájlal, de akkor visszaáll a mostani helyzet.
Szerintem is jól gondolod, hogy nem a scatter a lényeg. Az a mentéshez és újraíráshoz kell. A rendszer működéséhez a boot.img-ben kell átírni. pl. fstab mountolási pontok. Az is előfordulhat, hogy az init.rc-ben is van módosítandó. Ehhez ki kell csomagolnod a boot.img-t, átírni amit kell, majd újracsomagolni, végül flashelni.
-
mikk2000
őstag
válasz
mikk2000
#5543
üzenetére
Sziasztok!
Egyelőre minden szuper, köszönöm a segítséget még egyszer
Az előző hozzászólásban azt írtam, hogy igazából nem zavar hogy a System partíció több mint fele üres, mivel a link2sd-vel arra is lehet alkalmazásokat mozgatni. Igen ám, csakhogy azok kezelése (mivel rendszeralkalmazássá válnak) nehézkesebb, általában az appok fizetős verzióban kezelik csak (boot manager stb). Szóval mégiscsak jó lenne az user partíció méretét megnövelni a system partíció rovására, persze ha valaki bevállalja hogy segít ebben, mert van egy érzésem hogy nem csak a scatter fájlt kell módosítani.
A linken látható, hogy az eseteges átméretezést bonyolítja, hogy a System és User partíció között van egy partíció: a Cache.
Ahogy látható, a System partíció mérete 0x40000000, azaz pontosan 1 GB. Érdekes viszont, hogy a Diskinfo a következőt mondja:
Szóval ő csak 869MB-osnak látja a System partíciót összesen. Hova tűnik a maradék? A gyári updatében a Sytem image 400MB, tehát elvileg ennyi elég kéne legyen neki (na meg mondjuk 100MB tartalék).
A syshard Info eredménye: [link]
Itt a méret rendben lenne, de itt meg az az érdekes, hogy a scatter fál 19-es partícióval befejeződik, ez meg megy egészen 21-ig + zram0 (Swap). Szóval ha teljesen biztonságosan megoldható, jó lenne ha a system partíciónak elég lenne 500MB, a több meg hozzáadódna a User partícióhoz. Köszönöm
-
#5569
aprokaroka87
nagyúr
aprokaroka87
nagyúr
Üdv!
Adott egy Vodafone Smart 4 mini tipusú telefon.
Ma az történt hogy egyszercsak nem akarja be bootolni az os-t.Recovery wipe data sem segít.
Néztem neten romokat, de ott mind a flashtool-os megoldás van írva.Nincs olyan ami a recovery update zip-es megoldást használja?
Megmondom őszintén nem nagyon akarodzok én flashtool-al, "szenvedni".
-
válasz
RockFonok
#5565
üzenetére
Ó.... az már nem is olyan rossz. Tehát akkor képes úgy csatlakozni, hogy a kijelzőn nem jelenik meg semmi, de számítógépről eléred a belső tárhelyet ("belső SD"-t) ?
Mert ha így van, akkor vélhetően a uboot vagy uboot/boot páros cserével még akár jó is lehet. Azért a boot cserénél még a system is javasolt cserére, de akár e nélkül is bejöhet.
Az uboot a kijelző és kamera "meghajtó" adatai tartalmazza. -
válasz
RockFonok
#5563
üzenetére
Akkor az gyanúsan nem rá való ROM. Lehet, hogy több kiadás létezik/létezett belőle.
Vadászni kell hozzá egy olyan romot (típusazonosat!!!) ami felmegy és működik.
Ez sajna türelemjáték.Arra viszont vigyázni kell, hogy a preloader az tényleg rá való legyen. Mert ha nem, akkor tényleg véget lehet vetni neki.
(sőt volt olyan is, amikor több romból összeválogatva az egyes partíciókat sikerült életet lehelni egy klón galayx mini-be; igen galayx mini volt, nem elírás.)
-
-
válasz
RockFonok
#5561
üzenetére
A needrom-on kell körülnézni.
Természetesen pontos típus és módozat alapján.
Ha ott találsz flastool-os romot, akkor azzal érdemes - mivel most kármentés folyik, ezért mindegy, hogy "vírusos" vagy sem, ROM cserén ráérsz gondolkodni, ha már újra képes működni a telefon.
(szerintem) -
válasz
RockFonok
#5559
üzenetére
Igazából a flashtool használata értekezést érdemes elolvasni először. Bár az újabb flashtool már másképp néz ki, ettől az elv még u.a
Ha meg szeretnénk találni a módot a felélesztésre, akkor a hibaüzenetek elég beszédesek tudnak lenni.
Szerinted szervizbe meg tudnák csinálni?
Kb mennyiért csinálnak ilyent?
Ez irányú tapasztalatom nincs.Van egy régi Samsung Galaxy Pocket Neo S5310 telefonom, arra egyből felment az eredeti ROM
csakhogy az teljesen más platform, más szoftverekkel/eszközökkel, metódussal. -
RockFonok
tag
válasz
cappa72
#5558
üzenetére
Nem tudom hogy rossz a sorrend, nem értek hozzá.
Elvileg ez az alap ROM hozzá.
Eredeti ROM-ot a gyártó meg már letörölte az oldaláról.
Próbáltam másik ROM-al is de az elkezdte csinálni de az is meg szakadt.
Már azt se tudom hány ROM-al próbáltam, de mind sikertelen.Ezt is próbáltam már:
[link]Szerinted szervizbe meg tudnák csinálni?
Kb mennyiért csinálnak ilyent?Van egy régi Samsung Galaxy Pocket Neo S5310 telefonom, arra egyből felment az eredeti ROM innen:
[link] -
RockFonok
tag
válasz
aytukabozs
#5553
üzenetére
Igen látszik az ismeretlen eszköz sárga háromszög, de ha lecsatlakoztatóm a telót akkor is ott van, nálam mindig is ott volt.
-
válasz
RockFonok
#5552
üzenetére
Tyűha...
Pontos tipust kell tudni, és egy gyári romot kellene felszuszakolni az életre keltéséhez.
Hogy miért nem kel életre?
Mert a kiadások között lehettek (tuti voltak) hardverváltozások, amikhez külön vannak rom-részek.
Ilyenek lehetnek eltérőek pl.
preloader (minden élet keztete az MTKs telefonoknál)
boot.img (tényleges rendszermag)
recovery.img
uboot (képernyő és kamerameghajtó mikrokernel)
system.imgszóval néhány eltérés, amely alapvetően meghatározza a telefon működését.
-
RockFonok
tag
válasz
aytukabozs
#5551
üzenetére
Unokaöcsém rakta rá, nem tudom.
Az se értem legalább a képernyője működne, lehet akkor vissza tudnám állítani gyárira.
Hogy lehet életre kelteni?
-
RockFonok
tag
Sziasztok!
Ami gyárilag rajta volt ROM nagyon tele volt vírus malwerrel, 4-5 hét után gyári visszaállítás újra aktiválódót, tele ablakokkal, újra indult magától a teló, appokat telepített fel stb.
Ezért lett rá téve itthon új ROM, csak sajnos az óta be se kapcsol a telefon, csak az értesítési piros led világit, gép se ismeri fel már a telefont.
Kb mennyibe kerülne szervizbe új ROM?
Ha egyáltalán meg tudja bárki is csinálni olcsón.
DOOGEE X5 telefonról van szó.
Ha megtudják csinálni remélem nem a vírusos gyári ROM-ot rakják vissza.
Android 6.0 volt rajta.
Próbáltam sok ROM-ot, de sajnos már nem megy rá, hiába dugom rá a gépre nem is jelzi a gép hogy rajta van.
Meg lehet ezt még egyáltalán csinálni?
Mit csináljak?
Mi lehet a baja a telefonnak?Előre is köszönöm a segítségeteket!
-
mikk2000
őstag
válasz
cappa72
#5542
üzenetére
Szia, köszönöm még egyszer, egyelőre minden szuper. A hivatalos rendszerfrissítés után nem csak az NVRAM error tűnt el a wifi csatlakozási infó közül, de még a MAC cím sem változik induláskor.
Hát egyelőre azt hiszem nem mélyedek bele jobban mi a pontos menete a root megoldásának enek a telón, végülis működik teljesen, köszi.
Az 1 klikkes rootoló programoktól az vette el a kedvem hogy mindegyik tartalmaz backdoort azt olvastam. Na erre fel, mikor a SuperSU free eltűnt a play áruházból (és nincs azóta se, bár le lehetett tölteni mondjuk innen [link]), rákerestem és azt találtam, hogy pár verzió óta valami kínai cég fejleszti, ezért már nem lehet abban sem megbízni... [link] ó de jó. Úgy látom a legjobb megoldás a Magisk lenne, annál az sem látszik hogy rootolt a készülék, de annak Android 5x kell minimum. Nyilván azt senki nem vállalja be, hogy a KitKatos tabra csinál egy komplett 5x-es rendszert
Ügye az egész rootolási dolog elsődlegesen (teljes full backup utánajárás után) arra ment ki, hogy legyen a telón több hely, mert az a szabad 2 GB nem túl sok. SDFix-el a KitKat már tud SD írni mondjuk SDManager III-al.
Ahogy nézegettem feltűnt, hogy a System partíció kb. 2x akkora mint amekkora kellene. Ez kb 500 mega totális helypazarlás, hiszen arra írni semmi nem fog, hivatalos rendszerfrissítés nem várható erre a telóra már, hiszen a terméktámogatás oldal is régen megszűnt. Át lehetne méretezni a partíciót, csak épp közte van egy cache partíció is, ami bonyolítja a dolgot, meg gondolom ilyesmitől infarktust kapsz, mert utánaolvasva kissé veszélyes partíciókat méretezni (ész nélkül) androidon. Szerencsére Link2SD-vel lehet olyat csinálni, hogy az alkalmazásokat rendszeralkalmazássá tenni. Ezzel a módszerrel az alkalmazás frissüléséig nem foglal helyet az USER partíción a program kódja. Annyi előnye is van a rendszeralkalmazássá tételnek szerintem, hogy ha backupolom a System partíciót, akkor elvileg a legközelebbi újrahúzáskor (ha lesz ilyen) akkor eleve friss, és az általam használt programokkal feltelepített rendszert kapok. A link2SD fizetős verziójával elvileg egy app kódja + adata is áthelyezhető SD kártyára. -
válasz
mikk2000
#5541
üzenetére
Szivesen, örülök, hogy sikerült!
Az NVRAM warning viszont eltűnt teljesen a WIFI kapcsolatokból.
Lehet, hogy az a frissítő szoftver tartalmazott valami hibajavítást is....Kösz még egyszer, folytatás munka után! Esetleg nagyjából(!) leírhatnád, hogy tulajdonképpen hogy varázsoltál a boot imagéből insecure boot-ot.
Szóval az úgy volt (hogy jött szembe a cápa... ja nem... az egy másik sztori), a boot és recovery partíciók mentés után kibonthatók, módosíthatók, és összecsomagolhatók.A recovery-hez hasonlóan a boot esetén is módosítást kell végezni, az sbin könyvtárban a secure adbd-t egy insecure adbd-re kell cserélni (amit már egy másik insecure boot-ból kivesz az ember), illetve a default.prop-ban az átállításokat meg kell tenni (itt is jó támpont egy már meglévő insecure boot).
Mondanám, hogy copy/paste, de inkább azt mondom, hogy esetenként át kell nézni.
Az adbd isecure az másolható, a default.prop nem. (Pédául amiből a módosítást csináltam ott a default.prop ext4-es bejegyzést tartalmazott, a tiéd viszont ubifs.) -
mikk2000
őstag
válasz
cappa72
#5540
üzenetére
Szia, kösz szépen a segítséget!
Nézegettem, szépen ment a root, el tudtam végre érni az SD-t is SDFix-el KitKat-on.
Közben felbátorodtam és feltoltam a teljes updatét úgy, ahogy a gyári leírás is írja (magyarul). Tehát firmware update módot kellett kiválasztani. Az érdekes az, hogy a frissítés nagyon gyorsan felment, ránézésre USB1 mód felett (bezzeg mikor olvastam readback-el...) A frissítésnél eleve benne volt a te módosított boot imagéd. Ennek ellenére az adb nem adott # promptot. Na mondom ilyen nincs. Feltoltam megint a teljes firmware updatét az eredeti boot imagéval, majd 1-2 újraindítás meg matatás után fasboot módban külön a te boot imagédat. Ezek után mit ad isten az adb azt mondja hogy #
De épp most a play áruházból meg pont eltűnt a SuperSu ingyenes... gondolom frissítik vagy ilyesmi. Az NVRAM warning viszont eltűnt teljesen a WIFI kapcsolatokból.
Kösz még egyszer, folytatás munka után! Esetleg nagyjából(!) leírhatnád, hogy tulajdonképpen hogy varázsoltál a boot imagéből insecure boot-ot.
-
válasz
mikk2000
#5539
üzenetére
ööö ezt most nem értem... nem kell a SuperSU?
De, kell. Ez az, amelyik kontrollálja a hozzáféréseket.
Onnantól pedig ami root jogot akar szerezni, az szembetalálja magát azzal, hogy neked kell eldönteni: adod neki, vagy nem adod. A superSu-ban be tudod állítani, hogy kérdés nélkül engeded, rákérdezéssel engede, vagy tiltod az adott app-ot, kaphat-e root jogot.szerk:
Elsőre úgy néz ki működik, a root checker basic, miután engedélyeztem a SuperSU-val, azt írja ki a root sikeres.
Én a terminal emulator-nak hiszek.
Elindítod telepítés után, és a már jól ismertsu
parancs után ha ott van a#
akkor oké.Mivel azonban adb-n már láttad a
#-t, a root jog biztosított. -
mikk2000
őstag
válasz
mikk2000
#5537
üzenetére
Ezután lefuttattam a progit amit linkeltél. A víruskereső helyből karanténba tette... némi küzdelem után lefutott (érdekes a legújabb google adb binárisra azt mondta hogy outdated), tab újraindul. A SuperSU egyből reklamál, hogy az SU binárist frissíteni kéne. Ezt jut eszembe azért tettem fel, mert ez egy olyan program, ami védelmet biztosít rootolt készülék esetén, mivel nem engedi a root jogot bárminek ész nélkül, hanem kérdez előtte. El is felejtkeztem erről hogy ezt feltettem... Kérdezi milyen módban frissítse az SU binárist, hát mivel a recovery-t nem piszkáltuk eddig, menjen normálban. Azt mondja sikerült, újraindítást javasol, okés.
Elsőre úgy néz ki működik, a root checker basic, miután engedélyeztem a SuperSU-val, azt írja ki a root sikeres. Most olvasom írtál közben:
Na akkor mehet a root -exe.
Onnantól pedig ami root jogot akar szerezni, az szembetalálja magát azzal, hogy neked kell eldönteni: adod neki, vagy nem adod.ööö ezt most nem értem... nem kell a SuperSU?
-
válasz
mikk2000
#5531
üzenetére
na akkor insecure kernel v2
-
mikk2000
őstag
válasz
cappa72
#5529
üzenetére
Szia!
Miért is akartál másik scatter-t használni, mint az eredeti?
A PMT change az a partition management table rövidítése. Ha változtattál a scatter-ben a partíciók (bármelyik) méretén, akkor ez az üzenet teljesen jogos.Semmit nem változtattam rajta, főleg méretet nem, csupán a fájlnév van átírva a boot.img arra amit küldtél, illetve a többi partíció ami amúgy sem kell most (hiszen úgyis kiveszem a pipát), az ki lett törölve a scatter fájlból. Szóval ezen a scatter fájlon gyakorlatilag semmi sem lett változtatva. Azért változtattam tehát, hogy megadhassam az új fájlnevet, és kulturáltan nézzen ki az egész. Az SPTool-nak egyetlen partícióra van szüksége amire írni fog, így a többire nincs szüksége. Ez volt a gondolatmenetem.
Okés, akkor megcsinálom azt, hogy az eredeti scatter fájlt használom, változtatás nélkül. Még a fájlnevet sem írom át. Ekkor az általad küldött boot imagét átnevezem boot.img-re és abba a könyvtárba teszem, ahol a helye van, ahol a többi is van, ahová az útvonala mutat. Mikor olvastatom be az SPToollal a scatter fájlt, logikusan arra panaszkodik, hogy nem jó a checksum. Sebaj, van egy cheksum generátor a könyvtárban, lefuttatom hát. És valóban a boot.img cheksuma megváltozott a Checksum.ini-ben. Királyság. Most már el is fogadja a scatter fájlt. Kiveszem a pipát mindegyik elől, kivéve a bootimg elől (ezt nem kellett megcsinálni a módosított scatter fájllal ügye). Viszont úgy tűnik, most tényleg lefut a "download" amit inkább upload-nak mondanék. Akkor (bár nem használja, és nincs értelme) mégiscsak jó ha látszik a scatterben az összes partíció. A folyamat után teló nem indult újra. Elindítom, elindul a teló normálisan. Kíváncsiságból visszaolvastatom a boot partíciót, és egyezik az insecure kernellel amit küldtél, szóval a "download", azaz az unsecure kernel feltétele sikeres volt.
Legközelebbi boot után pedig ennyi dolgod van ismét:
adb shell
Ha erre a prompt mögött megjelenik a # jel (a $ helyén) akkor adb oldalról tudod használni a root jogot.
Ha ez megvan, akkor már csak 1 lépés van vissza a fix root kialakításához.Hát sajnos ez van:
c:\Mobil\Beex_Rainbow\platform-tools>adb devices
List of devices attached
0123456789ABCDEF devicec:\Mobil\Beex_Rainbow\platform-tools>adb shell
shell@Rainbow:/ $ -
-
válasz
mikk2000
#5528
üzenetére
Miért is akartál másik scatter-t használni, mint az eredeti?
A PMT change az a partition management table rövidítése. Ha változtattál a scatter-ben a partíciók (bármelyik) méretén, akkor ez az üzenet teljesen jogos.Amúgy másképp is fel lehet tenni a boot-ot.
adb reboot bootloader
fastboot flash boot beex-rainbow-insecure-boot.img
fastboot rebootLegközelebbi boot után pedig ennyi dolgod van ismét:
adb shell
Ha erre a prompt mögött megjelenik a # jel (a $ helyén) akkor adb oldalról tudod használni a root jogot.
Ha ez megvan, akkor már csak 1 lépés van vissza a fix root kialakításához.Ennek a kis aprócska programnak a lefuttatása.
Legyen bekapcsolva a tab, legyen összekötve a számítógéppel, mert adb-n keresztül dolgozik majd.
Lefuttatod, újraindul, kész.
Innentől szabadon garázdálkodhatsz.
Akár a link2sd programot is tudod használni innentől. Én annak idején használtam.
Ha netán mégsem működne, akkor szólj, van még a tarsolyban néhány ötlet.A recovery az más tészta, de elméletileg az sem kizárt. xda-n talán lehet találni még Carliv touch recovery-t ubifs támogatással.
-
mikk2000
őstag
válasz
cappa72
#5527
üzenetére
Szia!
Teljesen szemléletes eredményt ad a TC összehasonlítás, de kinek mi szimpatikus
Az általad küldött insecure kernel bootimg-t megpróbáltam felrakni, csak azt és nem mást [link]
...de ez a kép fogadott:
Erre mondom megpróbálom az update-ben levő bootimg-t feltenni próbaképpen, főleg hogy nem volt eltérés a backuppal. Ez felment, lett zöld pipa a végén, bár a tablet nem indult újra.
Simán csak a download/download only módot használtam. Úgy olvastam ez a hiba arra utal, hogy a területet formázni kéne, tehát gondolom format all + download, de nem vagyok benne biztos hogy az "all" mit formáz, úgyhogy egyelőre nem piszkáltam. A teló egyébként elindult gond nélkül.
Ezt a leírást olvastam egyébként frissítéshez:
[link]A scatter file amit szerkesztettem az insecure kernel bootimg update-hoz: [link]
-
válasz
mikk2000
#5526
üzenetére
Ha binárisan összehasonlítok két fájlt mondjuk total commanderrel, az kicsit értelmesebb infót ad, mint egy sima checksumos ellenőrzés
Nem vagyok biztos benne - így kipróbálnám a helyedben.
Jobban bíznék pl. a diff parancsban (Windows eseténfcparancs, ha jól láttam)ha két 1GB-os fájlod van, checksumos ellenőrzésre azt látod hogy nem egyezik, viszont ha összehasonlítod binárisan, akkor lehet hogy kiderül az, hogy csak egy byte-ban tér el, ami azért hasznosabb információ
Mivel nem ismerem a Total commander ezen részét , így nem tudok róla nyilatkozni.
A diff parancs ellenben megmondja hogy hol a különbség.
Példa (win)C:\Users\cappa>fc a.exe b.exe
Comparing files a.exe and B.EXE
00000000: 61 62
00000001: 20 0D
00000002: 0D 0A
00000003: 0A 11
FC: B.EXE longer than a.exeNa az nvram esetén már találkoztam ilyen folyamatosan változó wifi mac címmel: a gyártó elfelejtette feltölteni az nvram-ot, és üresen hagyta. Nem viccből mondom, tényleg üres volt. Erre utal az NVRAM warning...
De felrakok két azonos, de tartalmilag mégis kissé eltérő mentést a SYSTEM-ről, és ha gondolod nézz rá.
Kiváncsi vagyok, megpróbálok majd ránézni. -
mikk2000
őstag
válasz
cappa72
#5524
üzenetére
Sza, látom egyszerre csak egy kérdéssel foglalkozol, jó, akkor legalább nem keveredünk össze
Alapesetben úgy kell menteni, hogy a proc/partitions által megadott hossz és a mentés mérete azonos legyen.
Ez nyilvánvaló szerintem, így is írtad a példát fentebb. Tehát pl az ANDROID-nál (SYSTEM) a start: 0xf800000, a méret meg 0x40000000
Két img mentése során ha nem kapcsoltad be a tabot és azonos módon történt a mentés, úgy ellenörzőösszeges összehasonlítást használj (md5, sha).
A tab nem volt bekapcsolva természetesen.
Ha binárisan összehasonlítok két fájlt mondjuk total commanderrel, az kicsit értelmesebb infót ad, mint egy sima checksumos ellenőrzés, mert kb. látom, hogy mennyi az eltérés, vagy ha kevésben tér el, akkor miben. Magyarul ha két fájlt binárisan összehasonlítok, egyrészt informálisabb, másrészt az teljesen pontos (100%) eredményt ad, még pontosabbat is, mint bármilyen checksum. Mondok egy példát, ha két 1GB-os fájlod van, checksumos ellenőrzésre azt látod hogy nem egyezik, viszont ha összehasonlítod binárisan, akkor lehet hogy kiderül az, hogy csak egy byte-ban tér el, ami azért hasznosabb információ.Szerintem is azonosnak kellene lenni a mentéseknek, mégsem azok azoknál amiket írtam, bár a CACHE nyilván nem számít (gondolom az temp), az NVRAM is érdekes, mert egyrészt a nevében ott van hogy RAM (ami tudjuk mit jelent) másrészt érdekes, hogy a MAC address ennél a tabnál mindig más indulás után, márpedig ha ezt az NVRAM-ból veszi, akkor nyilván változik az is, és akkor nyilván el is fog térni a mentett adat. Marad az ANDROID (System) amit nem tudok hova tenni hogy miért tér el. De felrakok két azonos, de tartalmilag mégis kissé eltérő mentést a SYSTEM-ről, és ha gondolod nézz rá. Elvileg ügye azonosnak kellene lenniük. Link privátban megy!
Szerk: Ja, a WIFI kapcsolatnál az előző factory reset óta fixen látszik egy NVRAM WARNING: ERR=0X10, kitörölhetetlenül, szóval az NVRAM tuti nem az igazi.
-
-
válasz
mikk2000
#5523
üzenetére
Na, időközben mégiscsak mentegettem, méghozzá 2x
Alapesetben úgy kell menteni, hogy a proc/partitions által megadott hossz és a mentés mérete azonos legyen.
Két img mentése során ha nem kapcsoltad be a tabot és azonos módon történt a mentés, úgy ellenörzőösszeges összehasonlítást használj (md5, sha).
-
mikk2000
őstag
válasz
mikk2000
#5522
üzenetére
Na, időközben mégiscsak mentegettem, méghozzá 2x, és hasonlítottam. Ahol egyezik mindkét image, OK-t írtam, ahol nem, ott NOK-t.
ANDROID NOK!!!
BOOTIMG OK
CACHE NOK!!!
DKB OK
EXPDB OK
KB OK
LOGO OK
MISC OK
NVRAM NOK!!!
PRELOADER OK
PRO_INFO OK
PROTECT_F OK
RECOVERY OK
SEC_RO OK
SECCFG OK
TEE1 OK
TEE2 OK
UBOOT OKA CACHE -t még megértem hogy nem egyezik két kiolvasás során, de a többi...?
Másik, gyárilag SPTool-ból a v5.1436.00.000 verzió van az updaterhez mellékelve. Már ezen is van olyan lehetőség mentéskor (amit a leírásaidban nem látok), hogy page only, spare only, illetve első helyen a page + spare. Eddig azért mentettem page only-val, mert így egyezett az updaterben levő image a telefonról mentett imagéval. Viszont backupnál nem érdemesebb az alapértelmezett page+spare-val menteni? Egyáltalán mire szolgál a spare információ? Köszönöm
-
mikk2000
őstag
válasz
cappa72
#5520
üzenetére
Szia, ma kórházba kísérős elfoglaltságom volt, csak későn érkeztem.
Data partíciót azt nem feltétlen kell menteni, az csak a felhasználói adatokat tartalmazza (ez törlődik factory reset esetén). De meg lehet próbálni lementeni adott kezdőcím és a dumchar_info-ból kapott mérettel (aminek egyeznie kell a partitions mérettel. Mivel a gyári rom tartalmaz egy userdata.img-t, ezt felesleges menteni. Ez gyakorlatilag egy üres data partíció, simg típusú image fájlban.
Elsőre azért gondoltam menteni, mert az üres relatív dolog, hiszen nyilván van rajta egy filerendszer, és lehet pár rendszerállomány vagy bármi OS-től függ. De ha azt mondod üres, akkor üres, én elhiszem.
A "gyári rom" kifejezést viszont kicsit helytelennek érzem, mert ahogy lejjebb részletezem, ez egy update (esetleg "gyári update"), tehát a gyári update tartalmaz egy userdata.img-t, ha pontosíthatok.Ami a system métereltérést okozhatja az az, hogy a system partíció mérete az meghatározott, amit rá akar(sz) tenni, az pedig vagy ugyanakkora (img esetén), vagy kisebb (simg esetén)
A system szerintem azért tér el, mert amit feltettem dropboxra a lengyel oldalról, ez egy szoftverfrissítés, ergó nyilván valami megváltozott benne. A frissítésben levő instrukcja.pdf ezzel a sorral kezdődik:
"BeeX Rainbow szoftverfrissítés"
Ami arra utal, hogy frissít valamit (újabb verzió lesz a telón levő szoftver). Ergó nyilván a frissült(updatelt) adat nem akkora lesz byte-ra pontosan, mint az eredeti.
Tehát én azt írtam hogy "csak a PRELOADER, RECOVERY, és az ANDROID(System) tér el", mármint összehasonlítva tartalmilag, ami azt jelenti. hogy ezek a fájlok változnak, azaz frissülnek! Azaz ez egy update lesz, ahogy a pdf első sora is mondja. De abból is látszik, hogy a telón a kernel verzió ami látszik az 2014.09.29, míg az update könyvtárának nevében 20141010 van. Ami kb egy hónap eltérés.
De ha felraktam majd a backup fájlokat, akkor magad is összevetheted az update-vel.
Érttem amit írtál, hogy a preloader-t hiába vetem össze, mert azt vágni kell. Viszont ha nem tudom hogy kell vágni pontosan, baszhatom a backupot, mert nem tudom visszatenniEste megpróbálom majd megnézni a linkelt fájlokat, addig a mentést érdemes megcsinálni úgy, hogy a mentett fájl mérete megegyezzen a beírt partíciómérettel (talán page only mód). Ha az megvan, akkor már egészen jó a helyzet.
A ténylegesen mentett image-kat még nem tettem fel, de nem is baj, mert akkor lementek mindent, kivéve amit írtál.
Köszi a hasznos infókat, akkor elkezdek menteni, bár nem biztos hogy ma összejön, kicsit gáz hogy usb2 a kapcsolat, és mégis a System-et nekiáll lementeni kb. 1 MB/s-el, ami USB1. Újabb verziós SPTool-ok amiket néztem, meg lehalnak kiolvasáskor.
A rootot úgy szeretném majd megoldani (olvastam hasonlót) hogy ne boldog-boldogtalan minden program legyen hirtelen root jogú, hanem csak az, aminek én kifejezetten megengedem, a biztonság végett. Köszönöm.
-
válasz
mikk2000
#5517
üzenetére
Látom azért sok kérdés merült fel benned. Ez jó.
Data partíciót azt nem feltétlen kell menteni, az csak a felhasználói adatokat tartalmazza (ez törlődik factory reset esetén). De meg lehet próbálni lementeni adott kezdőcím és a dumchar_info-ból kapott mérettel (aminek egyeznie kell a partitions mérettel. Mivel a gyári rom tartalmaz egy userdata.img-t, ezt felesleges menteni. Ez gyakorlatilag egy üres data partíció, simg típusú image fájlban.
A boot, recovery esetén a partícióméret nagyobb, mint a tényleges boot méret, ez mindenképp jó, mert így "ráfér" egy esetleges módosított boot is.
Igen, a felesleges részt FF-fel tölti fel.Én a mentés esetén mindent lementek – data és bmtpool kivételével. A preloader és az nvram két különösen érzékeny partíció.
A preloader ráadásul megint egy furmányos dolog, mert amit lementesz, azt nem lehet 1:1-ben visszarakni, az elején van egy feljéc rész, azt le kell vágni (hex editorral...)
Az nvram pedig olyan adatokat tartalmaz, mint imei szám, tehát telefononként egyedi.Ami a system métereltérést okozhatja az az, hogy a system partíció mérete az meghatározott, amit rá akar(sz) tenni, az pedig vagy ugyanakkora (img esetén), vagy kisebb (simg esetén)
Flashtool-lal mindenképp az egész partíciót kell menteni.
(Leginkább ext4-es partíciók esetén kellemes, hogy azonnal bele lehet nézni... Linuxon legalábbis)Este megpróbálom majd megnézni alinkelt fájlokat, addig a mentést érdemes megcsinálni úgy, hogy a mentett fájl mérete megegyezzen a beírt partíciómérettel (talán page only mód). Ha az megvan, akkor már egészen jó a helyzet.
Alapvetően szerintem a root megoldható lesz, ha másnem így: [link]
Erre ráment pár órám. -
Szia!
Ez igazából nem mélyvíz téma, kérlek fáradj át a "Android dual sim telefonok" témába.
-
csdm
senior tag
Sziasztok!
Xiaomi Redmi 4-et tervezek venni használtan. Semmi tudásom nincs Xiaomi telefonokkal kapcsolatban. Ahogy gyorsan végignéztem a használt kínálatot, mintha lenne globál és nem globál piacra szánt verziója.
Tudnátok segíteni abban, mire ügyeljek a vásárláskor, mit ellenőrizzek a személyes találkozó folyamán, hogy ne verjem át magam, és itthon mind a két kártyáját tudjam használni?Köszi!
-
mikk2000
őstag
válasz
mikk2000
#5516
üzenetére
Ezek után kíváncsiságból végigszaladtam a fájlokon, amiket az SPTool megjelenít a scatter fájl alapján . Úgy nézem azokat jeleníti meg, ahol a scatter fájlban "is_download: true" bejegyzés van. Ezek:
ANDROID
BOOTIMG
LOGO
PRELOADER
RECOVERY
SEC_RO
TEE1
TEE2
UBOOT
USRDATAHogy ha az előző hozzászólásombanban a plusz $FF-eket jól értelmeztem tök üresnek, akkor csak a PRELOADER, RECOVERY, és az ANDROID(System) tér el. Az ANDROID annyiból érdekes, hogy egy picit hosszabb az eredeti, mint amit az update tartalmaz.
Az USRDATA-t nem tudtam lementeni, mert a scatter fájlban a hossza 0 (0x0), bár a következő partícióból ítélve ez jó hosszú lehet. Gondolom ezt egy factory reset után lehet érdemes lementeni, és megnézni, hogy meddig tartalmaz értelmes adatot.
Akkor ha teljes mentést akarok a telóról csinálni, az összes partíciót érdemes lementeni, tehát nem csak ahol a scatter fájlban az "is_download: true", hanem az összesről? Ha nem, akkor melyekről? Jó éjt mindenkinek!
-
mikk2000
őstag
válasz
cappa72
#5514
üzenetére
Okés, azzal az SPTool-al, ami a Beex frissítő csomagjában van, gond nélkül megy a kiolvasás. Mondjuk ez is hozta a spare, page és egyéb lehetőségeket, de engem nem vert át, mert lementettem az összes módban
Ránézésre nincs siker, mert az eredeti boot.img 4 megás, amik meg keletkeztek, azok 8 mega fölött vannak.
Nade engem sem ejtettek a fejemre teljesen. A partíció mérete egy dolog, viszont nyilván nagyobb, mint amekkora kell. Simán total commanderben összehasonlítottam (binárisan) az update boot.img-t a rom_1-el (page only). És mit látok? Egészen $445800-ig azonos, utána a mentés csak $FF-et tartalmaz (nem görgettem teljesen végig de ránézésre az). Ha pedig a $445800-at visszaszámolom decimálisba, akkor 4 478 976-et kapok, ami pedig pontosan megegyezik az updateben található boot.img méretével, azaz mondhatjuk azt, hogy a lementett boot.img teljesen azonos! Csak éppen mentéskor nem tudja szegény SPTool meddig érdemes beolvasni, hiszen méretnek a teljes partíció mérete volt megadva. Okés, hogyan tovább?
-
mikk2000
őstag
válasz
cappa72
#5514
üzenetére
Szia, szerintem elbeszélünk egymás mellett, mivel én pont az tészrevételeztem, hogy az update scatter file nem ül az adb-vel kiolvasott adatokhoz (és a scatter file ügye az updatelt firmware, legalábbis a dátumából ítélve). Erre te meg megismétled a scatter file adatait. Mindegy, látva a publikációidat nyilván nagy tudással rendelkezel a témában, csak én is szeretném érteni, mit csinálok.
Nos, ez alapján a leírásod alapján a boot.img-t menteném le [link]
Legújabb SPToolal próbálkoztam egyelőre, már ott elakadtam hogy vannak olyan opciók pluszban hogy page only, page + spare only spare és hasonlók. Mindegy, kettőt kiválasztva, csatlakoztatom a telót, de 0%-nál nem megy tovább percekig. Megnézem régebbiverzióval is.
-
válasz
mikk2000
#5513
üzenetére
Nó problémó, mondja a Terminátorban a kiskölyök.
Szóval a mentés során alinear_start_addr: 0x7800000
legyen a kezdőcím, a méret meg apartition_size: 0x800000De a fontosabb a boot.img lenne most elsőre.
linear_start_addr: 0x6800000
partition_size: 0x800000
összevethető lenne az általad letöltött rom-ban lévő boot.img-vel.
Hasznos volna. -
mikk2000
őstag
válasz
cappa72
#5512
üzenetére
Szia, köszi a sok melót
Nos, elsőre nekem is úgy tűnt, hogy hopp, itt egy scatter file kurva jó, ezzel tudok menteni, csak aztán gondolkodtam... ez egy új rendszer, mi garantálja, hogy nem változott meg a partíciók mérete, helye, egyéb paraméterei?
Úgyhogy elkezdtem összehasonlítani a scatter file-t azzal a cat /proc/dumchar_info eredménnyel amit írtatok nekem [link], és hát nem ül! Pl.Az updater scatter file azt mondja az egyik partícióra:
- partition_index: SYS7
partition_name: RECOVERY
file_name: recovery.img
is_download: true
type: NORMAL_ROM
linear_start_addr: 0x7800000
physical_start_addr: 0x7800000
partition_size: 0x800000
region: NONE
storage: HW_STORAGE_NAND
boundary_check: true
is_reserved: false
operation_type: UPDATE
d_type: LOW_PAGE
reserve: 0x00Ezzel szemben amit adb-vel kiirattatok velem, ezt mondja:
Part_Name Size StartAddr Type MapTo Region
recovery 0x0000000000800000 0x00000007 1 /dev/mtd/mtd7 USERA méret ül, viszont a (jav:start address) nem, de nem is nagyon értelmezhető mivel mi az hogy 0x00000007, ha mondjuk 0x0000000000700000 lenne azt mondom oké, de a scatter fájlban amúgy is 0x7800000 van. Több partíciót is nézvbe nem egyeznek a paraméterek.
Szóval ez a scatter fájl, bár nem értek hozzá, szerintem eltér a jelenlegi kiosztástól, tehát ha mentek vele, hülyeséget fog lementeni, így nyilván az esetleges visszaállítás is hülyeséget eredményez majd. Vélemény? -
válasz
mikk2000
#5511
üzenetére
Na ez egész jónak tűnik. Komplett gyári romra hasonlít.
A scatter a legfontosabb most neked a mentéshez.
Így már tudsz csinálni flashtool mentést.(közben összeraktam egy insecure kernelt is; de majd csak akkor osztom meg, ha már túl vagy a mentésen)
(szerk.: a windows esetén sajnos én hadilábon állok az oprendszerrel, mert alapesetben az otthoni gépen nem az fut, ezért is nem tudtam, hogy rendszergazdaként kell futtatni a terminált.)
szerk.2.: remélem nincs rajta bootloader zár...
Illetve asszem' a framaroot nevű root-oló program nem ad semmi szemetet. Sokáig használtam.
-
mikk2000
őstag
Csak hogy fokozzam a hangulatot így estére(éjjelre), google-n keresgéltem, és nicsak mit látok:
BEEX Ranibow firmware... gyönyörűség.. Az oldal címéből ítélve, valami komolyabb elektronikai oldal. Beregisztrálok, letöltöm... van benne egy instrukcja.pdf sokat sejtető nevű pdf, készítem is a google fordítót az ékes lengyel nyelv fordítására, erre ami benne van... teljesen magyar szöveg.
BeeX Rainbow szoftverfrissítés címmel, leírja hogyan lehet a szoftvert megfrissíteni... Van benne SP_Flash_Tool, hozzá driver, a komplett image-k, scatter file... Valahol olvastam is mintha ehhez a tablethez köze lett volna magyaroknak is, így talán nem véletlen a lengyel nevű instrukció fájlban a magyar szöveg...
Valaki belenézhetne hogy érdemes lehet-e feltenni, nem tudom ebből a márkából mennyi hardver verzió volt például... de ha az instrukció fájl magyar nyelvű, hát... A tab terméktámogatás oldala már régen nem él. Viszont ha jó lenne ez a cucc, akkor minden fájl meglenne ami szükséges... Aki meg akarja nézni, de nincs kedve beregisztrálni a lengyel oldalra, felnyomtam dropboxra: [link]Köszönöm
-
-
mikk2000
őstag
Szia,
d:\NetOK\MobilUtil\platform-tools>adb root
* daemon not running; starting now at tcp:5037
* daemon started successfullyd:\NetOK\MobilUtil\platform-tools>adb shell
shell@Rainbow:/ $ dd if=/dev/mtd/mtd6 of=/storage/sdcard1/Backup/boot.img
/dev/mtd/mtd6: cannot open for read: Permission denied
1|shell@Rainbow:/ $ -
Ha jól értem akkor egy recovery vagy boot.img mentésből tudnál csinálni egy rootolt recoveryt vagy boot-ot?
Inkább azt mondanám, hogy a mentett boot.img-ből egy insecure boot-ot, amit fastboot-tal flesselve már elérhető adb-n a root. Aztán azt system szinten véglegesíteni (/system/su).Recovery már más tészta, ott kellene találni egy ubifs támogatású működő recovery-t, amit meg át lehetne portolni a tab-ra. Akár az eredeti boot, recovery img-kből.
-
Shirko
tag
válasz
cappa72
#5497
üzenetére
cappa72 >
Ha jól értem akkor egy recovery vagy boot.img mentésből tudnál csinálni egy rootolt recoveryt vagy boot-ot?mikk2000 >
adb root
adb shell
dd if=/dev/mtd/mtd6 of=/sdcard/boot.img
dd if=/dev/mtd/mtd7 of=/sdcard/recovery.img// ha a /sdcard útvonal nem jó, keresd meg hova írhatsz.
Ha a parancs nem fut permission denied-re akkor ezt a két fájlt módosítva és flashelve rootolt lesz a készülék, ha a cappa72 számára feltett kérdésre igen a válasz
-
mikk2000
őstag
válasz
mikk2000
#5499
üzenetére
Megpróbáltam még egyszer... de most kíváncsiságból rendszergazda módban indítottam a command promptot... mondjuk senki nem írta hogy abban kéne és nem is reklamált a progi sem. Plusz kikapcsoltam a védelmi progikat.
Erre amikor a tab újraindult, akkor látom a PC képernyő jobb alsó sarkában hogy valami ADB driver telepítésre került, és ezek után a TAB tök fekete képernyővel fogad, egyik sarokban pici "fastboot mode" szöveg. Kiadtam a fastboot reboot parancsot, erre a tab újraindult. Akkor most örülni kéne?
d:\NetOK\MobilUtil\platform-tools>adb reboot bootloader
d:\NetOK\MobilUtil\platform-tools>fastboot reboot
Rebooting
Finished. Total time: 0.005sd:\NetOK\MobilUtil\platform-tools>
-
#5503
mikk2000
őstag
aytukabozs
#5502
mikk2000
őstag
válasz
aytukabozs
#5502
üzenetére
Értem, köszönöm.
..az SP Tools nem engedi formázni így nem tudom a gyári romot (vagy mást) feltenni...sajnos kifogytam az ötletekb?l...nagyon köszönöm a segítséget el?re is!
Az is igaz, hogy mtd/ubifs eszköz talán az a bizonyos nehéz root-os volt nálam egyedül, ilyeneket nem néztem meg.
most már végre használhatóm. 
Új hozzászólás Aktív témák
Hirdetés
- Casco és kötelező gépjármű felelősségbiztosítás
- Kerékpárosok, bringások ide!
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Intel Core Ultra 3, Core Ultra 5, Ultra 7, Ultra 9 "Arrow Lake" LGA 1851
- Luck Dragon: Asszociációs játék. :)
- iPhone topik
- E-roller topik
- Egy szenzor, két zoomkamera: újraírta a Huawei a mobilfotózás történetét
- Google Pixel 9 Pro XL - hét szűk esztendő
- Le Mans Ultimate
- További aktív témák...
- Dell P2419H P2419Hc Full HD LED IPS 24" + P2719H 27" LCD monitor (vékony keretes)
- Telefon felvásárlás!! iPhone 13 Mini/iPhone 13/iPhone 13 Pro/iPhone 13 Pro Max/
- BESZÁMÍTÁS! Nintendo Switch 32GB V2 játékkonzol garanciával hibátlan működéssel
- AKCIÓ! Gigabyte H610M i5 13600K 16GB DDR4 512GB SSD RTX 3060Ti 8GB Zalman S2 TG Seasonic 650W
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5700X3D 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged