Port Request for HUAWEI Honor 4X Che1-CL20

jerryhou85 commented 8 years ago

Hi Lanchon, Can I have a REPIT configuration file for my HUAWEI Honor 4X Che1-CL20? Thanks.

your exact device and device codename. http://www.phonemore.com/phone/huawei-honor-4x-che1-cl20/2184 HUAWEI Honor 4X Che1-CL20

your recovery (version? official? if not where did you get it?). http://forum.xda-developers.com/android/development/recovery-twrp-2-8-7-0-touch-recovery-t3199386 [RECOVERY][cherry] TWRP 2.8.7.0 touch recovery for Huawei G620S, Honor 4/4X

your kernel. Stock CM12.1 kernel, Linux 3.10.x

your rom. http://forum.xda-developers.com/android/development/rom-cyanogenmod-12-1-nightlies-huawei-t3203635 [ROM][Official][5.1.1][Nightly]CyanogenMod 12.1 Nightly for Huawei G620S,Honor 4/4X

is your device running the stock partition layout or is it already modified? Stock partition layout

Honor 4X Che1-CL20 repit-dump.zip

Lanchon commented 8 years ago

hi,

thanks for your request. cherry looks like a completely viable target for REPIT.

1) it looks like cherry is already partitioned in a usable manner and that REPIT is not really needed for this platform. could you please explain your motivation to repit?

2) do you happen to know what 'cust' and 'misc' partitions are used for in cherry? a link with info would be helpful.

thanks!

Lanchon commented 8 years ago

PS. it's no big effort to port repit. i just need to know what you want to do with it, so as to be sure that i bring the right partitions under management by repit.

jerryhou85 commented 8 years ago

Hi Lanchon, Thanks for your prompt reply.

The reason I'd like to get a REPIT file is that Cherry built with 8G ROM, but only 4G is usable to user even I'm using CM12.1 instead of stock EMUI ROM. I'm thinking can REPIT a easier way to re-partition the phone without losing any data?
I'm not sure about usage, but I saw it in another post, someone delete cust and system first and re-partition cust with 120M and system with 899M for a trimmed ROM. I'll find more information about these.

Regards Jerry

Lanchon commented 8 years ago

ok, that's the info i need. could you please point me to that thread? i need to see what's acceptable and recommended. thanks!

jerryhou85 commented 8 years ago

Hi Lanchon, You can refer to this post: http://tieba.baidu.com/p/3859064087 Sorry it's all Chinese, but you can see the picture around middle of the page of the final partition result of OP. And in the post he mentioned he flashed a highly trimmed custom ROM by a Chinese ROM maker, so he only gave /system 900MB.

Jerry

Lanchon commented 8 years ago

but that device is completely different! it has 40 partitions versus the 24 that your device has, check it out:

chinese: http://imgsrc.baidu.com/forum/pic/item/c7ce7beef01f3a29d093bb189c25bc315d607c2c.jpg

yours:

18      288MiB   308MiB   20.0MiB               boot
19      308MiB   332MiB   24.0MiB               recovery
20      332MiB   1100MiB  768MiB   ext4         cust
21      1100MiB  1356MiB  256MiB   ext4         cache
22      1356MiB  1360MiB  4.00MiB               misc
23      1360MiB  3152MiB  1792MiB  ext4         system
24      3152MiB  7456MiB  4304MiB  ext4         userdata
        7456MiB  7456MiB  0.01MiB  Free Space

so let me explain the problem with your device...

misc! misc is in the middle of everything. misc is typically used to tell the bootloader what to boot (ie: android or recovery) and some other things. see: https://lwn.net/Articles/504721/ so misc is probably accessed from the bootloader, before the kernel is up and running.

and the problem is: while REPIT can alter the partition table (GPT) and move misc and keep its contents, i have no guarantee that the bootloader will actually read the GPT to find where misc is. the location of misc could be replicated elsewhere, including the bootloader itself.

for instance, in samsung devices, the information of the partition table is stored in a number of places: in the GPT (for linux) and in areas known as "PIT"s. i've seen more than one PIT in the same device, one as part of the bootloader partition and the other i don't remember where (all having the same data). because the PIT is stored in the bootloader, i presume that the bootloader will just grab the info from there instead of reading parsing the more complex GPT.

