tempfile issue #1
Closed
opened 7 years ago by tukusejssirs
·
10 comments
Loading…
Reference in new issue
There is no content yet.
Delete Branch '%!s(<nil>)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
I've just found adebar and I wanted to give it a try, so I cloned it from git to my arch linux. Now, while I ran
./adebar-cli ./bu_test/
, I received these errors:So I explored the file
./lib/partitions.lib
on line 75 and 79:The
tempfile
command is not installed in my system and I hae no clue what should be done in order to achieve the solution :).I cannot tell you where it's on Arch – on Debian it's part of the
debianutils
package. You better ask on some Arch forum for that.Doing a little Google-Fu on it, I found a related issue in another project: seems like
tempfile
is something Debian specific, and I might substitute it bymktemp
. Will check that as soon as I find some time. Meanwhile, for a work-around to get you started: could you create a simple shell-script as e.g./usr/local/bin/tempfile
with the following content:make that executable for all (
chmod 0755 /usr/local/bin/tempfile
), and let me know if that works for you? If so, fixing the issue in Adebar would be a simple search-and-replace.Update: Please do a
git pull
, then checkout the devel branch (git co devel
) and try if it works – I did the replace: thetempfile
man-page even suggests so, astempfile
is declared "obsolete". A short test run didn't throw any error here for me – now I just need confirmation before merging that into master :)I just tried the
devel
branch. I am not sure if I do something incorrectly (or in a way that it is not supposed to work), but after running the script, it just hangs. Here’s the output:But indeed, there are no errors. :)
Thanks for the feedback – that's good news (the "no errors" part, of course)! Then my latest commit can be merged into master (as it fixes a "bug" affecting all non-Debianers).
For the "hanging", I'm not sure what that should be (would require some debug code – I doubt it's your fault, but I'd need more details). Are you using a config (or rather altered the default one – as according to your syntax, that's the only one Adebar might have picked)? If so, I'd like to see it. Moreover, the parameter passed to the script should normally be the name of the config (without path), so your syntax looks a bit strange to me – not that that should be the cause behind the hang (as this param originally was the directory to use, it shouldn't cause any trouble).
Furthermore, could you please provide some details on the device used: brand, model, Android version? And am I correctly assuming either a "NoName device" – or a custom ROM? The serial looks like that.
Hint: this repository also has a Wiki you might wish to check (e.g. for configuration hints :)
Well, I have not altered anything in your code, just used the default settings. But probably I just misunderstood the following:
and just used the target directory when to backup my device. Probably the problem lays in not creating a
config
file.Btw, my phone is Lenovo A536, stock Android 4.4.2 rooted. As for the serial (if by that you mean
0123456789ABCDEF
), I have this one since before rooting my device and even changing any of its settings (its a relatively new device and I am its first owner).Yes, I just now checked upon the wiki (I really thought there would be some help, at least basic one, in
./adbar-cli --help
how to use the script. :)Well, the
--help
stuff isn't there (feel free to create a separate issue for that) as there are simply no more command-line parameters. Everything is done via the config file. And no, not creating one is no issue – default settings are used then. You just cannot control anything without using your own config.OK, time for me to flash the Kitkat ROM to my good old Milestone 2: I've just tested Adebar with Android versions up to 4.3, might be something special introduced with 4.4 which I'm not aware of. According to your output, the script hangs at
Checking default install-location
. Please try:and let me know if that hangs as well – as that's the only command executed agains the device at that point. But according to your file list, that seems to have finished:
defaultInstallLoc
probably has the commandadb shell pm set-install-location
(so you can ommit that check) – which means you're stuck in partition check (which would be next – and misses the progress output, aha. OK, fixed that (do anotherpull
of the devel branch, please).Now let's figure where exactly you get stuck. Edit
lib/partitions.lib
. At line 222 startsgetPartInfo()
. Here we need to add some debug code for you – either using simpleecho
commands (as we either remove that later), or by facilitating thedoProgress()
function. Please add something before each_*()
function is called, likeecho "DEBUG: Calling _fsProcDumchar"
– so we see how far you get. (And again, no need for a config file at this point)After I pulled new devel brach, you cetainly did a good job. However, only one new line appeared in the output and the script hangs there:
After editing
lib/partitions.lib
file, the following is the output (it still hangs):Here’s the part at which it hangs:
echo "DEBUG: Calling _fsProcDumchar ..."
_fsProcDumchar # check for possible testers :)
if ${#MTD_D[*]} -gt 0 ; then
PARTITION_SRC="dumchar"
return
fi
I can do nothing about those "linker" errors – looks like some of your libraries have issues.
As for the "new output": Yes, only one more line (that was expected) – which tells us we really left the InstallLoc part and entered partInfo collection. So we're stuck collecting MTK details. That procedure (
_fsProcDumchar()
) starts at line 73 in the same file.The only explanation for the hanging here could be an endless loop, which is hardly possible – the loop goes over the … ah, stupid me! Over the "nothing: waiting for input", which is why it hangs, yuck! Fixed that (one more
pull
, please).I had no access to any MTK device, so I was never able to test the results here – but I'm confident it will work now (and am curious for the results).
Should it still hang, could you insert one line before line 88, please?
Then run it again. Abort when the counter exceeds ~50 – there shouldn't be that many lines. Then we need to see what further is to be done.
I think you’ve done it. :)
Just to make sure, should the backed up files look like this?
Looks OK for the "default config". On a first look I've missed the
partBackup
file, but that's turned off by default so it seems fine.I'd say we can close this issue as "solved", and you investigate your collection. If something's wrong, you can anytime create a new issue (or re-open this one). I'm still very curious for your partition info collection; as soon as you get started with your own config, I'd be grateful for the
partBackup
file.Quick start, within the Adebar directory:
Then please attach the
partBackup
script here. And btw: anotherpull
brings the "newbie intro" from your other issue. I will merge that to master now.Enjoy!