Related
I installed virtousity, it hangs 2 times, the 2nd time it wont boot anymore, stuck on white htc screen.
so i tried to reboot on recovery clockworkmod recovery v5.0.2.0 but it only shows the hat and arrow and "clockworkmod recovery v5.0.2.0" and nothing after that.
so i tried to install clockworkmod recovery via fastboot and it just hangs on "writing recovery..."
i dont know what else to try, anybody can help me?
i tried this method of installing via PG88IMG on bootloader, and its stuck in "updating..."
does it look like eMMC problem?
ruu says it cant detect my phone? and i notice that when i connect my phone it cant find/install "android phone" usb driver.
so i run adb command and this what came out, is this good news or bad news?
cat /proc/kmsg | grep mmc0
<3>[ 7.698364] mmc0: No card detect facilities available
<6>[ 7.698913] mmc0: Qualcomm MSM SDCC at 0x00000000a0500000 irq 98,0 dma 7
<6>[ 7.699127] mmc0: Platform slot type: MMC
<6>[ 7.699279] mmc0: 4 bit data mode disabled
<6>[ 7.699401] mmc0: 8 bit data mode enabled
<6>[ 7.699615] mmc0: MMC clock 144000 -> 50000000 Hz, PCLK 96000000 Hz
<6>[ 7.699737] mmc0: Slot eject status = 0
<6>[ 7.699890] mmc0: Power save feature enable = 1
<6>[ 7.700012] mmc0: DM non-cached buffer at ffa0f000, dma_addr 0x0baf0000
<6>[ 7.700134] mmc0: DM cmd busaddr 0x0baf0000, cmdptr busaddr 0x0baf0300
<6>[ 7.853759] mmc0: new high speed MMC card at address 0001
<6>[ 7.854980] mmcblk0: mmc0:0001 M4G2DE 2.10 GiB
Click to expand...
Click to collapse
Did you wipe data and cache before you flashed virtuous unity?
Sent from my HTC Desire S using XDA App
matthewsucks said:
Did you wipe data and cache before you flashed virtuous unity?
Sent from my HTC Desire S using XDA App
Click to expand...
Click to collapse
no, so thats the problem? what should i do know? the adb command seems saying that its not an eMMC problem.
Now, go into recovery and factory reset. Then, redownload rom manager and flash your rom from your sd card. To go into recovery mode, remove your battery and put it in, then hold the lock button and volume down button.
Sent from my HTC Desire S using XDA App
i cant factory reset, it just hangs when factory reset is selected.
Did you backup your stock rom? If you didn't, your phone's bricked. You gotta send it for repair.
Sent from my HTC Desire S using XDA App
matthewsucks said:
Did you backup your stock rom? If you didn't, your phone's bricked. You gotta send it for repair.
Sent from my HTC Desire S using XDA App
Click to expand...
Click to collapse
i backed up it, via clockwork mod recovery. but i cant install it cause clockwork mod recovery hangs and cant start.
Hang? How does. It hang?
Sent from my HTC Desire S using XDA App
matthewsucks said:
Hang? How does. It hang?
Sent from my HTC Desire S using XDA App
Click to expand...
Click to collapse
the factory reset hangs when i select it.
the clockworkmod recovery hangs when i go to recovery mode, its just says "clockworkmod recovery v5.0.2.0 recovery" with a hat and an orange circle arrow then nothing, i left it for a long time, still nothing
now all i can do is adb shell commands.
Now, don't enter recovery. Go to your bootloader and hit factory reset.
Sent from my HTC Desire S using XDA App
Not actually sure if this works on the Desire S (never had to use it) but have you tried:
adb reboot fastboot
fastboot erase cache
fastboot reboot
Whilst the HTC logo is displaying:
adb reboot recovery
Presuming it now enters recovery properly, you might want to do a full factory reset and another cache wipe from the main recovery menu.
I wish you luck!
LaKraven said:
Not actually sure if this works on the Desire S (never had to use it) but have you tried:
adb reboot fastboot
fastboot erase cache
fastboot reboot
Whilst the HTC logo is displaying:
adb reboot recovery
Presuming it now enters recovery properly, you might want to do a full factory reset and another cache wipe from the main recovery menu.
I wish you luck!
Click to expand...
Click to collapse
adb reboot fastboot - reboots the phone to htc logo and hangs, so what i did was go into hboot, select fastboot and connect usb, then fastboot turns to fastboot usb. after that i run fastboot erase cache which hangs the phone.
it seems this is not a burned eMMC problem, its just that the files are messed up/ maybe if theres a "scandisk" or repair partition i can use. but i dont know linux commands that well.
also tried this command inside adb shell:
mount data
mount: can't read '/etc/fstab': No such file or directory
so it seems im missing some files
matthewsucks said:
Now, don't enter recovery. Go to your bootloader and hit factory reset.
Sent from my HTC Desire S using XDA App
Click to expand...
Click to collapse
factory reset hangs
cd /dev/block
/dev/block # ll
ll
/sbin/sh: ll: not found
/dev/block # ls -l
ls -l
brw------- 1 root root 7, 0 Sep 11 05:40 loop0
brw------- 1 root root 7, 1 Sep 11 05:40 loop1
brw------- 1 root root 7, 2 Sep 11 05:40 loop2
brw------- 1 root root 7, 3 Sep 11 05:40 loop3
brw------- 1 root root 7, 4 Sep 11 05:40 loop4
brw------- 1 root root 7, 5 Sep 11 05:40 loop5
brw------- 1 root root 7, 6 Sep 11 05:40 loop6
brw------- 1 root root 7, 7 Sep 11 05:40 loop7
brw------- 1 root root 179, 0 Sep 11 05:40 mmcblk0
brw------- 1 root root 179, 1 Sep 11 05:40 mmcblk0p1
brw------- 1 root root 179, 10 Sep 11 05:40 mmcblk0p10
brw------- 1 root root 179, 11 Sep 11 05:40 mmcblk0p11
brw------- 1 root root 179, 12 Sep 11 05:40 mmcblk0p12
brw------- 1 root root 179, 13 Sep 11 05:40 mmcblk0p13
brw------- 1 root root 179, 14 Sep 11 05:40 mmcblk0p14
brw------- 1 root root 179, 15 Sep 11 05:40 mmcblk0p15
brw------- 1 root root 179, 16 Sep 11 05:40 mmcblk0p16
brw------- 1 root root 179, 17 Sep 11 05:40 mmcblk0p17
brw------- 1 root root 179, 18 Sep 11 05:40 mmcblk0p18
brw------- 1 root root 179, 19 Sep 11 05:40 mmcblk0p19
brw------- 1 root root 179, 2 Sep 11 05:40 mmcblk0p2
brw------- 1 root root 179, 20 Sep 11 05:40 mmcblk0p20
brw------- 1 root root 179, 21 Sep 11 05:40 mmcblk0p21
brw------- 1 root root 179, 22 Sep 11 05:40 mmcblk0p22
brw------- 1 root root 179, 23 Sep 11 05:40 mmcblk0p23
brw------- 1 root root 179, 24 Sep 11 05:40 mmcblk0p24
brw------- 1 root root 179, 25 Sep 11 05:40 mmcblk0p25
brw------- 1 root root 179, 26 Sep 11 05:40 mmcblk0p26
brw------- 1 root root 179, 27 Sep 11 05:40 mmcblk0p27
brw------- 1 root root 179, 28 Sep 11 05:40 mmcblk0p28
brw------- 1 root root 179, 3 Sep 11 05:40 mmcblk0p3
brw------- 1 root root 179, 4 Sep 11 05:40 mmcblk0p4
brw------- 1 root root 179, 5 Sep 11 05:40 mmcblk0p5
brw------- 1 root root 179, 6 Sep 11 05:40 mmcblk0p6
brw------- 1 root root 179, 7 Sep 11 05:40 mmcblk0p7
brw------- 1 root root 179, 8 Sep 11 05:40 mmcblk0p8
brw------- 1 root root 179, 9 Sep 11 05:40 mmcblk0p9
brw------- 1 root root 179, 64 Sep 11 05:40 mmcblk1
brw------- 1 root root 179, 65 Sep 11 05:40 mmcblk1p1
drwxr-xr-x 4 root root 80 Sep 11 05:40 platform
/dev/block # fsck/?
fsck/?
/sbin/sh: fsck/?: not found
/dev/block # mount -a
mount -a
mount: mounting /recovery on emmc failed: No such file or directory
mount: mounting /boot on emmc failed: No such file or directory
mount: mounting /cache on ext4 failed: No such file or directory
mount: mounting /data on ext4 failed: No such file or directory
mount: mounting /sdcard on vfat failed: No such file or directory
mount: mounting /system on ext4 failed: No such file or directory
/dev/block #
Click to expand...
Click to collapse
anybody know why cant i mount?
Hopefully this thread might help you out.
http://forum.xda-developers.com/showthread.php?t=1150917
zeekiz said:
Hopefully this thread might help you out.
http://forum.xda-developers.com/showthread.php?t=1150917
Click to expand...
Click to collapse
it seems im getting the same error from this thread when mounting /data and /cache. so its burned emmc?
since its s-off i have no more warranty, how available is this emmc from cellphone repair shops?
btw, i didnt pulled out the battery when the phone started not to boot, i used the vol+ vol- and power button. only used the pull out battery when the vol+ vol- power wont work.
this problem started when i use rom manager to "automatically" install virtuosity, and didnt clean my cache and data. also might be market related cause i was downloading and installing a lot of market apps when the phone hanged.
BratPAQ said:
it seems im getting the same error from this thread when mounting /data and /cache. so its burned emmc?
since its s-off i have no more warranty, how available is this emmc from cellphone repair shops?
btw, i didnt pulled out the battery when the phone started not to boot, i used the vol+ vol- and power button. only used the pull out battery when the vol+ vol- power wont work.
this problem started when i use rom manager to "automatically" install virtuosity, and didnt clean my cache and data. also might be market related cause i was downloading and installing a lot of market apps when the phone hanged.
Click to expand...
Click to collapse
Sorry to hear of this, it does sound very like yet another fired eMMC chip and it sounds like you did two of the possible things that I've read can cause eMMC fried chip. one) Remove battery and two) multiple market download.
Not that it's important anymore, but, wiping CACHE and DALVIK CACHE should always be done on a new ROM install, wiping DATA is just sometimes recommend. But not doing so should not lead to a bricked device. It sounds very like the battery pull has done it again - which to my reckoning is a hardware/software design flaw and SHOULD be covered under warranty!
Surely its worth returning just trying to return the device under warranty just to see if they don't notice that you've S-OFF you may be lucky!
If you cannot get past the HTC logo, and the eMMC's are indeed fried... there's no real way for HTC to know you've S-OFF'd your phone.
As Ben stated above, given that it's the removal of the battery (which is a user-intended activity and is SUPPOSED to be safe), this should certainly be accepted under warranty (or whatever your country's version is of "Statutory Rights") anyway.
Send it in for replacement/repair! The worst that'll happen is HTC refuse to do anything with it, send it back to you (as legally required to do so) and you're out of pocket on some postage!
Since the phone is FUBAR anyway, you've got nothing more than postage cost to lose!
LaKraven said:
If you cannot get past the HTC logo, and the eMMC's are indeed fried... there's no real way for HTC to know you've S-OFF'd your phone.
As Ben stated above, given that it's the removal of the battery (which is a user-intended activity and is SUPPOSED to be safe), this should certainly be accepted under warranty (or whatever your country's version is of "Statutory Rights") anyway.
Send it in for replacement/repair! The worst that'll happen is HTC refuse to do anything with it, send it back to you (as legally required to do so) and you're out of pocket on some postage!
Since the phone is FUBAR anyway, you've got nothing more than postage cost to lose!
Click to expand...
Click to collapse
Mine had the same symptoms, and I sent it to technical service. But, HTC's technicians can enter in recovery mode and realize that the terminal is s-off, has happened with my terminal. If so, warranty is void.
Hey all, i accidentally formatted the partitions on the tf700. it was unlocked/rooted and i have TWRP installed.
i do not have access to fastboot. i can use adb and adb shell.
i have tried the options 1a & 1b for the prime tf201 unbrick with no luck.
in the terminal if i write the command "df" it shows that the only partition i have is TMPFS, and it is 499732 1K blocks - mounted on /dev
since the card is showing up as TMPFS it is basically a ramdisk and it will be erased on a reboot, so no matter what changes i make, or rom i install it will always be erased.
if i try to mount the /data /system /cache partitions they all return E:Unable to mount '/system' (tw_mount)
( '/system' changes with '/data' and '/cache')
if i go to /dev/block the only things i see are loop0 - loop7 and mmcblk0p3
im thinking that all i need to do is somehow format the internal memory to reinstall a rom and i should be good to go, but i dont know what the partitions need to be, but i could also be way off.
im hoping someone has some insight. i would hate to have a brick
pbcustom98 said:
Hey all, i accidentally formatted the partitions on the tf700. it was unlocked/rooted and i have TWRP installed.
Click to expand...
Click to collapse
How did you do that?
pbcustom98 said:
if i go to /dev/block the only things i see are loop0 - loop7 and mmcblk0p3
Click to expand...
Click to collapse
Looks like your GPT got damaged - this may not be easy to repair (AFAIK the original GPT is nowhere in the Asus firmware download), but as long as you can boot TWRP and use adb, there is hope.
First of all, what does "cat /proc/partitions" say? For comparison, here is my output:
Code:
# cat /proc/partitions
major minor #blocks name
179 0 62087168 mmcblk0
179 1 786432 mmcblk0p1
179 2 438272 mmcblk0p2
179 3 2048 mmcblk0p3
179 4 835584 mmcblk0p4
179 5 5120 mmcblk0p5
179 6 512 mmcblk0p6
179 7 5120 mmcblk0p7
179 8 59976192 mmcblk0p8
179 32 4096 mmcblk0boot1
179 16 4096 mmcblk0boot0
179 48 31166976 mmcblk1
179 49 31162880 mmcblk1p1
_that said:
How did you do that?
Looks like your GPT got damaged - this may not be easy to repair (AFAIK the original GPT is nowhere in the Asus firmware download), but as long as you can boot TWRP and use adb, there is hope.
First of all, what does "cat /proc/partitions" say? For comparison, here is my output:
Code:
# cat /proc/partitions
major minor #blocks name
179 0 62087168 mmcblk0
179 1 786432 mmcblk0p1
179 2 438272 mmcblk0p2
179 3 2048 mmcblk0p3
179 4 835584 mmcblk0p4
179 5 5120 mmcblk0p5
179 6 512 mmcblk0p6
179 7 5120 mmcblk0p7
179 8 59976192 mmcblk0p8
179 32 4096 mmcblk0boot1
179 16 4096 mmcblk0boot0
179 48 31166976 mmcblk1
179 49 31162880 mmcblk1p1
Click to expand...
Click to collapse
out of stupidity
cat /proc/partitions shows the following:
# cat /proc/partitions
major minor #blocks name
under it though, there is nothing there
pbcustom98 said:
out of stupidity
Click to expand...
Click to collapse
If you can describe what you did, maybe it is easier to find out what exactly happened.
I assume you don't have an nvflash backup, right?
pbcustom98 said:
under it though, there is nothing there
Click to expand...
Click to collapse
OK. What is the output if you run:
Code:
dmesg|grep mmcblk0
?
_that said:
If you can describe what you did, maybe it is easier to find out what exactly happened.
I assume you don't have an nvflash backup, right?
OK. What is the output if you run:
Code:
dmesg|grep mmcblk0
?
Click to expand...
Click to collapse
I was unlocking the tablet, installing TWRP and then wiping the data, i misread the options and went too far by doing the format data option.
no backup. i do not have access to fastboot/APX now, and i did not create one before.
C:\Users\Daniel>adb shell
~ # ←[6ndmesg|grep mmcblk0
dmesg|grep mmcblk0
~ # ←[6n^C
C:\Users\Daniel>
also, the only way i have seen to get the other mmcblk0 partitions to show up (0p3, 0p4 etc) is to run the commands for the tf201 unbrick (option 1a/b)
dd if=/dev/zero of=/dev/block/mmcblk0p4 bs=100 count=1
dd if=/dev/zero of=/dev/block/mmcblk0p3 bs=16 count=1
i was thinking that all i needed to do was to somehow format the data so the tablet can write to the partition instead of it just acting as a ramdisk. i even tried running fdisk -H 1 /dev/block/mmcblk0 and tried to format the data but i'm not familiar with the partition table of this tablet to redo it.
i have also tried doing those commands above and then running a live usb gparted disk to see if it shows up, but it hasnt worked yet
pbcustom98 said:
C:\Users\Daniel>adb shell
~ # ←[6ndmesg|grep mmcblk0
dmesg|grep mmcblk0
~ # ←[6n^C
C:\Users\Daniel>
Click to expand...
Click to collapse
Strange, it should at least output the line about detecting the card. Please reboot your tablet into recovery (to restart the kernel log), then do from your computer
Code:
adb shell dmesg > dmesg.txt
and put the resulting file on pastebin or attach it here.
pbcustom98 said:
I was unlocking the tablet, installing TWRP and then wiping the data, i misread the options and went too far by doing the format data option.
no backup. i do not have access to fastboot/APX now, and i did not create one before.
C:\Users\Daniel>adb shell
~ # ←[6ndmesg|grep mmcblk0
dmesg|grep mmcblk0
~ # ←[6n^C
C:\Users\Daniel>
also, the only way i have seen to get the other mmcblk0 partitions to show up (0p3, 0p4 etc) is to run the commands for the tf201 unbrick (option 1a/b)
dd if=/dev/zero of=/dev/block/mmcblk0p4 bs=100 count=1
dd if=/dev/zero of=/dev/block/mmcblk0p3 bs=16 count=1
i was thinking that all i needed to do was to somehow format the data so the tablet can write to the partition instead of it just acting as a ramdisk. i even tried running fdisk -H 1 /dev/block/mmcblk0 and tried to format the data but i'm not familiar with the partition table of this talet to redo it.
i have also tried doing those commands above and then running a live usb gparted disk to see if it shows up, but it hasnt worked yet
Click to expand...
Click to collapse
That's odd, format data will not and shouldn't do that. I did this all the time. Do you have the lastest TWRP and was on JB? if you do, go back to "WIPE" option and do the wipe format again. This should reformat with ext4. After that do factory reset, wipe system, internal storage then try to reflash Cleanrom. TWRP may some how corrupted your partition, but not what you did.
_that said:
Strange, it should at least output the line about detecting the card. Please reboot your tablet into recovery (to restart the kernel log), then do from your computer
Code:
adb shell dmesg > dmesg.txt
and put the resulting file on pastebin or attach it here.
Click to expand...
Click to collapse
i cannot post outside links until about 10 posts.
Here is the pastebin attachedView attachment dmesg.txt
pbcustom98 said:
also, the only way i have seen to get the other mmcblk0 partitions to show up (0p3, 0p4 etc) is to run the commands for the tf201 unbrick (option 1a/b)
dd if=/dev/zero of=/dev/block/mmcblk0p4 bs=100 count=1
dd if=/dev/zero of=/dev/block/mmcblk0p3 bs=16 count=1
Click to expand...
Click to collapse
If the partitions are not already there, then these commands simply create files that are named like the block devices that are missing. Not what you want at all, but harmless.
pbcustom98 said:
i was thinking that all i needed to do was to somehow format the data so the tablet can write to the partition instead of it just acting as a ramdisk. i even tried running fdisk -H 1 /dev/block/mmcblk0 and tried to format the data but i'm not familiar with the partition table of this tablet to redo it.
Click to expand...
Click to collapse
Do not try to to use fdisk, it does not support GPT.
pbcustom98 said:
i have also tried doing those commands above and then running a live usb gparted disk to see if it shows up, but it hasnt worked yet
Click to expand...
Click to collapse
How would you run a live disk on the tablet?
---------- Post added at 05:53 PM ---------- Previous post was at 05:46 PM ----------
pbcustom98 said:
i cannot post outside links until about 10 posts.
Here is the pastebin attachedView attachment 1456337
Click to expand...
Click to collapse
The important part is here:
Code:
<6>[ 9.067211] [mmc]:mmc_read_ext_csd:259 ext_csd.sectors 0x766c000 prod_name HYNIX BOOT_SIZE_MULTI 0x20
<4>[ 9.109988] mmc0: switch to bus width 1 ddr 0 failed
<3>[ 9.116163] mmc0: error -110 whilst initialising MMC card
The recovery kernel cannot initialize the MMC card. So there is no point in trying to run partitioning tools at this time, first you need to gain access to the eMMC. It cannot be completely broken, otherwise it could not boot the recovery.
Next step: find out what error -110 is and how to fix it.
btw, this thread seems to describe the same situation (read the post from MysticMgcn): http://forum.xda-developers.com/showthread.php?t=1917304
_that said:
If the partitions are not already there, then these commands simply create files that are named like the block devices that are missing. Not what you want at all, but harmless.
Do not try to to use fdisk, it does not support GPT.
How would you run a live disk on the tablet?
Click to expand...
Click to collapse
i ran gparted live usb on my laptop and tried connecting the tablet via usb after i had the partitions created.
pbcustom98 said:
i ran gparted live usb on my laptop and tried connecting the tablet via usb after i had the partitions created.
Click to expand...
Click to collapse
I still don't understand - where did you create those partitions? On your laptop?
Anyway, your TF700 is bricked until someone finds out how to make the TWRP kernel initialize the eMMC correctly in your situation. Without that, your internal storage is inaccessible, so any fix attempt at that level will fail.
Unfortunately there is still very little public information how the bootloader interacts with the kernels, so I cannot help you further. You may try asking in the thread I linked in my last post if anyone was able to recover from this.
_that said:
I still don't understand - where did you create those partitions? On your laptop?
Anyway, your TF700 is bricked until someone finds out how to make the TWRP kernel initialize the eMMC correctly in your situation. Without that, your internal storage is inaccessible, so any fix attempt at that level will fail.
Unfortunately there is still very little public information how the bootloader interacts with the kernels, so I cannot help you further. You may try asking in the thread I linked in my last post if anyone was able to recover from this.
Click to expand...
Click to collapse
i ran these two commands via adb shell:
dd if=/dev/zero of=/dev/block/mmcblk0p4 bs=100 count=1
dd if=/dev/zero of=/dev/block/mmcblk0p3 bs=16 count=1
then once i saw them in /dev/block, i rebooted my laptop into gparted hoping that they would show up as a partition i can make changes to, but they didnt.
i will ask in the thread you linked, and thanks for all your help.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
TWRP 3.1.x - Based upon Android 7.1 :
* Whole new TWRP 3 interface
* Flashable to FOTA for permanent recovery
* Bootable recovery image if required
OFFICIAL DOWNLOADS FOR TAOSHAN :
https://twrp.me/sony/sonyxperial.html
twrp-3.x.x-x-taoshan.img : Official TWRP image
How to install : All informations available on TWRP.me
You can download the recovery via Official TWRP App as well :
https://play.google.com/store/apps/details?id=me.twrp.twrpapp&hl=en
DEVELOPMENT DOWNLOADS FOR TAOSHAN :
https://mega.nz/#F!vYwXRRRa!PQgFIpUqjEjJoHVkwTWe0w
twrp-3.x.x-x-fota-taoshan.zip : Flashable TWRP 3 to FOTA installer [Flash this zip if you already have older TWRP installed]
twrp-3.x.x-x-boot-taoshan.img : Fastboot bootable TWRP 3 image
twrp-3.x.x-x-secondary-multirom-taoshan.zip : As secondary MultiROM (optional)
cleaner-fota-taoshan.zip : Flashable FOTA formatter (optional)
HOW TO INSTALL EASILY TO FOTA :
* Boot to recovery : Enter the existing recovery as usual
* Flash to FOTA : Install the TWRP FOTA zip to upgrade to latest TWRP
* (Optional) : Flash the ROM you want
HOW TO INSTALL MANUALLY TO FOTA :
* Bootimage : Download the TWRP bootimage you want to flash
* File storage : Adapt the path and push the file to the device this way :
Code:
adb root
adb wait-for-device
adb push FullPathToTheRecovery.img /tmp/twrp.img
* Flash : Extract the TWRP image to the FOTA partition
Code:
adb shell dd if=/tmp/twrp.img of=/dev/block/platform/msm_sdcc.1/by-name/FOTAKernel
* Reboot to recovery : adb reboot recovery
INFORMATIONS ABOUT TWRP 3 :
* Installation : Simply flash the zip with a working TWRP or CyanogenRecovery
* Known issues : No major issue remaining, but sources open to improvements
* Usage : Built for Nougat, works for Marshmallow, Lollipop based ROMs too
* More here : http://www.xda-developers.com/twrp-3-0-0-has-arrived/
ADDITIONAL LINKS :
* Easy ADB and Fastboot for unexperienced users :
http://forum.xda-developers.com/showthread.php?p=48915118
Thanks to @AdrianDC for big help in bring-up and thread template
Thanks to the TWRP Team for sources
Current local manifest of the TWRP build
Code:
<?xml version="1.0" encoding="UTF-8"?>
<!-- https://github.com/STRYDER-007/twrp_development_sony -->
XDA:DevDB Information
[Recovery][OFFICIAL][UBL] TWRP 3.1.1 Touch Recovery for Xperia L, Tool/Utility for the Sony Xperia L
Contributors
STRYDER~007
Version Information
Status: Stable
Created 2017-10-02
Last Updated 2017-10-05
Nice work, but where can I download the zip file. Ready for testing. But I mis the link.
Btw nice work.
I was to early. They are here now
paul.coster said:
Nice work, but where can I download the zip file. Ready for testing. But I mis the link.
Btw nice work.
I was to early. They are here now
Click to expand...
Click to collapse
The link is up! Enjoy!
Is it just me, or does this recovery not work? Holding volUp to enter the recovery just turns the screen black; the screen flashes between the sony logo and the said black screen after that, and I have to remove the battery to get the phone working again.
I used both your method of installation, as well as mine, and none of them worked. The older official TWRP recovery (3.0.2-0) works just fine, though.
stuckbootloader said:
Is it just me, or does this recovery not work? Holding volUp to enter the recovery just turns the screen black; the screen flashes between the sony logo and the said black screen after that, and I have to remove the battery to get the phone working again.
I used both your method of installation, as well as mine, and none of them worked. The older official TWRP recovery (3.0.2-0) works just fine, though.
Click to expand...
Click to collapse
Can you mention the steps you performed as well as the scenario in which you're trying to flash it?
Btw you can simply flash twrp-3.x.x-x-fota-taoshan.zip from existing recovery to upgrade TWRP.
STRYDER~007 said:
Can you mention the steps you performed as well as the scenario in which you're trying to flash it?
Btw you can simply flash twrp-3.x.x-x-fota-taoshan.zip from existing recovery to upgrade TWRP.
Click to expand...
Click to collapse
Sorry for the late reply.
I transferred the twrp.img file to the root of the SD card, and ran this command through adb shell
dd if=/storage/36BD-1A02/twrp.img of=/dev/block/platform/msm_sdcc.1/by-name/FOTAKernel.
That worked with the older releases.
I also tried the commands in the description (pushing twrp.img /tmp/ and then moving it to FOTAKernel), and there was no difference.
Weirdly enough, flashing the .zip worked.
stuckbootloader said:
Sorry for the late reply.
I transferred the twrp.img file to the root of the SD card, and ran this command through adb shell
dd if=/storage/36BD-1A02/twrp.img of=/dev/block/platform/msm_sdcc.1/by-name/FOTAKernel.
That worked with the older releases.
I also tried the commands in the description (pushing twrp.img /tmp/ and then moving it to FOTAKernel), and there was no difference.
Weirdly enough, flashing the .zip worked.
Click to expand...
Click to collapse
Well there you go! IMO flashing zip to upgrade TWRP is the simplest so I'd always prefer that. Enjoy the new recovery! :highfive:
STRYDER~007 said:
Can you mention the steps you performed as well as the scenario in which you're trying to flash it?
Btw you can simply flash twrp-3.x.x-x-fota-taoshan.zip from existing recovery to upgrade TWRP.
Click to expand...
Click to collapse
Hi,
I have the same issue, on a Xperia L (white, C2105), tried with two possibilities now, using recovery image twrp.3.1.1-0-taoshan.img, two methods:
1) flashing via existing TWRP recovery (v 2.8.7.0): according to your description I selected install, image, with the aforementioned TWRP recovery image.
2) using the recovery installer app from corphish/StdBarbarossa (version 1.4 - dated 18 May 2016): selecting the menu option to install a custom recovery, to install the aforementioned TWRP recovery image.
Please note that the same recovery installer app from corphish/StdBarbarossa works perfectly to install the TWRP 2.8.7.0.
Therefore I would suggest that the latest TWRP image might need to be reviewed for side-effects by implemented changes. I will try with older versions, to identify if it works with older versions.
Please let me know in case you need any further details, either of the device or of the steps that I performed.
Cheers, Henning
---------- Post added at 10:39 PM ---------- Previous post was at 10:30 PM ----------
xleng said:
Hi,
I have the same issue, on a Xperia L (white, C2105), tried with two possibilities now, using recovery image twrp.3.1.1-0-taoshan.img, two methods:
1) flashing via existing TWRP recovery (v 2.8.7.0): according to your description I selected install, image, with the aforementioned TWRP recovery image.
2) using the recovery installer app from corphish/StdBarbarossa (version 1.4 - dated 18 May 2016): selecting the menu option to install a custom recovery, to install the aforementioned TWRP recovery image.
Please note that the same recovery installer app from corphish/StdBarbarossa works perfectly to install the TWRP 2.8.7.0.
Therefore I would suggest that the latest TWRP image might need to be reviewed for side-effects by implemented changes. I will try with older versions, to identify if it works with older versions.
Please let me know in case you need any further details, either of the device or of the steps that I performed.
Cheers, Henning
Click to expand...
Click to collapse
OK
Using the method to install TWRP v3 via the existing TWRP recovery version 2.8.7.0 (actually I'm not quite sure about the version, since the splash screen reported version 2.8.7.2, but the main application header reports 2.8.7.0, probably the latter version number was just not updated), finally was SUCCESSFUL with twrp-3.0.2-0-taoshan.img!
I didn't try the earlier ones, since I identified a TWRP version which should be functional.
I think probably something went wrong with the most recent update!?
Please let me know in case I could support troubleshooting somehow.
I have actually two Xperia L's, one as my primary smartphone, the second as spare, which I typically use to try out new things prior to messing around with the primary one.
Cheers
---------- Post added at 10:50 PM ---------- Previous post was at 10:39 PM ----------
STRYDER~007 said:
Well there you go! IMO flashing zip to upgrade TWRP is the simplest so I'd always prefer that. Enjoy the new recovery! :highfive:
Click to expand...
Click to collapse
Just noted that I should have read the thread more carefully first .... *doh*
Actually, where can I get the zip file? I only could download the img from the TWRP website.
Eventually I would also be interested to take a look to the sources, if possible (just out of curiosity).
Thanks in advance!
---------- Post added at 11:15 PM ---------- Previous post was at 10:50 PM ----------
xleng said:
Hi,
I have the same issue, on a Xperia L (white, C2105), tried with two possibilities now, using recovery image twrp.3.1.1-0-taoshan.img, two methods:
1) flashing via existing TWRP recovery (v 2.8.7.0): according to your description I selected install, image, with the aforementioned TWRP recovery image.
2) using the recovery installer app from corphish/StdBarbarossa (version 1.4 - dated 18 May 2016): selecting the menu option to install a custom recovery, to install the aforementioned TWRP recovery image.
Please note that the same recovery installer app from corphish/StdBarbarossa works perfectly to install the TWRP 2.8.7.0.
Therefore I would suggest that the latest TWRP image might need to be reviewed for side-effects by implemented changes. I will try with older versions, to identify if it works with older versions.
Please let me know in case you need any further details, either of the device or of the steps that I performed.
Cheers, Henning
---------- Post added at 10:39 PM ---------- Previous post was at 10:30 PM ----------
OK
Using the method to install TWRP v3 via the existing TWRP recovery version 2.8.7.0 (actually I'm not quite sure about the version, since the splash screen reported version 2.8.7.2, but the main application header reports 2.8.7.0, probably the latter version number was just not updated), finally was SUCCESSFUL with twrp-3.0.2-0-taoshan.img!
I didn't try the earlier ones, since I identified a TWRP version which should be functional.
I think probably something went wrong with the most recent update!?
Please let me know in case I could support troubleshooting somehow.
I have actually two Xperia L's, one as my primary smartphone, the second as spare, which I typically use to try out new things prior to messing around with the primary one.
Cheers
---------- Post added at 10:50 PM ---------- Previous post was at 10:39 PM ----------
Just noted that I should have read the thread more carefully first .... *doh*
Actually, where can I get the zip file? I only could download the img from the TWRP website.
Eventually I would also be interested to take a look to the sources, if possible (just out of curiosity).
Thanks in advance!
Click to expand...
Click to collapse
I found the zip file now. But actually it didn't work either.
I extracted the twrp.img from the twrp-3.1.1-20171005-fota-taoshan.zip.
Then I applied the following commands :
adb root
adb push twrp.img /tmp/twrp.img
adb shell dd if=/tmp/twrp.img of=/dev/block/platform/msm_sdcc.1/by-name/FOTAKernel
The result is a boot loop, looping between the SONY logo and a black screen.
Afterwards I successfully installed back TWRP-3.0.2-0 using the recovery installer app from corphish.
Cheers
xleng said:
The result is a boot loop, looping between the SONY logo and a black screen.
Afterwards I successfully installed back TWRP-3.0.2-0 using the recovery installer app from corphish.
Cheers
Click to expand...
Click to collapse
Flash that .zip through the 3.0.2-0 recovery now, it ought to work. I had the same flashing issue. Both the app and the .zip should work now, so it doesn't really matter which method you use.
xleng said:
Hi,
I have the same issue, on a Xperia L (white, C2105), tried with two possibilities now, using recovery image twrp.3.1.1-0-taoshan.img, two methods:
1) flashing via existing TWRP recovery (v 2.8.7.0): according to your description I selected install, image, with the aforementioned TWRP recovery image.
2) using the recovery installer app from corphish/StdBarbarossa (version 1.4 - dated 18 May 2016): selecting the menu option to install a custom recovery, to install the aforementioned TWRP recovery image.
Please note that the same recovery installer app from corphish/StdBarbarossa works perfectly to install the TWRP 2.8.7.0.
Therefore I would suggest that the latest TWRP image might need to be reviewed for side-effects by implemented changes. I will try with older versions, to identify if it works with older versions.
Please let me know in case you need any further details, either of the device or of the steps that I performed.
Cheers, Henning
---------- Post added at 10:39 PM ---------- Previous post was at 10:30 PM ----------
OK
Using the method to install TWRP v3 via the existing TWRP recovery version 2.8.7.0 (actually I'm not quite sure about the version, since the splash screen reported version 2.8.7.2, but the main application header reports 2.8.7.0, probably the latter version number was just not updated), finally was SUCCESSFUL with twrp-3.0.2-0-taoshan.img!
I didn't try the earlier ones, since I identified a TWRP version which should be functional.
I think probably something went wrong with the most recent update!?
Please let me know in case I could support troubleshooting somehow.
I have actually two Xperia L's, one as my primary smartphone, the second as spare, which I typically use to try out new things prior to messing around with the primary one.
Cheers
---------- Post added at 10:50 PM ---------- Previous post was at 10:39 PM ----------
Just noted that I should have read the thread more carefully first .... *doh*
Actually, where can I get the zip file? I only could download the img from the TWRP website.
Eventually I would also be interested to take a look to the sources, if possible (just out of curiosity).
Thanks in advance!
---------- Post added at 11:15 PM ---------- Previous post was at 10:50 PM ----------
I found the zip file now. But actually it didn't work either.
I extracted the twrp.img from the twrp-3.1.1-20171005-fota-taoshan.zip.
Then I applied the following commands :
adb root
adb push twrp.img /tmp/twrp.img
adb shell dd if=/tmp/twrp.img of=/dev/block/platform/msm_sdcc.1/by-name/FOTAKernel
The result is a boot loop, looping between the SONY logo and a black screen.
Afterwards I successfully installed back TWRP-3.0.2-0 using the recovery installer app from corphish.
Cheers
Click to expand...
Click to collapse
You can use official TWRP app from play store OR simply flash the twrp-3.1.1-DATE-fota-taoshan.zip using any existing recovery from HERE. That's all, simple!
stuckbootloader said:
Flash that .zip through the 3.0.2-0 recovery now, it ought to work. I had the same flashing issue. Both the app and the .zip should work now, so it doesn't really matter which method you use.
Click to expand...
Click to collapse
Hi!
Unfortunately it doesn't work for me.
I tried to flash the zip via the recovery, but ended in another boot loop after reboot with attempt to enter the recovery again.
Sent from my Xperia L using XDA-Developers Legacy app
Hi again,
I just installed the official twrp app (version 1.15, build 28) and tried to flash the twrp image 3.1.1-0.
Twrp reported successful flashing, butafter reboot the recovery was not entered, but instead I had a bootloop again.
Prior to flashing, I did a backup of the existing recovery (containing twrp-3.0.2), after re-flashing the recovery backup resulted in a functional installation of twrp3.0.2 again.
Any recommendation? I'm using the XperiaL, C2105, white version.
The device actually was returned from Sony, eg was shipped without any provider branding, because the initial phone (which did have provider branding) had issues with the camera, which therefore has been sent to Sony within the guarantee period. Sony however did not repair the phone, but rather sent back a new and original Sony device.
In case any other information might be of interest, please let me know.
Would be great to be able to install twrp3.1.1 + LineageOS 14.1!
Actually it's not clear to me if LOS14.1 could be flashed with twrp3.0.2, since errors have been reported?
Sent from my Xperia L using XDA-Developers Legacy app
xleng said:
Actually it's not clear to me if LOS14.1 could be flashed with twrp3.0.2, since errors have been reported?
Click to expand...
Click to collapse
I am not sure about your device, in my Xperia M, I use lineage 14.1 with twrp 3.0.2 with no problems. Even I tried cwm recovery, there was no problem again. So yeah you can try it.
xleng said:
Hi!
Unfortunately it doesn't work for me.
I tried to flash the zip via the recovery, but ended in another boot loop after reboot with attempt to enter the recovery again.
Sent from my Xperia L using XDA-Developers Legacy app
Click to expand...
Click to collapse
Make sure you're following the steps properly.
xleng said:
Hi again,
I just installed the official twrp app (version 1.15, build 28) and tried to flash the twrp image 3.1.1-0.
Twrp reported successful flashing, butafter reboot the recovery was not entered, but instead I had a bootloop again.
Prior to flashing, I did a backup of the existing recovery (containing twrp-3.0.2), after re-flashing the recovery backup resulted in a functional installation of twrp3.0.2 again.
Any recommendation? I'm using the XperiaL, C2105, white version.
The device actually was returned from Sony, eg was shipped without any provider branding, because the initial phone (which did have provider branding) had issues with the camera, which therefore has been sent to Sony within the guarantee period. Sony however did not repair the phone, but rather sent back a new and original Sony device.
In case any other information might be of interest, please let me know.
Would be great to be able to install twrp3.1.1 + LineageOS 14.1!
Actually it's not clear to me if LOS14.1 could be flashed with twrp3.0.2, since errors have been reported?
Sent from my Xperia L using XDA-Developers Legacy app
Click to expand...
Click to collapse
If you have working TWRP 3.0.2, you can simply flash the twrp-3.1.1-20171005-fota-taoshan.zip from HERE.
Hi again,
I try now another attempt. I take the "twrp-3.1.1-20171005-fota-taoshan.zip", saved in the SD card of the phone, which contains two items:
- folder "META-INF"
- file "twrp.img"
Using TWRP, version 3.0.2-0:
1) Menu Install
2) Select Storage -> Micro SDCard
3) Select twrp-3.1.1-20171005-fota-taoshan.zip
4) Swipe to confirm Flash
5) Adrian DC - TWRP Installer reports the following : "Flashing TWRP Recovery to FOTA... Done. Update Completed. script succeeded: result was [1.000000]; Update partition details...done"
6) Reboot system
7) Hit the vol-up during boot (especially during SONY logo)
8) Boot loop is entered.
I don't think that I have missed anything, did I?
Sorry to be a pain ....
xleng said:
Hi again,
I try now another attempt. I take the "twrp-3.1.1-20171005-fota-taoshan.zip", saved in the SD card of the phone, which contains two items:
- folder "META-INF"
- file "twrp.img"
Using TWRP, version 3.0.2-0:
1) Menu Install
2) Select Storage -> Micro SDCard
3) Select twrp-3.1.1-20171005-fota-taoshan.zip
4) Swipe to confirm Flash
5) Adrian DC - TWRP Installer reports the following : "Flashing TWRP Recovery to FOTA... Done. Update Completed. script succeeded: result was [1.000000]; Update partition details...done"
6) Reboot system
7) Hit the vol-up during boot (especially during SONY logo)
8) Boot loop is entered.
I don't think that I have missed anything, did I?
Sorry to be a pain ....
Click to expand...
Click to collapse
When you flash the zip, recovery log is generated. Can you give me that log? You can find it in "Advanced" tab.
If I read the log correctly, the dd command fails, because the ZIP is by 1 record too long for the partition.
At least the input record count is different than the output record count, which is strange.
I'm just thinking aloud if there could be a dependency with the host Maschine (at least with the ZIP file), so that the bit pattern might slightly differ due to differences in the file system types?
I believe this is the relevant part oft the log, though I can also send the complete log by PM:
==============================
==============================
| Adrian DC - TWRP Installer |
| Adrian DC - TWRP Installer |
==============================
==============================
- Flashing TWRP Recovery to FOTA...
- Flashing TWRP Recovery to FOTA...
about to run program [/sbin/dd] with 3 args
dd: writing '/dev/block/platform/msm_sdcc.1/by-name/FOTAKernel': No space left on device
32769+0 records in
32768+0 records out
16777216 bytes (16.0MB) copied, 2.417855 seconds, 6.6MB/s
run_program: child exited with status 1
Done.
Done.
Update Completed.
Update Completed.
script succeeded: result was [1.000000]I:Updater process ended with RC=0
I:Legacy property environment disabled.
Updating partition details...
...done
I:Set page: 'flash_done'
Iperation_end - status=0
I:Set page: 'clear_vars'
I:Set page: 'install'
I:Set page: 'main'
I:Set page: 'clear_vars'
I:Set page: 'main2'
I:Set page: 'advanced'
I:Set page: 'confirm_action'
I:Set page: 'action_page'
Iperation_start: 'Copy Log'
I:Copying file /tmp/recovery.log to /external_sd/recovery.log
xleng said:
If I read the log correctly, the dd command fails, because the ZIP is by 1 record too long for the partition.
At least the input record count is different than the output record count, which is strange.
I'm just thinking aloud if there could be a dependency with the host Maschine (at least with the ZIP file), so that the bit pattern might slightly differ due to differences in the file system types?
I believe this is the relevant part oft the log, though I can also send the complete log by PM:
==============================
==============================
| Adrian DC - TWRP Installer |
| Adrian DC - TWRP Installer |
==============================
==============================
- Flashing TWRP Recovery to FOTA...
- Flashing TWRP Recovery to FOTA...
about to run program [/sbin/dd] with 3 args
dd: writing '/dev/block/platform/msm_sdcc.1/by-name/FOTAKernel': No space left on device
32769+0 records in
32768+0 records out
16777216 bytes (16.0MB) copied, 2.417855 seconds, 6.6MB/s
run_program: child exited with status 1
Done.
Done.
Update Completed.
Update Completed.
script succeeded: result was [1.000000]I:Updater process ended with RC=0
I:Legacy property environment disabled.
Updating partition details...
...done
I:Set page: 'flash_done'
Iperation_end - status=0
I:Set page: 'clear_vars'
I:Set page: 'install'
I:Set page: 'main'
I:Set page: 'clear_vars'
I:Set page: 'main2'
I:Set page: 'advanced'
I:Set page: 'confirm_action'
I:Set page: 'action_page'
Iperation_start: 'Copy Log'
I:Copying file /tmp/recovery.log to /external_sd/recovery.log
Click to expand...
Click to collapse
Hi,
Thanks for the logs.
Something is not right here..
PHP:
16777216 bytes (16.0MB) copied, 2.417855 seconds, 6.6MB/s
Why 16 MB is getting copied while the recovery size is just 11.5-12 MB? This doesn't seem right.
If possible, can you run these command in device terminal? I need the output of these-
Code:
cat /proc/partitions
Code:
ls -al /dev/block/platform/msm_sdcc.1/by-name
You can upload the output on hastebin.com
Thanks and regards,
STRYDER~007
cat /proc/partitions:
[email protected]:/ # cat /proc/partitions
major minor #blocks name
254 0 262144 zram0
179 0 7634944 mmcblk0
179 1 2048 mmcblk0p1
179 2 256 mmcblk0p2
179 3 512 mmcblk0p3
179 4 512 mmcblk0p4
179 5 1024 mmcblk0p5
179 6 1024 mmcblk0p6
179 7 1024 mmcblk0p7
179 8 256 mmcblk0p8
179 9 512 mmcblk0p9
179 10 512 mmcblk0p10
179 11 1024 mmcblk0p11
179 12 1024 mmcblk0p12
179 13 1024 mmcblk0p13
179 14 1024 mmcblk0p14
179 15 1024 mmcblk0p15
179 16 3456 mmcblk0p16
179 17 16384 mmcblk0p17
179 18 8192 mmcblk0p18
179 19 8192 mmcblk0p19
179 20 16384 mmcblk0p20
179 21 8192 mmcblk0p21
179 22 8192 mmcblk0p22
179 23 65536 mmcblk0p23
179 24 19456 mmcblk0p24
179 25 5120 mmcblk0p25
179 26 8192 mmcblk0p26
179 27 16384 mmcblk0p27
179 28 1228800 mmcblk0p28
179 29 65536 mmcblk0p29
179 30 262144 mmcblk0p30
179 31 1671168 mmcblk0p31
179 32 4210671 mmcblk0p32
179 64 31472640 mmcblk1
179 65 31471616 mmcblk1p1
ls -al /dev/block/platform/msm_sdcc.1/by-name:
[email protected]:/ # ls -al /dev/block/platform/msm_sdcc.1/by-name
total 0
drwxr-xr-x 2 system root 680 2017-11-12 00:46 .
drwxr-xr-x 4 root root 740 2017-11-12 00:46 ..
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 FOTAKernel -> /dev/block/mmcblk0p27
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 LTALabel -> /dev/block/mmcblk0p20
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 TA -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 aboot -> /dev/block/mmcblk0p6
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 alt_aboot -> /dev/block/mmcblk0p12
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 alt_rpm -> /dev/block/mmcblk0p15
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 alt_s1sbl2 -> /dev/block/mmcblk0p10
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 alt_sbl1 -> /dev/block/mmcblk0p8
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 alt_sbl2 -> /dev/block/mmcblk0p9
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 alt_sbl3 -> /dev/block/mmcblk0p11
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 alt_tz -> /dev/block/mmcblk0p13
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 apps_log -> /dev/block/mmcblk0p26
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 boot -> /dev/block/mmcblk0p24
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 cache -> /dev/block/mmcblk0p30
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 fsg -> /dev/block/mmcblk0p19
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 ftma -> /dev/block/mmcblk0p29
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 ftmd -> /dev/block/mmcblk0p18
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 modem -> /dev/block/mmcblk0p23
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 modemst1 -> /dev/block/mmcblk0p21
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 modemst2 -> /dev/block/mmcblk0p22
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 persist -> /dev/block/mmcblk0p17
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 ramdump -> /dev/block/mmcblk0p25
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 rpm -> /dev/block/mmcblk0p14
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 rsv -> /dev/block/mmcblk0p16
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 s1sbl2 -> /dev/block/mmcblk0p4
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 sbl1 -> /dev/block/mmcblk0p2
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 sbl2 -> /dev/block/mmcblk0p3
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 sbl3 -> /dev/block/mmcblk0p5
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 sdcard -> /dev/block/mmcblk0p32
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 system -> /dev/block/mmcblk0p28
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 tz -> /dev/block/mmcblk0p7
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 userdata -> /dev/block/mmcblk0p31
I think the partition layout is normal. I did not previously try any modifications to the partition scheme, e.g. as suggested by some "hacks" to provide more storage to user data. I consider these as high risk (also many hard bricks have ben reported), and modify "only" the recovery and ROM area.
Best regards
xleng said:
cat /proc/partitions:
[email protected]:/ # cat /proc/partitions
major minor #blocks name
254 0 262144 zram0
179 0 7634944 mmcblk0
179 1 2048 mmcblk0p1
179 2 256 mmcblk0p2
179 3 512 mmcblk0p3
179 4 512 mmcblk0p4
179 5 1024 mmcblk0p5
179 6 1024 mmcblk0p6
179 7 1024 mmcblk0p7
179 8 256 mmcblk0p8
179 9 512 mmcblk0p9
179 10 512 mmcblk0p10
179 11 1024 mmcblk0p11
179 12 1024 mmcblk0p12
179 13 1024 mmcblk0p13
179 14 1024 mmcblk0p14
179 15 1024 mmcblk0p15
179 16 3456 mmcblk0p16
179 17 16384 mmcblk0p17
179 18 8192 mmcblk0p18
179 19 8192 mmcblk0p19
179 20 16384 mmcblk0p20
179 21 8192 mmcblk0p21
179 22 8192 mmcblk0p22
179 23 65536 mmcblk0p23
179 24 19456 mmcblk0p24
179 25 5120 mmcblk0p25
179 26 8192 mmcblk0p26
179 27 16384 mmcblk0p27
179 28 1228800 mmcblk0p28
179 29 65536 mmcblk0p29
179 30 262144 mmcblk0p30
179 31 1671168 mmcblk0p31
179 32 4210671 mmcblk0p32
179 64 31472640 mmcblk1
179 65 31471616 mmcblk1p1
ls -al /dev/block/platform/msm_sdcc.1/by-name:
[email protected]:/ # ls -al /dev/block/platform/msm_sdcc.1/by-name
total 0
drwxr-xr-x 2 system root 680 2017-11-12 00:46 .
drwxr-xr-x 4 root root 740 2017-11-12 00:46 ..
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 FOTAKernel -> /dev/block/mmcblk0p27
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 LTALabel -> /dev/block/mmcblk0p20
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 TA -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 aboot -> /dev/block/mmcblk0p6
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 alt_aboot -> /dev/block/mmcblk0p12
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 alt_rpm -> /dev/block/mmcblk0p15
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 alt_s1sbl2 -> /dev/block/mmcblk0p10
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 alt_sbl1 -> /dev/block/mmcblk0p8
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 alt_sbl2 -> /dev/block/mmcblk0p9
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 alt_sbl3 -> /dev/block/mmcblk0p11
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 alt_tz -> /dev/block/mmcblk0p13
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 apps_log -> /dev/block/mmcblk0p26
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 boot -> /dev/block/mmcblk0p24
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 cache -> /dev/block/mmcblk0p30
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 fsg -> /dev/block/mmcblk0p19
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 ftma -> /dev/block/mmcblk0p29
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 ftmd -> /dev/block/mmcblk0p18
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 modem -> /dev/block/mmcblk0p23
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 modemst1 -> /dev/block/mmcblk0p21
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 modemst2 -> /dev/block/mmcblk0p22
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 persist -> /dev/block/mmcblk0p17
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 ramdump -> /dev/block/mmcblk0p25
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 rpm -> /dev/block/mmcblk0p14
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 rsv -> /dev/block/mmcblk0p16
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 s1sbl2 -> /dev/block/mmcblk0p4
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 sbl1 -> /dev/block/mmcblk0p2
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 sbl2 -> /dev/block/mmcblk0p3
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 sbl3 -> /dev/block/mmcblk0p5
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 sdcard -> /dev/block/mmcblk0p32
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 system -> /dev/block/mmcblk0p28
lrwxrwxrwx 1 root root 20 2017-11-12 00:46 tz -> /dev/block/mmcblk0p7
lrwxrwxrwx 1 root root 21 2017-11-12 00:46 userdata -> /dev/block/mmcblk0p31
I think the partition layout is normal. I did not previously try any modifications to the partition scheme, e.g. as suggested by some "hacks" to provide more storage to user data. I consider these as high risk (also many hard bricks have ben reported), and modify "only" the recovery and ROM area.
Best regards
Click to expand...
Click to collapse
Yes I was suspicious about that. It seems partitions are all fine. Okay, one last thing, can you follow these steps mentioned on official TWRP site and see if recovery installs properly?
https://dl.twrp.me/taoshan/twrp-3.1.1-0-taoshan.img.html
dd Install Method (Requires Root):
Download the latest image file (.img) from the download link above. Place it in the root of your /sdcard folder and rename it to twrp.img. Run the following commands via adb shell or a terminal emulator app:
su
dd if=/sdcard/twrp.img of=/dev/block/platform/msm_sdcc.1/by-name/FOTAKernel
Click to expand...
Click to collapse
Update - March 23rd, 2019.
There is now an excellent offline rooting method for HD10 (2017), HD8(2016-2018), all current FireOS versions, thanks to the fantastic effort by @diplomatic - link. This new root is obtained within a few seconds, so it is very fast. To install permanent root after mtk-su for HD10 (2017), HD8 (2016-2017), use the scripts by @Rortiz2 in here: v2.1, or v1.0 (see this link for a Linux script). For HD8 (2018), there is a dedicated full bootloader unlocking and permanent root guide - link. For HD10 (2017) there is also a full bootloader unlocking procedure available - link. The historical Kingoroot rooting procedure for HD10 (2017) is below. As a friendly reminder, once you have a root shell (obtained by any means), ensure that you disable OTA updates as to avoid getting an unrootable update (except for HD8 (2018) - do not run the commands below before you unlock the bootloader!!!):
Code:
mount -w -o remount /system
mv /system/priv-app/DeviceSoftwareOTA/DeviceSoftwareOTA.apk /system/priv-app/DeviceSoftwareOTA/DeviceSoftwareOTA.apk_
ls -l /system/priv-app/DeviceSoftwareOTA/
The original Kingoroot method for HD10 (2017), all current FireOS versions - EASY SuperSu
Update v0.9, 12/29/18 As empasized by shonkin in this post, the method still works for FireOS 5.6.3.4. Enjoy!!! I would never have expected the hole to last his long ...
Update v0.8, 01/26/18 - as first reported by @najoor in this post, FireOS 5.6.0.1 is rootable! Today I verified this myself after a somewhat unsuccessful FlashFire update.
Update v0.7, 01/14/18 - @freaky2xd made a video with these rooting instructions, please follow it if you prefer a visual guide (here or here)
Update v0.6, 01/09/18 - there were reports that dr.fone app seems to be able to root the device as well. I took dr.fone for a spin, and based on its bloatedness and a few other annoying features, my personal recommendation is that you stick with the devil we know - Kingoroot (link)
Update v0.5, 01/04/18 - add a DOS bat file to remove any possible updates to Amazon packages
Update v0.4, 01/02/18 - title update
Update v0.3, 12/31/17 - light clean up; I got into a bootloop, and had to sideload a stock ROM & re-root - a.k.a. "eat my own dogfood" - Everything works fine.
Update v0.2, 12/30/17 - some redundant commands are removed.
Update v0.1, 12/30/17 - the rooting procedure is essentially taken from @retyre (here and here). Except, the instructions below include a lot of details, and handle mostly everything from the PC/ADB side. Try, and report back. GOOD LUCK!
Here is the guide to the painless root (while out of the box FireOS allows it; right now all FireOS versions up to and including 5.6.0.1 - the current OTA - are rootable). The key enabler is the original post by @ztrund (link), great work blazing the trail (and motivating me to get another Fire tablet ASAP, LOL).
Given that the devices will be shipping with the (older) rootable FireOS for the next few months (but beware of the upcoming updates - see below !!!), there is a good window of opportunity to acquire a rootable Fire HD 10, and root it. As of Dec 27th 2017, there are no reports yet of non-rootable OTAs, but those OTAs will be coming soon, count on it!
The utmost goal here is to preserve the earliest FireOS version that you get, and not let it get updated by Amazon on a whim.
I am starting with a recently bought Fire HD 10 2017 (light refurb from eBay, missed the Black Friday mega sale ). I have FireOS 5.5.0.0 (earlier than 5.6.0.0!), version name 5.3.5.1 (591450020)
Part I (avoiding Amazon updating procedure upon the initial Fire setup) - this can (almost safely) be skipped today (end of Dec, 2017), since there are no reports of unrootable OTAs yet
Low tech way (thanks to @Blaiser47 and @retyre for suggestions!):
Unpack Fire HD 10, turn it on, it will immediately demand a WiFi access
Choose any option on that WiFi screen, press cancel, and then skip
Once Alexa shows up, swipe down from the top, turn on Airplane mode just to be sure
High tech way:
Set up a dedicated slow router, limit upload/download speed to ~25 kbps (this is the trickiest part, I have a dedicated Tomato router which I use to control traffic)
Unpack Fire HD 10, turn it on, it will immediately demand a WiFi access
Connect Fire to your slow router
Once Fire finds Internet, it'll immediately have "Checking for updates" on the screen, this is where the slow router should kick in, and do the trick of forcing the update to give up
Wait a bit for updates, hopefully, it won't find them, if found something, do factory reset, and repeat (on my 1st try it did find the update, although, could not download it quickly enough, I did a factory reset via Pwr&Vol+ recovery mode, and tried again - the 2nd time it skipped the update due to the slowness of the connection)
Sign in to Amazon account when prompted
Once Alexa shows up, swipe down from the top, turn on Airplane mode - no more risk of updates!!!
Part II (rooting via Kingoroot, disabling OTA, and getting SuperSu replacement, as per @retyre recommendations)
Take your Fire HD as is, do not do anything dramatic such as "factory reset", Amazon ROM sideloading, etc
Swipe down from the top, turn on Airplane mode - to ensure that there are no OTA updates during the procedure
In "Settings/Device Options", tap "Serial Number" 7 times, a menu "Developer Options" will appear
In "Settings/Device Options/Developer Options", turn ADB debugging to ON (under "Debugging")
In "Settings/Security", turn "Apps from Unknown Sources" to ON
Download ADB to your PC (link)
Setup ADB drivers on your PC, connect Fire to your PC, make sure "adb devices" command shows your Fire device, authorize ADB connection on Fire
Download SuperSu 2.79 (this exact version!!!) to your PC from this link, place it into your ADB PC folder. The filename of this apk will be assumed to be SuperSU-v2.79-20161205182033.apk below
Download the attached su64.zip to your PC (see the attachment below), unzip to your ADB PC folder
Open a CMD window in ADB PC folder (this will be called ADB_cmd window in the following steps), type
Code:
adb devices
adb uninstall eu.chainfire.supersu
This is a clean up of possible old SuperSu (just in case), ignore any errors you may get (if SuperSu is absent ...)
Download Kingoroot to your PC (link), install, let it update
Connect Fire to your PC; launch Kingoroot on PC; before pushing the big "ROOT" button in Kingoroot, uncheck a small box in the lower left corner for "Install recommended app" ; push "ROOT" button; wait for Kingoroot to root
Once Kingoroot succeeds, open a 2nd CMD window in ADB PC folder to your Fire (this will be called ADB_root window in the following steps), get a root shell, and disable OTA updates
Code:
adb shell
su
mount -w -o remount /system
mv /system/priv-app/DeviceSoftwareOTA/DeviceSoftwareOTA.apk /system/priv-app/DeviceSoftwareOTA/DeviceSoftwareOTA.apk_
ls -l /system/priv-app/DeviceSoftwareOTA/
ignore any errors you may get while doing this; after 'su', you should see root (#) prompt here
Switch to the first ADB_cmd window, type
Code:
adb uninstall com.lionmobi.powerclean
adb uninstall com.kingoapp.link
adb uninstall kingoroot.supersu
adb install SuperSU-v2.79-20161205182033.apk
adb shell "am start -n eu.chainfire.supersu/eu.chainfire.supersu.MainActivity"
Skip this step - it is not needed
Switch to the second ADB_root window (with # prompt), type
Code:
cd /data/local/tmp
mount -w -o remount /system
cp ./su64 /system/xbin/daemonsu
chmod 0755 /system/xbin/daemonsu
daemonsu -d &
cp ./su64 /system/xbin/su
chmod 0755 /system/xbin/su
am start -n eu.chainfire.supersu/eu.chainfire.supersu.MainActivity
On your Fire, SuperSu should pop up. Update SuperSu binary as "Normal", it should report "Installation failed." Proceed to reboot. (If it doesn't report an outcome ("failed") in a couple of minutes, go to the Fire's Apps and force-stop SuperSU and retry.)
Upon reboot, SuperSU should be functional. Choose "Grant" as the default access.
Uninstall all the junk from Kingoroot on your Fire, thanks to @fstanis for detailed instructions (copied here, executed from PC):
Code:
adb uninstall com.nemo.vidmate
adb shell rm -rf /sdcard/VidMate
adb shell rm -rf /sdcard/.a
adb shell rm -rf /sdcard/.DataStorage
adb shell rm -rf /sdcard/.UTSystemConfig
Some troubleshooting options:
If you believe you have the correct FireOS, but Kingoroot (or SuperSu) still fail, download the attached no_amzn_updates.zip to your PC, unzip to your ADB PC folder, open a CMD window in ADB PC folder, and type
Code:
.\no_amzn_updates.bat
The script will attempt to uninstall any apk updates to the official Amazon packages. Then repeat the rooting procedure from Step 1 skipping as necessary. See this post for more additional info on what the script does.
If you mess up your /system too much and get into a bootloop with "Fire" logo - use this post for links to the official Amazon ROM files; these bin's can be sideloaded via "adb sideload" in recovery
Want to say thanks by clicking the "Thanks" button ?
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Fire HD 10 ROM links & misc :
Update: Uploaded modified Supersu 2.82 SR5 ready to be flashed in FlashFire. It really represents the Chainfire's swan song, the last of the true SuperSu versions, the end of the era !!!
Fire HD 10 (7th Gen 2017) ROM links from Amazon (use for sideloading your preferred version in case you mess up). If possible, turn off WiFi before sideloading a bin file - you don't want to catch an OTA while it's loading!
FireOS 5.6.3.0 (reports say that it's still rootable, the downgrade behavior is not clear)
update-kindle-suez-40.6.2.6_user_626533320.bin
update-kindle-40.6.2.6_user_626533320.bin
FireOS 5.6.2.0 (still rootable, but cannot be downgraded to anything earlier!)
update-kindle-40.6.1.2_user_612495820.bin
FireOS 5.6.1.0 (still rootable, but cannot be downgraded to anything earlier!)
update-kindle-40.6.0.5_user_605485120.bin
System image (restore via FlashFire) link. Unzip files to /sdcard/FlashFire/Backups/5.6.1.0, rename the 2 img to bin extensions. Create md5 sum files (in a shell, type "md5 system.bin > system.md5", same for boot.bin) The system image includes SuperSu, Xposed, Busybox; OTA apk is NOT renamed.
FireOS 5.6.0.1
update-kindle-40.5.9.5_user_595550320.bin
System image (restore via FlashFire v0.24) - link. Unzip files to /sdcard/FlashFire/Backups/5.6.0.1. The system image includes SuperSu, Xposed, Busybox; OTA apk is renamed.
FireOS 5.6.0.0
update-kindle-40.5.9.5_user_595457320.bin
FireOS 5.6.0.0
update-kindle-40.5.9.5_user_595457020.bin
FireOS 5.5.0.0
update-kindle-40.5.9.1_user_591450020.bin
In addition, please find attach a SuperSu zip that works with Flash Fire v0.24 (tested with FireOS 5.5.0.0 & 5.6.0.0).
The file was created by taking SuperSu v2.82 zip from this link (file name - SuperSU-v2.82-201705271822.zip).
Then in META-INF\com\google\android\update-binary I replaced one line forcing SuperSu to install armv7 binaries instead of arm64:
Code:
if [ "$ABILONG" = "arm64-v8a" ]; then ARCH=arm64; SYSTEMLIB=/system/lib64; APPPROCESS64=true; fi;
with this one:
Code:
if [ "$ABILONG" = "arm64-v8a" ]; then ARCH=armv7; fi;
Everything else is identical to the official version.
Using the official SuperSu zip will cause a bootloop - it looks like Fire HD 10 is not quite arm64 yet, and needs armv7 version of su binaries to work.
Useful tips & information:
How to install Xposed & Flashfire for easy backups and ROM updates
Follow this post by @retyre (and thank him!!!): link
Note: With stock FlashFire versions, the latest Flashfire version you can use is v0.24 (see the attached v0.24 apk, it needs the date patch which requires Xposed installed). Alternatively, it is possible to replace a library in Flashfire v0.51, and make v0.51 work:
link1
link2
link3
For convenience, I've done this procedure to the free FlashFire v.51 version using free apktool, and attached the file below (the signature will not match with the original FlashFire signed by @Chainfire, so you will need to uninstall other FlashFire packages before installing this one!)
With v0.51, uncheck two options (as per link2):
1) Emulate framebuffer in Settings
2) Mount /system read/write (after you choose the update file).
If you don't do 2), Flashfire v.51 will just sit there and never do anything
How to enable Amazon packages (apk) updates but prevent the ROM updates (keeping root & rootable rom).
1) Edit /system/build.prop and change ro.build.version.number to have "9" as the first value instead of "5", as recommended in this link
2) Reboot
3) Enable OTA by ensuring that /system/priv-app/DeviceSoftwareOTA/DeviceSoftwareOTA.apk is renamed back to apk from apk_
4) Reboot
At this point the Fire will download a lot of apk packages, and will update Amazon system components (keeping FireOS version the same).
Partition trivia:
Partition info (gdisk binary) :
Code:
[email protected]:/ # df
df
Filesystem Size Used Free Blksize
/dev 907.7M 80.0K 907.6M 4096
/dev/logd 512.0K 96.0K 416.0K 4096
/sys/fs/cgroup 907.7M 12.0K 907.7M 4096
/mnt/asec 907.7M 0.0K 907.7M 4096
/mnt/obb 907.7M 0.0K 907.7M 4096
/system 1.5G 1.2G 317.9M 4096
/data 26.5G 1.1G 25.4G 4096
/data/metrics 5.8M 232.0K 5.6M 4096
/cache 410.7M 14.9M 395.8M 4096
/mnt/sqfs 79.8M 79.8M 0.0K 32768
/mnt/cd-rom 1.2M 1.2M 0.0K 2048
/mnt/shell/emulated 26.5G 1.1G 25.4G 4096
/storage/emulated 907.7M 0.0K 907.7M 4096
/storage/emulated/0 26.5G 1.1G 25.4G 4096
/storage/emulated/0/Android/obb 26.5G 1.1G 25.4G 4096
/storage/emulated/legacy 26.5G 1.1G 25.4G 4096
/storage/emulated/legacy/Android/obb 26.5G 1.1G 25.4G 4096
[email protected]:/data/local/tmp # ./gdisk -l /dev/block/mmcblk0
./gdisk -l /dev/block/mmcblk0
GPT fdisk (gdisk) version 0.8.4
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/block/mmcblk0: 61071360 sectors, 29.1 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): B1541C10-343E-474B-B5B2-05796C64E992
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 61071326
Partitions will be aligned on 1024-sector boundaries
Total free space is 990 sectors (495.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 1024 7167 3.0 MiB 8300 proinfo
2 7168 16383 4.5 MiB 8300 PMT
3 16384 18431 1024.0 KiB 8300 kb
4 18432 20479 1024.0 KiB 8300 dkb
5 20480 22527 1024.0 KiB 8300 lk
6 22528 32767 5.0 MiB 8300 tee1
7 32768 43007 5.0 MiB 8300 tee2
8 43008 123903 39.5 MiB 8300 metadata
9 123904 124927 512.0 KiB 8300 MISC
10 124928 141311 8.0 MiB 8300 reserved
11 141312 174079 16.0 MiB 8300 boot
12 174080 208895 17.0 MiB 8300 recovery
13 208896 3515391 1.6 GiB 8300 system
14 3515392 4383743 424.0 MiB 8300 cache
15 4383744 61071326 27.0 GiB 8300 userdata
[email protected]:/ # cat /proc/partitions
cat /proc/partitions
major minor #blocks name
7 0 81664 loop0
7 1 1254 loop1
7 2 10240 loop2
179 0 30535680 mmcblk0
179 1 3072 mmcblk0p1
179 2 4608 mmcblk0p2
179 3 1024 mmcblk0p3
179 4 1024 mmcblk0p4
179 5 1024 mmcblk0p5
179 6 5120 mmcblk0p6
179 7 5120 mmcblk0p7
179 8 40448 mmcblk0p8
179 9 512 mmcblk0p9
179 10 8192 mmcblk0p10
179 11 16384 mmcblk0p11
179 12 17408 mmcblk0p12
179 13 1653248 mmcblk0p13
179 14 434176 mmcblk0p14
179 15 28343791 mmcblk0p15
179 96 4096 mmcblk0rpmb
179 64 4096 mmcblk0boot1
179 32 1024 mmcblk0boot0
179 33 2 mmcblk0boot0p1
179 34 2 mmcblk0boot0p2
179 35 256 mmcblk0boot0p3
179 36 747 mmcblk0boot0p4
[email protected]:/ # ls -l /dev/block
ls -l /dev/block
brw------- root root 7, 0 2017-12-28 11:05 loop0
brw------- root root 7, 1 2017-12-28 11:05 loop1
brw------- root root 7, 2 2017-12-28 11:05 loop2
brw------- root root 7, 3 2017-12-28 11:05 loop3
brw------- root root 7, 4 2017-12-28 11:05 loop4
brw------- root root 7, 5 2017-12-28 11:05 loop5
brw------- root root 7, 6 2017-12-28 11:05 loop6
brw------- root root 7, 7 2017-12-28 11:05 loop7
brw-rw---- root system 179, 0 2017-12-28 11:05 mmcblk0
brw-rw---- root system 179, 32 2017-12-28 11:05 mmcblk0boot0
brw------- root root 179, 33 2017-12-28 11:05 mmcblk0boot0p1
brw------- root root 179, 34 2017-12-28 11:05 mmcblk0boot0p2
brw------- root root 179, 35 2017-12-28 11:05 mmcblk0boot0p3
brw------- root root 179, 36 2017-12-28 11:05 mmcblk0boot0p4
brw-rw---- root system 179, 64 2017-12-28 11:05 mmcblk0boot1
brw------- root root 179, 1 2017-12-28 11:05 mmcblk0p1
brw------- root root 179, 10 2017-12-28 11:05 mmcblk0p10
brw------- root root 179, 11 2017-12-28 11:05 mmcblk0p11
brw------- root root 179, 12 2017-12-28 11:05 mmcblk0p12
brw------- root root 179, 13 2017-12-28 11:05 mmcblk0p13
brw------- root root 179, 14 2017-12-28 11:05 mmcblk0p14
brw------- root root 179, 15 2017-12-28 11:05 mmcblk0p15
brw------- root root 179, 2 2017-12-28 11:05 mmcblk0p2
brw------- root root 179, 3 2017-12-28 11:05 mmcblk0p3
brw------- root root 179, 4 2017-12-28 11:05 mmcblk0p4
brw------- root root 179, 5 2017-12-28 11:05 mmcblk0p5
brw------- root root 179, 6 2017-12-28 11:05 mmcblk0p6
brw------- root root 179, 7 2017-12-28 11:05 mmcblk0p7
brw------- root root 179, 8 2017-12-28 11:05 mmcblk0p8
brw------- root root 179, 9 2017-12-28 11:05 mmcblk0p9
brw-rw---- root system 179, 96 2017-12-28 11:05 mmcblk0rpmb
drwxr-xr-x root root 2017-12-28 11:05 platform
drwx------ root root 2017-12-28 11:05 vold
brw------- root root 254, 0 2017-12-28 11:05 zram0
[email protected]:/ # ls -l /dev/block/platform/mtk-msdc.0/by-name/
ls -l /dev/block/platform/mtk-msdc.0/by-name/
lrwxrwxrwx root root 2017-12-28 11:05 MISC -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2017-12-28 11:05 PMT -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2017-12-28 11:05 boot -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 2017-12-28 11:05 boot0hdr0 -> /dev/block/mmcblk0boot0p1
lrwxrwxrwx root root 2017-12-28 11:05 boot0hdr1 -> /dev/block/mmcblk0boot0p2
lrwxrwxrwx root root 2017-12-28 11:05 boot0img0 -> /dev/block/mmcblk0boot0p3
lrwxrwxrwx root root 2017-12-28 11:05 boot0img1 -> /dev/block/mmcblk0boot0p4
lrwxrwxrwx root root 2017-12-28 11:05 cache -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 2017-12-28 11:05 dkb -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2017-12-28 11:05 kb -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2017-12-28 11:05 lk -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2017-12-28 11:05 metadata -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2017-12-28 11:05 proinfo -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2017-12-28 11:05 recovery -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 2017-12-28 11:05 reserved -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2017-12-28 11:05 system -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 2017-12-28 11:05 tee1 -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2017-12-28 11:05 tee2 -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 2017-12-28 11:05 userdata -> /dev/block/mmcblk0p15
[email protected]:/ # fdisk /dev/block/mmcblk0
fdisk /dev/block/mmcblk0
The number of cylinders for this disk is set to 3786.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): p
p
Disk /dev/block/mmcblk0: 29 GB, 31268536320 bytes, 61071360 sectors
3786 cylinders, 256 heads, 63 sectors/track
Units: cylinders of 16128 * 512 = 8257536 bytes
Device Boot StartCHS EndCHS StartLBA EndLBA Sectors
Size Id Type
/dev/block/mmcblk0p1 0,0,2 1023,255,63 1 4294967295 4294967295 2047G ee EFI GPT
bibikalka said:
Here is the guide to the painless root (while out of the box FireOS allows it - right now all versions up to FireOS 5.6.0.0 are rootable). The key enabler is the original post by @ztrund (link), great work blazing the trail (and motivating me to get another Fire tablet ASAP, LOL).
Given that the devices will be shipping with the (older) rootable FireOS for the next few months (but beware of the upcoming updates - see below !!!), there is a good window of opportunity to acquire a rootable Fire HD 10, and root it. As of Dec 27th 2017, there are no reports yet of non-rootable OTAs, but those OTAs will be coming soon, count on it!
The utmost goal here is to preserve the earliest FireOS version that you get, and not let it get updated by Amazon on a whim.
I am starting with a recently bought Fire HD 10 2017 (light refurb from eBay, missed the Black Friday mega sale ). I have FireOS 5.5.0.0 (earlier than 5.6.0.0!), version name 5.3.5.1 (591450020)
Part I (avoiding Amazon updating procedure upon the initial Fire setup) - this can (almost safely) be skipped today (end of Dec, 2017), since there are no reports of unrootable OTAs yet
Set up a dedicated slow router, limit upload/download speed to ~25 kbps (this is the trickiest part, I have a dedicated Tomato router which I use to control traffic)
Unpack Fire HD 10, turn it on, it will immediately demand a WiFi access
Connect Fire to your slow router
Once Fire finds Internet, it'll immediately have "Checking for updates" on the screen, this is where the slow router should kick in, and do the trick of forcing the update to give up
Wait a bit for updates, hopefully, it won't find them, if found something, do factory reset, and repeat (on my 1st try it did find the update, although, could not download it quickly enough, I did a factory reset via Pwr&Vol+ recovery mode, and tried again - the 2nd time it skipped the update due to the slowness of the connection)
Sign in to Amazon account when prompted
Once Alexa shows up, swipe down from the top, turn on Airplane mode - no more risk of updates!!!
Done
Click to expand...
Click to collapse
Why not just try to connect to a wifi with the wrong password, let it try, then hit back, then hit skip. Then you can get through without connecting to internet at all.
Blaiser47 said:
Why not just try to connect to a wifi with the wrong password, let it try, then hit back, then hit skip. Then you can get through without connecting to internet at all.
Click to expand...
Click to collapse
Even simpler: Choose any option on that WiFi screen, press cancel, and then skip.
No offense to the OP, but given the kind of questions that get asked on these root threads, s/he probably lost half the visitors at "dedicated slow router."
Blaiser47 said:
Why not just try to connect to a wifi with the wrong password, let it try, then hit back, then hit skip. Then you can get through without connecting to internet at all.
Click to expand...
Click to collapse
retyre said:
Even simpler: Choose any option on that WiFi screen, press cancel, and then skip.
No offense to the OP, but given the kind of questions that get asked on these root threads, s/he probably lost half the visitors at "dedicated slow router."
Click to expand...
Click to collapse
Great! Awesome tip!!! Even better than messing with the router - I've updated the post! XDA is no strangers to people with routers, especially if it involves blocking Amazon updates.
Curious does this work for the Fire 8? If not why?
ginfest said:
Curious does this work for the Fire 8? If not why?
Click to expand...
Click to collapse
The key difference is that the 2017 Fire HD 10 has an 'arm64-v8a' compiled system (with 64 bits), while all the older Fires are running 'armeabi-v7a' (with 32 bits). So a 64 bit bug must have slipped in. But let's be clear, if history is any guide, an Amazon update plugging this rootable bug is imminent at this point in time. That is why I urge everybody with root to disable OTA for good by renaming /system/priv-app/DeviceSoftwareOTA/DeviceSoftwareOTA.apk to *apk_
Unfortunately, all the other Fires seem to be on lock down, for now I have disabled updates on all of mine (including Fire TV 2 sticks) in case an exploit becomes available in the future.
bibikalka said:
Great! Awesome tip!!! Even better than messing with the router - I've updated the post! XDA is no strangers to people with routers, especially if it involves blocking Amazon updates.
Click to expand...
Click to collapse
Thanks very much for your simple approach to rooting the hd 10, starting from unboxing it, and giving step by step guide.
What apps/tweaks/settings did you do after you rooted your HD 10 that you recommend we do, you seem to have a way of writing that is concise and to the point, very much appreciated. Any other suggestions for protecting the HD 10 from Amazon OTA updates or other hazards?
Thanks again.
Are you saying at the beginning that 5.6.0.0 is or is not rootable?
encephalon9986 said:
Are you saying at the beginning that 5.6.0.0 is or is not rootable?
Click to expand...
Click to collapse
It is rootable, I clarified, thanks!
Amazing, much easier than the previous guide!
For those interested, I wrote here how to remove the Kingoroot junk: https://forum.xda-developers.com/hd8-hd10/general/added-kingoroot-t3721482
After rooting can I remove FireOS and install Oreo?
Stansted said:
After rooting can I remove FireOS and install Oreo?
Click to expand...
Click to collapse
No. That requires an unlocked boot loader and a custom oreo rom. Neither are available yet and likely will not be
This guide didn't work for me. While KingoRoot reported achieving root, I couldn't run SuperSU because the SuperSU binary is already occupied (presumably by KingoRoot's version of SuperSU).
Stansted said:
This guide didn't work for me. While KingoRoot reported achieving root, I couldn't run SuperSU because the SuperSU binary is already occupied (presumably by KingoRoot's version of SuperSU).
Click to expand...
Click to collapse
Thanks!
I was not sure if unrooting was necessary, it now looks like you should launch SuperSu from the root shell after running unroot with Kingoroot:
Unroot Fire via Kingoroot on PC
Can you try and report back?
bibikalka said:
Thanks!
I was not sure if unrooting was necessary, it now looks like you should launch SuperSu from the root shell after running unroot with Kingoroot:
Unroot Fire via Kingoroot on PC
Can you try and report back?
Click to expand...
Click to collapse
I already tried that. It didn't work. After unrooting, SuperSU won't do anything because it doesn't detect root.
Stansted said:
I already tried that. It didn't work. After unrooting, SuperSU won't do anything because it doesn't detect root.
Click to expand...
Click to collapse
How about going back to su commands - link
Yeah, so I just double-checked to make sure I hadn't made a mistake. This doesn't work. While SuperSU launches just fine from the root shell, it won't do anything after you've unrooted with KingoRoot. And if you haven't unrooted with KingoRoot, the SuperSU binary is occupied. For the record, I'm using a 7th Gen Fire HD 10 running Fire OS 5.6.0.0. I might try retyre's method later, but I don't currently understand what he's asking me to do.
Stansted said:
Yeah, so I just double-checked to make sure I hadn't made a mistake. This doesn't work. While SuperSU launches just fine from the root shell, it won't do anything after you've unrooted with KingoRoot. And if you haven't unrooted with KingoRoot, the SuperSU binary is occupied. For the record, I'm using a 7th Gen Fire HD 10 running Fire OS 5.6.0.0. I might try retyre's method later, but I don't currently understand what he's asking me to do.
Click to expand...
Click to collapse
Download the 5.6.0.0 update .bin from here, adb sideload that file, and follow these steps to the letter. It will work.
Software root method for Mediatek MT816x, MT817x and MT67xx!
A tool that gives you a temporary root shell with Selinux permissive to do with as you please
STATUS
Confirmed Working
Fire HD 8 8th gen (2018) (thanks @xyz`) -- up to Fire OS 6.3.0.1 only
Fire HD 8 7th gen (2017) -- up to Fire OS 5.6.4.0 build 636558520 only
Fire HD 8 6th gen (2016) (thanks @bibikalka) -- up to Fire OS 5.3.6.4 build 626536720
Fire HD 10 7th gen (2017) (thanks @bibikalka) -- up to Fire OS 5.6.4.0 build 636558520 only
Fire TV 2 2015 (mt8173-based) (thanks @el7145) -- up to Fire OS 5.2.6.9 only
Fire 7 9th gen (2019) (thanks @Michajin) -- up to Fire OS 6.3.1.2 build 0002517050244 only
Fire HD 10 9th gen (2019) -- up to Fire OS 7.3.1.0 only
Various phones and tablets up to Android 9.x (see link below for full list)
Note that for Fire OS 5, OS version 5.3.x.x is newer than 5.6.x.x.
Amazing Temp Root for MediaTek ARMv8: expanded thread covering all compatible MTK devices
DISCLAIMER
Anything you do that is described in this thread is at your own risk. No one else is responsible for any data loss, corruption or damage of your device, including that which results from bugs in this software.
REQUIREMENTS
Proficiency with the Thanks button under XDA posts
A Fire HD tablet based on mt8163 or mt8173 (or another MTK ARMv8 device)
Either:
A PC with ADB installed to interact with your device, or
A terminal emulator app
Familiarity with ADB (if using PC) and basic Linux shell commands
INSTRUCTIONS
Download the current mtk-su zip file to your PC and unzip it. Inside will be 2 directories: 'arm' & 'arm64' with an 'mtk-su' binary in each. Pick one for your device. Differences between the flavors:
arm64: 64-bit kernel and userspace
arm: 32-bit userspace on a 64-bit or 32-bit kernel (will also work in 64-bit userspace)
The arm64 one is suitable for most devices. The notable devices that need the arm version are the Fire HD 8 2018, Fire 7, and Fire HD 10 2019.
Connect your device to ADB and push mtk-su to your /data/local/tmp folder
Code:
adb push path/to/mtk-su /data/local/tmp/
Open an adb shell
Code:
adb shell
Change to your tmp directory
Code:
cd /data/local/tmp
Add executable permissions to the binary
Code:
chmod 755 mtk-su
At this point keep your tablet screen on and don't let it go to sleep. Run the program
Code:
./mtk-su
If the program gets stuck for more than a few seconds, press Ctrl+C to close it.
The -v option turns on verbose printing, which is necessary for me to debug any problems.
It will take several seconds, but using the -v option, you should see output similar to this (with id command added):
Code:
$ ./mtk-su -v
param1: 0x3000, param2: 0x18040, type: 2
Building symbol table
kallsyms_addresses pa 0x40bdd500
kallsyms_num_syms 70337, addr_count 70337
kallsyms_names pa 0x40c66d00, size 862960
kallsyms_markers pa 0x40d39800
kallsyms_token_table pa 0x40d3a100
kallsyms_token_index pa 0x40d3a500
Patching credentials
Parsing current_is_single_threaded
ffffffc000354868+50: ADRP x0, 0xffffffc000fa2000
ffffffc000354868+54: ADD xd, x0, 2592
init_task VA: 0xffffffc000fa2a20
Potential list_head tasks at offset 0x340
comm swapper/0 at offset 0x5c0
Found own task_struct at node 1
cred VA: 0xffffffc0358ac0c0
Parsing avc_denied
ffffffc0002f13bc+24: ADRP x0, 0xffffffc001113000
ffffffc0002f13bc+28: LDR [x0, 404]
selinux_enforcing VA: 0xffffffc001113194
Setting selinux_enforcing
Switched selinux to permissive
starting /system/bin/sh
UID: 0 cap: 3fffffffff selinux: permissive
#
Some other options:
mtk-su -c <command>: Runs <command> as root. Default command is /system/bin/sh.mtk-su -s: Prints the kernel symbol tableIf you see any errors other than about unsupported or incompatible platform or don't get a root shell, report it here.
Important: in rare cases, it may be necessary to run the tool multiple times before you hit UID 0 and get selinux permissive. If you don't achieve root on a particular run, the "UID: N cap: xxxxx...." line will reflect that. If it doesn't say "UID: 0 cap: 3fffffffff selinux: permissive", type exit to close the subshell and try mtk-su again.
If you succeed in getting temporary root, at that point you might want to install SuperSU for a more permanent root solution. Here is the official guide on which files should be present to kickstart SuperSU from temporary root. They are available in the latest SuperSU zip file. Remember that this only applies to Fire OS 5.
FIRE OS 5 AND ANDROID 5 USERS: There's an automated SuperSU loader by @Rortiz2 that makes jumpstarting SuperSU quick and easy.
WARNING FOR FIRE HD 8 2018 AND OTHER FIRE OS 6 DEVICES: If you have achieved root on such a device, do not remount the system partition as read/write. The remount command will probably not work. But forcing it will trigger dm-verity, which will result in a very bad day. Your tablet will become inoperable until you restore the stock system partition. You can accomplish a lot without modifying /system. But if you would like to get persistent root with Magisk by unlocking the bootloader, head on over to @bibikalka's outstanding Unlock/Magisk/TWRP Tutorial.
DOWNLOAD
Current Version
Release 23
Past releases & change log live at Amazing Temp Root for MediaTek ARMv8
FAQ
I got the error, "This firmware cannot be supported". What do I do?
This means that your device's firmware is not prone to the mechanism used by mtk-su. Check the firmware version and build number of the OS on your device. If your version is higher than that next to your device on the list above, then mtk-su will no longer work on your device. There may be other ways to achieve root. Check elsewhere on the forum.
Will this work on the Fire 7?
No, it is very doubtful this method can be used on the MT8127 chipset. The same also goes for the Fire TV stick.
After getting a root shell I'm still getting 'permission denied' errors. WTH?
It may be that selinux is still being enforced. Having root with selinux enabled is somehow more restrictive than a normal shell user. First, check that mtk-su succeeded in setting selinux to permissive by running getenforce. If it says Enforcing, then exit your shell and run mtk-su again.
Does this thing unlock the bootloader?
No, it does nothing to unlock the bootloader. But after running mtk-su, you may be able to use @xyz`'s revolutionary LK exploit or derivative works to achieve what is effectively an unlocked bootloader on some devices. Namely, you should be able to flash the specially crafted TWRP image using dd from Android.
How does this tool work?
It overwrites the process's credentials & capabilities in the kernel in order to gain privileges. It also turns off selinux enforcement by overwriting the kernel's selinux_enforcing variable. As for how it accesses that memory, I don't think I should discuss that as of yet.
Will this work on the Fire TV Stick 4K?
Unfortunately, no. While it has a 64-bit chip, the required vulnerabilities are not present in its OS.
Can I include mtk-su in my app or meta-tool?
Generally speaking, you may not distribute any mtk-su zip or binaries with your software. That includes doing any automatic download of those files into your app. You can still use it with your tools. But you should ask your users to visit this thread and download the current release zip themselves. No apps have been permitted to bundle or auto-download mtk-su.
Why don't you reply to my post?
I read every post in this thread, and respond to practically every post that warrants a response. Sometimes I will only click a Thanks as an acknowledgement. The reasons I may not answer your question are:
It has already been answered in the FAQ or multiple times in the thread.
Your post is unrelated to this project. It may be specific to your device, which would make it off topic for this thread.
Your question is extremely vague and you appear to be intentionally leaving out basic information (e.g. fishing).
CREDITS
@Supersonic27543 for helping me port it to Fire OS 5 and namely the HD 8 7th gen
Thank you to everyone who has donated. You're the best!
I want to thank you again for your efforts on this! I was ill the days before, so I didn't get much time to test SuperSU, and I'm trying to make a script now. Good luck to everyone who tries this!
EDIT: Oops, sorry for the reserve post.
How to use without a PC
INSTRUCTIONS FOR TERMINAL APP
You can optionally use mtk-su from a terminal emulator such as Termux or Terminal Emulator for Android (my preference). The gist of the process is to copy the executable to the terminal app's internal directory and run it from there. These are the instructions for Termux, but a similar procedure applies to all terminal shell apps.
Download the current mtk_su zip to your device and unzip it. Take note of where you extracted it. Pick the variant that fits your device. (See above.)
Open Termux and copy the mtk-su binary to its home directory, which in this case is the shell's initial working directory.
General idea: cp path/to/mtk-su ./
For example,
Code:
cp /sdcard/mtk-su_r14/arm64/mtk-su ./
For this to work, you have to enable the Storage permission for your term app. Do not try to circumvent the cp command with clever copying methods involving file managers or external tools. Mtk-su will not get the right permissions that way.
Make file executable
Code:
chmod 700 mtk-su
Run the program
Code:
./mtk-su
If mtk-su fails, post the output of ./mtk-su -v here along with a link to firmware and kernel sources, if possible.
Note that for most terminal shell apps, the internal app directory is stored in the variable $HOME. So in general you would do
cd
cp path/to/mtk-su ./
chmod 700 mtk-su
./mtk-su
Great work!
So could this theoretically work for any Mediatek device? Or do specific modifications need to be done for another model chip?
What do you think is likely the worst to happen if this is tried as-is on another device? Will it just not work? Or explode the device?
I have an Acer B3-A40 that has an MT8167 chip that I wouldn't mind rooting.
@cybersaga, yes, it's very possible it will work on an mt8167 device. Although I can't 100% guarantee it won't damage your device, I would just go ahead and try it. The risk is very minimal. It will print some error if it fails. I think realistically, I would need to tweak some parameters or make a workaround if there's a problem.
The method should be applicable to most 64-bit platforms. There are newer 4.x kernels where the necessary hole is not present, though. But time will tell what devices this ultimately will be compatible with.
That's super neat. I'll probably give it a try sometime this week.
Very cool from what I can see, however it doesn't work on HD8 2018 because there's no 64-bit userspace (only the kernel is 64-bit), could you recompile it for arm?
Oh, that's a bummer, @xyz`. Why would they do that? I think there's some other tweaks I have to make besides compiling it. I'll post a test version as soon as I can. This might be the case for other devices too...
diplomatic said:
Oh, that's a bummer, @xyz`. Why would they do that? I think there's some other tweaks I have to make besides compiling it. I'll post a test version as soon as I can. This might be the case for other devices too...
Click to expand...
Click to collapse
Maybe you can just compile it as a static binary instead if that's easier.
Awesome! I just rooted my HD8 2017
Try the automated script by @Rortiz2
Previous instructions:
For anyone that is confused by the process of manually installing SuperSu, I did the following...
IMPORTANT: This is for FireOS 5 devices such as HD8 2017. Do not attempt this on HD8 2018
Install SuperSu from Playstore
Download SuperSu and unzip somewhere
adb push arm64/su arm64/supolicy arm64/libsupol.so /data/local/tmp
Follow directions from OP to get a root shell. You should not get permission denied when running ls. If you see permission denied, run exit and try again. Took me a few tries
mount -o remount -rw /system
cp /data/local/tmp/su /system/xbin/su
cp /data/local/tmp/su /system/xbin/daemonsu
cp /data/local/tmp/supolicy /system/xbin/
cp /data/local/tmp/libsupol.so /system/lib/
cp /data/local/tmp/libsupol.so /system/lib64/
chmod 0755 /system/xbin/su
chcon ubject_r:system_file:s0 /system/xbin/su
chmod 0755 /system/xbin/daemonsu
chcon ubject_r:system_file:s0 /system/xbin/daemonsu
at this point, running su should work and show a root shell
daemonsu --auto-daemon
Open SuperSu app and allow it to update the su binary
My tablet hung at the boot logo when I manually installed SuperSu via the linked instructions. Installing the bare minimum and letting the SuperSu app do the rest seems less error-prone
@diplomatic
Wow!!! This is crazy !!! Where have you been before??? I almost had to drill a hole into HD8 2016!!!
I tried this on HD8 2016, FireOS 5.3.2.1, and the method worked! It takes less than 1 second to run, way faster than any Kingoroot. I had to exit and run again to get system mounting permissions rw as per @dutchthomas recommendation {mount -o remount -rw /system}. Then I updated su manually (using armv7 binaries from SR5-SuperSU-v2.82-SR5-20171001224502.zip - on HD10 2017 I am always using armv7 versions as well), and let SuperSu update itself. Full success! SuperSu needs to be set to "Grant" as per this link.
Now, for HD8 2018 I believe the following could work. 0) Drain the battery to really minimal amount ~ 3% 1) Run this to get temp root. 2) Zero out boot0 {dd if=/dev/zero of=/dev/block/mmcblk0boot0}. At this point the device should be booting into BootRom mode (as claimed by others - @xyz`, @hwmod, @k4y0z, can you confirm?). In BootRom, run the scripts from this link. If it hangs in BootRom, just let it sit disconnected from anything. The low battery should shut it down, and you can try again later in BootRom. Low battery would remove the need to open the case should the amonet script hang.
Actually, for HD8 2018, if RPMB does not need to be cleared, all of amonet steps could be done via dd while having a temporary root shell. One could dd all of LK/TZ/boot/recovery/preloader. If RPMB needs clearing, then one should still dd everything but the preloader, which instead should be zeroed out {dd if=/dev/zero of=/dev/block/mmcblk0boot0}. Then amonet would be used to clear our RPMB, and put the preloader back. One of the current seeming issues is that amonet appears to write LK exploit into the memory area outside of boot0 size (thus precluding dd operation for that piece of code into boot0) - see this link for details. If this issue could be addressed, then HD8 2018 could be unlockable without ever opening the case.
My HD8 2016 output:
Code:
C:\Program Files\Minimal ADB and Fastboot>adb shell
[email protected]:/ $ cd /data/local/tmp
[email protected]:/data/local/tmp $ chmod 755 mtk-su
[email protected]:/data/local/tmp $ ./mtk-su -v
Building symbol table
kallsyms_addresses_pa 0x40ad8f00
kallsyms_num_syms 67082, addr_count 67082
kallsyms_names_pa 0x40b5c100
Size of kallsyms_names 805834 bytes
kallsyms_markers_pa 0x40c20d00
kallsyms_token_table_pa 0x40c21600
kallsyms_token_index_pa 0x40c21a00
Patching credentials
init_task va: ffffffc000edaa20
Possible list_head tasks at offset 0x338
0xffffffc0030c8338 0xffffffc050347638 0x000000000000008c
comm offset 0x5a8 comm: swapper/0
Found own task_struct at node 0
real_cred: 0xffffffc052669900, cred: 0xffffffc052669900
New UID/GID: 0/0
Setting selinux permissive
Found adrp at offset 4
ADRP x0, base is 0xffffffc001030000
Found ldr at offset 28
LDR [x0,444], selinux_enforce VA is 0xffffffc0010301bc
Switched selinux to permissive
starting /system/bin/sh
[email protected]:/data/local/tmp #
Edit: Despite my super careful SuperSu injection into FireOS 5.3.6.4 system image, I still could not get SuperSu to work after I restored this image using FlashFire. Regardless, the method from this thread also rooted 5.3.6.4 in no time! Awesome!
dutchthomas said:
Awesome! I just rooted my HD8 2017
For anyone that is confused by the process of manually installing SuperSu, I did the following:
Install SuperSu from Playstore
Download SuperSu and unzip somewhere
adb push arm64/su arm64/supolicy arm64/libsupol.so /data/local/tmp
Follow directions from OP to get a root shell. You should not get permission denied when running ls. If you see permission denied, run exit and try again. Took me a few tries
mount -o remount -rw /system
cp /data/local/tmp/su /system/xbin/su
cp /data/local/tmp/su /system/xbin/daemonsu
cp /data/local/tmp/supolicy /system/xbin/
cp /data/local/tmp/libsupol.so /system/lib/
cp /data/local/tmp/libsupol.so /system/lib64/
at this point, running su should work and show a root shell
daemonsu --auto-daemon
Open SuperSu app and allow it to update the su binary
My tablet hung at the boot logo when I manually installed SuperSu via the linked instructions. Installing the bare minimum and letting the SuperSu app do the rest seems like a less error-prone middle ground.
Click to expand...
Click to collapse
Thanks for this! I'm not sure if I'm doing it correctly, but everything works fine until I get to #11. Do I just type su? When I do, it says permission denied.
EDIT: Just tried the new commands you edited and it worked. My FireHD 8 7th gen is now rooted.
diplomatic said:
Software root method found for Mediatek MT8163, MT8173 and MT67xx!
Click to expand...
Click to collapse
Great work!
bibikalka said:
Now, for HD8 2018 I believe the following could work. 0) Drain the battery to really minimal amount ~ 3% 1) Run this to get temp root. 2) Zero out boot0 {dd if=/dev/zero of=/dev/block/mmcblk0boot0}. At this point the device should be booting into BootRom mode (as claimed by others - @xyz`, @hwmod, @k4y0z, can you confirm?). In BootRom, run the scripts from this link. If it hangs in BootRom, just let it sit disconnected from anything. The low battery should shut it down, and you can try again later in BootRom. Low battery would remove the need to open the case should the amonet script hang.
Actually, for HD8 2018, if RPMB does not need to be cleared, all of amonet steps could be done via dd while having a temporary root shell. One could dd all of LK/TZ/boot/recovery/preloader. If RPMB needs clearing, then one should still dd everything but the preloader, which instead should be zeroed out {dd if=/dev/zero of=/dev/block/mmcblk0boot0}. Then amonet would be used to clear our RPMB, and put the preloader back. One of the current seeming issues is that amonet appears to write LK exploit into the memory area outside of boot0 size (thus precluding dd operation for that piece of code into boot0) - see this link for details. If this issue could be addressed, then HD8 2018 could be unlockable without ever opening the case.
Click to expand...
Click to collapse
If you want to zero out preloader, you should do it this way:
Code:
su -c "echo 0 > /sys/block/mmcblk0boot0/force_ro; cat /dev/zero > /dev/block/mmcblk0boot0; echo 'EMMC_BOOT' > /dev/block/mmcblk0boot0"
that way the sanity check of amonet won't fail.
I'm not sure about the boot0 size on the HD8. According to @xyz` it is 4MB on the HD8 as well.
bibikalka said:
@diplomatic
Wow!!! This is crazy !!! Where have you been before??? I almost had to drill a hole into HD8 2016!!!
I tried this on HD8 2016, FireOS 5.3.2.1, and the method worked! It takes less than 1 second to run, way faster than any Kingoroot. I had to exit and run again to get system mounting permissions rw as per @dutchthomas recommendation {mount -o remount -rw /system}. Then I updated su manually (using armv7 binaries from SR5-SuperSU-v2.82-SR5-20171001224502.zip - on HD10 2017 I am always using armv7 versions as well), and let SuperSu update itself. Full success! SuperSu needs to be set to "Grant" as per this link.
Now, for HD8 2018 I believe the following could work. 0) Drain the battery to really minimal amount ~ 3% 1) Run this to get temp root. 2) Zero out boot0 {dd if=/dev/zero of=/dev/block/mmcblk0boot0}. At this point the device should be booting into BootRom mode (as claimed by others - @xyz`, @hwmod, @k4y0z, can you confirm?). In BootRom, run the scripts from this link. If it hangs in BootRom, just let it sit disconnected from anything. The low battery should shut it down, and you can try again later in BootRom. Low battery would remove the need to open the case should the amonet script hang.
Actually, for HD8 2018, if RPMB does not need to be cleared, all of amonet steps could be done via dd while having a temporary root shell. One could dd all of LK/TZ/boot/recovery/preloader. If RPMB needs clearing, then one should still dd everything but the preloader, which instead should be zeroed out {dd if=/dev/zero of=/dev/block/mmcblk0boot0}. Then amonet would be used to clear our RPMB, and put the preloader back. One of the current seeming issues is that amonet appears to write LK exploit into the memory area outside of boot0 size (thus precluding dd operation for that piece of code into boot0) - see this link for details. If this issue could be addressed, then HD8 2018 could be unlockable without ever opening the case.
My HD8 2016 output:
Code:
C:\Program Files\Minimal ADB and Fastboot>adb shell
[email protected]:/ $ cd /data/local/tmp
[email protected]:/data/local/tmp $ chmod 755 mtk-su
[email protected]:/data/local/tmp $ ./mtk-su -v
Building symbol table
kallsyms_addresses_pa 0x40ad8f00
kallsyms_num_syms 67082, addr_count 67082
kallsyms_names_pa 0x40b5c100
Size of kallsyms_names 805834 bytes
kallsyms_markers_pa 0x40c20d00
kallsyms_token_table_pa 0x40c21600
kallsyms_token_index_pa 0x40c21a00
Patching credentials
init_task va: ffffffc000edaa20
Possible list_head tasks at offset 0x338
0xffffffc0030c8338 0xffffffc050347638 0x000000000000008c
comm offset 0x5a8 comm: swapper/0
Found own task_struct at node 0
real_cred: 0xffffffc052669900, cred: 0xffffffc052669900
New UID/GID: 0/0
Setting selinux permissive
Found adrp at offset 4
ADRP x0, base is 0xffffffc001030000
Found ldr at offset 28
LDR [x0,444], selinux_enforce VA is 0xffffffc0010301bc
Switched selinux to permissive
starting /system/bin/sh
[email protected]:/data/local/tmp #
Click to expand...
Click to collapse
Thanks for the feedback, bro! So the HD8 2016 is crossed off the untested list. For the HD8 2018, as far as I see, you can just flash the premade TWRP to recovery by dd. Why do you need to do the whole bootrom procedure? Then reboot to recovery to check if everything's ok. If not, Android will just restore the stock recovery on next boot. If TWRP works, just install Magisk or whatever you do to modify boot.
dutchthomas said:
Awesome! I just rooted my HD8 2017
For anyone that is confused by the process of manually installing SuperSu, I did the following:
Install SuperSu from Playstore
Download SuperSu and unzip somewhere
adb push arm64/su arm64/supolicy arm64/libsupol.so /data/local/tmp
Follow directions from OP to get a root shell. You should not get permission denied when running ls. If you see permission denied, run exit and try again. Took me a few tries
mount -o remount -rw /system
cp /data/local/tmp/su /system/xbin/su
cp /data/local/tmp/su /system/xbin/daemonsu
cp /data/local/tmp/supolicy /system/xbin/
cp /data/local/tmp/libsupol.so /system/lib/
cp /data/local/tmp/libsupol.so /system/lib64/
at this point, running su should work and show a root shell
daemonsu --auto-daemon
Open SuperSu app and allow it to update the su binary
My tablet hung at the boot logo when I manually installed SuperSu via the linked instructions. Installing the bare minimum and letting the SuperSu app do the rest seems like a less error-prone middle ground.
Click to expand...
Click to collapse
Oh, nice, thanks for this... This is more straightfoward than doing it "offline". I just realized Chainfire has instructions specifically for dealing with exploits here.
diplomatic said:
Thanks for the feedback, bro! So the HD8 2016 is crossed off the untested list. For the HD8 2018, as far as I see, you can just flash the premade TWRP to recovery by dd. Why do you need to do the whole bootrom procedure? Then reboot to recovery to check if everything's ok. If not, Android will just restore the stock recovery on next boot. If TWRP works, just install Magisk or whatever you do to modify boot.
Click to expand...
Click to collapse
Flashing TWRP isn't enough.
LK-payload needs to be written to boot0 at offset 0x200000.
Additionally you need to have the correct version of LK installed.
If you have an older version it could just be overwritten.
If your installed LK is newer, you will have to zero out RPMB.
LOL
Very nice!
Awesome work @diplomatic
If you had discovered it before, I would not have asked you to compile TWRP for the BQ M8 and I would not have bothered you. By the way I I prefer to have TWRP. (thanks!)
I have reinstalled stock in my BQ M8 and the script has worked! If you want you can add it to the list of devices...
On Fire 7 7th Gen it not worked.. But we have TWRP.
EDIT: I have tried again and now I get this error
Code:
130|[email protected]_M8:/data/local/tmp $ ./mtk-su -v
Building symbol table
kallsyms_addresses_pa 0x40a43000
kallsyms_num_syms 49221, addr_count 49221
kallsyms_names_pa 0x40aa3400
Size of kallsyms_names 602609 bytes
kallsyms_markers_pa 0x40b36600
kallsyms_token_table_pa 0x40b36c00
warning: token_count 1
kallsyms_token_index_pa 0x40b36d00
Patching credentials
__ksymtab_init_task not found
New UID/GID: 2000/2000
Setting selinux permissive
find_selinux_enforce_var() returned -1
starting /system/bin/sh
k4y0z said:
Flashing TWRP isn't enough.
LK-payload needs to be written to boot0 at offset 0x200000.
Additionally you need to have the correct version of LK installed.
If you have an older version it could just be overwritten.
If your installed LK is newer, you will have to zero out RPMB.
Click to expand...
Click to collapse
diplomatic said:
... For the HD8 2018, as far as I see, you can just flash the premade TWRP to recovery by dd. Why do you need to do the whole bootrom procedure? Then reboot to recovery to check if everything's ok. If not, Android will just restore the stock recovery on next boot. If TWRP works, just install Magisk or whatever you do to modify boot.
Click to expand...
Click to collapse
Yep! Cannot just flash TWRP on HD8 2018 - need to also unlock bootloader, otherwise TWRP won't boot. Which is not a problem, and in theory can be done all via dd - except for the amonet address issue (2Mb), see more below.
k4y0z said:
If you want to zero out preloader, you should do it this way:
Code:
su -c "echo 0 > /sys/block/mmcblk0boot0/force_ro; cat /dev/zero > /dev/block/mmcblk0boot0; echo 'EMMC_BOOT' > /dev/block/mmcblk0boot0"
that way the sanity check of amonet won't fail.
I'm not sure about the boot0 size on the HD8. According to @xyz` it is 4MB on the HD8 as well.
Click to expand...
Click to collapse
OK - once boot0 is zeroed out, how does one get into BootRom after that? One basically turns off the tablet, and then plugs it into Linux with amonet listening? Which tablet models were tested so far with this BootRom activation method?
For the boot0 size, see these outputs from 2 tablets, 'cat /proc/partitions'. In both cases, boot0 is only 1Mb - 1024 blocks below. So it's not possible to dd beyond that 1Mb from within FireOS. If the exploit was placed at ~512 Kb, then it'd be all in range.
Fire HD8 2016:
Code:
major minor #blocks name
179 0 15388672 mmcblk0
179 1 3072 mmcblk0p1
179 2 5120 mmcblk0p2
179 3 10240 mmcblk0p3
179 4 10240 mmcblk0p4
179 5 256 mmcblk0p5
179 6 500 mmcblk0p6
179 7 16268 mmcblk0p7
179 8 16384 mmcblk0p8
179 9 6144 mmcblk0p9
179 10 512 mmcblk0p10
179 11 8192 mmcblk0p11
179 12 10240 mmcblk0p12
179 13 1024 mmcblk0p13
179 14 5120 mmcblk0p14
179 15 5120 mmcblk0p15
179 16 40320 mmcblk0p16
179 17 1024 mmcblk0p17
179 18 1024 mmcblk0p18
179 19 1653024 mmcblk0p19
179 20 434176 mmcblk0p20
179 21 512 mmcblk0p21
179 22 16384 mmcblk0p22
179 23 4320 mmcblk0p23
179 24 13138927 mmcblk0p24
179 96 4096 mmcblk0rpmb
179 64 4096 mmcblk0boot1
179 32 1024 mmcblk0boot0
179 33 2 mmcblk0boot0p1
179 34 2 mmcblk0boot0p2
179 35 256 mmcblk0boot0p3
179 36 747 mmcblk0boot0p4
Fire HD8 2018:
Code:
major minor #blocks name
179 0 15267840 mmcblk0
179 1 3072 mmcblk0p1
179 2 4608 mmcblk0p2
179 3 1024 mmcblk0p3
179 4 1024 mmcblk0p4
179 5 1024 mmcblk0p5
179 6 5120 mmcblk0p6
179 7 5120 mmcblk0p7
179 8 40448 mmcblk0p8
179 9 512 mmcblk0p9
179 10 8192 mmcblk0p10
179 11 16384 mmcblk0p11
179 12 20480 mmcblk0p12
179 13 3177472 mmcblk0p13
179 14 230400 mmcblk0p14
179 15 512000 mmcblk0p15
179 16 11240431 mmcblk0p16
179 96 4096 mmcblk0rpmb
179 64 4096 mmcblk0boot1
179 32 1024 mmcblk0boot0
179 33 2 mmcblk0boot0p1
179 34 2 mmcblk0boot0p2
179 35 256 mmcblk0boot0p3
179 36 747 mmcblk0boot0p4
@diplomatic - awesome work - just had to give it a go for myself...
Factory reset my HD8 (2017) (root originally via @t0x1cSH "Fire hd8 2017 root, debrick" post) and followed your post plus the 'speedy SU install' from @dutchthomas - post 10.
One difficulty: mtk-su seemed to run fine and UID= 0 was shown - but I did have trouble getting the the 'mount -o remount -rw /system' command to work at first - it needed a few attempts.
And then, using the work-through from post 10, I couldn't get full root (i.e. 'su' accepted at command prompt) until I changed permissions on each of the copied SU components (su, daemonsu etc) to those prescribed in @<br />'s awesome Hardmod post.
Bit strange? I was using Fire OS 5.3.6.0 - I wonder if version makes any difference? Got there eventually tho' :good:
bibikalka said:
Yep! Cannot just flash TWRP on HD8 2018 - need to also unlock bootloader, otherwise TWRP won't boot. Which is not a problem, and in theory can be done all via dd - except for the amonet address issue (2Mb), see more below.
OK - once boot0 is zeroed out, how does one get into BootRom after that? One basically turns off the tablet, and then plugs it into Linux with amonet listening? Which tablet models were tested so far with this BootRom activation method?
For the boot0 size, see these outputs from 2 tablets, 'cat /proc/partitions'. In both cases, boot0 is only 1Mb - 1024 blocks below. So it's not possible to dd beyond that 1Mb from within FireOS. If the exploit was placed at ~512 Kb, then it'd be all in range.
Fire HD8 2016:
Code:
major minor #blocks name
179 0 15388672 mmcblk0
179 1 3072 mmcblk0p1
179 2 5120 mmcblk0p2
179 3 10240 mmcblk0p3
179 4 10240 mmcblk0p4
179 5 256 mmcblk0p5
179 6 500 mmcblk0p6
179 7 16268 mmcblk0p7
179 8 16384 mmcblk0p8
179 9 6144 mmcblk0p9
179 10 512 mmcblk0p10
179 11 8192 mmcblk0p11
179 12 10240 mmcblk0p12
179 13 1024 mmcblk0p13
179 14 5120 mmcblk0p14
179 15 5120 mmcblk0p15
179 16 40320 mmcblk0p16
179 17 1024 mmcblk0p17
179 18 1024 mmcblk0p18
179 19 1653024 mmcblk0p19
179 20 434176 mmcblk0p20
179 21 512 mmcblk0p21
179 22 16384 mmcblk0p22
179 23 4320 mmcblk0p23
179 24 13138927 mmcblk0p24
179 96 4096 mmcblk0rpmb
179 64 4096 mmcblk0boot1
179 32 1024 mmcblk0boot0
179 33 2 mmcblk0boot0p1
179 34 2 mmcblk0boot0p2
179 35 256 mmcblk0boot0p3
179 36 747 mmcblk0boot0p4
Fire HD8 2018:
Code:
major minor #blocks name
179 0 15267840 mmcblk0
179 1 3072 mmcblk0p1
179 2 4608 mmcblk0p2
179 3 1024 mmcblk0p3
179 4 1024 mmcblk0p4
179 5 1024 mmcblk0p5
179 6 5120 mmcblk0p6
179 7 5120 mmcblk0p7
179 8 40448 mmcblk0p8
179 9 512 mmcblk0p9
179 10 8192 mmcblk0p10
179 11 16384 mmcblk0p11
179 12 20480 mmcblk0p12
179 13 3177472 mmcblk0p13
179 14 230400 mmcblk0p14
179 15 512000 mmcblk0p15
179 16 11240431 mmcblk0p16
179 96 4096 mmcblk0rpmb
179 64 4096 mmcblk0boot1
179 32 1024 mmcblk0boot0
179 33 2 mmcblk0boot0p1
179 34 2 mmcblk0boot0p2
179 35 256 mmcblk0boot0p3
179 36 747 mmcblk0boot0p4
Click to expand...
Click to collapse
When you execute that command, simply turn off the tablet and when you connect it to the PC it will detect it in BootROM Mode. Checked in Fire 7 2017.
Wait, will this work for a mt6753 chipset?