Error restoring backups

[Astral92]

How to fix this?

Edit: Added another error during restoring after switching to stock ROM Android 8 encrypted data partition

2022-10-09-11-14-57-843.log

[tsiflimagas]

Fix what? You've literally said nothing. Properly fill in the issue template, instead of removing it, and give enough information about your issue, if you want to get any help.

[Astral92]

Fix what? You've literally said nothing. Properly fill in the issue template, instead of removing it, and give enough information about your issue, if you want to get any help.

I attached a screenshot I don't know why it didn't appear first try

[hg42]

the logged error contains: "/data/local/toybox: not found"

this is unlikely to appear at that point. NB should complain when it is started (which is not tested very often, or may be like never? because everyone has a toybox, it's part of Android).

Note: "toybox" is the toolbox/utilbox executable (much like busybox) that includes the tar and ls commands we heavily use.

Can you open a terminal and try to execute "toybox" inside? (hope you know what I mean... If you have Telegram, you might enter our group)

[Astral92]

I get this: No command toybox found, did you mean: Command dosbox in package dosbox from the x11-repo repository

[hg42]

you are probably using Termux?

though it udually shoukd have access to toybox if it exists, the path could be reconfigured in Termux. Also, you might need to su first, because the environment is differemt for root.

You could/should try to invoke toybox in adb or in another terminal (one that uses the standard environment, Termux tries to be unix)

You could also look with a root file manager, if toybox is in one if the usual directories. Mine is in /system/bin/

Note: toybox is part of Android if it is really missing, it's probably a fault of your ROM. So, you need to change the ROM. Or for NB alone, you can install the toybox Magisk module. It's also a fixed toybox, which is good. It installed as toybox-ext, so it's still not usable as the system toybox, unless you link it to the standard name without -ext

[Astral92]

In terminal emulator:

HWRNE:/ $ toybox acpi base64 basename blkid blockdev cal cat chattr chcon chgrp chmod chown chroot chrt cksum clear cmp comm cp cpio cut date dd df dirname dmesg dos2unix du echo egrep env expand expr fallocate false fgrep file find flock free freeramdisk fsfreeze getenforce getfattr getprop grep groups head help hostname hwclock id ifconfig inotifyd insmod install ionice iorenice kill killall ln load_policy log logname losetup ls lsattr lsmod lsof lsusb makedevs md5sum microcom mkdir mkfifo mknod mkswap mktemp modinfo modprobe more mount mountpoint mv nbd-client netstat nice nl nohup od partprobe paste patch pgrep pidof pivot_root pkill pmap printenv printf ps pwd pwdx readlink realpath renice restorecon rev rfkill rm rmdir rmmod runcon sed sendevent seq setenforce setfattr setprop setsid sha1sum sha224sum sha256sum sha384sum sha512sum sleep sort split start stat stop strings swapoff swapon sync sysctl tac tail tar taskset tee time timeout top touch tr traceroute traceroute6 true truncate tty tunctl ulimit umount uname uniq unix2dos uptime usleep uudecode uuencode vconfig vmstat wc which whoami xargs xxd yes HWRNE:/ $

[hg42]

ok, that explains why NB doesn't complain at startup. So toybox is there...

what is the output of 'which toybox'?

[Astral92]

ok, that explains why NB doesn't complain at startup. So toybox is there...

what is the output of 'which toybox'?

/system/bin/toybox

[hg42]

ok, so it's a dead end. Nothing like I assumed.

Could you provide a logcat of NB starting (first kill / force close it)

and a logcat from the action that produced the error and/or the one according the error log file. That's assußing you can recreate the situation...do you?

[Astral92]

ok, so it's a dead end. Nothing like I assumed.

Could you provide a logcat of NB starting (first kill / force close it)

and a logcat from the action that produced the error and/or the one according the error log file. That's assußing you can recreate the situation...do you?

Backing up Only Data for 1DM+ App.txt Starting Neo-Backup (After Force Stop).txt

[Astral92]

I used logcat extreme application per-app log cat, I also have telegram to join the group

[Astral92]

ok, so it's a dead end. Nothing like I assumed.

Could you provide a logcat of NB starting (first kill / force close it)

and a logcat from the action that produced the error and/or the one according the error log file. That's assußing you can recreate the situation...do you?

Solved it by copying toybox to data/local and changing its permissions to be executable, Thanks!

[hg42]

ah, interesting...

so, I wasn't as wrong as It thought. All commands fail with "/data/local/toybox not found"

The logcat of the start sequence si very short... there are no commands from finding the toybox executable.

did you wait until the list is loaded?

the logcat should contain a table of toybox executables found in the system and a score attached to each: toyboxvariant -> score

I wonder why it tries to use /data/local/toybox ? Is it possible that a toybox file was hanging out in /data/local but wasn't executable? (because you said, you changed the permissions) This would explain everything...

[Astral92]

The logcats before were only for neo backup activities This one shows toybox stuff(neo backup start up) .txt

Toybox was already rwx inside system but when I copied it to data/local it became rw so I had to make it rwx again that's all there was no toybox in data/local only a temp folder

[hg42]

10-11 23:22:45.460 31415 31415 I <init>@60:j: is root         = true
10-11 23:22:45.460 31415 31415 I <init>@100:j: is mount-master = true

good :-)

