• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[RECOVERY] TWRP 3.3.1 for Galaxy S10 Exynos series [G970F/G973F/G975F/G977B]

Search This thread

ianmacd

Senior Member
Jan 5, 2016
2,352
3,800
Amsterdam
localhost
twrp-featured.jpg


Preamble

After TWRP first appeared for the S10 range of devices, it quickly became clear that there were some major issues with the initial builds.

Many users were understandably frustrated at losing the ability to boot their device after shutting it down, and at being unable to update Magisk after installing TWRP.

A number of users took to contacting me privately for support. I answered their questions and even shared fixed images in a few cases, but the number of support requests was rising daily and I could not keep pace with the demand.

Given that the poster of the original images (Geiti94) was evidently unable to offer fixed TWRP images in a timely fashion, I ultimately took the liberty of doing so myself in a posting to the original TWRP thread as a service to the community.

Whilst this served to relieve the immediate pressure, the ongoing need to fix bugs and make further enhancements to the software made a fork of the original project inevitable, so I have taken the step of promoting it to its own DevDB project and thread here on XDA.

Credit goes to Geiti94 for conducting the time-consuming initial legwork and releasing the original builds. His is the foundation on which this work now builds. This fork in no way implies any disrespect to him, but does strongly acknowledge the need of the S10 user base to be supplied with proper, working images and timely updates.

System-as-root with A-only partitioning scheme

All new devices launched with Android 9 are required to be factory-configured as system-as-root devices. The ramdisk image formerly used in boot.img is now merged with system.img.

For Samsung devices such as the S10 series, this means that boot.img can no longer be used to root the device. Instead, Magisk will be installed to the recovery partition and the user will be required to always boot to that partition, regardless of whether TWRP or Android is desired. The hardware keys are used at boot time to select either Magisk-rooted Android or TWRP.

This configuration dictates that TWRP and Android share a common recovery kernel. However, because TWRP cannot be booted with a stock kernel, a custom kernel must be compiled from Samsung's source code. Unfortunately, this kernel is sensitive to changes in Samsung's firmware releases from one month to the next, meaning that problems can arise if a given kernel is used with firmware newer than the version the kernel was intended for.

This unfortunate situation necessitates semi-regular maintenance releases of TWRP to keep the kernel in step with the latest version of the S10 series firmware. This requirement is further complicated by the fact that any given release of Samsung's modified kernel source code typically trails the associated firmware release by anything from a few days to a few weeks.

TWRP without Magisk

If your device is currently still unrooted and running stock firmware, you are strongly advised not to proceed with installing TWRP. First root your device with Magisk, using John Wu's excellent Samsung system-as-root-instructions for patching the firmware's AP file. Only when you have completed that procedure should you return here and continue from the Image Preparation section.

If you insist on proceeding with installing TWRP to a stock device without Magisk, you will need — at a minimum — to flash a vbmeta.img with verity disabled or you will render your device unable to boot. You can construct such an image using the following command:

Code:
$ avbtool make_vbmeta_image --out vbmeta.img

Alternatively, if you don't have a copy of avbtool at hand, the following piece of shell code will do the trick:

