FORUMS
Remove All Ads from XDA

 View Poll Results: Is Migrate backup and restore working without any errors?

Yes. No errors at all.
 
173 Vote(s)
42.40%
Minor ignorable issues
 
104 Vote(s)
25.49%
No! There are huge errors!
 
131 Vote(s)
32.11%

[APP][ROOT][5.0+][20th Nov] Migrate - custom ROM migration tool

343 posts
Thanks Meter: 1,218
 
By SayantanRC, Senior Member on 4th November 2018, 04:02 PM
Post Reply Email Thread
1st December 2019, 08:50 PM |#1031  
BillGoss's Avatar
Senior Member
Flag Sydney
Thanks Meter: 3,065
 
More
Quote:
Originally Posted by Wishmasterflo

When I try to flash a Migrate_Backup.zip file in TWRP (on a Android 10 custom ROM Oneplus6). I get error 6 as well.
No luck in flashing back a Backup. I tried with several different Backup files created with different Versions of Migrate.

What is that AWK ? Something with/for Busybox?

Here some extract from the recovery.log file:



EDIT: OK I removed now the part with the free space checking and AWK from the script and after that I could successfully flash my Backup.zip file(es) in TWRP without any error 7 but then when restarting my Phone the Migrate Helper app has not found anything to restrore. I dont know why.
I took a look in the following folders and all of them were empty:

SDCARD/Android/Data/balti.migrate
SDCARD/Android/Data/balti.migrate.helper

also the subfolder CACHE within these folders is empty.
Are these the folders where the flashed Migrate_Backup.zip data is put or where is that located?

Rather than remove the free space check (it'll assume there's none and not extract the backed up data), replace every instance of "awk" in the script files (*.sh) with "/tmp/busybox awk". Then it should work.

It seems that not every version of TWRP includes awk.

Busybox is a collection of Unix utilities. Awk is one of the utilities and is a file editor, similar to sed, but more versatile.

Sent from my OnePlus3T using XDA Labs
2nd December 2019, 08:19 AM |#1032  
Senior Member
Flag Stockholm
Thanks Meter: 71
 
More
Quote:
Originally Posted by BillGoss

Rather than remove the free space check (it'll assume there's none and not extract the backed up data), replace every instance of "awk" in the script files (*.sh) with "/tmp/busybox awk". Then it should work.

It seems that not every version of TWRP includes awk.

Busybox is a collection of Unix utilities. Awk is one of the utilities and is a file editor, similar to sed, but more versatile.

OK I did that now but it fails when trying to move the files to the migrate\cache folder:

mv: bad '/data/migrateTemp/org.thoughtcrime.securesms.app': Operation not permitted

so that error Message I see then for all my apps and later on the error "unpack failed" I guess due to the above error.

What is causing that the mv command fails?
2nd December 2019, 11:01 PM |#1033  
BillGoss's Avatar
Senior Member
Flag Sydney
Thanks Meter: 3,065
 
More
Quote:
Originally Posted by Wishmasterflo

OK I did that now but it fails when trying to move the files to the migrate\cache folder:

mv: bad '/data/migrateTemp/org.thoughtcrime.securesms.app': Operation not permitted

so that error Message I see then for all my apps and later on the error "unpack failed" I guess due to the above error.

What is causing that the mv command fails?

Zip up the recovery log and the modified shell scripts and I'll have a look.

Sent from my OnePlus3T using XDA Labs
2nd December 2019, 11:13 PM |#1034  
Senior Member
Flag Stockholm
Thanks Meter: 71
 
More
Quote:
Originally Posted by BillGoss

Zip up the recovery log and the modified shell scripts and I'll have a look.

Here the recovery log.
Attached Files
File Type: zip recovery.zip - [Click for QR Code] (11.3 KB, 4 views)
3rd December 2019, 02:16 AM |#1035  
BillGoss's Avatar
Senior Member
Flag Sydney
Thanks Meter: 3,065
 
More
Quote:
Originally Posted by Wishmasterflo

Here the recovery log.

Hmm. I see two issues which may or may not be related.

1. The command "getprop ro.product.cpu.abi" in the prep.sh script doesn't return anything as seen in the following output (nothing showing after Found: )
ui_print Original CPU ABI was arm64-v8a
ui_print Found:
ui_print Restoration of some apps MAY FAIL!
2. The many lines from the mover.sh like:
mv: bad '/data/migrateTemp/balti.migrate.app': Operation not permitted
are related, from my limited Google search, to a permission problem.

Unfortunately I can't help with this.

It seems to me that the context in which the scripts run might not have root access. But I could be totally wrong.

The endless lines of ' error reading config file "/system/etc/ld.config.txt" ' show up for me also in TWRP when an Android 10 system is mounted. But they don't appear to cause problems.

Anybody else have any suggesting as to why a "mv" command gets "Operation not permitted"?

Sent from my OnePlus3T using XDA Labs
The Following User Says Thank You to BillGoss For This Useful Post: [ View ] Gift BillGoss Ad-Free
3rd December 2019, 07:30 PM |#1036  
Senior Member
Thanks Meter: 450
 
More
Quote:
Originally Posted by BillGoss

Hmm. I see two issues which may or may not be related.

1. The command "getprop ro.product.cpu.abi" in the prep.sh script doesn't return anything as seen in the following output (nothing showing after Found: )
ui_print Original CPU ABI was arm64-v8a
ui_print Found:
ui_print Restoration of some apps MAY FAIL!
2. The many lines from the mover.sh like:
mv: bad '/data/migrateTemp/balti.migrate.app': Operation not permitted
are related, from my limited Google search, to a permission problem.

