[Announcement] TWRP 3.0.2-1 has a fatal bug! Do not backup or restore EFS on 3.0.2-1

Search This thread

bogomil4e

Member
Oct 18, 2012
36
77
Haskovo
Hello everyone! I bring news from the TWRP developers from the #TWRP IRC channel! TWRP 3.0.2-1 has a fatal bug! If you backup and restore EFS it will brick you! Do not backup and restore EFS on 3.0.2-1! Use 3.0.2-0 instead! This has already been fixed in the newer builds!

If you have been bricked you NEED to Erase the EFS partitions and that will fix it immediately.
For the Nexus 6P go to TWRP. Then on PC Open Command Prompt with access to ADB ( Android Debug Bridge) and execute the following commands:

ADB shell dd if=/dev/zero of=/dev/block/platform/soc.0/f9824900.sdhci/by-name/modemst1 bs=16384

and

ADB shell dd if=/dev/zero of=/dev/block/platform/soc.0/f9824900.sdhci/by-name/modemst2 bs=16384


This should fix it for ANY Nexus 6P users.

Users on other phones with the same problem await instructions!
 
Last edited:

Ericarthurc

Senior Member
Jul 28, 2013
330
127
Fastboot flash (or use Flashfire?) a Marshmallow vendor.img to get older versions of TWRP working on encrypted Nougat.

Sent from my Nexus 5X using Tapatalk

So I can flash MTC20F vendor through fastboot and Nougat will still run fine??

My phone isn't in boot loop btw; I am running stock Nougat. Just saw that 3.0.2-1 had issues
 
Last edited:

ultyrunner

Senior Member
Dec 31, 2010
816
255
604
No. TWRP team is not made of hundreds of people! You can count them on one hand AND they have other jobs and families.
Sadly that means that they cant work on it 24/7 and well just have to wait and see. All the devs told me was that a fix has been made and pushed soon.
Yeah, I know. A "no idea" would have been sufficient, instead of the unnecessary lecture about devs volunteering their time, which I understand very well.
 

joeyddr

Senior Member
May 4, 2011
1,991
329
Google Pixel 6 Pro
Yeah, I know. A "no idea" would have been sufficient, instead of the unnecessary lecture about devs volunteering their time, which I understand very well.

I agree but, i think maybe they should of tested a MM backup and restore before releasing? cause thats what caused mine and of course now that the fix is out my phone is sitting with huawei right now for up to 14 days.... the phone in which i flashed stock MM and locked. So if they decide not to fix my phone for whatever reason i get a locked bootlooping phone back. Hopefully I can fastboot boot twrp and run the DD commands if thats what they decide to do.
 

defcondev

Senior Member
Jul 19, 2013
199
199
TX
I agree but, i think maybe they should of tested a MM backup and restore before releasing? cause thats what caused mine and of course now that the fix is out my phone is sitting with huawei right now for up to 14 days.... the phone in which i flashed stock MM and locked. So if they decide not to fix my phone for whatever reason i get a locked bootlooping phone back. Hopefully I can fastboot boot twrp and run the DD commands if thats what they decide to do.

Mine shipped off to Huawei as well.

But with you flashing stock and re-locking the bootloader, I don't think that's possible.

Due to California's "Smartphone Kill-Switch Law" (SB-962), you have to enable the "Allow OEM Unlocking" in developer settings to unlock the bootloader.

And an unlocked bootloader is required to "fastboot flash", as well as "fastboot boot" if I remember correctly.

Perhaps someone can clarify...
 

joeyddr

Senior Member
May 4, 2011
1,991
329
Google Pixel 6 Pro
Mine shipped off to Huawei as well.

But with you flashing stock and re-locking the bootloader, I don't think that's possible.

Due to California's "Smartphone Kill-Switch Law" (SB-962), you have to enable the "Allow OEM Unlocking" in developer settings to unlock the bootloader.

And an unlocked bootloader is required to "fastboot flash", as well as "fastboot boot" if I remember correctly.

Perhaps someone can clarify...
Thing is if it was unlocked but then I locked it via fb command but it never booted Android to read that you checked off allow unlock it might be possible to fastboot OEM unlock again. Just a thought.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 50
    Hello everyone! I bring news from the TWRP developers from the #TWRP IRC channel! TWRP 3.0.2-1 has a fatal bug! If you backup and restore EFS it will brick you! Do not backup and restore EFS on 3.0.2-1! Use 3.0.2-0 instead! This has already been fixed in the newer builds!

    If you have been bricked you NEED to Erase the EFS partitions and that will fix it immediately.
    For the Nexus 6P go to TWRP. Then on PC Open Command Prompt with access to ADB ( Android Debug Bridge) and execute the following commands:

    ADB shell dd if=/dev/zero of=/dev/block/platform/soc.0/f9824900.sdhci/by-name/modemst1 bs=16384

    and

    ADB shell dd if=/dev/zero of=/dev/block/platform/soc.0/f9824900.sdhci/by-name/modemst2 bs=16384


    This should fix it for ANY Nexus 6P users.

    Users on other phones with the same problem await instructions!
    37
    I'd like to clarify some things:

    The EFS restoration issue was due to a missing file name set bug during the backup restoration process.

    This caused all subpartitions associated with a backup-enabled partition to have the first item (ex. the main/non-subpartition) restored to all subpartitions as well.

    See for example the partition entries in Angler's recovery.fstab:
    Code:
    /efs1            emmc              /dev/block/platform/soc.0/f9824900.sdhci/by-name/modemst1  flags=backup=1;display=EFS
    /efs2            emmc              /dev/block/platform/soc.0/f9824900.sdhci/by-name/modemst2  flags=backup=1;subpartitionof=/efs1

    While creating the backup of EFS, you will end up with:
    efs1.emmc.win (modemst1 partition raw data)
    efs2.emmc.win (modemst2 partition raw data)

    When restoring this EFS backup, what happened was the file name was not updated for restore, and you ended up with:
    Restoring EFS...
    Restoring efs1.emmc.win to modemst1
    Restoring efs1.emmc.win to modemst2


    It should have been:
    Restoring EFS...
    Restoring efs1.emmc.win to modemst1
    Restoring efs2.emmc.win to modemst2


    If you had a working backup, you could restore it properly with:
    dd if=/sdcard/TWRP/BACKUPS/SERIALNO/BACKUPNAME/efs2.emmc.win of=/dev/block/platform/soc.0/f9824900.sdhci/by-name/modemst2 bs=16384

    As I figured many users may have accidentally backed up the badly restored partitions, and that command is easier said than done for many, the simpler solution was to just erase the partition entirely using zeros and have the modem firmware regenerate it on next boot.
    (Snapdragon modem firmware is usually smart enough to regenerate from scratch ex. zeros, but panics on random data or incorrect magic!)

    If you're wondering, here was the actual fix: https://github.com/omnirom/android_bootable_recovery/commit/724c5148a5bf341479bf943b0c64ce8d40814148

    This bug was present in both Angler and Bullhead as far as I can tell, as they were rebuilt recently on the latest sources (between the time the bad commit happened and the fix linked above).
    Most other devices are built on the TWRP version release commit rather than latest sources, so they should not have the bug.
    There could be some user built builds out there with this issue, I see the OnePlus 3 did have a build on XDA with the issue.

    If you're wondering, I just like to set block size (bs) to 16384 in dd for funsies. It's not necessary.

    Update

    TWRP 3.0.2-2 seems to have a backup bug where the 2nd tar file created after ~1GB will fail to write and cancel the backup.

    I'll see about creating a quick build without the broken patches. (this is why it's bad to build on latest sources instead of release tags! ;))

    Update #2

    I've built new builds for Angler and Bullhead, they can be found here: https://idlekernel.com/twrp/nexus/
    They should be up to date, but have the adb backup patches rebased out until the bugs are solved.
    These builds are untested, and I recommend sticking with 3.0.2-0 instead for the time being.
    9
    Let me explain the subpartitons issue
    Lets brief out first what is subpartition
    In Android we have multiple partitions like
    Code:
    /data 
    /boot 
    /system
    /recovery 
    /cache

    Sometime we have multiple partition for same type of partition like
    In Samsung the download mode is /boot1 (or something like that )

    Same way the efs is in two (or more) partitons
    Code:
    /efs1
    /efs2

    TWRP for simple GUI experience it lists the multiple partitions as a single button

    When does the bug come in ?
    The bug is that TWRP was restoring a single subpartition to all subpartitions of it
    example in this case
    /efs2 was restored in both /efs2 and /efs1
    so
    when backing up
    /efs1 = efs1.emmc.win
    /efs2 = efs2.emmc.win

    But when restoring
    /efs1 = efs1.emmc.win
    /efs2 = efs1.emmc.win

    How was it fixed ?
    https://github.com/omnirom/android_bootable_recovery/commit/724c5148a5bf341479bf943b0c64ce8d40814148
    In this fix @Dees_Troy fixed the restore by referring to the subparts instead of the parentpart which caused the bug
    5
    Looks like 3.0.2-2 is up on their website. https://dl.twrp.me/angler/
    3
    Any word whether they'll release a 3.0.2-2 soon?

    No. TWRP team is not made of hundreds of people! You can count them on one hand AND they have other jobs and families.
    Sadly that means that they cant work on it 24/7 and well just have to wait and see. All the devs told me was that a fix has been made and pushed soon.