Code:
h=$(printf '4156423%08d1%0240d617662746f6f6c20312e312e3%0230d')
d=''
for ((i=0; i<${#h}; i+=2)); do
  d="$d\x${h:$i:2}"
done
printf "$d" > vbmeta.img

Next, flash this to the vbmeta partition, using either Heimdall or Odin.

Code:
# heimdall flash --VBMETA vbmeta.img

You may then proceed with installing TWRP according to the instructions below.

Image preparation

In contrast to the original Geit94 release, these and subsequent TWRP images will not be supplied pre-rooted with Magisk. Whilst it would be trivial to offer them in this format, this kind of binary distribution of Magisk is against the terms of use laid out by Magisk's developer, John Wu.

To root the TWRP image yourself, simply use Magisk Manager to Select and Patch a File. Provide your freshly downloaded TWRP image file as the input.

Installation

You are now ready to flash the resulting magisk_patched.img image file to your device's recovery partition.

One quick and easy way to do this on an already rooted device is from a root shell:

Code:
# dd if=/storage/emulated/0/Download/magisk_patched.img of=/dev/block/sda15 bs=$(stat -c%s /storage/emulated/0/Download/magisk_patched.img)
1+0 records in
1+0 records out
61734912 bytes transferred in 0.426 secs (144917633 bytes/sec)

If TWRP is already installed and you are merely updating it, you may, of course, use TWRP itself to flash the new version.

If the device is not yet rooted (or even if it is), you may use Odin in Windows, but you will need to tar the image first. For example:

Code:
$ mv twrp-beyond[012]lte.img recovery.img
$ tar cf twrp-beyond[012]lte.img.tar recovery.img

And if rebooting to Windows is too disruptive, there's always Heimdall:

Code:
# heimdall flash --RECOVERY twrp-beyond[012]lte.img

Download

The latest unofficial local builds currently available are:


The latest official builds are available from the official TWRP site. Note that there is no official build for beyondx (G977B), because officially supported status has not been sought.

Unless you have a very particular requirement, you are advised to use the unofficial builds for reasons discussed under Frequently Asked Questions below.

These builds are based on the latest version of TWRP, 3.3.1-0, and include a 4.14.85 kernel compiled from Samsung's latest available source code. The kernel runs in SELinux enforcing mode and has intentionally been kept as close to stock as possible in order to provide maximum compatibility with both Android and TWRP.

The builds have been well-tested and are known to work as intended on supported firmware versions. See posting #2 of this thread for details of which TWRP builds work with which versions of Samsung's firmware.

If you later find yourself running on updated firmware that is incompatible with this kernel, you have the option of flashing and rebooting to TWRP on demand. When you are finished in TWRP, you can replace your recovery image with Magisk-rooted stock recovery and reboot back to Android.

If installing TWRP on your device for the first time or reinstalling it following a firmware upgrade, do not forget to disable file-based encryption (FBE) immediately after flashing TWRP or you won't be able to read files on /data in TWRP. To achieve this (and to protect yourself against various anti-root protection mechanisms that Samsung have booby-trapped the device with), flash the multidisabler as soon as you have installed TWRP.

Device firmware updates

When it comes time to update your device's firmware, please follow John Wu's excellent instructions for patching the firmware's AP file.

Next, use Odin to flash the patched AP file, together with the stock BL, CP and HOME_CSC files. Never leave these slots empty, or your /data partition may be shrunk during the flash).

When finished, reboot back to download mode and immediately reflash your Magisk-patched TWRP image.

Alternatively, you may replace recovery.img in the patched AP file with your rooted TWRP image, thereby completing the upgrade in a single flash:

Code:
$ tar f magisk_patched_twrp.tar --delete recovery.img && tar rf magisk_patched_twrp.tar recovery.img

Lastly, boot to TWRP and reflash the multidisabler. Do not skip this last step, as flashing new firmware will have re-enabled critical security features that you must now re-disable.

Frequently Asked Questions

Q. Is there a difference between the builds offered here and those on the official TWRP site?


A. Both the official and unofficial builds are compiled from the android-9.0 branch of TWRP, using the source code of the latest official versioned release of TWRP. Any post-release changes present in the HEAD of the android-9.0 branch are usually omitted.

The latest unofficial builds may contain changes not yet integrated into the official builds, due to the bureaucratic overhead of the official release engineering process. They may also contain patches unable to be integrated into the official versions, due to policy or technical restrictions.

Additionally, the official versioning can get out of step with the unofficial versioning. This can happen, for example, if two unofficial revisions are released in quick succession, before the first sees its official release. In such a case, the second revision can find itself released with the version number intended for the first revision.

Due to the additional complexity and overhead associated with maintaining the official builds, I now recommend using only the unofficial builds.

Q. I don't want to boot Android using the custom kernel from my TWRP image. The latest TWRP kernel is often intended for older firmware. Even if there are no visible issues using this older kernel, I'm probably missing out on improvements and fixes made in the latest kernel. Is there really no other way to run TWRP on these devices?


A. There actually is another way. You can opt to flash and boot TWRP on demand, leaving a Magisk-rooted stock recovery on your device the rest of the time.

For example, you can adapt the following simple script to toggle your recovery between stock and TWRP.

Copy the below (not as the superuser) into a file, for example /storage/emulated/0/switch-recovery:

Code:
#!/bin/sh

twrp_img=/storage/9C33-6BBD/twrp-beyond2lte-3.3.1-2_ianmacd-magisk.img
stock_img=/external_sd/recovery-ase5-magisk.img

if [ -f /sbin/magisk ]; then
  # We're in system: Switch to TWRP.
  #
  infile=$twrp_img
  su='su -c'
else
  # We're in TWRP: Switch to system.
  #
  infile=$stock_img
fi

$su dd if=$infile of=/dev/block/sda15 && reboot recovery

Then run it in Android by opening a terminal session and typing:

Code:
$ sh /storage/emulated/0/switch-recovery

It will flash your TWRP image and reboot the device to recovery. If the TWRP image isn't rooted, you'll still need to press the usual key combo to force pass-through to TWRP.

Do your work in TWRP and then run the script again from the TWRP terminal. This time, it will reflash your stock recovery image and boot you again to recovery. There's no need to press the keys this time, because you are booting to Magisk-rooted Android.

Obviously, you must change the paths in the script to match where your own images are stored.

Q. Somewhere in upgrading my firmware, rooting and installing TWRP, my /data file-system mysteriously shrank to a fraction of its former size and appears to have been wiped. What happened? Is TWRP responsible for this?


A. No. This appears to be a side-effect of using Odin to flash only an AP file to these devices, i.e. with the BL, CP and CSC slots left empty. We don't know why this causes /data to be shrunk, but we have narrowed it down to this.

To repair it, you need to boot to TWRP, select Advanced Wipe, tick Data, select Repair or Change File System followed by Resize File System. Your /data will return to its former size, but you will probably find you have lost some data. Restore a /data back-up afterwards.

Q. When I mount /system and execute commands in the TWRP terminal or over adb, I get a lot of noise about problems with the dynamic linker.


A. This problem is fixed as of version 3.3.1-1_ianmacd.

It is caused by /etc/system becoming a symlink to itself, causing infinite recursion when followed.

The screen on your text is just a warning, not an error. Your commands are being executed.

Nevertheless, noise annoys, so you can silence the warning by pasting the following commands into the terminal (with thanks to John Wu):

Code:
# mount --move /system /system_root && mount -o bind /system_root/system /system

Q. When I flash my favourite zip using this TWRP, I can't boot my device. The zip's author says these TWRP builds are to blame. Why don't you fix them?


A. Because there's nothing wrong with them. It's the installer code of your favourite zip that is broken. These builds of TWRP are merely exposing that fact. Don't shoot the messenger.

A lot of poorly written legacy installer code lazily assumes the presence of certain binaries, in particular BusyBox. However, the inclusion of BusyBox in TWRP is a compile-time option at the discretion of the builder.

Not only that, but the inclusion of BusyBox in builds of TWRP that target Android 9.0 and later is officially deprecated. Maintainers of affected devices are instead advised to use Toybox, and these builds for the S10 series comply with that advice. Furthermore, it's actually not even possible to build an official image for these devices with BusyBox included. Compilation fails on the official build server.

In short, the assumption of BusyBox on the device is unsafe and your favourite zip's author should fix his installer code. Supply him with an installation log and politely ask him to rewrite his code to be independent of this TWRP implementation detail.

Links


XDA:DevDB Information
TWRP for Galaxy S10 Exynos series, Tool/Utility for the Samsung Galaxy S10+

Contributors
ianmacd, Geiti94

Version Information
Status: Stable
Current Stable Version: 3.3.1-3.1_ianmacd
Stable Release Date: 2019-06-12

Created 2019-04-26
Last Updated 2019-06-21
 

Attachments

  • Screenshot_2019-04-16-12-48-09.png
    Screenshot_2019-04-16-12-48-09.png
    109.1 KB · Views: 1,365

romstockprivate

Senior Member
Jan 18, 2014
66
2
This may not apply to your build but..

I have TWRP 3.4.0-1 installed and I am trying to install a backup but every time TWRP says successful, it the log is shows and error (failed to mount '/product). What am I doing wrong?\

My S10e shows a clean install of crdriod after this. I need to install my backup so I can screenshot the recovery key for signal.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 7
    twrp-featured.jpg


    Preamble

    After TWRP first appeared for the S10 range of devices, it quickly became clear that there were some major issues with the initial builds.

    Many users were understandably frustrated at losing the ability to boot their device after shutting it down, and at being unable to update Magisk after installing TWRP.

    A number of users took to contacting me privately for support. I answered their questions and even shared fixed images in a few cases, but the number of support requests was rising daily and I could not keep pace with the demand.

    Given that the poster of the original images (Geiti94) was evidently unable to offer fixed TWRP images in a timely fashion, I ultimately took the liberty of doing so myself in a posting to the original TWRP thread as a service to the community.

    Whilst this served to relieve the immediate pressure, the ongoing need to fix bugs and make further enhancements to the software made a fork of the original project inevitable, so I have taken the step of promoting it to its own DevDB project and thread here on XDA.

    Credit goes to Geiti94 for conducting the time-consuming initial legwork and releasing the original builds. His is the foundation on which this work now builds. This fork in no way implies any disrespect to him, but does strongly acknowledge the need of the S10 user base to be supplied with proper, working images and timely updates.

    System-as-root with A-only partitioning scheme

    All new devices launched with Android 9 are required to be factory-configured as system-as-root devices. The ramdisk image formerly used in boot.img is now merged with system.img.

    For Samsung devices such as the S10 series, this means that boot.img can no longer be used to root the device. Instead, Magisk will be installed to the recovery partition and the user will be required to always boot to that partition, regardless of whether TWRP or Android is desired. The hardware keys are used at boot time to select either Magisk-rooted Android or TWRP.

    This configuration dictates that TWRP and Android share a common recovery kernel. However, because TWRP cannot be booted with a stock kernel, a custom kernel must be compiled from Samsung's source code. Unfortunately, this kernel is sensitive to changes in Samsung's firmware releases from one month to the next, meaning that problems can arise if a given kernel is used with firmware newer than the version the kernel was intended for.

    This unfortunate situation necessitates semi-regular maintenance releases of TWRP to keep the kernel in step with the latest version of the S10 series firmware. This requirement is further complicated by the fact that any given release of Samsung's modified kernel source code typically trails the associated firmware release by anything from a few days to a few weeks.

    TWRP without Magisk

    If your device is currently still unrooted and running stock firmware, you are strongly advised not to proceed with installing TWRP. First root your device with Magisk, using John Wu's excellent Samsung system-as-root-instructions for patching the firmware's AP file. Only when you have completed that procedure should you return here and continue from the Image Preparation section.

    If you insist on proceeding with installing TWRP to a stock device without Magisk, you will need — at a minimum — to flash a vbmeta.img with verity disabled or you will render your device unable to boot. You can construct such an image using the following command:

    Code:
    $ avbtool make_vbmeta_image --out vbmeta.img

    Alternatively, if you don't have a copy of avbtool at hand, the following piece of shell code will do the trick:

    Code:
    h=$(printf '4156423%08d1%0240d617662746f6f6c20312e312e3%0230d')
    d=''
    for ((i=0; i<${#h}; i+=2)); do
      d="$d\x${h:$i:2}"
    done
    printf "$d" > vbmeta.img

    Next, flash this to the vbmeta partition, using either Heimdall or Odin.

    Code:
    # heimdall flash --VBMETA vbmeta.img

    You may then proceed with installing TWRP according to the instructions below.

    Image preparation

    In contrast to the original Geit94 release, these and subsequent TWRP images will not be supplied pre-rooted with Magisk. Whilst it would be trivial to offer them in this format, this kind of binary distribution of Magisk is against the terms of use laid out by Magisk's developer, John Wu.

    To root the TWRP image yourself, simply use Magisk Manager to Select and Patch a File. Provide your freshly downloaded TWRP image file as the input.

    Installation

    You are now ready to flash the resulting magisk_patched.img image file to your device's recovery partition.

    One quick and easy way to do this on an already rooted device is from a root shell:

    Code:
    # dd if=/storage/emulated/0/Download/magisk_patched.img of=/dev/block/sda15 bs=$(stat -c%s /storage/emulated/0/Download/magisk_patched.img)
    1+0 records in
    1+0 records out
    61734912 bytes transferred in 0.426 secs (144917633 bytes/sec)

    If TWRP is already installed and you are merely updating it, you may, of course, use TWRP itself to flash the new version.

    If the device is not yet rooted (or even if it is), you may use Odin in Windows, but you will need to tar the image first. For example:

    Code:
    $ mv twrp-beyond[012]lte.img recovery.img
    $ tar cf twrp-beyond[012]lte.img.tar recovery.img

    And if rebooting to Windows is too disruptive, there's always Heimdall:

    Code:
    # heimdall flash --RECOVERY twrp-beyond[012]lte.img

    Download

    The latest unofficial local builds currently available are:


    The latest official builds are available from the official TWRP site. Note that there is no official build for beyondx (G977B), because officially supported status has not been sought.

    Unless you have a very particular requirement, you are advised to use the unofficial builds for reasons discussed under Frequently Asked Questions below.

    These builds are based on the latest version of TWRP, 3.3.1-0, and include a 4.14.85 kernel compiled from Samsung's latest available source code. The kernel runs in SELinux enforcing mode and has intentionally been kept as close to stock as possible in order to provide maximum compatibility with both Android and TWRP.

    The builds have been well-tested and are known to work as intended on supported firmware versions. See posting #2 of this thread for details of which TWRP builds work with which versions of Samsung's firmware.

    If you later find yourself running on updated firmware that is incompatible with this kernel, you have the option of flashing and rebooting to TWRP on demand. When you are finished in TWRP, you can replace your recovery image with Magisk-rooted stock recovery and reboot back to Android.

    If installing TWRP on your device for the first time or reinstalling it following a firmware upgrade, do not forget to disable file-based encryption (FBE) immediately after flashing TWRP or you won't be able to read files on /data in TWRP. To achieve this (and to protect yourself against various anti-root protection mechanisms that Samsung have booby-trapped the device with), flash the multidisabler as soon as you have installed TWRP.

    Device firmware updates

    When it comes time to update your device's firmware, please follow John Wu's excellent instructions for patching the firmware's AP file.

    Next, use Odin to flash the patched AP file, together with the stock BL, CP and HOME_CSC files. Never leave these slots empty, or your /data partition may be shrunk during the flash).

    When finished, reboot back to download mode and immediately reflash your Magisk-patched TWRP image.

    Alternatively, you may replace recovery.img in the patched AP file with your rooted TWRP image, thereby completing the upgrade in a single flash:

    Code:
    $ tar f magisk_patched_twrp.tar --delete recovery.img && tar rf magisk_patched_twrp.tar recovery.img

    Lastly, boot to TWRP and reflash the multidisabler. Do not skip this last step, as flashing new firmware will have re-enabled critical security features that you must now re-disable.

    Frequently Asked Questions

    Q. Is there a difference between the builds offered here and those on the official TWRP site?


    A. Both the official and unofficial builds are compiled from the android-9.0 branch of TWRP, using the source code of the latest official versioned release of TWRP. Any post-release changes present in the HEAD of the android-9.0 branch are usually omitted.

    The latest unofficial builds may contain changes not yet integrated into the official builds, due to the bureaucratic overhead of the official release engineering process. They may also contain patches unable to be integrated into the official versions, due to policy or technical restrictions.

    Additionally, the official versioning can get out of step with the unofficial versioning. This can happen, for example, if two unofficial revisions are released in quick succession, before the first sees its official release. In such a case, the second revision can find itself released with the version number intended for the first revision.

    Due to the additional complexity and overhead associated with maintaining the official builds, I now recommend using only the unofficial builds.

    Q. I don't want to boot Android using the custom kernel from my TWRP image. The latest TWRP kernel is often intended for older firmware. Even if there are no visible issues using this older kernel, I'm probably missing out on improvements and fixes made in the latest kernel. Is there really no other way to run TWRP on these devices?


    A. There actually is another way. You can opt to flash and boot TWRP on demand, leaving a Magisk-rooted stock recovery on your device the rest of the time.

    For example, you can adapt the following simple script to toggle your recovery between stock and TWRP.

    Copy the below (not as the superuser) into a file, for example /storage/emulated/0/switch-recovery:

    Code:
    #!/bin/sh
    
    twrp_img=/storage/9C33-6BBD/twrp-beyond2lte-3.3.1-2_ianmacd-magisk.img
    stock_img=/external_sd/recovery-ase5-magisk.img
    
    if [ -f /sbin/magisk ]; then
      # We're in system: Switch to TWRP.
      #
      infile=$twrp_img
      su='su -c'
    else
      # We're in TWRP: Switch to system.
      #
      infile=$stock_img
    fi
    
    $su dd if=$infile of=/dev/block/sda15 && reboot recovery

    Then run it in Android by opening a terminal session and typing:

    Code:
    $ sh /storage/emulated/0/switch-recovery

    It will flash your TWRP image and reboot the device to recovery. If the TWRP image isn't rooted, you'll still need to press the usual key combo to force pass-through to TWRP.

    Do your work in TWRP and then run the script again from the TWRP terminal. This time, it will reflash your stock recovery image and boot you again to recovery. There's no need to press the keys this time, because you are booting to Magisk-rooted Android.

    Obviously, you must change the paths in the script to match where your own images are stored.

    Q. Somewhere in upgrading my firmware, rooting and installing TWRP, my /data file-system mysteriously shrank to a fraction of its former size and appears to have been wiped. What happened? Is TWRP responsible for this?


    A. No. This appears to be a side-effect of using Odin to flash only an AP file to these devices, i.e. with the BL, CP and CSC slots left empty. We don't know why this causes /data to be shrunk, but we have narrowed it down to this.

    To repair it, you need to boot to TWRP, select Advanced Wipe, tick Data, select Repair or Change File System followed by Resize File System. Your /data will return to its former size, but you will probably find you have lost some data. Restore a /data back-up afterwards.

    Q. When I mount /system and execute commands in the TWRP terminal or over adb, I get a lot of noise about problems with the dynamic linker.


    A. This problem is fixed as of version 3.3.1-1_ianmacd.

    It is caused by /etc/system becoming a symlink to itself, causing infinite recursion when followed.

    The screen on your text is just a warning, not an error. Your commands are being executed.

    Nevertheless, noise annoys, so you can silence the warning by pasting the following commands into the terminal (with thanks to John Wu):

    Code:
    # mount --move /system /system_root && mount -o bind /system_root/system /system

    Q. When I flash my favourite zip using this TWRP, I can't boot my device. The zip's author says these TWRP builds are to blame. Why don't you fix them?


    A. Because there's nothing wrong with them. It's the installer code of your favourite zip that is broken. These builds of TWRP are merely exposing that fact. Don't shoot the messenger.

    A lot of poorly written legacy installer code lazily assumes the presence of certain binaries, in particular BusyBox. However, the inclusion of BusyBox in TWRP is a compile-time option at the discretion of the builder.

    Not only that, but the inclusion of BusyBox in builds of TWRP that target Android 9.0 and later is officially deprecated. Maintainers of affected devices are instead advised to use Toybox, and these builds for the S10 series comply with that advice. Furthermore, it's actually not even possible to build an official image for these devices with BusyBox included. Compilation fails on the official build server.

    In short, the assumption of BusyBox on the device is unsafe and your favourite zip's author should fix his installer code. Supply him with an installation log and politely ask him to rewrite his code to be independent of this TWRP implementation detail.

    Links


    XDA:DevDB Information
    TWRP for Galaxy S10 Exynos series, Tool/Utility for the Samsung Galaxy S10+

    Contributors
    ianmacd, Geiti94

    Version Information
    Status: Stable
    Current Stable Version: 3.3.1-3.1_ianmacd
    Stable Release Date: 2019-06-12

    Created 2019-04-26
    Last Updated 2019-06-21