Unfortunately I can't help with this.

It seems to me that the context in which the scripts run might not have root access. But I could be totally wrong.

The endless lines of ' error reading config file "/system/etc/ld.config.txt" ' show up for me also in TWRP when an Android 10 system is mounted. But they don't appear to cause problems.

Anybody else have any suggesting as to why a "mv" command gets "Operation not permitted"?

Likely due to the dynamic partitions that were introduced as part of Android 10.
Depending on the device (the 7T experiences this badly), much of the internal storage is not converted until init.

For this reason, a lot of TWRP based modules are now moving to Magisk, due to completing it's tasks around init.
The Following 3 Users Say Thank You to jslawler For This Useful Post: [ View ] Gift jslawler Ad-Free
5th December 2019, 08:09 AM |#1037  
Senior Member
Flag Stockholm
Thanks Meter: 71
 
More
Quote:
Originally Posted by jslawler

Likely due to the dynamic partitions that were introduced as part of Android 10.
Depending on the device (the 7T experiences this badly), much of the internal storage is not converted until init.

For this reason, a lot of TWRP based modules are now moving to Magisk, due to completing it's tasks around init.

OK I see. Thanks. I have a Oneplus 6.
But at least the manual Backup extract works here and I can restore my Migrate Backup this way.
5th December 2019, 08:34 PM |#1038  
str8str's Avatar
Senior Member
Flag Kitchener Ontario
Thanks Meter: 1,039
 
Donate to Me
More
Quote:
Originally Posted by BillGoss

Excellent, thanks!

A missing awk or a version of awk that behaves differently will cause the script to exit with an error and TWRP gives an error 7. I'm glad the BB one worked.

@SayantanRC I have a couple of suggestions to make:
1. Use the include busybox for the awk calls (/tmp/busybox awk ...) to ensure consistency across versions of TWRP.
2. Use a shell script update-binary (and a dummy updater-script) instead of the edify binary version. This allows OUTFD to be exported in update-binary and used in the other shell scripts that are called. Then the echoIt function will work if it's defined as:


These two changes would eliminate most(?) of the error 7 and error 1 problems and produce good output to the TWRP display and logs. I've attached a sample update-binary for your consideration.

So where do I put this or how to use it
6th December 2019, 02:50 AM |#1039  
BillGoss's Avatar
Senior Member
Flag Sydney
Thanks Meter: 3,065
 
More
Quote:
Originally Posted by str8str

So where do I put this or how to use it

I'm not providing a solution - that's up to the developer to do. I'm just identifying the cause of the errors and possible solutions.
If you're not familiar with shell scripts and how to modify them, then you're best waiting for an updated version of Migrate.
Also, to fix an individual problem depends on the errors you're getting and then modifying the scripts in your backup zips.

Sent from my OnePlus3T using XDA Labs
6th December 2019, 08:01 PM |#1040  
Senior Member
Thanks Meter: 31
 
More
Quote:
Originally Posted by 1aladdin1

so prep.sh calls /system/bin/awk and ... it's not there.

Reason is the specific recovery version I used.
At the moment official TWRP recovery is not ready for Android 10 - as described by Dees_Troy here
So I took a special system-as-root ready version (needed for Android 10), developed by XDA Senior Member Captain Throwback for my device HTC M8 - see here

In this recovery system partition is mounted at /system_root and not at /system
/system is a link to /system_root/system and the latter doesn't even exist

Quote:
Originally Posted by BillGoss

Excellent, thanks!

A missing awk or a version of awk that behaves differently will cause the script to exit with an error and TWRP gives an error 7. I'm glad the BB one worked.

@SayantanRC I have a couple of suggestions to make:
1. Use the include busybox for the awk calls (/tmp/busybox awk ...) to ensure consistency across versions of TWRP.
2. Use a shell script update-binary (and a dummy updater-script) instead of the edify binary version. This allows OUTFD to be exported in update-binary and used in the other shell scripts that are called. Then the echoIt function will work if it's defined as:

Code:
echoIt() {
    echo "ui_print $1" > ${OUTFD}
}
These two changes would eliminate most(?) of the error 7 and error 1 problems and produce good output to the TWRP display and logs. I've attached a sample update-binary for your consideration.

Sent from my OnePlus3T using XDA Labs

Finally I got all mtest*.zip running in the specific recovery version I use.
I placed a symlink
Code:
/system -> /system_root/
in the root directory. Then all awk calls were redirected accordingly and installation of zips finished without errors.


I also asked the dev of the particular recovery I use @Captain_Throwback and got this answer:
Quote:

/system_root is the correct mount point for SAR devices. There is a symlink from /system_root/system to /system by default, but in order for zip installations to succeed, it has to be deleted. The actual location of the binary is /system_root/system/bin. There is no adjustment to be made here. The proper way to determine where the binaries should be located is to check the path of the ANDROID_ROOT variable, and if it's system, use system/bin, but if it's system_root, use the longer path mentioned above. That's pretty basic logic which any app should be able to accommodate

The Following 3 Users Say Thank You to 1aladdin1 For This Useful Post: [ View ] Gift 1aladdin1 Ad-Free
7th December 2019, 11:34 AM |#1041  
pnsdhrn's Avatar
Senior Member
Thanks Meter: 357
 
More
The TWRP is installed in unrooted Realme 5 Pro phone.Will Migrate work in this?
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes