Moto G 2013 (falcon) 8GB CM 12.1 hang on "rereading partition table"

[angrybb]

Here is the log before hanging http://pastebin.com/4BkcQRif and http://pastebin.com/SjASrEjG

After that i did:
disable mtp from twrp mount menu and restarted recovery
repeated flashing repit, it failed with same error and copied itself to /tmp
flashed repit from /tmp, got same error
entered twrp terminal and umounted /sdcard and /data manualy

Tried all of the above with twrp 3.0.0-0, 3.0.1-0 and 3.0.2-0 with adb debuging on and off, still hangs on same position.
And here is where it hangs: http://imgur.com/a/n1vkp
I left it over night (8h) and still nothing.
Also tried to unmount all partitions by ticking mounts in twrp mount menu, still no progress.

What can i do next? Thanks!

[the-gangster]

Obviously Lanchon already reported exactly this as a bug to TWRP.
See here: http://forum.xda-developers.com/showpost.php?p=68844701&postcount=88
and follow the link there to TWRP bug report.
Maybe if you knew the official maintainer for that device's kernel that could lead to some progress.

[angrybb]

Thanks for the info. On https://twrp.me/devices/motorolamotog2013.html says @luca020400 is maintainer.

[Lanchon]

thank you both! i'll leave this open for others to find. and i'll link the bug reports.

i think TWRP info is outdated and Luca isn't maintaining that TWRP anymore. plus there are no source code links. and i also think i PM'ed Luca with the kernel bug report weeks ago and i didn't receive an answer.

[luca020400]

Sorry if I didn't reply but I don't really know what could lead to this problem
@gmrt owns falcon and may be able to repro it

[gmrt]

@Lanchon
I haven't tried to reproduce the problem yet, I'm just here to say that the source is linked in the message of the commit that added the zImage:

falcon: Unified tree

Kernel: https://github.com/CyanogenMod/android_kernel_motorola_msm8226
at commit 5e5969d404146424cda5b4dbd1d2dcecd6e44bc1

Maybe a README would be more appropriate...

EDIT: oh, and the defconfig used was falcon_defconfig

[Lanchon]

thanks!

i meant that the device sources weren't linked here:
https://twrp.me/devices/motorolamotog2013.html

that was a few weeks ago, but now they are :)

[gmrt]

Oh, OK, I saw your TWRP bug report and thought you were talking about the kernel sources.

Anyway, I'd guess the problem is caused by CyanogenMod/android_kernel_motorola_msm8226@56621de (CONFIG_APANIC_MMC)

[Lanchon]

interesting piece of crap! congrats on finding that out so fast, btw.

ok so only fastboot can repartition then.

but is it just me, or is there an ugly rotten smell with recovery unsuspectingly writing to the emmc when it wants? should it not just panic in a sane way instead?

[gmrt]

I think apanic_mmc just doesn't work properly with BLKRRPART, which causes the kernel to remove and readd all the partitions. If you disabled the driver, you can run blockdev without issues and probably resize partitions too. Still, I'd be careful with that and do some research before doing anything. 'kpan', the partition used by apanic_mmc, is put right before 'userdata', which is the last partition. I don't know who writes there and how.

[Lanchon]

well if all involved software accesses the partition through a linux kernel there would be no problem as linux reads the GPT. the problem would be the bootloader accessing moved partitions and doing so without going through the GPT.

all in all, there's always the possibility of a brick. the xt1032 is fixable by EDL though.

if you want to read a similar story...
#28 (comment)

[gmrt]

the problem would be the bootloader accessing moved partitions and doing so without going through the GPT.

That's exactly what I meant with "I don't know who writes there and how."

I doubt the bootloader uses some hardcoded addresses, especially considering how many variants of this device sharing the same software there are out there. Running 'strings' on the bootloader also makes me think they did everything properly, but that's definitely not enough to prove it.

That said, I wouldn't take the risk and to be honest, I'm OK with how my device is partitioned, so I don't see myself going deeper into this in the near future.

[Lanchon]

some bootloaders could use a parallel simplified data structure and ignore the GPT. (not hardcoded addresses.) samsungs have "PIT" files which might be this or not. they are flashed using their custom bootloader. in any case, as long as you dont touch bootloader-accessed partitions, modding the GPT works on samsung. that's how i support samsung phones via REPIT.

falcon uses a "gpt.bin" file, which might be just an image of the GPT, and is flashed using "fastboot flash partition gpt.bin".

i still think that the recovery writing to the panic partition is wrong. IMHO it shouldn't be there.

anyway, thanks for clearing this up! ;)

[Lanchon]

WARNING !!! WARNING !!! WARNING !!!

in view of recent events, and taking into account that this device is Qualcomm-based, the possibility of hard-bricking by repartitioning cannot be ruled out.

i know there are hard-brick recovery tools for the xt1032, including the GPE, but i don't know if they work with the newest bootloaders. (motorola has the nasty habit of disabling older bootloaders via efuse-blowing causing bricks on bootloader downgrade.) potential testers proceed at your own peril.

[Lanchon]

WARNING !!! WARNING !!! WARNING !!!

the use of GPT signing on falcon has been mostly confirmed.

RUNNING REPIT ON FALCON WILL PROBABLY RESULT IN DEVICE BRICKING !!!

[DoctorStrange96]

I've managed to pack a modified TWRP image which should work with REPIT. I unpacked the official image, built a kernel (CM13) with CONFIG_APANIC_MMC disabled, copied zImage-dtb (renamed to zImage), repacked the image and that's all. I'll do a blockdev and see if it really works

UPDATE: It does work. The whole repartitioning process goes without errors. However, a reboot will cause all changes to be lost, as the bootloader will (probably) load the old partition table (or a backup table if there is one).

If only we could self-sign a custom gpt.bin, or bypass signature verification in some way...

[Lanchon]

thank you for your effort and help!

you can't bypass GPT signing. only engineering devices can, and a fuse is blown to exit engineering mode so no way back. i think there's a protection disallowing GPT writing after fastboot. i have reason to believe the GPE bootloader doesn't enable this protection and on the GPE running REPIT would result in a device brick on reboot, due to GPT signature check failing.

i'm removing the falcon build ASAP.