but then every toybox detection fails, so the scores are all zero:

10-11 23:22:45.586 31415 31415 I <init>@471:j: utilBox: /data/local/toybox: 0.0.0 -> 0.0
10-11 23:22:45.587 31415 31415 I <init>@471:j: utilBox: toybox-ext: 0.0.0 -> 0.0
10-11 23:22:45.587 31415 31415 I <init>@471:j: utilBox: toybox_vendor: 0.0.0 -> 0.0
10-11 23:22:45.588 31415 31415 I <init>@471:j: utilBox: toybox: 0.0.0 -> 0.0

the first question is, why do they fail? if a toybox was in /system/bin/toybox, it should have been executed when trying toybox, but it is:

10-11 23:22:45.584 31415 31415 E b@76:g$a: unexpected: {
10-11 23:22:45.584 31415 31415 E b@76:g$a: utilBox toybox failed
10-11 23:22:45.584 31415 31415 E b@76:g$a: }

unfortunately there is no further error detail... did you only use Error as level? you should use the maximum level instead, there are a lot more messages from NB (and other parts) with level info and debug or verbose. E.g. Magisk logs the shell commands actually executed, and we see the results, e.g. error messages from the commands.

[Astral92]

10-11 23:22:45.460 31415 31415 I <init>@60:j: is root         = true
10-11 23:22:45.460 31415 31415 I <init>@100:j: is mount-master = true

good :-)

but then every toybox detection fails, so the scores are all zero:

10-11 23:22:45.586 31415 31415 I <init>@471:j: utilBox: /data/local/toybox: 0.0.0 -> 0.0
10-11 23:22:45.587 31415 31415 I <init>@471:j: utilBox: toybox-ext: 0.0.0 -> 0.0
10-11 23:22:45.587 31415 31415 I <init>@471:j: utilBox: toybox_vendor: 0.0.0 -> 0.0
10-11 23:22:45.588 31415 31415 I <init>@471:j: utilBox: toybox: 0.0.0 -> 0.0

the first question is, why do they fail? if a toybox was in /system/bin/toybox, it should have been executed when trying toybox, but it is:

10-11 23:22:45.584 31415 31415 E b@76:g$a: unexpected: {
10-11 23:22:45.584 31415 31415 E b@76:g$a: utilBox toybox failed
10-11 23:22:45.584 31415 31415 E b@76:g$a: }

unfortunately there is no further error detail... did you only use Error as level? you should use the maximum level instead, there are a lot more messages from NB (and other parts) with level info and debug or verbose. E.g. Magisk logs the shell commands actually executed, and we see the results, e.g. error messages from the commands.

I changed the priority level in the application to "verbose (show all)" Log_2022-10-13_00-49-30.txt

[hg42]

not sure about this, at least it's an old issue and it seems, I didn't notice the last log, but it does look weird... I think, I'll close this. Please reopen if it's still a problem.