samsung devices have a procedure to "PIT" (partition) from the bootloader (called download mode) that presumably updates all PIT copies and creates the GPT too. REPIT cannot do this proprietary stuff, and so i chose not to touch partitions that could be used by the bootloader, modem etc. i only touch partitions that the linux kernel accesses, knowing all too well that linux finds them via the GPT. so it all works. (the PITs are not modified and keep the stock partition layout, but linux doesn't know PITs (so it doesn't care that PIT data is out of sync), and the bootloader doesn't know filesystems (so it never accesses /system /data etc via the PITs.))

in your case: -it should be presumed that misc is accessed from the bootloader. -there is no assurance that the bootloader will read the location of misc from the expected place, the GPT, instead of from some obscure proprietary place.

so the problem is that to keep misc where it is i can resize this pair: 20 332MiB 1100MiB 768MiB ext4 cust 21 1100MiB 1356MiB 256MiB ext4 cache (which is useless)

and this pair: 23 1360MiB 3152MiB 1792MiB ext4 system 24 3152MiB 7456MiB 4304MiB ext4 userdata

so i can shrink /system to 1GB and give you 0.75GB extra to /data (userdata). but i can't give your an additional added 1GB to /data taken from /cust and /cache!

in REPIT parlance, this device would have two "heaps". each heap is processed independently. (this is a limitation of REPIT, btw: REPIT cannot alter the order of partition's on-disk areas and thus cannot move partitions among different heaps.)

solutions for you:

a REPIT that can only shrink /system. will give you around 0.75GB extra to /data.
manually repartition and move /system from the first heap to the second. you will end up with very small /cache and /cust (no prob i think) and around 0.9GB /system. you cannot have a bigger /system, that's it! then you could use REPIT to resize /data without loosing your stuff. this would give you an added 1.75GB in /data. (but is a very manual procedure.)
hope for the best: that the bootloader finds misc via the GPT and use a fully configured REPIT to move misc. i though of a reasonably safe test for this: it would tell us where the bootloader reads misc from, ideally without causing boot problems. if misc can be moved (ie: BL reads from GPT) then great, we have full REPIT! otherwise, the changes done for this test can easily be reverted to stock. (but things could always go wrong! no warranties you know...)

so assuming you understood me (read again to make sure!), which direction you want to go?

thanks!

jerryhou85 commented 8 years ago

Hi Lanchon, Thanks for your replay. I think since I decide to do it, then why not do it to full? :) I'd like to try the third method, trying to get a full REPIT!

Thanks.

Lanchon commented 8 years ago

ok. i hope you understand this kind of experiment always entails some risk.

so this is the plan... 20 332MiB 1100MiB 768MiB ext4 cust 21 1100MiB 1356MiB 256MiB ext4 cache 22 1356MiB 1360MiB 4.00MiB misc 23 1360MiB 3152MiB 1792MiB ext4 system 24 3152MiB 7456MiB 4304MiB ext4 userdata

use a test REPIT build to:

reduce size of cache by a few megabytes and move misc up (closer to the start of the disk).
not touch system at all, leaving a gap of unpartitioned unused space where misc currently is.

then:

if the bootloader reads misc using the GPT (case GOOD), then it will read the right data from the relocated partition (REPIT copied the data there).
if the bootloader reads misc using a proprietary partitioning table scheme (case BAD), then it will read the data from the original, pre-relocation misc area. (REPIT cannot know of nor modify obscure proprietary partition tables.) but the bootloader will still read the right data: the disk area that once was 'misc' will now be marked as unused in the GPT; but nothing actually overwrites it, so the right data will still be there.

so the expectation is that no mater what case (GOOD or BAD), the bootloader will find valid data and will boot as always. so theoretically there is no chance of bricking.

now we need to find out where the BL is reading from, so...

