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

TWRP , extracttarfork() process ended with error=255, How to Fix.. ?

Search This thread

plewu

Member
Jun 29, 2016
6
0
That happened to me twice, loosing the imei.
To fix it, just restore or flash any rom you want, and follow this steps:

  • Extract NON-HLOS.bin file from official ROM.
  • Copy extracted NON-HLOS.bin to the adb/fastboot folder.
  • Boot your device into fastboot mode.
  • Connect your device to PC
  • In the folder with adb/fastboot tools press “Shift” key + right mouse button and select “Open command window here”.
  • Enter these commands in order:
Code:
Fastboot devices
Fastboot.exe erase modem
Fastboot.exe flash modem NON-HLOS.bin
Fastboot.exe reboot
  • Check your IMEI. It should be restored now.

Man if you will ever be in Poland You have best Vodka from me
 

ggez

Member
Mar 6, 2017
31
2
So comments here made me realize something.

TRY THIS!

1.Restore System & Boot first in TWRP (IDK if others works; Maybe for the fp and stuff, because mine didn't register after)
2.then reboot
3.You'll be on miui's setup screen; set it all up again. You can click next w/o configuring it really(I think you get the idea by now)
4. reboot to recovery and restore DATA next and after that
5.Enjoy!
 
  • Like
Reactions: murmurous

murmurous

Member
Aug 31, 2017
15
6
So comments here made me realize something.

TRY THIS!

1.Restore System & Boot first in TWRP (IDK if others works; Maybe for the fp and stuff, because mine didn't register after)
2.then reboot
3.You'll be on miui's setup screen; set it all up again. You can click next w/o configuring it really(I think you get the idea by now)
4. reboot to recovery and restore DATA next and after that
5.Enjoy!
You're a lifesaver, man!

I had this same issue on a different phone (OnePlus 7 pro), and this procedure was the only method that worked. Extracting the archive files with tar didn't work for me.

I took a slightly-different but equivalent path:
  1. Factory reset, format data
  2. Use TWRP recovery on all partitions except data
  3. Reboot system, complete setup flow (I set my old PIN again)
  4. Reboot recovery and use TWRP recovery on only the data partition
  5. Reboot system
One of my apps (Signal) was acting up when I restored, but other than that it's like nothing ever happened.
 

Asia81

Member
May 28, 2017
26
0
The good fix!!!

TWRP always skip data/media in backup or restore. This is a problem!

Restoring procedure "automatic format" skipped data/media folder, only delete other folders. "Wiping data without wiping data/media ..."

To delete data partition completly:

1. Go to Wipe menu
2. Wipe Data
3. Yes (all data, audio, video, etc deleted)
4. Go to Restore menu
5. Restore Data partition

Restore completed without error!
Thank you so much
 

Top Liked Posts

  • There are no posts matching your filters.
  • 2
    Firmware Problem "extractTarFork process ended with ERROR 255"

    In My case Firmware is not restoring
    shoiwing error "extractTarFork process ended with ERROR 255"
    so to solve it
    1.Wipe data dalvik cache and system
    2.Just flash the new rom which u had earlier.
    for exp. i had lineage 14.1
    3.After installing it ask for wipe dalvik and cache do it then dont wipe it from the main menu.
    4.just restore the backuped file without ticking the firmware
    Note-Firmware must be untick while restoring
    5.done Problem of fingerprint scanner and network problem also solved by this
    Note-Dont restart in between
    :p
    if it helps you
    Subscribe to My Youtube Channel youtube.com/AnonymAb
    2
    Hello ..
    Someone help me.
    i Took Backup from Official TWRP but when i am trying to restore it giving me error=255 . How i fix this.
    it happens when i am trying to restore FIRMWARE partition.
    any solution . anyone facing this issue.. ?
    GAulQuug.jpg

    does not work for me. do you have any other method?

    That happened to me twice, loosing the imei.
    To fix it, just restore or flash any rom you want, and follow this steps:

    • Extract NON-HLOS.bin file from official ROM.
    • Copy extracted NON-HLOS.bin to the adb/fastboot folder.
    • Boot your device into fastboot mode.
    • Connect your device to PC
    • In the folder with adb/fastboot tools press “Shift” key + right mouse button and select “Open command window here”.
    • Enter these commands in order:
    Code:
    Fastboot devices
    Fastboot.exe erase modem
    Fastboot.exe flash modem NON-HLOS.bin
    Fastboot.exe reboot
    • Check your IMEI. It should be restored now.
    1
    Hello ..
    Someone help me.
    i Took Backup from Official TWRP but when i am trying to restore it giving me error=255 . How i fix this.
    it happens when i am trying to restore FIRMWARE partition.
    any solution . anyone facing this issue.. ?
    Just restore system, data,and boot , don't forget flash frimware..Done , solved.
    1
    I am stuck with the same problem. Can you link me to your answer to him or just again tell me what's the solution? :(

    Firmware was 90MB before, after trying to restore it, TWRP wiped it and now it's 23MB.
    The answer is to just restore system, data and boot. That's the way to go.

    Sent from my mido using XDA Labs
    1
    I had this problem on a Redmi Note 3 Pro/Qualcomm recently. It seems to me to be loosely correlated to the /data backup size, and seems to manifest just below 4GB, looks suspiciously like some 32bit counter/offset ... but .... in my case this seems to happen only in the first tar/win file which much < 2GB uncompressed anyway.

    Interestingly, not all tar binaries are equal. The binary from LineageOS 14.1 crashes reading win000 files often if I try to test this from a terminal session when the phone is booted normally, however tar from TWRP does work and doesn't crash. Using tar from ubuntu 18.04 I can see all the files, however there are numerous reports of
    Code:
    tar: Malformed extended header: missing equal sign

    Maybe this tar crash is also what is happening for the TWRP GUI using it's internal tar? Although this seems to be crashing when the recovery is nearing 4GB, however my tar crash seems to happen on the first segmented win000 file? Maybe it is related in some way to pigz which seems to be used by the TWRP GUI to compress/uncompress and it does multi-threading. I haven't looked at TWRP code.

    I tried TWRP 3.1.1-0, and downloaded the latest 3.2.3-0 from twrp.me. Both failed in the same way.

    I inspected some of the backups I had, finding decrypted /data space usage less /data/media:

    Code:
    $ ls -1
    2018-09-06--12-41-18_lineage_kenzo-userdebug_7.1.2_NJH47F_02865f
    2018-11-10--11-08-53_lineage_kenzo-userdebug_7.1.2_NJH47F_02865f
    2019-01-10--10-01-22_lineage_kenzo-userdebug_7.1.2_NJH47F_02865f
    2019-01-26--16-04-54_lineage_kenzo-userdebug_7.1.2_NJH47F_02865f
    $ grep Data.backup.size */recovery.log|uniq|sed 's/\// /;s/--[^ ]* / /;s/:/ /'
    2018-09-06 recovery.log I:Data backup size is 3464MB, free: 14062MB.
    2018-09-06 recovery.log I:Data backup size is 3464MB, free: 11552MB.
    2018-11-10 recovery.log I:Data backup size is 4622MB, free: 11065MB.
    2018-11-10 recovery.log I:Data backup size is 4622MB, free: 7576MB.
    2019-01-10 recovery.log I:Data backup size is 4041MB, free: 11284MB.
    2019-01-10 recovery.log I:Data backup size is 4041MB, free: 8192MB.
    2019-01-26 recovery.log I:Data backup size is 652MB, free: 24414MB.
    $

    I could restore 2018-09-06 and 2019-01-26 using TWRP GUI while the other 2 failed with error=255. Of the backups I could restore with the TWRP GUI, both backups are easily < 4GB. 2019-01-10 is just below, still no idea if it is related to 4GB. In each case I formatted /data before hand, so /data/media was empty, so there was 24GB of free space, so there was always at least 2 times, sometimes 5 times, the actual space required for the recovery available.

    Irrespective of the actual failure mode, I was able to restore the other backups manually.

    Interestingly when I examine the .win and .win000 files with
    Code:
    tar tvf file | sed 5q
    I find that the single .win file backups need to be restored while current directory is /data whereas the multipart backups need to be restored while current directory is /.

    Manual restore process from TWRP recovery shell :
    1. Backup everything to storage external the phone, and then backup the backup.
    2. Wipe /data. I prefer to format /data while also wipes /data/media = /sdcard as this guarantees /data is clean, however if your backups are stored in /sdcard/TWRP then you are going to need to either not format /data or restore them from your PC, or not store them in /sdcard/TWRP and store them on an external sdcard or external USB OTG drive. Actual location may vary depending on TWRP build. Determine the b= lines below appropriately.
    3. Connect using adb shell. You could type this in using the TWRP Advanced Terminal, but error prone.
    4. Make sure you have enough free space on /data to do the restore. You should have, but this is the manual process so cross check.
    5. Restore the .win0?? files with tar.
      Code:
      ... # PS1="# "  # optional
      # cd /location/TWRP/BACKUPS/serialnumber/2019-01-10* # location: sdcard sdcard1 usb-otg
      # pwd # verify backup directory
      /location/TWRP/BACKUPS/.../2019-01-10--10-01-22_...
      # b=$(pwd) # remeber backup folder location
      # ls -l data.*.win000 # verify backup file exists
      -rw-rw---- 1 root sdcard_rw 1109681843 2019-01-26 11:02 data.ext4.win000
      # for m in data*md5; do md5sum -c $m; done # verify md5 checksums of each tar/win file.
      data.ext4.win000: OK
      data.ext4.win001: OK
      data.ext4.win002: OK
      # cd /
      # for w in $b/data*win0??; do echo recover $w; tar xpvf $w > $w.rec; echo; done
      recover /.../data...win000
      tar: removing leading '/' from member names
      
      recover /.../data...win001
      tar: removing leading '/' from member names
      
      recover /.../data...win002
      tar: removing leading '/' from member names
      
      # cd $b
      # wc -l data*rec # verify recovery of reasonable number of files
          29346 data.ext4.win000.rec
            343 data.ext4.win001.rec
           1831 data.ext4.win002.rec
          31520 total
      # df /data
      Filesystem           1K-blocks      Used Available Use% Mounted on
      /dev/block/dm-0       25667344  15051056  10599904  59% /data
      #
    6. Reboot