[RECOVERY][3.0.2.0][OFFICIAL] TWRP Recovery for Plank (Honor 7)

[zinko_pt]

I can't use the "fastboot boot twrp-3.0.2-0-plank-modaco-rc3.img" command. Always results in a "Command not allowed" error. I used this with all my phones before to do a nandroid backup including the stock recovery. Why doesn't it work with the Honor 7? Bootloader is unlocked, drivers installed, adb and fastboot work... I tried with other versions of twrp, same result.

Any idea what could be the issue? Or does this just not work with this phone?

fastboot boot twrp-modaco-rc3.img
downloading 'boot.img'...
OKAY [ 0.594s]
booting...
FAILED (remote: Command not allowed)
finished. total time: 0.606s

PS: I don't want to try and flash the recovery before I pulled a full stock backup. But maybe that will fail, too, anyway. Hoping for some input if other have the same issue.

I think H7 does not allow booting live bootloaders. You have to install it.
I wanted to do the same: do not install TWRP, just boot it to install SuperSU and do the normal operations.

 

[t-ryder]

All OTAs, stock images and stock recoveries are available for download somewhere. Download all you need now (to be safe just in case), and use Honor Multitool to do your stuff.
Before I unlocked my bootloader using DC unlocker I downloaded everything so I can go back to complete stock with locked BL without hustle.

 

[paulobrien]

I can't use the "fastboot boot twrp-3.0.2-0-plank-modaco-rc3.img" command. Always results in a "Command not allowed" error. I used this with all my phones before to do a nandroid backup including the stock recovery. Why doesn't it work with the Honor 7? Bootloader is unlocked, drivers installed, adb and fastboot work... I tried with other versions of twrp, same result.

Any idea what could be the issue? Or does this just not work with this phone?

fastboot boot twrp-modaco-rc3.img
downloading 'boot.img'...
OKAY [ 0.594s]
booting...
FAILED (remote: Command not allowed)
finished. total time: 0.606s

PS: I don't want to try and flash the recovery before I pulled a full stock backup. But maybe that will fail, too, anyway. Hoping for some input if other have the same issue.

Huawei phones don't support fastboot boot.

P

 

[SoulSeekerHS]

OK, thanks for the answers. Thought as much, but figured I might just be missing something. Weird that Huawei would block booting a recovery, but alas, as long as I can flash it...

 

[Ing.King]

Sorry for silly question. Can I boot fastboot boot twrp.img without unlocking of bootloader ?

 

[Icetea]

Sorry for silly question. Can I boot fastboot boot twrp.img without unlocking of bootloader ?

this really silly question was answered only a few post back my friend!!!
look here -> http://forum.xda-developers.com/showpost.php?p=67828469&postcount=83

 

[Ing.King]

my lazy ass didn´t read 2 posts earlier... my bad

 

[m_esser]

Hello @paulobrien;

thanks again for your effort regarding TWRP for Honor 7 devices. I have a question regarding the USB OTG support of TWRP 3.0.2.

Currently I strive to enhance my custom rom H7cROM so that it will store several files to an usbotg device (if one is attached).

In order to check if a device is attached to usbotg I wanted to use a little trick as part of the updater-script file:

• simply create a folder on /usbotg and copy a file to that folder
• ignoring potential error messages
• checking whether the file exists

.
During my tests I had to find out that I can store/write file to the /usbotg (under TWRP) even if there is no device attached. The attached screen was made when no usbotg device was attached

Because of that I am asking myself now

• Where are files stored when no usbotg device is attached?
• How can I implement a valid check to find out whether a device is attached or not?

Perhaps you could provide a useful hint? Thank you in advance!

Best regards
m_esser

 

[DigiGoon]

@m_esser maybe, try checking the partition size? If it's equal to 0 then not attached, but if you get some value then it is attached. Just a thought, don't know if this works.

 

[m_esser]

@m_esser maybe, try checking the partition size? If it's equal to 0 then not attached, but if you get some value then it is attached. Just a thought, don't know if this works.

Thanks for the hint ... will check it

Best regards
m_esser

 

[DigiGoon]

Thanks for the hint ... will check it

Best regards
m_esser

Yes, and do report back so that we can know if it works.

 

[hackslash]

@m_esser
I don't know if it would work but you could try it.

Try the Mount applet from Busybox. You can check the status of the mount command by looking at the return codes:

RETURN CODES
       mount has the following return codes (the bits can be ORed):
       0      success
       1      incorrect invocation or permissions
       2      system error (out of memory, cannot fork, no more loop devices)
       4      internal mount bug
       8      user interrupt
       16     problems writing or locking /etc/mtab
       32     mount failure
       64     some mount succeeded

You can use echo $ to display the error code.
What you can basically do is write a script that first unmounts the USB OTG (will unmount if present, will fail if not mounted) and then try to remount it. Read the return code for the remount part. If it's "0", then that means USB is mounted successfully and you can continue whatever you were initially thinking to do and if it returns any other code, you can simply display a message like "USB not inserted" or error basically referring to the reason why the mount failed. Now this has some obvious flaws such as if the script is being executed from the USB itself, then you know...
I took this information from here http://unix.stackexchange.com/questions/38870/how-to-check-if-a-filesystem-is-mounted-with-a-script and there is a nice little bash script in the answer which can help you achieve what you want to.