reboot the phone to android, making sure the reboot-to-recovery flag is not set.
in android, we request reboot to recovery by any means (eg: adb root; adb reboot recovery). android will signal reboot-to-recovery by writing a flag in the misc partition, then reboot the device. (the partition modified will be the new one, as the linux kernel will find misc via the GPT.)
then the device reboots and the BL takes over:
- if the BL boots recovery (case GOOD) it means that it read the new misc via the GPT. now we know that the misc partition can be moved. SUCCESS!
- if the BL boots android (case BAD) it means that it read the old misc via some proprietary partition table. the misc partition cannot be moved, and we need to REPIT back to original state. FAIL :(

assumption:

the reboot flag is actually stored in misc. on standard android it is, but the manufacturer could have modified that.

if you dare to go ahead with this, i'll code the test REPIT build.

sorry this is so complicated. other devices would get ported immediately by me with the very complete info you gave in your first post. your device is certainly special in this regard.

jerryhou85 commented 8 years ago

Hi Lanchon, Thanks for your explanation. I think this is a thoughtful and good plan, I understand there always will be some risk, let's just proceed to the test. :)

Lanchon commented 8 years ago

ok!

this file should cut cache in half, and move misc 128MB closer to the start of the disc: lanchon-repit-20160415-cust=same-cache=0.125+wipe-cherry_test.zip

flash using twrp; will fail.
flash again from /tmp; will succeed.
now boot into android. let's hope it boots.
now, in android, request to reboot to recovery (by any means).
note what happens:
- boots to recovery: looks like bootloader reads partitions from GPT, hurray!
- boots to android: BL reads partitions from some proprietary place... we cant move misc.

please report, thanks!!

jerryhou85 commented 8 years ago

Hi Lanchon, I downloaded the file and follow your REPIT guide. Here are things I've done:

Download the zip file to /sdcard/Download
in CM12.1, long press power button, select "Reboot to recovery"
in TWRP 2.8.7 recovery, flash zip file from folder, failed (can't umount /sdcard: Device or resource busy
flash zip again from /tmp, showing "info: rereading partition table" and then next line "blockdev: /dev/block/mmcblk0: Device or resource busy", then same error message below as step 3, "FATAL: unable to reread the partition table (please reboot TWRP and run this package again; run it immediately after boot up...".
Thought I may be using the wrong method to enter TWRP, this time I powered off my phone and press vol up + power to enter recovery, same steps as above: failed, flash again from /tmp. Same error message.
Reboot into system, check phone settings, phone not encrypted and SELinux is enforcing (not sure related or not, just check)

Is there any step I did wrong? Please advise. Thanks.

Lanchon commented 8 years ago

some builds of TWRP don't like to release locks:

boot recovery (any method is same).
in 'Mount', disable MTP.
disconnect from USB.
reboot recovery.
flash from sdcard, then flash from /tmp.

jerryhou85 commented 8 years ago

repit-dump-new.zip Hi Lanchon, I just found out that I need to manually un-mount all partitions in Mount menu in TWRP 2.8.7, after that I flashed twice, its log shows OK. Then I reboot to system, and long press power button, select Reboot into recovery, and I successfully reboot into TWRP 2.8.7.

I also get a new repit-dump after flash the zip for your reference.

I think that means it is OK to proceed a full REPIT?

Lanchon commented 8 years ago

cool! thanks!

it means:

the device is standard android: it reads the boot flag from /misc as normal android does, and the BL reads partition info form the GPT as normal BLs do. all is cool! which is not surprising for a non-samsung device.
or... the device is all-nonstandard and the reboot flag is not even stored in /misc lol :)

i would say first option is immensely more probably, which means that very probably full repit would work. i can't think of any more tests. all looks cool but next step would be leap of faith. i'll prepare full repit for you while you think about whether to go forward :)

Lanchon commented 8 years ago

EDIT: WAIT!!! DONT CONTINUE! that repit-dump-new.zip doesn't show partition any changes!! are you sure it's the new log?? this doesn't make sense if the repit went well to the [OK] finish! could you please reflash the previous repit and post REPITs log? thanks!

ok, this is the best i can do, now you have to figure out if you can run the risk :)

this wipes cust and cache, and sets /system to 1GB. (which might not fit its current contents! so check/adjust according to your needs.) note that changing the start of /data is a long, expensive operation.

lanchon-repit-20160416-cust=min+wipe-cache=0.03125+wipe-system=1.0-data=max-cherry.zip

good luck!

jerryhou85 commented 8 years ago

EDIT: oh, I get it: I used IDM to download your zip file which will change the file name to lanchon-repit-20160415-cust.same-cache.0.125.wipe-cherry_test, no more "=", so the params are all the same. I'll do the tests again and let you know. Sorry for being so dumb... :-1:

EDIT 2: YEEEEEEEEEEEEEEEEEEEEES!!!!!!!! I flashed with correct params this time and did see 128M free space in repit-dump. I reboot into system and select Reboot into recovery. TWRP 2.8.7 was popped up again. :) I'll proceed to the real file after I find out how much space I need for /system. Thank you again for your help!!!

Original: I just checked the log, I notice this part, does this mean nothing to change?

processing heap 'main'

info: checking existing partition layout info: current size: partition #20 'cust' (cust): 768 MiB info: current size: partition #21 'cache' (cache): 256 MiB info: current size: partition #22 'misc' (misc): 4 MiB info: checking new partition layout info: new size: partition #20 'cust' (cust): 768 MiB info: new size: partition #21 'cache' (cache): 256 MiB info: new size: partition #22 'misc' (misc): 4 MiB

Full log: _ #################################### Lanchon REPIT A Data-Sparing Repartitioning Tool Version: 2016-04-15 Device: cherry_test Copyright 2016, Lanchon (GPLv3) ####################################

----- DEFAULTS ----- cust = size:same + content:keep + fs:ext4 cache = size:same + content:keep + fs:ext4

info: parsing package name

----- CONFIGURATION ----- cust = size:same + content:keep + fs:ext4 cache = size:same + content:keep + fs:ext4 misc = size:same + content:keep + fs:raw

info: disabling swap info: unmounting all partitions info: rereading partition table

===== PREPARATION ===== info: determining usable sector range of block device info: checking existing partitions

processing heap 'main'

info: checking existing partition layout info: current size: partition #20 'cust' (cust): 768 MiB info: current size: partition #21 'cache' (cache): 256 MiB info: current size: partition #22 'misc' (misc): 4 MiB info: checking new partition layout info: new size: partition #20 'cust' (cust): 768 MiB info: new size: partition #21 'cache' (cache): 256 MiB info: new size: partition #22 'misc' (misc): 4 MiB

===== DRY-RUN =====

processing heap 'main'

----- analyzing partition #20 'cust' (cust) * processing partition #20 'cust' (cust) info: will resize the ext4 file system if needed to fit its partition info: checking and trimming the file system /dev/block/mmcblk0p20: 54/49152 files (0.0% non-contiguous), 12388/196608 blocks ----- analyzing partition #21 'cache' (cache) * processing partition #21 'cache' (cache) info: will resize the ext4 file system if needed to fit its partition info: checking and trimming the file system /dev/block/mmcblk0p21: 21/16384 files (0.0% non-contiguous), 2106/65536 blocks ----- analyzing partition #22 'misc' (misc) ***\ processing partition #22 'misc' (misc)

===== EXECUTION =====

processing heap 'main'

----- analyzing partition #20 'cust' (cust) ***\ processing partition #20 'cust' (cust) info: resizing the ext4 file system if needed to fit its partition resize2fs 1.42.9 (28-Dec-2013) The filesystem is already 196608 blocks long. Nothing to do!

info: checking and trimming the file system /dev/block/mmcblk0p20: 54/49152 files (0.0% non-contiguous), 12388/196608 blocks ----- analyzing partition #21 'cache' (cache) ***\ processing partition #21 'cache' (cache) info: resizing the ext4 file system if needed to fit its partition resize2fs 1.42.9 (28-Dec-2013) The filesystem is already 65536 blocks long. Nothing to do!

info: checking and trimming the file system /dev/block/mmcblk0p21: 21/16384 files (0.0% non-contiguous), 2106/65536 blocks ----- analyzing partition #22 'misc' (misc) ***\ processing partition #22 'misc' (misc) info: flushing buffers

===== SUCCESS =====

[OK] _

Lanchon commented 8 years ago

lol! ok cool, eagerly waiting for results. thanks!

Lanchon commented 8 years ago

any news?

jerryhou85 commented 8 years ago

repit-dump.zip

18 288MiB 308MiB 20.0MiB boot 19 308MiB 332MiB 24.0MiB recovery 20 332MiB 340MiB 8.00MiB ext4 cust 21 340MiB 372MiB 32.0MiB ext4 cache 22 372MiB 376MiB 4.00MiB misc 23 376MiB 1400MiB 1024MiB ext4 system 24 1400MiB 7452MiB 6052MiB ext4 userdata 7452MiB 7456MiB 4.00MiB Free Space

