Database Info

Cant boot, stuck on htc screen.

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.

[GUIDE] Huawei Ascend G6 LTE [G6-L11] (Root & Xposed Framework)

[GUIDE] Huawei Ascend G6 LTE [G6-L11] (Root & Xposed Framework)
ROOTING
Phone was rooted using ROOT Genius
- Download from shuame.com/en/root/
- Install and turn on USB debugging on your phone
- Connect the phone and wait for a little bit, it will work
- After rooting your phone will reboot
*Users who rooted with TOWELROOT*
When rooting with Towelroot there is a problem accesing partitions in root mode.
So now please use Root Genius method!
Uninstalling Towelroot
- Uninstall Towelroot (tr.apk) like normal app
- Go to SuperSU, settings then press permanent unroot
- Check your root status, then reboot the phone
- Now you can root with ROOT Genius method
You can check root with Root Checker or similar app.
Congratulations, your phone is rooted now
Xposed Framework
Xposed Framework will work only if you rooted the phone!
- Download Xposed Framework dl.xposed.info/latest.apk and install it
***Xposed will not work on Huawei devices because of conflict between Xposed and Huawei Theme engeine***
To make it work there are 2 options:
1 - Launch Xposed Installer, go to Settings and in the bottom tick "Disabled resource hooks"
Note: many modules will NOT work with this option checked
2 - This option involves editing build.prop file so be VERY CAREFUL! Also please BACKUP your build.prop file before editing!!!
You need to DISABLE Huawei Theme engeine then you DONT NEED "Disabled resource hook" and many modules will work.
In build.prop file you need to change this line: ro.config.hwtheme=2 to this line: ro.config.hwtheme=0
*If you dont have this line you have to add it
To edit build.prop file download app "BuildProp Editor" from Google play run it, allow root privileges for app
and tick search (down left corner)
Write "ro.config.hwtheme" tick the found line and change PROPERTY VALUE to 0 and tick save.
BE VERY CAREFUL TO NOT CHANGE ANY OTHER LINE THAN THIS!
After applying option 1 or 2 you can install Xposed Framework. (I recommend option 2 beacuse more modules will work)
Open the Xposed Installer, go to Framework (press OK) (make shure that INSTALLATION MODE is Classical (write to /system directly)
then tick Install/Update button and finnaly reboot the phone.
You now have fully working Xposed
Some nice Xposed modules:
- GravityBoxJB (Jelly Bean)
- BootManager
- Tinted Status Bar (works better with Google Now Launcher)
*Also im finding method to unlock bootloader for G6 LTE, when i suceed i will update this guide.
DISCLAMER:
I am not responsible for any damage to your phone, do this on your own risk!!!

need urgent helpp
man i broke my phone, Its soft brick right now. can u please me copy if system.img partition... my phone wont work till then:crying:

Please explain what you did to make it softbricked? Did you made build.prop backup?
Sent from my HUAWEI G6-L11 using XDA Free mobile app

wow bro
very good :victory:

Doesn't work
I've tried so many thing to root this phone but nothing works.
Towelroot just stay open for ages when i press make it rain, it stays freezed until i close it.
Still looking for a way to root this phone.

i have rooted my g6, but i have a problem.. when i use root-explorer end it get root access , bhot sdcards (internal and external) disappear.. how can i fix this?
Sent from my HUAWEI G6-L11 using XDA Free mobile app

Install File Explorer from NextApp and File Explorer root addon from Google play, and tell me if works.
Sent from my HUAWEI G6-L11 using XDA Free mobile app

If you having problems with Towelroot try RootGenius, Vroot or Kingo to root it.
Sent from my HUAWEI G6-L11 using XDA Free mobile app

the device is rooted, i can put and edit files in the /system folder and other root access folders, thevonly problem is the access on external cards... it appears unmounted in superuser mode..
if i try virtual terminal:
ls /storage/sdcard0 (or sdcard1) it show the external memory files
if i try :
su
ls /stoage/sdcard0 the folder is empty...
...i have also tryed to mount dev/block/mmcblk0p25 (sdcard0) it result busy
Sent from my HUAWEI G6-L11 using XDA Free mobile app

amonpaike said:
the device is rooted, i can put and edit files in the /system folder and other root access folders, thevonly problem is the access on external cards... it appears unmounted in superuser mode..
if i try virtual terminal:
ls /storage/sdcard0 (or sdcard1) it show the external memory files
if i try :
su
ls /stoage/sdcard0 the folder is empty...
...i have also tryed to mount dev/block/mmcblk0p25 (sdcard0) it result busy
Sent from my HUAWEI G6-L11 using XDA Free mobile app
Click to expand...
Click to collapse
I have tryed that now, I can confirm that when in root mode its "empty"
But tell me what are you trying to do? With File Explorer from NextApp and File Explorer root addon i can acces storage and / partiton with root privileges and see all the content. I will try to find out why is it like that.

whit fx explorer and root addon when i try to access to -> system(root)->storage/sdcard0/ it is empty...
i have rooted the g6-l11 whit towelroot.
this is the device block composition... in case any developer can make clockworkmod or other recovery for the g6-l11
[email protected]:/ # cat /proc/partitions
major minor #blocks name
179 0 7634944 mmcblk0
179 1 512 mmcblk0p1
179 2 32 mmcblk0p2
179 3 32 mmcblk0p3
179 4 500 mmcblk0p4
179 5 500 mmcblk0p5
179 6 5592 mmcblk0p6
179 7 1024 mmcblk0p7
179 8 65536 mmcblk0p8
179 9 4096 mmcblk0p9
179 10 4096 mmcblk0p10
179 11 98304 mmcblk0p11
179 12 4096 mmcblk0p12
179 13 1 mmcblk0p13
179 14 8 mmcblk0p14
179 15 32768 mmcblk0p15
179 16 65536 mmcblk0p16
179 17 8192 mmcblk0p17
179 18 12288 mmcblk0p18
179 19 16384 mmcblk0p19
179 20 262144 mmcblk0p20
179 21 196608 mmcblk0p21
179 22 4096 mmcblk0p22
179 23 1048576 mmcblk0p23
179 24 2097152 mmcblk0p24
179 25 3694575 mmcblk0p25
179 32 512 mmcblk0rpmb
(this is my 32gb external sdcard..)
179 64 30703616 mmcblk1
179 65 25626483 mmcblk1p1
179 66 4882874 mmcblk1p2
179 67 193536 mmcblk1p3
---------------------------------------------------------
ls - al /dev/block/platform/msm_sdcc.1/by-name/
lrwxrwxrwx root root 1970-05-06 22:58 DDR -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 1970-05-06 22:58 aboot -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 1970-05-06 22:58 bkbootup -> /dev/block/mmcblk0p16
lrwxrwxrwx root root 1970-05-06 22:58 boot -> /dev/block/mmcblk0p18
lrwxrwxrwx root root 1970-05-06 22:58 cache -> /dev/block/mmcblk0p21
lrwxrwxrwx root root 1970-05-06 22:58 cust -> /dev/block/mmcblk0p20
lrwxrwxrwx root root 1970-05-06 22:58 fsc -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 1970-05-06 22:58 fsg -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 1970-05-06 22:58 grow -> /dev/block/mmcblk0p25
lrwxrwxrwx root root 1970-05-06 22:58 log -> /dev/block/mmcblk0p15
lrwxrwxrwx root root 1970-05-06 22:58 misc -> /dev/block/mmcblk0p22
lrwxrwxrwx root root 1970-05-06 22:58 modem -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 1970-05-06 22:58 modemst1 -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 1970-05-06 22:58 modemst2 -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 1970-05-06 22:58 oeminfo -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 1970-05-06 22:58 pad -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 1970-05-06 22:58 persist -> /dev/block/mmcblk0p17
lrwxrwxrwx root root 1970-05-06 22:58 recovery -> /dev/block/mmcblk0p19
lrwxrwxrwx root root 1970-05-06 22:58 rpm -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 1970-05-06 22:58 sbl1 -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 1970-05-06 22:58 sdi -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 1970-05-06 22:58 ssd -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 1970-05-06 22:58 system -> /dev/block/mmcblk0p23
lrwxrwxrwx root root 1970-05-06 22:58 tz -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 1970-05-06 22:58 userdata -> /dev/block/mmcblk0p24
Sent from my HUAWEI G6-L11 using XDA Free mobile app

Maybe it's SuperSU binary, some users reported problems. If you find out the problem please report it here also

dont think it's a superSu binary problem...
this is
fstab.qcom
file in the root folder, there are no sdcards block mounted....
# Android fstab file.
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
#TODO: Add 'check' as fs_mgr_flags with data partition.
# Currently we dont have e2fsck compiled. So fs check would failed.
#
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1 wait
/dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc wait,check,encryptable=footer,continue
/dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 nosuid,nodev,barrier=1 wait,check,continue
/dev/block/platform/msm_sdcc.1/by-name/persist /persist ext4 nosuid,nodev,barrier=1 wait,check,continue
/dev/block/platform/msm_sdcc.1/by-name/log /log ext4 nosuid,nodev,barrier=1 wait,check,continue
-----------------------------------------------------
the internal and external sdcard are mounted for non root mode by
/etc/internal_sd.fstab
#
/devices/msm_sdcc.2/mmc_host /storage/sdcard1 vfat nosuid,nodev wait,voldmanaged=external_sd:auto
/devices/msm_sdcc.1/mmc_host /storage/sdcard0 vfat nosuid,nodev wait,voldmanaged=internal_sd:25
/devices/platform/msm_hsusb_host /storage/usb vfat nosuid,nodev wait,voldmanaged=usbotg:auto
Sent from my HUAWEI G6-L11 using XDA Free mobile app
---------- Post added at 07:52 PM ---------- Previous post was at 07:22 PM ----------
the my big problem is... for example
i cant bakup system files to sdcard for same tests or cant copy a bootanimation.zip from sdcard to the root /cust folder for a personalized bootanimation etc etc..
Sent from my HUAWEI G6-L11 using XDA Free mobile app

Joseph Katana said:
If you having problems with Towelroot try RootGenius, Vroot or Kingo to root it.
Sent from my HUAWEI G6-L11 using XDA Free mobile app
Click to expand...
Click to collapse
Well, i just tried, Root Genius: stuck at connecting, Vroot detects my phone but fails at the end, Kingo doesn't detect my g6-l11.
Tried with 2 cables and 2 computer ( just in case )
So i guess, i'll just give up and wait for a better way to root it later.

amonpaike said:
i have rooted my g6, but i have a problem.. when i use root-explorer end it get root access , bhot sdcards (internal and external) disappear.. how can i fix this?
Sent from my HUAWEI G6-L11 using XDA Free mobile app
Click to expand...
Click to collapse
that problem is know. you can read how to solve it here: http://forum.xda-developers.com/android/general/huawei-ascend-g6-root-method-t2805938

washichi said:
that problem is know. you can read how to solve it here: http://forum.xda-developers.com/android/general/huawei-ascend-g6-root-method-t2805938
Click to expand...
Click to collapse
ok! i have used rootgenius metod and now sdcards are accessible in root mode.. tankyou!
Sent from my HUAWEI G6-L11 using XDA Free mobile app

Thank you for this info I will update the guide and post a link to this thread.

need urgent helpp
Joseph Katana said:
Please explain what you did to make it softbricked? Did you made build.prop backup?
Sent from my HUAWEI G6-L11 using XDA Free mobile app
Click to expand...
Click to collapse
Yes i have a backup but phone isnt starting and bootloader is locked and i dont know how to unlock it and flash the built.prop back. this is my first huawei phone. I downloaded whole firmware but dont know how to flash it

feetsonfire said:
Yes i have a backup but phone isnt starting and bootloader is locked and i dont know how to unlock it and flash the built.prop back. this is my first huawei phone. I downloaded whole firmware but dont know how to flash it
Click to expand...
Click to collapse
extract the downloaded official firmware to your sd, so you will get: SD:/dload/UPDATE.APP
then reboot your phone, and it will install

trouble with bootloader lock and firmware upgrades
Hi everyone!
I'm fairly new (to the board, too) and this thread has been resting for a while, but still I want to share my experience of rooting the Huawei Ascend P7 mini (or G6-L11) since there are tons of posts and threads out there on how to do it and they all did not work for me.
First of all, thanks for your guide, Joseph Katana! Helped me out partially.
I spent days on searching and trying and finally (just 2 hours ago!) I did it! So here are my Do's and Dont's:
After unpacking and booting for the first time, of course I went straight to updating from P7miniV100R001dontaskmeforgottomakescreenshot to P7miniV100R001C??B370 (also forgot to do a screenshot). First mistake, as the new firmware updates to Android 4.4.2 and I was not able to root my phone with whatever tool there is.
Took me a few hours of researching why I could not flash my phone, since its bootloader was locked to begin with. Turn to [email protected] for requesting an unlock code and make sure to include your phone specs such as Model-no, S/N, IMEI and PID. Alternatively, there are tons of 3rd-party softwares and websites which offer the same service (tho they'll want your PayPal specs, too : ).
So, I was basically all set, my phone was quickly unlocked via Fastboot. After some hours more of devouring tutorials and stuff I also had the appropriate USB-Drivers and HiSuite v2.3.42 installed (tho now I'm not sure, if that was even needed). Still RootGenius v1.8.7 kept complaining what a tough cookie I had, so I told it to shut it and turned to Framaroot, Towelroot, RootGenius v2.20(Chinese version) and basically went through each and every other tool. All failed.
And here's where it's back to Point 1. Just out of frustration I downgraded the firmware B370 back to B127. And surprisingly my phone was game since it rebooted without complaint and I was back to where I started. Of course I ran RootGenius again, but it wouldn't connect so I tried the Chinese versions. I know pretty risky to push buttons without knowing what they're doing, but the program recognized my phone correctly and I was able to root it successfully! Just to be sure, I checked with RootGenius v1.8.7. It connected immediately and also confirmed the root.
And to be absolutely sure I installed Xposed Framedwork, checked "Disable Resource Hooks" ("Ressourcen-APIs deaktivieren" in german) and voila, I was free to pick any module I so desired.
My phone is now running Android 4.3 Emotion UI 2.0 Lite G6-L11V100R001C00B127. Actually I had been expecting SuperSU but now it's Kinguser-Root, but I'm fine with that.
I have not yet tried out much with installing modules and stuff since it's all quite fresh.
Just wanted to let you know that it is doable : )

[Fixed][Q] possible permanent soft-brick tf700t

So, I just managed to get the Bootloader unlocked, flashed CWRM and then accidentally hit the factory reset button from the system settings menu, and am now stuck in the reset recovery screen.
I have access to adb but not fastboot. I have not done anything with NVFLASH
Am I permanently screwed for this motherboard or can I still be recovered?
ls -l /dev/block/mmc*
__bionic_open_tzdata: couldn't find any tzdata when looking for localtime!
__bionic_open_tzdata: couldn't find any tzdata when looking for GMT!
__bionic_open_tzdata: couldn't find any tzdata when looking for posixrules!
brw------- 1 root root 179, 0 Aug 29 02:23 /dev/block/mmcblk0
brw------- 1 root root 179, 16 Aug 29 02:23 /dev/block/mmcblk0boot0
brw------- 1 root root 179, 32 Aug 29 02:23 /dev/block/mmcblk0boot1
brw------- 1 root root 179, 1 Aug 29 02:23 /dev/block/mmcblk0p1
brw------- 1 root root 179, 10 Aug 29 02:23 /dev/block/mmcblk0p10
brw------- 1 root root 179, 2 Aug 29 02:23 /dev/block/mmcblk0p2
brw-rw---- 1 root system 179, 3 Aug 29 02:23 /dev/block/mmcblk0p3
brw-rw---- 1 root system 179, 4 Aug 29 02:23 /dev/block/mmcblk0p4
brw------- 1 root root 179, 5 Aug 29 02:23 /dev/block/mmcblk0p5
brw------- 1 drm drm 179, 6 Aug 29 02:23 /dev/block/mmcblk0p6
brw-rw---- 1 root system 179, 7 Aug 29 02:23 /dev/block/mmcblk0p7
brw------- 1 root root 179, 8 Aug 29 02:23 /dev/block/mmcblk0p8
brw------- 1 root root 179, 9 Aug 29 02:23 /dev/block/mmcblk0p9
Click to expand...
Click to collapse

Code:
adb shell
~ #cd sys
/sys # ls
ls
block class devices fs module tf_driver
bus dev firmware kernel power
/sys #cd block
/sys/block # ls
ls
loop0 loop2 loop4 loop6 mmcblk0 mmcblk0boot1
loop1 loop3 loop5 loop7 mmcblk0boot0 zram0
can I use this to edit something and unbrick?

Stephenopolos said:
Code:
adb shell
~ #cd sys
/sys # ls
ls
block class devices fs module tf_driver
bus dev firmware kernel power
/sys #cd block
/sys/block # ls
ls
loop0 loop2 loop4 loop6 mmcblk0 mmcblk0boot1
loop1 loop3 loop5 loop7 mmcblk0boot0 zram0
can I use this to edit something and unbrick?
Click to expand...
Click to collapse
If you reboot by long pressing the power button, does it boot straight back to recovery?
If so you can try these commands to clear the Wipe Data command from the misc partition:
Code:
adb shell
dd if=/dev/zero of=/dev/block/mmcblk0p3 bs=64 count=1
reboot
Good luck!

Thanks for the quick response. Yes it does drop immediately into the recovery/reset wipe data screen on reboot.
It's pretty late and I want to avoid making any mistakes in typing commands so I'm going to try that in the morning.
Also, while i'm not the best at the command line side, I am comfortable opening things up, so if it doesn't work I'm not entirely opposed to just buying a replacement MB and swapping it out. Hopefully it'll work though.

Stephenopolos said:
Thanks for the quick response. Yes it does drop immediately into the recovery/reset wipe data screen on reboot.
It's pretty late and I want to avoid making any mistakes in typing commands so I'm going to try that in the morning.
Also, while i'm not the best at the command line side, I am comfortable opening things up, so if it doesn't work I'm not entirely opposed to just buying a replacement MB and swapping it out. Hopefully it'll work though.
Click to expand...
Click to collapse
If you use Wipe Data from the bootloader or the Factory reset from Settings a command gets written to misc to start the recovery and wipe data.
Problem is, custom recoveries don't really "get" the command and do not execute it so the command does not get erased from misc and you're stuck in booting to recovery because the bootloader executes that command on each boot.
If your recovery is CWM you can try just leaving it on the wipe data screen for a few hours. With past CWM versions that usually worked and it eventually finished the wipe. Not with TWRP though.
Connect the tab to power and leave it on the wipe data screen until tomorrow. Then you can still try to clear the command with dd.
Copy and paste it. You don't want to have any typos with a dd command...

berndblb said:
Problem is, custom recoveries don't really "get" the command
Click to expand...
Click to collapse
Only if your recovery kernel is too old to work with the bootloader, in which case it can't access any partitions.
berndblb said:
If your recovery is CWM you can try just leaving it on the wipe data screen for a few hours. With past CWM versions that usually worked and it eventually finished the wipe. Not with TWRP though.
Click to expand...
Click to collapse
TWRP should do its "Factory Reset" (which doesn't clear /sdcard). I've never tried it because I don't want to restore everything from a backup.

ran command this morning, and it hung in the shell... just sits there without finishing the command.
frustrating... I thought i'd read everything and triple read it again, but the main thread for custom recoveries for this tablet, didn't really mention anything about avoiding factory reset from device.
oh well. found a MB on ebay cheap i'll try the command again in a bit and if it doesn't work then next week i'll be installing a mb myself.
Code:
adb shell dd if=/dev/zero of=/dev/block/mmcblk0p3 bs=64 count=1
1+0 records in
1+0 records out
64 bytes (64B) copied, 402.164494 seconds, 0B/s
I'm assuming this means success...
will see in a bit... tablet is now claiming it has a low battery after I told it to reboot.

Hallelujah! it worked! berndblb You're my new favorite person in the world today.

_that said:
Only if your recovery kernel is too old to work with the bootloader, in which case it can't access any partitions.
TWRP should do its "Factory Reset" (which doesn't clear /sdcard). I've never tried it because I don't want to restore everything from a backup.
Click to expand...
Click to collapse
I have never tried it either. Just seen users reporting that with CWM installed the command eventually went through if you left it alone long enough. That doesn't seem to work with TWRP. But that's just hearsay....
Stephenopolos said:
Hallelujah! it worked! berndblb You're my new favorite person in the world today.
Click to expand...
Click to collapse
Very good!
But you have to thank @_that ^^^ for the command. He's the one I stole it from

berndblb said:
I have never tried it either. Just seen users reporting that with CWM installed the command eventually went through if you left it alone long enough. That doesn't seem to work with TWRP. But that's just hearsay....
Very good!
But you have to thank @_that ^^^ for the command. He's the one I stole it from
Click to expand...
Click to collapse
... you got to me first though...
Anyway, I had difficulty getting CM11 and CM12 to install eventually managed to get zombipop to install by dropping it onto a USB stick and using the keyboard dock. Had to flash a new recovery image as well.. apparently the one I put on there the first time around was screwy.

Stephenopolos said:
... you got to me first though...
Anyway, I had difficulty getting CM11 and CM12 to install eventually managed to get zombipop to install by dropping it onto a USB stick and using the keyboard dock. Had to flash a new recovery image as well.. apparently the one I put on there the first time around was screwy.
Click to expand...
Click to collapse
Luck for you that I was here first. _that would have made you pull all kinds of logs before giving you the same command :laugh: :cyclops:

berndblb said:
Luck for you that I was here first. _that would have made you pull all kinds of logs before giving you the same command :laugh: :cyclops:
Click to expand...
Click to collapse
The required logs in this case are already in the OP. But thank you for taking over first level support.

[Recovery][OFFICIAL][UBL] TWRP 3.1.1 Touch Recovery for Xperia L

{
"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

Rapid Temporary Root for HD 8 & HD 10

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 table​If 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?