The second method which you can also use is to use df applet in busybox. Executing command:

df -h

will list the partition, mount point, size and other stuff about all mounted partitions. Channel the output to a text file:

df -h > output.txt

Then try to search for the USB OTG mount point or the partition itself and if it's found, execute the commands you want to:

File=output.txt
 if grep -q /usbotg "$File"; then
   >> commands to execute
 fi

Well it could be as simple as checking the size of the directory, but I wanted to add more insight to the topic and give how I may tackle the same issue. I haven't tested both the methods but since the all commands are available via Busybox, I think it might work.

 

[m_esser]

@hackslash and @DigiGoon: Thank you very much for your suggestions:good:! Both hints were very helpful for me.

I have played around with several "approaches" considering your input. At the end I have found the following solution for my issue:

• by using the function 'getdisksize("/usbotg","m")' I am getting the size of the partition /usbotg (as part of the aroma config file)
• if no usb otg device is attached the funktions returns "-1" and otherwise the size of the partition
• the value gets stored in an aroma prop file so that it can be accessed during the core installation
• during the core installation (execution of updater-script file) I am using the function "file_getprop" to read the parition size and to find out whether there is a device attached via USB OTG

So, my main issue is solved ... thanks to your input.

But I am still a bit surprised that a script can create folders and write files to /usbotg even though there is no phyiscal device attached.

Best regards
m_esser

 

[DigiGoon]

But I am still a bit surprised that a script can create folders and write files to /usbotg even though there is no phyiscal device attached.

Best regards
m_esser

Yes that's a bit strange, it should store it somewhere, did you try to explore any temp directory after the installation?

 

[m_esser]

Yes that's a bit strange, it should store it somewhere, did you try to explore any temp directory after the installation?

To be honest - I didn't because I wanted to focus on the solution and not on the problem. Perhaps paulobrien can fix that issue very fast (e. g. by making this "virtual" partition read-only or something similar).

Best regards
m_esser

 

[DigiGoon]

To be honest - I didn't because I wanted to focus on the solution and not on the problem. Perhaps paulobrien can fix that issue very fast (e. g. by making this "virtual" partition read-only or something similar).

Best regards
m_esser

It will take sometime, as he has to manage all the Honor devices.

 

[hackslash]

@m_esser
Think of it as your Ubuntu drive where you can create folders and add data to it or mount a partition over that directory (which is basically a symlink, much advanced approach though). As far as I think of it, when you boot to recovery or you boot to system, all other partitions are mounted at one main partition at different directories. That main partition stores all the SoC related files and drivers, proc folders, etc. That main partition is still a partition and you can add data to it up to the storage limit of that partition. Remember that a folder is just a typical folder until a partition is mounted over it. That folder can store data and the space will be used from the partition the folder is created into. It's actually not a bug in any case. If a partition allows user to create folders, then hell yes, it would let it create (unless there are permissions issues which is not the case here because TWRP mounts partitions RW which allows it to actually create folders on that main partition and mount all partitions onto it).

My thoughts or knowledge of how it works can be really wrong but it's what I think it is.

 

[m_esser]

@m_esser
Think of it as your Ubuntu drive where you can create folders and add data to it or mount a partition over that directory (which is basically a symlink, much advanced approach though). As far as I think of it, when you boot to recovery or you boot to system, all other partitions are mounted at one main partition at different directories. That main partition stores all the SoC related files and drivers, proc folders, etc. That main partition is still a partition and you can add data to it up to the storage limit of that partition. Remember that a folder is just a typical folder until a partition is mounted over it. That folder can store data and the space will be used from the partition the folder is created into. It's actually not a bug in any case. If a partition allows user to create folders, then hell yes, it would let it create (unless there are permissions issues which is not the case here because TWRP mounts partitions RW which allows it to actually create folders on that main partition and mount all partitions onto it).

My thoughts or knowledge of how it works can be really wrong but it's what I think it is.

@hackslash: I think that your explanation is not wrong - it is going into the right direction and it is explaining why folders and file scan be stored. If a device is attached via OTG the "symlink" is pointing to the device if not it is pointing to a folder of the "main partition".

Best regards
m_esser

 

[DigiGoon]

@hackslash
Yes, you are correct, the main partition has various mount points of our device's partitions, defaults like /system, /boot, /cust, /data. etc so as you said, we can create folders in mount points, as basically the mount point is itself a folder, symlinked to the real partitions(that's why the use of recovery.fstab).
So, the files stored inside /usbotg should reside here: main_partition/usbotg/
Thanks for the explanation.

 

[lakistrike95]

Does it works with PLK-TL01H? I have 4.0.1 EMUI, B380.
Is twrp-3.0.2-0-plank ok?