Hi Lanchon, Last night arrived home late and didn't get it done. This morning I backup first and flash the zip with 1G /system, works like a charm!!! Thank you very much for the awesome REPIT file!

Regards Jerry

Lanchon commented 8 years ago

congrats! thanks!!

jerryhou85 commented 7 years ago

Hi @Lanchon , I'm gonna sell this phone and want to revert to stock ROM. How can I revert to original partition layout? I assume use the same REPIT file and input original partition value? Please enlighten me. Thanks.

Lanchon commented 7 years ago

yep!

your original GPT:

18      288MiB   308MiB   20.0MiB               boot
19      308MiB   332MiB   24.0MiB               recovery
20      332MiB   1100MiB  768MiB   ext4         cust
21      1100MiB  1356MiB  256MiB   ext4         cache
22      1356MiB  1360MiB  4.00MiB               misc
23      1360MiB  3152MiB  1792MiB  ext4         system
24      3152MiB  7456MiB  4304MiB  ext4         userdata
        7456MiB  7456MiB  0.01MiB  Free Space

all partitions are positioned and sized with correct alignment, so it is a question of rerunning REPIT.

try this config. for speed, it will wipe EVERYTHING, including /system: lanchon-repit-20170115-cust=768M+wipe-cache=256M+wipe-system=1792M+wipe-data=4304M+wipe-cherry.zip

afterwards you can rerun the REPIT dumper you used to request this port to verify that the before/after outputs match. (the 'before' version is in the OP of this issue.)

Lanchon commented 7 years ago

by the way, can i ask for a favor?

could you please boot to TWRP, connect to the PC, and from the PC run this command: adb pull /dev/block/platform/7824900.sdhci/by-name/aboot

it will create an 'aboot' file. could you zip it and post it here? this file doesn't have any sensitive information about you or your device.

jerryhou85 commented 7 years ago

@Lanchon I tried the config you posted but it ended up showing me error like below:

It successfully shows some info like before, but then a FATAL.

FATAL: the new partition layout of heap 'main' requires more space than available.

[ERROR 1]

Then the process ends with red font. I suppose it was something with the numbers in config, I'll convert M to G then try again.

jerryhou85 commented 7 years ago

By using the original 20160416 REPIT file, I'm able to get it to work. LOL

lanchon-repit-20160416-cust=0.75+wipe-cache=0.25+wipe-system=1.75+wipe-data=max+wipe-cherry

jerryhou85 commented 7 years ago

@Lanchon Got the aboot file you asked, but I'm having trouble uploading it here.

I put it up in my MEGA. https://mega.nz/#!kttHXICC!WWLnZcmSRabjqAYJCV64yZ4HP35j_hhPt8CgtWFlj9U

Lanchon commented 7 years ago

but you did a data=max. i'm sure that in the current REPIT, had you done the same, it would have worked.

in any case there is something off. i guess the partition layout is not exactly the same as before for some reason. too bad you didn't post the log! :( in any case, running a repit dump now would show any differences if you are interested.

thanks for the aboot file!

Lanchon commented 7 years ago

aboot-cherry.zip

this device (cherry) does not enforce GPT sigantures and works with REPIT, but still has references to GPT sigantures in its bootloader.

this proves that looking for strings in the bootloader is not a reliable way to predict enforcement of GPT signatures as it can result in false positives.

$ strings aboot | grep -i GPT

GPT: FAILED to write the partition entry array
GPT: Could not read primary gpt from mmc
GPT: Could not read backup gpt from mmc
GPT: Primary and backup signatures invalid
GPT: mmc read card failed reading partition entries.
MMC Boot: GPT read failed!
GPT: Primary signature invalid cannot write GPT
GPT: Backup signature invalid cannot write GPT
Failed to write GPT header
Failed to write GPT backup header
GPT: Could not write GPT Partition entries array
GPT: Partition Table written
 gpt

$ strings aboot | grep -i GPT | grep -i sign

GPT: Primary and backup signatures invalid
GPT: Primary signature invalid cannot write GPT
GPT: Backup signature invalid cannot write GPT

Lanchon / REPIT