Related
All:
I have been having this strange problem with my ion and I thought maybe I will post here to see if someone can help. I updated to the stock ICS using PC companion and that worked well and I was quite happy with the update, but lately I am seeing this very strange behavior on the device that has really hurt my battery life - Android OS and system_server are taking up a lot of resources and battery.
I have been trying to get to the bottom of this - and here is what I am seeing:
The device boots up and works fine - all processes within normal CPU use.
Device goes to sleep, and about a minute after that, I get the following on my Logcat:
10-10 18:41:06.533: I/Adreno200-EGLSUB(3124): <CreateImage:893>: Android Image
10-10 18:41:06.533: I/Adreno200-EGLSUB(3124): <GetImageAttributes:1102>: RGBA_8888
10-10 18:41:06.543: D/memalloc(3124): /dev/pmem: Allocated buffer base:0x428ef000 size:3674112 offset:44937216 fd:50
10-10 18:41:06.553: D/memalloc(3155): /dev/pmem: Mapped buffer base:0x6a993000 size:48611328 offset:44937216 fd:245
10-10 18:41:06.573: I/Adreno200-EGLSUB(3124): <CreateImage:893>: Android Image
10-10 18:41:06.573: I/Adreno200-EGLSUB(3124): <GetImageAttributes:1102>: RGBA_8888
10-10 18:41:06.733: I/Adreno200-EGLSUB(3124): <CreateImage:893>: Android Image
10-10 18:41:06.733: I/Adreno200-EGLSUB(3124): <GetImageAttributes:1102>: RGBA_8888
Right after this happens, top starts showing something like this:
User 23%, System 7%, IOW 0%, IRQ 0%
User 73 + Nice 0 + Sys 22 + Idle 215 + IOW 0 + IRQ 0 + SIRQ 0 = 310
PID PR CPU% S #THR VSS RSS PCY UID Name
3155 0 22% S 80 667232K 79664K fg system system_server
3124 0 3% S 10 155268K 11184K fg system /system/bin/surfaceflinger
5444 0 3% R 1 1092K 496K fg root top
903 0 0% S 5 5280K 548K fg root /system/bin/mpdecision
81 0 0% S 1 0K 0K fg root kworker/0:2
So system_server and /system/bin/surfaceflinger takes up 25% of CPU and keeps going like this until I turn the device on. Then everything is again back to normal.
My question is - what is the Adreno200-EGLSUB doing in the background? Is it creating some kind of a system image that I will just need to let happen until it is done and hopefully the battery life will improve then? If anyone else is seeing the same behavior and have found a way to fix it, I would greatly appreciate some pointers.
Thanks so much!
Jit
When I have a battery issue I usually clear the cache and fix permissions and it clears up but it may not be your case
Sent from my LT28at using xda premium
Strange I would suggest the following.
Back up with titanium and cwm.
Clear cache and dalvic via cwm.
No solution uninstall app via titanium and restore without data. In the event this causes issues restore via cwm or titanium.
If still not fixed freeze the apk via titanium ans allow normal use to check for a fix or other issues.
Still nothing reflash. Sorry
This is the method I usually fallow for issues such as this. Give it a go. Hope this helps.
+++++--------+++++
Sent from:
Xperia Ion(lt28i) ICS
Rooted with CWM
+++++--------+++++
Hi All,
Having some issues with my phone. I'm on CNexus' 4.3 stock MK3 rom. The only mods I've done to it is disabling some of the bloat with TB and also have Wanam Xposed installed.
Note that I have seen this behavior on other roms too.
Usually within a day or 2 of doing a reboot, the "system" process will begin using 50% CPU all the time. No wakelocks show up in BBS, and "android system" doesn't show increased usage in the stock battery stats, however other apps can see it happening.
I took a few screenshots with System Panel to show - after running it's monitoring function for a few hours. I also used the command "top" in terminal emulator to generate a text file showing the results:
Code:
User 23%, System 34%, IOW 0%, IRQ 0%
User 13 + Nice 141 + Sys 228 + Idle 271 + IOW 0 + IRQ 0 + SIRQ 0 = 653
PID PR CPU% S #THR VSS RSS PCY UID Name
778 0 49% S 143 771668K 149192K fg system system_server
10258 0 4% R 1 1336K 644K root top
381 1 1% S 8 10628K 1808K root /system/bin/netd
8713 1 0% S 1 0K 0K root kworker/u:4
1668 0 0% S 5 5244K 608K root /system/bin/mpdecision
I have renamed qsiff_daemon to .bak to see if it would help with the issue, however it did not. Qosmgr file apparently doesn't exist in this rom.
As you can see in the screenshots, System is at maximum CPU (this is with my phone sitting idle), and it is using a lot of CPU time when my phone was otherwise doing nothing. I also attached a screenshot of OS Monitor showing the process in detail.
Does anyone else have this issue? Any ideas on how to solve it? I can't seem to find a way to get any details as to what "System" is and if there are sub-processes that make it up.
EDIT: More details. Ran Top again, this time so it would name the thread:
Code:
User 23%, System 38%, IOW 0%, IRQ 0%
User 14 + Nice 162 + Sys 284 + Idle 283 + IOW 0 + IRQ 0 + SIRQ 0 = 743
PID TID PR CPU% S VSS RSS PCY UID Thread Proc
778 1283 0 48% R 779916K 146584K bg system CountryDetector system_server
12255 12255 1 8% R 1840K 1152K fg u0_a210 top top
8455 8455 0 0% S 0K 0K root kworker/u:3
778 903 0 0% S 779916K 146584K fg system er.ServerThread system_server
1668 1687 0 0% S 5244K 608K root mpdecision /system/bin/mpdecision
CountryDetector??
dirkdigles said:
Hi All,
Having some issues with my phone. I'm on CNexus' 4.3 stock MK3 rom. The only mods I've done to it is disabling some of the bloat with TB and also have Wanam Xposed installed.
Note that I have seen this behavior on other roms too.
Usually within a day or 2 of doing a reboot, the "system" process will begin using 50% CPU all the time. No wakelocks show up in BBS, and "android system" doesn't show increased usage in the stock battery stats, however other apps can see it happening.
I took a few screenshots with System Panel to show - after running it's monitoring function for a few hours. I also used the command "top" in terminal emulator to generate a text file showing the results:
Code:
User 23%, System 34%, IOW 0%, IRQ 0%
User 13 + Nice 141 + Sys 228 + Idle 271 + IOW 0 + IRQ 0 + SIRQ 0 = 653
PID PR CPU% S #THR VSS RSS PCY UID Name
778 0 49% S 143 771668K 149192K fg system system_server
10258 0 4% R 1 1336K 644K root top
381 1 1% S 8 10628K 1808K root /system/bin/netd
8713 1 0% S 1 0K 0K root kworker/u:4
1668 0 0% S 5 5244K 608K root /system/bin/mpdecision
CountryDetector??
Click to expand...
Click to collapse
Same issue here. I tried strace'ing the process, and it stopped spinning. I also could no longer wake my screen and performed a 'reset' from adb.
I was seeing a slew of "SensorManager Error: Sensor Event is null for Sensor: null" messages going through.
lsuchocki said:
Same issue here. I tried strace'ing the process, and it stopped spinning. I also could no longer wake my screen and performed a 'reset' from adb.
I was seeing a slew of "SensorManager Error: Sensor Event is null for Sensor: null" messages going through.
Click to expand...
Click to collapse
My error ended up having to do with location services... I ended up enabling "Access to my location" and "Use GPS Satellites" in location services, but left "use wireless networks" disabled.
Since then I have installed decimalman's 12/26 kernel. Running rock solid with no abnormal wakelocks since (however my idle battery life seems a little worse).
Here it is as I promised.
This phone (the model with one sim card) is sold as a device with 8GB internal memory. In fact the memory chip inside is 16GB, so we can increase the available internal space.
PLEASE READ CAREFULLY AND IF SOMETHING IS NOT CLEAR DO NOT HESITATE TO ASK.
*** The data on your device will be untouched after this operation. But again please read carefully! ***
*** A good practice is always to make a backup of everything which will be changed. I do it and I've made a backup of the entire internal memory of the device before the start of the operation which is described below. ***
*** At the end of the post there is a link to a ZIP file which can be flashed through TWRP in order to perform the procedure automatically. Also includes a check for the size of the EMMC (as there are devices on which the resizing cannot be performed...their chip is smaller).***
1. You can go to this thread and to say Thanks! @meghd00t as his static build of gdisk is used in the recovery below.
2. What is needed:
- A different TWRP Recovery with gdisk inside. It can be downloaded from here twrp-2.8.7.0-idol3-6039y-with-gdisk.img - md5sum: 66b3f82a3e2e1afe14627b3b900a9319
- (Optional) An SD card for backup of the original GPT partition layout.
- Patience and careful reading.
- The Windows users probably need the drivers from this post, for access to the device in recovery mode.
3. How to do it (the output used below is from the terminal window from which I've done this operation on my device):
- reboot to bootloader:
Code:
adb reboot-bootloader
- start the recovery
Code:
fastboot -i 0x1bbb boot twrp-2.8.7.0-idol3-6039y-with-gdisk.img
- go to the device
Code:
adb shell
- unmount all partitions of the internal memory
Code:
~ # umount /cache
~ # umount /sdcard
~ # umount /and-sec
- ensure that there are no mounted partitions from mmcblk0. The output from the mount command should looks like this:
Code:
~ # mount
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,seclabel,nosuid,relatime,size=713016k,nr_inodes=157853,mode=755)
devpts on /dev/pts type devpts (rw,seclabel,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,seclabel,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,seclabel,relatime,size=713016k,nr_inodes=157853)
adb on /dev/usb-ffs/adb type functionfs (rw,relatime)
/dev/block/mmcblk1p1 on /external_sd type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
- start gdisk
Code:
~ # gdisk /dev/block/mmcblk0
all partitions can be listed by pressing 'p' but we are interested by the last two:
Code:
37 5000400 15269853 4.9 GiB FFFF userdata
38 15269854 30535646 7.3 GiB 0700 userdatabak
and their information which will be shown by pressing 'i' and entering the partition number:
Code:
Command (? for help): i
Partition number (1-38): 37
Partition GUID code: 1B81E7E6-F50D-419B-A739-2AEEF8DA3335 (Unknown)
Partition unique GUID: BDD7FA27-93D4-40BC-B266-313E074E0E87
First sector: 5000400 (at 2.4 GiB)
Last sector: 15269853 (at 7.3 GiB)
Partition size: 10269454 sectors (4.9 GiB)
Attribute flags: 0000000000000000
Partition name: 'userdata'
Command (? for help): i
Partition number (1-38): 38
Partition GUID code: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (Microsoft basic data)
Partition unique GUID: BD12CF41-10E7-BBF7-D096-5553B89882E7
First sector: 15269854 (at 7.3 GiB)
Last sector: 30535646 (at 14.6 GiB)
Partition size: 15265793 sectors (7.3 GiB)
Attribute flags: 0000000000000000
Partition name: 'userdatabak'
The information which is needed from the above output is Partition GUID code, First sector, Last sector and Partition name. You can write these somewhere (if your values are different from the above) from where can be pasted easily later (alternatively you can use the scrollback function of the terminal ).
- if you have an SD card make a backup of the partitions layout (in case that something goes wrong):
Code:
Command (? for help): b
Enter backup filename to save: /external_sd/gpt_partitions_table.backup
The operation has completed successfully.
- delete partitions 37 and 38:
Code:
Command (? for help): d
Partition number (1-38): 38
Command (? for help): d
Partition number (1-37): 37
- create a new partition 37, bigger in size with the same (as before) Partition GUID code, and the same (as before) start sector:
Code:
Command (? for help): n
Partition number (37-40, default 37): 37
First sector (34-30535646, default = 5000400) or {+-}size{KMGTP}: 5000400
Last sector (5000400-30535646, default = 30535646) or {+-}size{KMGTP}: 30535546
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): 1B81E7E6-F50D-419B-A739-2AEEF8DA3335
Changed type of partition to 'Unknown'
The difference here is in the last sector of the partition 30535546.
- create a new partition 38 with same Partition GUID code, but with different First sector:
Code:
Command (? for help): n
Partition number (38-40, default 38): 38
First sector (34-30535646, default = 34) or {+-}size{KMGTP}: 30535547
Information: Moved requested sector from 30535547 to 30535548 in
order to align on 2-sector boundaries.
Use 'l' on the experts' menu to adjust alignment
Last sector (30535548-30535646, default = 30535646) or {+-}size{KMGTP}: 30535646
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
Changed type of partition to 'Microsoft basic data'
Please note that here in the output after 'n' the default first sector is 34, so you explicitly must enter the value!!! As can be seen I've entered the next available sector (after partition 37) 305355547 but it has been corrected automatically to 30535548. So you can use directly 30535548 as a start sector. The last sector is at the end of the memory 30535646.
- write the names of the new partitions:
Code:
Command (? for help): c
Partition number (1-38): 37
Enter name: userdata
Command (? for help): c
Partition number (1-38): 38
Enter name: userdatabak
- if you list the partitions again (with 'p') the end of the table should looks like this:
Code:
37 5000400 30535546 12.2 GiB FFFF userdata
38 30535548 30535646 49.5 KiB 0700 userdatabak
- now it is safe to write the changes by pressing 'w':
Code:
Command (? for help): w
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/block/mmcblk0.
The operation has completed successfully.
- resize the file system:
Code:
~ # resize2fs -p /dev/block/mmcblk0p37
resize2fs 1.42.9 (28-Dec-2013)
Please run 'e2fsck -f /dev/block/mmcblk0p37' first.
... hmm ... let's run it:
Code:
~ # e2fsck -f /dev/block/mmcblk0p37
e2fsck 1.42.9 (28-Dec-2013)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/block/mmcblk0p37: 12519/321280 files (5.8% non-contiguous), 678615/1283425 blocks
~ # resize2fs -p /dev/block/mmcblk0p37
resize2fs 1.42.9 (28-Dec-2013)
Please run 'e2fsck -f /dev/block/mmcblk0p37' first.
... well the resize2fs have some checks and refuses to resize the file system therefore we must force the execution:
Code:
~ # resize2fs -fp /dev/block/mmcblk0p37
resize2fs 1.42.9 (28-Dec-2013)
Resizing the filesystem on /dev/block/mmcblk0p37 to 3191893 (4k) blocks.
The filesystem on /dev/block/mmcblk0p37 is now 3191893 blocks long.
The device now can be rebooted and its internal memory will be almost 12GB which compared to its previous size is a very nice upgrade. Screenshots before and after the repartitioning can be seen here.
Update (19.09.2015): This is a link to a flashabable zip which can be used from the TWRP to automate the process. Can be used with any TWRP recovery for 6039.
md5sum: c3f685310283bdc00cee5412fa33259c
Just tried it, and it worked like a charm. Thank you very much!
Wow ! Kudos to meghd00t and petrov.0. I just ordered this phone as a backup, waiting for my beloved Xperia Z1 Compact to be saved from watering (medium rain during less than 10min, so long Sony waterproof phones...). Can't wait to receive it and play with this extra storage !! Thank you :victory:
Here i'am, crazy thinking that if the 6039y(Single chip, SDcard and 8Gb) come with 8Gb worth of wasted money, that the 6039j dual chip and 16Gb non-SDCard version may very well come with a SDCard reader hardware worth of wasted money.
It would be like just changing the Chip Support slot thing or whatever...
Can someone support my craziness and post a picture of thi "where the chip stays" of the SDCard reader version of this phone??
Thanks a lot!!
evilinheaven said:
Here i'am, crazy thinking that if the 6039y(Single chip, SDcard and 8Gb) come with 8Gb worth of wasted money, that the 6039j dual chip and 16Gb non-SDCard version may very well come with a SDCard reader hardware worth of wasted money.
It would be like just changing the Chip Support slot thing or whatever...
Can someone support my craziness and post a picture of thi "where the chip stays" of the SDCard reader version of this phone??
Thanks a lot!!
Click to expand...
Click to collapse
Well ... I like crazy things. But is impossible just to add a chip.
The thread itself is for other things. I don't want more reminders from the moderators. So please use the general section next time.
Thank you in advance.
Here is the complete partition list for 8Gb single sim variant:
Code:
Disk /dev/block/mmcblk0: 30535680 sectors, 14.6 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 98101B32-BBE2-4BF2-A06E-2BB33D000C20
Partition table holds up to 40 entries
First usable sector is 34, last usable sector is 30535646
Partitions will be aligned on 2-sector boundaries
Total free space is 256464 sectors (125.2 MiB)
Number Start (sector) End (sector) Size Code Name
1 131072 262143 64.0 MiB 0700 modem
2 262144 265215 1.5 MiB FFFF tunning
3 265216 267263 1024.0 KiB FFFF traceability
4 267264 267265 1024 bytes FFFF fsc
5 267266 267281 8.0 KiB FFFF ssd
6 267282 268305 512.0 KiB FFFF sbl1
7 268306 269329 512.0 KiB 0700 sbl1bak
8 269330 270353 512.0 KiB FFFF rpm
9 270354 271377 512.0 KiB 0700 rpmbak
10 271378 272401 512.0 KiB FFFF tz
11 272402 273425 512.0 KiB 0700 tzbak
12 273426 274449 512.0 KiB FFFF hyp
13 274450 275473 512.0 KiB 0700 hypbak
14 275474 278545 1.5 MiB FFFF modemst1
15 278546 281617 1.5 MiB FFFF modemst2
16 281618 283665 1024.0 KiB FFFF simlock
17 283666 286737 1.5 MiB FFFF efsdata
18 393216 393279 32.0 KiB FFFF DDR
19 393280 396351 1.5 MiB FFFF fsg
20 396352 396383 16.0 KiB FFFF sec
21 396384 398431 1024.0 KiB FFFF aboot
22 398432 400479 1024.0 KiB 0700 abootbak
23 400480 466015 32.0 MiB FFFF boot
24 466016 531551 32.0 MiB FFFF recovery
25 531552 4306427 1.8 GiB FFFF system
26 4325376 4390911 32.0 MiB FFFF persist
27 4390912 4407295 8.0 MiB FFFF splash
28 4407296 4448255 20.0 MiB 0700 tctpersist
29 4448256 4468735 10.0 MiB 0700 hdcp
30 4468736 4468751 8.0 KiB FFFF fota
31 4468752 4993039 256.0 MiB FFFF cache
32 4993040 4995087 1024.0 KiB FFFF misc
33 4995088 4996111 512.0 KiB FFFF keystore
34 4996112 4996175 32.0 KiB FFFF config
35 4996176 4996303 64.0 KiB FFFF oem
36 4996304 5000399 2.0 MiB FFFF FactoryRP
37 5000400 15269853 4.9 GiB FFFF userdata
38 15269854 30535646 7.3 GiB 0700 userdatabak
Maybe someone can post the list for 16Gb dual sim variant?
Ok, I bit the bullet and resized the "userdata" partition. Only that I did not create the smaller #38 partition, I did not see any reason to do it (if any update tries to store something inside it, will fail anyway; this partition does not look special, all *bak partitions have the same GUID). Plus there isn't any "userdatabak" partition on 16Gb models. Instead I made partition #37 up to the latest available sector (30535646). The phone is working just fine.
rioachim said:
Ok, I bit the bullet and resized the "userdata" partition. Only that I did not create the smaller #38 partition, I did not see any reason to do it (if any update tries to store something inside it, will fail anyway; this partition does not look special, all *bak partitionshave the same GUID). Plus there isn't any "userdatabak" partition on 16Gb models. Instead I made partition #37 up to the latest available sector (30535646). The phone is working just fine.
Click to expand...
Click to collapse
OK. But don't be fulled by the GUID. Most of the bak partitions contain data which is equivalent to the data in the primary ones (aboot, rpm, sbl1 etc.). The data is patched in both partitions with the same patch during an upgrade.
Script to repartition "internal memory"
Hello petrov.0, all
Is it possible to create a shell for all thoses commands ?
In this case if partitions are lost (upgrade, patchs....) we could apply it easily.
And nice discovered.
Regards
Google99
google99 said:
Hello petrov.0, all
Is it possible to create a shell for all thoses commands ?
In this case if partitions are lost (upgrade, patchs....) we could apply it easily.
And nice discovered.
Regards
Google99
Click to expand...
Click to collapse
No it is not:
Code:
GPT fdisk (aka gdisk) is a text-mode menu-driven program for creation and manipulation of partition tables.
Hi petrov.0 great news and thanks.
Just a doubt, a friend of mine will receive Idol 3 4,7" 8 GB tomorrow, he can made OTA update (that I think are available for security reasons as "stagefright" and another I know Alcatel get users a way to set SD as main memory) and then use your guide to expand memory t 16 Gb or for this operation is better been in a fresh unchained device not updated?
Because in this second option device become 16 Gb Rom but will be afected by stagefright and for the rest of his life
Thanks!
Romagnolo1973 said:
Hi petrov.0 great news and thanks.
Just a doubt, a friend of mine will receive Idol 3 4,7" 8 GB tomorrow, he can made OTA update (that I think are available for security reasons as "stagefright" and another I know Alcatel get users a way to set SD as main memory) and then use your guide to expand memory t 16 Gb or for this operation is better been in a fresh unchained device not updated?
Because in this second option device become 16 Gb Rom but will be afected by stagefright and for the rest of his life
Thanks!
Click to expand...
Click to collapse
It shouldn't be updated. The official updates for 6039 removes the fastboot commands therefore you will not be able to do the repartitioning nor to root the device. Give me the update file and will modify it in a way which will preserve the commands (there is a risk for a broken device after it though ... I wish to try such modification first on my phone, but unfortunately I still do not have official update for it with which to test).
petrov.0 said:
It shouldn't be updated. The official updates for 6039 removes the fastboot commands therefore you will not be able to do the repartitioning nor to root the device. Give me the update file and will modify it in a way which will preserve the commands (there is a risk for a broken device after it though ... I wish to try such modification first on my phone, but unfortunately I still do not have official update for it with which to test).
Click to expand...
Click to collapse
By the way is there any hope (other than getting Alcatel to push an update to put fastboot commands back in, cause is anyone that optimistic?) for people who have indeed updated to recover those?
Sent from my 6039Y using Tapatalk
Rorshan said:
By the way is there any hope (other than getting Alcatel to push an update to put fastboot commands back in, cause is anyone that optimistic?) for people who have indeed updated to recover those?
Sent from my 6039Y using Tapatalk
Click to expand...
Click to collapse
If you find a way to root the device after the update then may be there is a hope.
petrov.0 said:
It shouldn't be updated. The official updates for 6039 removes the fastboot commands therefore you will not be able to do the repartitioning nor to root the device. Give me the update file and will modify it in a way which will preserve the commands (there is a risk for a broken device after it though ... I wish to try such modification first on my phone, but unfortunately I still do not have official update for it with which to test).
Click to expand...
Click to collapse
Understood the problem is new update that remove some action from fastboot needed for repartioning. Idol 3 was received and he resize rom from 8 to 16 with no issue with your guide, after that he made OTA update and they are working perfectly, no issue with the new partitioning size and device is working well.
Romagnolo1973 said:
Understood the problem is new update that remove some action from fastboot needed for repartioning. Idol 3 was received and he resize rom from 8 to 16 with no issue with your guide, after that he made OTA update and they are working perfectly, no issue with the new partitioning size and device is working well.
Click to expand...
Click to collapse
Not some but all fastboot commands are removed. Glad to see that you have made it though. The OTA update however is a mistake. Now you can't get root access nor the fastboot commands are available.
petrov.0 said:
Not some but all fastboot commands are removed. Glad to see that you have made it though. The OTA update however is a mistake. Now you can't get root access nor the fastboot commands are available.
Click to expand...
Click to collapse
Yes, it was risky but probably he is not interested in root, I only inform you that new partitioning with OTA is still there, I think is a goodnews and a base to start, now the perfect situation is if Alcatel made a future OTA as soon as possible with fastboot perfectly working.
Romagnolo1973 said:
Yes, it was risky but probably he is not interested in root, I only inform you that new partitioning with OTA is still there, I think is a goodnews and a base to start, now the perfect situation is if Alcatel made a future OTA as soon as possible with fastboot perfectly working.
Click to expand...
Click to collapse
There is nothing wrong with the fastboot commands prior the update. I have doubts that they will be returned. Thanks for the info though (despite that I already know this by looking in the update files). I can't live without root access however therefore there is no option to loose it.
I'm kinda confused here. Are all the steps done from a terminal on the computer or is some of that to be typed inside the TWRP terminal? Because as soon as I boot TWRP with gdisk I get a device not found from typing adb shell. I'm pretty sure I have all the drivers mentioned in the linked post (and even more too). Any kind soul to explain how stupid I am being (because I know that's the solution in the end, I'm a fool)
Rorshan said:
I'm kinda confused here. Are all the steps done from a terminal on the computer or is some of that to be typed inside the TWRP terminal? Because as soon as I boot TWRP with gdisk I get a device not found from typing adb shell. I'm pretty sure I have all the drivers mentioned in the linked post (and even more too). Any kind soul to explain how stupid I am being (because I know that's the solution in the end, I'm a fool)
Click to expand...
Click to collapse
Everything after adb shell must be done directly on the device. The VID & PID of the device are different in the recovery and you don't have the necessary drivers. Try to install the drivers mentioned in the first post (- The Windows users probably need the drivers from this post, for access to the device in recovery mode).
hello,
im trying to flash my S4 Mini with lineage os - first step installing twrp fails.
i tried using heimdall to to flash twrp with the gui and via cli, but fail the same way: they report no error at all! finish the flashing and reboot. when i then try to go into recovery the standard recovery is still there! everything is jsut as stock as it was before.
here is the cli output:
Code:
sudo heimdall flash --RECOVERY twrp-3.2.3-0-serranoltexx.img --verbose
Heimdall v1.4.0
Copyright (c) 2010-2013, Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au/
This software is provided free of charge. Copying and redistribution is
encouraged.
If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/
Initialising connection...
Detecting device...
Manufacturer: "Sasmsung"
Product: "MSM8960"
length: 18
device class: 2
S/N: 0
VID:PID: 04E8:685D
bcdDevice: 0100
iMan:iProd:iSer: 1:2:0
nb confs: 1
interface[0].altsetting[0]: num endpoints = 1
Class.SubClass.Protocol: 02.02.01
endpoint[0].address: 82
max packet size: 0010
polling interval: 09
interface[1].altsetting[0]: num endpoints = 2
Class.SubClass.Protocol: 0A.00.00
endpoint[0].address: 81
max packet size: 0200
polling interval: 00
endpoint[1].address: 01
max packet size: 0200
polling interval: 00
Claiming interface...
Setting up interface...
Initialising protocol...
WARNING: Control transfer #1 failed. Result: -9
WARNING: Control transfer #2 failed. Result: -9
WARNING: Control transfer #3 failed. Result: -9
WARNING: Control transfer #4 failed. Result: -9
WARNING: Control transfer #5 failed. Result: -9
WARNING: Control transfer #6 failed. Result: -9
Protocol initialisation successful.
Beginning session...
Some devices may take up to 2 minutes to respond.
Please be patient!
Session begun.
Downloading device's PIT file...
PIT file download successful.
Uploading RECOVERY
0%
11%
22%
33%
45%
56%
67%
79%
90%
100%
RECOVERY upload successful
Ending session...
Rebooting device...
Releasing device interface...
note that: i tried 2 different versions of the latest twrp (one compiled by someone from xda), and i tried the gui too - adding the path to the save pit -> same result.
my problem seems similar to this post:
https://forum.xda-developers.com/galaxy-s4-mini/help/heimdall-reboot-to-custom-recovery-t3474163
but there was no response
also, ive read that sudo can be problem for heimdall, but without sudo it cant access the usb....
if anyone has any idea, please dont be shy to attempt to help, or point to other places where i could get help thank you!
about me: this is literally the first time im having an android device (im a sailfish user), so forgive me the possible beginners mistakes. also, my host pc is runing mint19.
misc11 said:
hello,.
Click to expand...
Click to collapse
Bro I think you are in stock.....
But which model? If i9192
Then root using https://forum.xda-developers.com/galaxy-s4-mini/general/root-root-s4-mini-i9192-2018-t3780235 and flash twrp.img using apps
HemanthJabalpuri said:
Bro I think you are in stock.....
But which model? If i9192
Then root using https://forum.xda-developers.com/galaxy-s4-mini/general/root-root-s4-mini-i9192-2018-t3780235 and flash twrp.img using apps
Click to expand...
Click to collapse
yes, the phone is still completely stock. not rooted, but apparently the bootloader comes unlocked with samsung phones...
the version is: GT-I9195. so, from your link, i understand that i HAVE to root it?
HemanthJabalpuri said:
Bro I think you are in stock.....
But which model? If i9192
Then root using https://forum.xda-developers.com/galaxy-s4-mini/general/root-root-s4-mini-i9192-2018-t3780235 and flash twrp.img using apps
Click to expand...
Click to collapse
thank you for your help! in fact, rooting the phone was the solution. installing twrp worked right away!
misc11 said:
thank you for your help! in fact, rooting the phone was the solution. installing twrp worked right away!
Click to expand...
Click to collapse
Thanks no worries
HemanthJabalpuri
Tried two offical Xiaomi fastboot Pie images, and system.img doesn't flash. Other smaller in size system images I flashed to see what would happen do go through, but they don't work. Pie image is 2.1 GB. Other partitions are all flashed.
Each attempt via Xiaomi flash tool ends with: Chunk data size exceeds partition size.
Log:
$fastboot -s 08f97d930705 flash system_a C:\XiaoMi\XiaoMiFlash\Source\ThirdParty\Google\Android\daisy_global_images_V10.0.10.0.PDLMIXM_9.0\\images\system.img ||
[10:26:06 AM 08f97d930705]:target reported max download size of 534773760 bytes
[10:26:06 AM 08f97d930705]:sending sparse 'system_a' 1/3 (462332 KB)...
[10:26:06 AM 08f97d930705]KAY [ 59.062s]
[10:26:06 AM 08f97d930705]:writing 'system_a' 1/3...
[10:26:06 AM 08f97d930705]:error:FAILED (remote: Chunk data size exceeds partition size)
[10:26:06 AM 08f97d930705]:flashSuccess False
Fastboot flash_all.bat gives:
fastboot getvar product 2>&1 | findstr /r /c:"^product: *d
aisy" ||
The system cannot find message text for message number 0x8 in the message file f
or System.
Fastboot flash system sends sparse chunks and gives:
data too large
So, what gives? Any ideas greatly appreciated.
MarkR7 said:
Tried two offical Xiaomi fastboot Pie images, and system.img doesn't flash. Other smaller in size system images I flashed to see what would happen do go through, but they don't work. Pie image is 2.1 GB. Other partitions are all flashed.
Each attempt via Xiaomi flash tool ends with: Chunk data size exceeds partition size.
Log:
$fastboot -s 08f97d930705 flash system_a C:\XiaoMi\XiaoMiFlash\Source\ThirdParty\Google\Android\daisy_global_images_V10.0.10.0.PDLMIXM_9.0\\images\system.img ||
[10:26:06 AM 08f97d930705]:target reported max download size of 534773760 bytes
[10:26:06 AM 08f97d930705]:sending sparse 'system_a' 1/3 (462332 KB)...
[10:26:06 AM 08f97d930705]KAY [ 59.062s]
[10:26:06 AM 08f97d930705]:writing 'system_a' 1/3...
[10:26:06 AM 08f97d930705]:error:FAILED (remote: Chunk data size exceeds partition size)
[10:26:06 AM 08f97d930705]:flashSuccess False
Fastboot flash_all.bat gives:
fastboot getvar product 2>&1 | findstr /r /c:"^product: *d
aisy" ||
The system cannot find message text for message number 0x8 in the message file f
or System.
Fastboot flash system sends sparse chunks and gives:
data too large
So, what gives? Any ideas greatly appreciated.
Click to expand...
Click to collapse
It could be an error from the tool or maybe you need to delete some logs that can cause a conflict anyway did you try using just fastboot command to flash just system? if not trying finding which is your current slot and then flash it directly to it.
I guess size image support is around 2,5GB.
SubwayChamp said:
It could be an error from the tool or maybe you need to delete some logs that can cause a conflict anyway did you try using just fastboot command to flash just system? if not trying finding which is your current slot and then flash it directly to it.
I guess size image support is around 2,5GB.
Click to expand...
Click to collapse
I direct fastboot flashed system multiple times, also flash all bat, I also restored Oeeo from TWRP backup multiple timea, Oreo working fine, now that I think of it, Mi Flash tool seems to be from 2017 and it seems old to me, I got it from their link somewhere, but could the newest one be that old? Need to check that.
MarkR7 said:
I direct fastboot flashed system multiple times, also flash all bat, I also restored Oeeo from TWRP backup multiple timea, Oreo working fine, now that I think of it, Mi Flash tool seems to be from 2017 and it seems old to me, I got it from their link somewhere, but could the newest one be that old? Need to check that.
Click to expand...
Click to collapse
This seems to be the latest stable version https://c.mi.com/thread-1329226-1-0.html and although this is newer use the tool from 2017 but ever worked for me https://xiaomifirmware.com/downloads/mif anyway you have too the option to flash through edl
I think someone had a problem due to fastboot being too old.
The partition should be 2.5Gb so unless you or someone else resized partitions, it should be large enough.
I can use fdisk from a running phone to print partition info. If you can't boot, perhaps you can check from twrp?
Code:
# fdisk /dev/block/mmcblk0
Found valid GPT with protective MBR; using GPT
Command (m for help): p
Disk /dev/block/mmcblk0: 122142720 sectors, 2296M
Logical sector size: 512
Disk identifier (GUID): 98101b32-bbe2-4bf2-a06e-2bb33d000c20
Partition table holds up to 60 entries
First usable sector is 34, last usable sector is 122142686
Number Start (sector) End (sector) Size Name
1 34 49 8192 fsc
2 50 65 8192 ssd
3 66 81 8192 dpo
4 82 113 16384 sec
5 114 145 16384 bk1
6 146 185 20480 bk2
7 186 249 32768 DDR
8 250 313 32768 limits
9 314 377 32768 config
10 378 505 65536 bk3
11 506 761 128K lksecapp
12 762 1017 128K lksecappbak
13 1018 1529 256K devcfg_a
14 1530 2041 256K devcfg_b
15 2042 2553 256K apdp
16 2554 3065 256K msadp
17 3066 4089 512K sbl1_a
18 4090 5113 512K sbl1_b
19 5114 6137 512K rpm_a
20 6138 7161 512K rpm_b
21 7162 8185 512K mota
22 8186 9209 512K keystore
23 9210 10233 512K syscfg
24 10234 12281 1024K cmnlib_a
25 12282 14329 1024K cmnlib_b
26 14330 16377 1024K cmnlib64_a
27 16378 18425 1024K cmnlib64_b
28 18426 20473 1024K keymaster_a
29 20474 22521 1024K keymaster_b
30 22522 24569 1024K misc
31 24570 26617 1024K aboot_a
32 26618 28665 1024K aboot_b
33 28666 30713 1024K dip
34 30714 32761 1024K bk4
35 32762 36857 2048K tz_a
36 36858 40953 2048K tz_b
37 40954 49145 4096K mcfg
38 49146 65529 8192K devinfo
39 65530 81913 8192K fsg
40 81914 98297 8192K modemst1
41 98298 114681 8192K modemst2
42 114682 131065 8192K bk5
43 131066 163833 16.0M splash
44 163834 196601 16.0M dsp_a
45 196602 229369 16.0M dsp_b
46 229370 262137 16.0M bk6
47 262138 327673 32.0M mdtp_a
48 327674 393209 32.0M mdtp_b
49 393210 458745 32.0M persist
50 458746 524281 32.0M persistbak
51 524288 655359 64.0M boot_a
52 655360 786431 64.0M boot_b
53 786432 917503 64.0M logdump
54 917504 1179647 128M modem_a
55 1179648 1441791 128M modem_b
56 1441792 6684671 2560M system_a
57 6684672 11927551 2560M system_b
58 11927552 13500415 768M vendor_a
59 13500416 15073279 768M vendor_b
60 15073280 122142686 51.0G userdata
Command (m for help): q
a1291762 said:
I think someone had a problem due to fastboot being too old.
The partition should be 2.5Gb so unless you or someone else resized partitions, it should be large enough.
I can use fdisk from a running phone to print partition info. If you can't boot, perhaps you can check from twrp?
Code:
# fdisk /dev/block/mmcblk0
Found valid GPT with protective MBR; using GPT
Command (m for help): p
Disk /dev/block/mmcblk0: 122142720 sectors, 2296M
Logical sector size: 512
Disk identifier (GUID): 98101b32-bbe2-4bf2-a06e-2bb33d000c20
Partition table holds up to 60 entries
First usable sector is 34, last usable sector is 122142686
Number Start (sector) End (sector) Size Name
1 34 49 8192 fsc
2 50 65 8192 ssd
3 66 81 8192 dpo
4 82 113 16384 sec
5 114 145 16384 bk1
6 146 185 20480 bk2
7 186 249 32768 DDR
8 250 313 32768 limits
9 314 377 32768 config
10 378 505 65536 bk3
11 506 761 128K lksecapp
12 762 1017 128K lksecappbak
13 1018 1529 256K devcfg_a
14 1530 2041 256K devcfg_b
15 2042 2553 256K apdp
16 2554 3065 256K msadp
17 3066 4089 512K sbl1_a
18 4090 5113 512K sbl1_b
19 5114 6137 512K rpm_a
20 6138 7161 512K rpm_b
21 7162 8185 512K mota
22 8186 9209 512K keystore
23 9210 10233 512K syscfg
24 10234 12281 1024K cmnlib_a
25 12282 14329 1024K cmnlib_b
26 14330 16377 1024K cmnlib64_a
27 16378 18425 1024K cmnlib64_b
28 18426 20473 1024K keymaster_a
29 20474 22521 1024K keymaster_b
30 22522 24569 1024K misc
31 24570 26617 1024K aboot_a
32 26618 28665 1024K aboot_b
33 28666 30713 1024K dip
34 30714 32761 1024K bk4
35 32762 36857 2048K tz_a
36 36858 40953 2048K tz_b
37 40954 49145 4096K mcfg
38 49146 65529 8192K devinfo
39 65530 81913 8192K fsg
40 81914 98297 8192K modemst1
41 98298 114681 8192K modemst2
42 114682 131065 8192K bk5
43 131066 163833 16.0M splash
44 163834 196601 16.0M dsp_a
45 196602 229369 16.0M dsp_b
46 229370 262137 16.0M bk6
47 262138 327673 32.0M mdtp_a
48 327674 393209 32.0M mdtp_b
49 393210 458745 32.0M persist
50 458746 524281 32.0M persistbak
51 524288 655359 64.0M boot_a
52 655360 786431 64.0M boot_b
53 786432 917503 64.0M logdump
54 917504 1179647 128M modem_a
55 1179648 1441791 128M modem_b
56 1441792 6684671 2560M system_a
57 6684672 11927551 2560M system_b
58 11927552 13500415 768M vendor_a
59 13500416 15073279 768M vendor_b
60 15073280 122142686 51.0G userdata
Command (m for help): q
Click to expand...
Click to collapse
I don't know what the hell is going on. Just tried to flash again with newer late 2018 Xiaomi Flash tool and included fastboot. This time the thing didn't run erase commands before flashing partitions and ended up with the same Chunk Size Data exceeds partition size error. I restored to Oreo from my TWRP backups. TWRP shows partition size as normal 2.5 GB. Never touched the partition table. Smaller GSI images flash in there. Oreo is 1.7 GB, I think, it restores. On Oreo everything works, encryption disabler, Magisk. Just can't flash the lousy official Pie system, tried 10.0.03.0 Whatever, tried 10.0.10 from June, same thing. Somebody suggested I convert to ext4 image, but why the hell does it not just work? Like it can't handle the size of the system image somehow. Will try your commands, thanks. Maybe even newer Xiaomi tool. Damn
Thanks for help.
What is really bloody funny is I have puny Redmi Go running Lineage 16 and all set up without any trouble. Just hilarious.
MarkR7 said:
I don't know what the hell is going on. Just tried to flash again with newer late 2018 Xiaomi Flash tool and included fastboot. This time the thing didn't run erase commands before flashing partitions and ended up with the same Chunk Size Data exceeds partition size error. I restored to Oreo from my TWRP backups. TWRP shows partition size as normal 2.5 GB. Never touched the partition table. Smaller GSI images flash in there. Oreo is 1.7 GB, I think, it restores. On Oreo everything works, encryption disabler, Magisk. Just can't flash the lousy official Pie system, tried 10.0.03.0 Whatever, tried 10.0.10 from June, same thing. Somebody suggested I convert to ext4 image, but why the hell does it not just work? Like it can't handle the size of the system image somehow. Will try your commands, thanks. Maybe even newer Xiaomi tool. Damn
Thanks for help.
What is really bloody funny is I have puny Redmi Go running Lineage 16 and all set up without any trouble. Just hilarious.
Click to expand...
Click to collapse
Try the latest rom http://bigota.d.miui.com/V10.0.12.0...0.PDLMIXM_20190717.0000.00_9.0_59368ef014.tgz and try it using edl, edl is a lower level than fastboot and probably might work better.
edl flash fail - identical to fastboot
SubwayChamp said:
Try the latest rom http://bigota.d.miui.com/V10.0.12.0...0.PDLMIXM_20190717.0000.00_9.0_59368ef014.tgz and try it using edl, edl is a lower level than fastboot and probably might work better.
Click to expand...
Click to collapse
This thing is impossible. EDL flash fails the same way, at about the same time in the flash process. Just says error and maybe the device got disconnected. It did not.
Since I got the phone recently, I never run any OTA updates on it and it's on the lastest Oreo 9.6.11 before 10.0.2.0 Pie. System partition is actually 2.4 GB and Vendor is also slightly smaller than a1291762's partition size. Could it be they increased partitio sizes during 10.0.2.0 Pie update and not applying/skipping that update causes the trouble? Honestly I have no idea, anybody who can make something out of this? Should I run 10.0.2.0 to see if it changes partitions? Or does skipping that update cause trouble for some other unfathomable reason? I will just try OTA sooner or later, I guess.
Here's the output:
daisy_sprout:/ $ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/block/mmcblk0p56 2.4G 1.6G 751M 70% /system_root
tmpfs 1.7G 1.4M 1.7G 1% /sbin
tmpfs 1.7G 712K 1.7G 1% /dev
/dev/block/mmcblk0p58 744M 555M 174M 77% /vendor
tmpfs 1.7G 0 1.7G 0% /mnt
/dev/block/mmcblk0p49 27M 2.7M 24M 11% /persist
/dev/block/mmcblk0p54 128M 81M 47M 63% /firmware
/dev/block/mmcblk0p44 12M 6.9M 4.5M 61% /dsp
/sbin/.magisk/block/data 50G 808M 49G 2% /sbin/.magisk/modules
/data/media 50G 808M 49G 2% /storage/emulated
/mnt/media_rw/0403-0201 29G 28G 712M 98% /storage/0403-0201
daisy_sprout:/ $ df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/block/mmcblk0p56 2539312 1754068 768860 70% /system_root
tmpfs 1821960 1500 1820460 1% /sbin
tmpfs 1821960 712 1821248 1% /dev
/dev/block/mmcblk0p58 761776 567948 178100 77% /vendor
tmpfs 1821960 0 1821960 0% /mnt
/dev/block/mmcblk0p49 28144 2772 24720 11% /persist
/dev/block/mmcblk0p54 131008 82464 48544 63% /firmware
/dev/block/mmcblk0p44 12016 7072 4620 61% /dsp
/sbin/.magisk/block/data 52562448 827192 51718872 2% /sbin/.magisk/modules
MarkR7 said:
This thing is impossible. EDL flash fails the same way, at about the same time in the flash process. Just says error and maybe the device got disconnected. It did not.
Since I got the phone recently, I never run any OTA updates on it and it's on the lastest Oreo 9.6.11 before 10.0.2.0 Pie. System partition is actually 2.4 GB and Vendor is also slightly smaller than a1291762's partition size. Could it be they increased partitio sizes during 10.0.2.0 Pie update and not applying/skipping that update causes the trouble? Honestly I have no idea, anybody who can make something out of this? Should I run 10.0.2.0 to see if it changes partitions? Or does skipping that update cause trouble for some other unfathomable reason? I will just try OTA sooner or later, I guess.
Here's the output:
daisy_sprout:/ $ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/block/mmcblk0p56 2.4G 1.6G 751M 70% /system_root
tmpfs 1.7G 1.4M 1.7G 1% /sbin
tmpfs 1.7G 712K 1.7G 1% /dev
/dev/block/mmcblk0p58 744M 555M 174M 77% /vendor
tmpfs 1.7G 0 1.7G 0% /mnt
/dev/block/mmcblk0p49 27M 2.7M 24M 11% /persist
/dev/block/mmcblk0p54 128M 81M 47M 63% /firmware
/dev/block/mmcblk0p44 12M 6.9M 4.5M 61% /dsp
/sbin/.magisk/block/data 50G 808M 49G 2% /sbin/.magisk/modules
/data/media 50G 808M 49G 2% /storage/emulated
/mnt/media_rw/0403-0201 29G 28G 712M 98% /storage/0403-0201
daisy_sprout:/ $ df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/block/mmcblk0p56 2539312 1754068 768860 70% /system_root
tmpfs 1821960 1500 1820460 1% /sbin
tmpfs 1821960 712 1821248 1% /dev
/dev/block/mmcblk0p58 761776 567948 178100 77% /vendor
tmpfs 1821960 0 1821960 0% /mnt
/dev/block/mmcblk0p49 28144 2772 24720 11% /persist
/dev/block/mmcblk0p54 131008 82464 48544 63% /firmware
/dev/block/mmcblk0p44 12016 7072 4620 61% /dsp
/sbin/.magisk/block/data 52562448 827192 51718872 2% /sbin/.magisk/modules
Click to expand...
Click to collapse
Eventually a failed update can do some weird things like this but is unusual or rarely heard.
Don´t wait that OTA comes to your device, choose one from the official site to be flashed through stock recovery if you have some hope that this help.
Also then to try this in TWRP there is an option to restore system partition (I´m not sure if this really works)
And as a last resource maybe you might to re-adjust the size partition http://en.miui.com/thread-183258-1-1.html
OTA ROM update
Thanks for all advice, really appreciated. I got a zillion backups thru TWRP and those not working fastboot ROMs. I am on a crappy limited mobile connection right now and need to get wifi to get all the ROMs, so preferred to store them locally on a laptop, but should have just run an OTA straight away. Anyway, am back on original stock Oreo, fully stock boot system everything. Have last August 10.13 OTA rom zip and wonder how the hell to try that one. Nothing under system update that would let me use locally stored OTA ROM. Renaming it to update.zip and putting in root of internal storage doesn't seem to work for stock recovery.
Never mind. found a way. Still craps out. Says error in package zip Status 1 whatever the hell that is. Thanks anyway.
MarkR7 said:
Thanks for all advice, really appreciated. I got a zillion backups thru TWRP and those not working fastboot ROMs. I am on a crappy limited mobile connection right now and need to get wifi to get all the ROMs, so preferred to store them locally on a laptop, but should have just run an OTA straight away. Anyway, am back on original stock Oreo, fully stock boot system everything. Have last August 10.13 OTA rom zip and wonder how the hell to try that one. Nothing under system update that would let me use locally stored OTA ROM. Renaming it to update.zip and putting in root of internal storage doesn't seem to work for stock recovery.
Never mind. found a way. Still craps out. Says error in package zip Status 1 whatever the hell that is. Thanks anyway.
Click to expand...
Click to collapse
Update from internal storage and from adb sideload are available on stock recovery. Unfortunately TWRP can´t flash stock updates like on other Xiaomi devices using Miui.
Probably you might try the Miui rom ported available in this forum https://forum.xda-developers.com/mi-a2-lite/development/9-miui-rom-t3960704, system image has almost 2,40GB (version 1.1)
Stocl Recovery
SubwayChamp said:
Update from internal storage and from adb sideload are available on stock recovery. Unfortunately TWRP can´t flash stock updates like on other Xiaomi devices using Miui.
Probably you might try the Miui rom ported available in this forum https://forum.xda-developers.com/mi-a2-lite/development/9-miui-rom-t3960704, system image has almost 2,40GB (version 1.1)
Click to expand...
Click to collapse
You don't unserstand. I DO have stock recovery om both slots, everything as stock as possible. Had Full backups and restored them, boot images also. It is stock recovery that gives the error. Supposedly Status 1 has sth to do with setting permissions, but thanks anyway.
EDL finally worked, many thanks for help
:laugh:
SubwayChamp said:
Update from internal storage and from adb sideload are available on stock recovery. Unfortunately TWRP can´t flash stock updates like on other Xiaomi devices using Miui.
Probably you might try the Miui rom ported available in this forum https://forum.xda-developers.com/mi-a2-lite/development/9-miui-rom-t3960704, system image has almost 2,40GB (version 1.1)
Click to expand...
Click to collapse
:fingers-crossed:
After some fails, EDL flash finally worked and the phone is now on Pie. Many thanks for the suggestion. For some seconds after flash I thought it was a total brick, but I think it must have been exiting EDL. Normal fastboot flash of system.img failed each time.
Again, many thanks for help and time you took.