• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Mods updater-script needs help [Root only]

HasH_BrowN

HasH_BrowN

Android Expert
I am trying to make a updater-script that contains 2 commands. They are the only things being performed.


What I have so far for the script entry is:

run_program("/sbin/busybox", "dd", "if=/dev/zero", "of=/dev/block/platform/msm_sdcc.1/by-name/fota");

run_program("/sbin/busybox", "dd", "if=/dev/zero", "of=/dev/block/platform/msm_sdcc.1/by-name/misc");

The rest of the file is ui_print lines and thats all.

The zip will pass in recovery, but I can't figure out if the commands have actually been executed, they're for a bootloop after an OTA. I haven't had a bootloop, since switching to deodexed ROM. I'm pretty sure there doesn't need to be any mounts included because the commands can be entered into Terminal Command in custom recovery starting with the "dd". So a small updater-script. But is [run_program("/sbin/busybox",] correct for dd to execute the remainder of that command??
I've looked far and wide, also for many weeks and read about 40 different multi-paged threads. I'm just not finding anything relevant to getting a command executed in edify script. Is there a If This Then That type of command that can be used?
I'm new to this particular area, so any help would be appreciated.
 
Last edited:
Hey HasH_BrowN,

I'm a little hamstrung here with resources 'cause all of my real files and examples are at home on my desktop, but you've got a couple of options that might help:

- try using the update-binary file as a shell script instead of the actual update-binary (this is what the UPDATE-SuperSU-v#.##.zip does--the updater-script in that file is just a dummy file):

#!/sbin/sh
logfile="/cache/HBlog.txt"
echo "about to do first dd command" >> $logfile
/sbin/busybox dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/by-name/fota >> $logfile
echo "about to do second dd command" >> $logfile
/sbin/busybox dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/by-name/misc>> $logfile
echo "all done!" >> $logfile
Click to expand...

Then you can examine the /cache/HBlog.txt file to see what what recorded by your script.

There is an if/then/else syntax in the edify language...see my thread here for a little bit of info on that:


Hope that helps!

:)
 
scary alien said:
Hey HasH_BrowN,

I'm a little hamstrung here with resources 'cause all of my real files and examples are at home on my desktop, but you've got a couple of options that might help:

- try using the update-binary file as a shell script instead of the actual update-binary (this is what the UPDATE-SuperSU-v#.##.zip does--the updater-script in that file is just a dummy file):

​

Then you can examine the /cache/HBlog.txt file to see what what recorded by your script.

There is an if/then/else syntax in the edify language...see my thread here for a little bit of info on that:


Hope that helps!

:)
Click to expand...
Thank you for an excellent reply. Have to finish working, will try when I get home.

I didn't even think of trying a dummy file, nor to even look @ the SU update zip. This is something I didn't even read about in the many hours of research. I didn't realize how hard it would be to get some terminal commands to run from a zip in TWRP. Almost seems easier to write a script for a ROM install. Lol, jk.
Thanks will post back with a result.

BTW, I now have confirmation that the commands do not get executed. I'm having a user with a failed install pull a log from TWRP for me since I can't reproduce a bootloop right now.

I'm ecstatic that I have some info from you that might help me, thank you!!!
 
Took a quick look at the link you provided and read the OP. Simply awesome, surprised I didn't run across your app sooner. Can't wait to get home.:p:D
 
======================
OTA Verifier v2.7 Analysis
======================

statements read: 12
expressions processed: 10
true statements: 10
false statements: 0
inaccessible files: 0
inaccessible allowed: 0
sha1 mismatches allowed: 0

- there were no false/failed expressions encountered (excellent!)

Device information:

Device: e2nas
Rooted: true
Maker: LGE
Model: LGLS660
Carrier: M'hudha Phaquin
Board: MSM8226
Name: e2nas_spr_us
Bootloader: unknown
Android OS: 4.4.2

Had a few more minutes & this is result.
Will have to wait to try the dummy file and get the log from user with failed install
 
HasH_BrowN said:
Took a quick look at the link you provided and read the OP. Simply awesome, surprised I didn't run across your app sooner. Can't wait to get home.:p:D
Click to expand...

Thank you for the kind words :).

I put a ton of effort into that app (parsing the Edify language and executing/interpreting the non-invasive ones) to help folks with vetting OTAs before they tried to install them.

Well, now Google's changed how (some of) the OTAs are put together such that there's a post install/patch phase that checks the SHA1 sums of files that don't exist until after the OTA actually gets run/installed, so that takes away from the usefulness of the app for the OTA verification.

Also, bear in mind that I don't execute all Edify expressions--only the ones listed in the app or thread description (i.e., so I won't "execute" a run_program expression for example)--I didn't want to do anything that actually modifies a device, so it's all kind of "read-only" if you will.

But I did learn an awful lot about OTAs, Edify, etc...;) :) :p.
 
Work order put on hiatus for next hour, yipee!!

So I copied the script you supplied above and created a dummy script with it. Packaged it up and zipped, went into TWRP and it failed (binary issue). Flashed the zip I have with the commands and it passed. Since the dummy script failed, no HBlog.txt.
The file should have been renamed to updater-script and then packaged normally, correct? Or is there a different way.
I have a recovery log that I cropped. It's showing the dd commands on lines 52 and 68. Data is shown being written. Appears to be executed. I've attached as .txt also here is the download link to the zip :
http://androidforums.com/resources/twrp-bootloop-fix-zip.214/download?version=219

Sometimes it would be nice if my brain would slow down....its distracting to go a million miles an hour.
I'm stumped as to why it had a failed install (as per user reply). I don't want to pull the resource if the script can be fixed, but then again I don't want to be supplying the community with a useless fix zip either.

As always, credit will be duly noted in OP of the link above and in the zip ui_print for all help provided.
 

Attachments

Last edited:
For the script, it will need to be named as "update-binary" and NOT as "updater-script".

edit: so, when you flash a .zip file with this script as the update-binary file, then only the script will get run--the updater-script file does not get invoked.

You'll also want to make sure you're using an editor to create that text file that does not contain any superfluous trailing characters (i.e., each line should be terminated with a linefeed and not a carriage-return & linefeed combo.

I use gVim or vi, etc...I've heard UltraEdit works good, too, but I've never used it.

I've attached what I hope is a "clean" (linefeed terminated) version of the mini-script above (I had to put it in a .zip file to upload it to here at AF; you'll have to extract it, of course :).

Lemme know if this works better :).
 

Attachments

Last edited:
Follow-up post:

Okay, I just looked at your updater-script file, too, which contains your original edify commands, etc...

You might have been having problems with this file, too, if the lines had trailing cr/lf characters instead of just linefeeds.

Try-out the script in post #8 above as your "update-binary" first and then we'll figure-out how to call that script from a proper updater-script file so that you can do the important ro.product.device checks, etc. that I see you have in the updater-script example.

We'll figure that part out later, though...btw, I won't be home until later this evening...about 9 PM EDT, if you still need help with things (but I'll be better able to test and debug with you).

edit: also note the edit that I made in post #8 above.
 
I ended up downloading the SuperSU zip to look at structure and format. Then realized it was the update-binary not the updater-script, to late on my error. Lol

I will try what you said in post 8 & 9. I'm in Florida and don't go to sleep till 2-3am. Enjoy the rest of your day.
 
No worries...:)

I'll try tonight to pack-up a small .zip file for you that will do the best of both worlds--i.e., it will call a shell script from the edify syntax.

Cheers!
 
Okay did what you suggested. Got it to leave the HBlog.txt in /cache.
Re edited updater (took out extra [;]).
*The only reason the assert is in there is I didn't test on any other devices. But I've used those commands in terminal command in TWRP on my device, so I'm sure that the commands work as intended.

Here is the edited zip, with device binary. (Guessing) I'm stuck until later. Wonder if I should switch /sbin to /xbin.

Oh...I wish I knew more about edify and sh scripts. I usually have to learn most things on my own, but your help is just what the doctor ordered and very educational.
 

Attachments

Last edited:
HasH_BrowN said:
Is the script correct or ??
I'm clueless.
Click to expand...

Well, I didn't get much time to play with this tonight--I got home a bit later than I thought.

I pulled out and old device to test on and I'm getting errors I didn't / don't expect :(, so I didn't make the progress that I had hoped to for you this evening I'm afraid.

The HBlog.txt output looks fine/right...I would have expected to see the busybox dd output also redirected there, though, I'm guessing that the output is sent to the error file descriptor instead of stdout.

You'll probably have to change the dd commands to something like this to redirect the output to the log file:

/sbin/busybox dd if=aaa of=bbb 2>> $logfile >> $logfile​

correcting the dd commands with your proper ones, of course. That should allow you to see if the busybox dd command is actually getting invoked

I think your /sbin references are fine since that's where the utilities are in the ramdisk.

You can always include your own utilities in your flashable .zip if you're unsure about the /sbin refs, etc., but you'll have to extract them with a package_extract or an explicit unzip (like the UPDATE-SuperSU*.zip does).

I gotta crash since now but I'll check back tomorrow with you.

Cheers!
 
scary alien said:
Well, I didn't get much time to play with this tonight--I got home a bit later than I thought.

I pulled out and old device to test on and I'm getting errors I didn't / don't expect :(, so I didn't make the progress that I had hoped to for you this evening I'm afraid.

The HBlog.txt output looks fine/right...I would have expected to see the busybox dd output also redirected there, though, I'm guessing that the output is sent to the error file descriptor instead of stdout.

You'll probably have to change the dd commands to something like this to redirect the output to the log file:

/sbin/busybox dd if=aaa of=bbb 2>> $logfile >> $logfile​

correcting the dd commands with your proper ones, of course. That should allow you to see if the busybox dd command is actually getting invoked

I think your /sbin references are fine since that's where the utilities are in the ramdisk.

You can always include your own utilities in your flashable .zip if you're unsure about the /sbin refs, etc., but you'll have to extract them with a package_extract or an explicit unzip (like the UPDATE-SuperSU*.zip does).

I gotta crash since now but I'll check back tomorrow with you.

Cheers!
Click to expand...
I edited binary script like you said. Worked.
(Mr. Burns/Simpsons, tapping his fingers together mischievously) EXCELLENT!!;):D:cool:

See attachment. That confirms that the commands do get executed, correct??
 

Attachments

HasH_BrowN said:
I edited binary script like you said. Worked.
(Mr. Burns/Simpsons, tapping his fingers together mischievously) EXCELLENT!!;):D:cool:

See attachment. That confirms that the commands do get executed, correct??
Click to expand...
Yes!

:D :D :D

Most excellent! :)

about to do first dd command
dd: writing '/dev/block/platform/msm_sdcc.1/by-name/fota': No space left on device
65537+0 records in
65536+0 records out
33554432 bytes (32.0MB) copied, 2.155834 seconds, 14.8MB/s
about to do second dd command
dd: writing '/dev/block/platform/msm_sdcc.1/by-name/misc': No space left on device
32769+0 records in
32768+0 records out
16777216 bytes (16.0MB) copied, 1.195191 seconds, 13.4MB/s
all done!
Click to expand...

I'm charging-up my old N5 so I can give you some more examples and options...more later, but it sounds like you're well on your way with the tools you currently have :).
 
scary alien said:
Oh, nothing big...I was just going to expand on some of things that I mentioned to fill in some gaps and show different ways to do what you asked about.

Just bonus stuff :).
Click to expand...
Cool, what do you have for today's lesson? (Said with utmost sincerity)

I would like to figure out how to find out those "fota" and "misc" locations on multiple devices so I could run IfThisThenThat commands, make it a universal bootloop fix. That though is a lot of research, user feedback, and elbow grease. Grandiose plans.
I also would like a way to supply the fix to developers to use in their ROM updates. Possibly adding the updater-script edits to their own. The extra commands would include a reboot to recovery and an auto flash for the fix, followed but a final reboot to system.
I just can see this as being somewhat universal provided I add the proper elements to the updater-script.
 
Last edited:
Okay, quite a lot to cover here :).

Here's the updater-script file that is included in the testflash.zip file that I've attached to this post. The attached testflash.zip file is a "normal" flashable .zip file--i.e., the update-binary is a binary file and the updater-script is an edify script that will be executed by the update-binary.

Code: 
ui_print("");
ui_print("okay, let's do this thing...");
ui_print("");

ui_print("  extracting the first file...");
package_extract_file("testfile1.txt", "/tmp/file1.txt");

ui_print("");
ui_print("  extracting the third file...");
package_extract_file("shellscript.sh", "/tmp/script.sh");

ui_print("");
ui_print("  setting permissions on the script file...");
set_metadata("/tmp/script.sh","uid", 0, "gid", 0, "mode", 0777);

ui_print("");
ui_print("  running busybox dd...");
run_program("/sbin/busybox","dd","if=/tmp/file1.txt","of=/tmp/file2.txt");

ui_print("  running the script...");
run_program("/sbin/sh","/tmp/script.sh");

ui_print("");
ui_print("all done!");

Inside the testflash.zip file are two extra files: shellscript.sh and testfile1.txt. I added these two files to show how you can include "resources" (i.e., extra files) that you can install (package_extract) into a location (/tmp in this case).

You can see how I extracted the files from the flashable .zip file and how they were installed, with new names, in the /tmp folder.

Then, I used the set_metadata expression to secure the shell script so it could later be executed.

Next, I used the busybox dd command to make a copy of /tmp/file1.txt to /tmp/file2.txt.

Finally, I ran the shell script via the run_program command in a fashion similar to how the dd command was invoked.

Inside that shell script, you could do all kinds of stuff--i.e., the busybox dd command for instance that we did yesterday, etc. or whatever floats your boat :).

In the shell script I provided, I just did some simple echo commands and redirected the output to a /cache/logfile.txt file.

So, you've got lots of flexibility in creating a flashable .zip file that's really extended when you can also execute a shell script--without having to resort to having the update-binary BE the shell script like we did before.

By the way: most of my troubles last night were because I had an outdated update-binary that I was trying to use...you must have a proper update-binary that's intended for and works for your device.

Also, make sure you don't have any carriage-return characters in your updater-script file.

~ ~ ~

Okay, here is the raw output of the /tmp/recovery.log that's easier to show than a screen shot of my recovery screen.

Code: 
ScaryAlien@LV-426 ~/hb/testflash
$ adb push testflash.zip /sdcard/
3361 KB/s (278847 bytes in 0.081s)

ScaryAlien@LV-426 ~/hb/testflash
$ adb shell tail -f /tmp/recovery.log
I:TWFunc::Set_Brightness: Setting brightness control to 5
I:TWFunc::Set_Brightness: Setting brightness control to 0
I:TWFunc::Set_Brightness: Setting brightness control to 255
I:Set overlay: ''
I:Set page: 'clear_vars'
I:Set page: 'install'
I:Set page: 'flash_confirm'
I:Set page: 'flash_zip'
I:operation_start: 'Flashing'
Installing '/sdcard/testflash.zip'...
Checking for MD5 file...
Skipping MD5 check: no MD5 file found
I:Zip does not contain SELinux file_contexts file in its root.
I:Legacy property environment initialized.

okay, let's do this thing...

  extracting the first file...

  extracting the third file...

  setting permissions on the script file...

  running busybox dd...
about to run program [/sbin/busybox] with 4 args
0+1 records in
0+1 records out
23 bytes (23B) copied, 0.000069 seconds, 325.5KB/s
about to run program [/sbin/sh] with 2 args
  running the script...
-----------------------------------------------
hello from shellscript.sh (or /tmp/script.sh)!


see ya later :)
-----------------------------------------------

all done!
script succeeded: result was [all done!]I:Legacy property environment disabled.
Updating partition details...
I:Data backup size is 663MB, free: 12020MB.
I:Unable to mount '/usb-otg'
I:Actual block device: '', current file system: 'vfat'
...done
I:Set page: 'flash_done'
I:operation_end - status=0

Next is a annotated one where I show the output of the script that you would see on the recovery screen in blue (the XF forum formatting is going to make the emoticons show up here because it's not surrounded in a code-block, but that's okay):

ScaryAlien@LV-426 ~/hb/testflash
$ adb push testflash.zip /sdcard/
3361 KB/s (278847 bytes in 0.081s)

ScaryAlien@LV-426 ~/hb/testflash
$ adb shell tail -f /tmp/recovery.log
I:TWFunc::Set_Brightness: Setting brightness control to 5
I:TWFunc::Set_Brightness: Setting brightness control to 0
I:TWFunc::Set_Brightness: Setting brightness control to 255
I:Set overlay: ''
I:Set page: 'clear_vars'
I:Set page: 'install'
I:Set page: 'flash_confirm'
I:Set page: 'flash_zip'
I:eek:peration_start: 'Flashing'
Installing '/sdcard/testflash.zip'...
Checking for MD5 file...
Skipping MD5 check: no MD5 file found
I:Zip does not contain SELinux file_contexts file in its root.
I:Legacy property environment initialized.

okay, let's do this thing...

extracting the first file...

extracting the third file...

setting permissions on the script file...

running busybox dd...
about to run program [/sbin/busybox] with 4 args
0+1 records in
0+1 records out
23 bytes (23B) copied, 0.000069 seconds, 325.5KB/s
about to run program [/sbin/sh] with 2 args
running the script...
-----------------------------------------------
hello from shellscript.sh (or /tmp/script.sh)!


see ya later :)
-----------------------------------------------

all done!
script succeeded: result was [all done!]I:Legacy property environment disabled.
Updating partition details...
I:Data backup size is 663MB, free: 12020MB.
I:Unable to mount '/usb-otg'
I:Actual block device: '', current file system: 'vfat'
...done
I:Set page: 'flash_done'
I:eek:peration_end - status=0
Click to expand...

Finally, here's the adb session where I explored the /tmp and /cache directories to show where everything ended-up and what the contents and results were (I didn't put this in a code block either so that I could use the color formatting to highlight some items):

ScaryAlien@LV-426 ~/hb/testflash
$ adb shell
~ # alias ll='ls -l'
~ # cd /tmp
/tmp # ll
-rw-rw-rw- root root 23 1970-01-01 04:23 file1.txt
-rw-rw-rw- root root 23 1970-01-01 04:23 file2.txt
-rw-rw-rw- root root 33757 1970-01-01 04:24 recovery.log
-rwxrwxrwx root root 277 1970-01-01 04:23 script.sh
-rwxr-xr-x root root 365632 1970-01-01 04:23 updater
/tmp # cd /cache
/cache # ll
drwx------ system system 1970-01-22 13:11 backup
-rw-rw-rw- root root 40 1970-01-01 04:23 logfile.txt
drwxrwx--- root root 1970-01-01 00:00 lost+found
drwxrwx--- system cache 1970-01-01 02:51 recovery
/cache # cat logfile.txt
logging a message to /cache/logfile.txt
/cache # cd /tmp
/tmp # cat file2.txt
Hi! I'm testfile #1 :)
/tmp # diff file1.txt file2.txt
/tmp # cat script.sh
#!/sbin/sh
echo "-----------------------------------------------"
echo "hello from shellscript.sh (or /tmp/script.sh)!"
echo
echo "logging a message to /cache/logfile.txt" >> /cache/logfile.txt
echo
echo "see ya later :)"
echo "-----------------------------------------------"
/tmp # exit
ScaryAlien@LV-426 ~/hb/testflash
Click to expand...

Finally, an excellent and current resource about Edify:


Cheers and I hope that helps!

Let me know if you have any questions.

:)

edit: oh, if you want to flash this, be sure to replace/update the update-binary with the proper one for your device.
 

Attachments

scary alien said:
P.S., remind me tomorrow to show you a cool trick for (carefully) testing a flashable .zip file from outside of custom recovery while Android is up and running.

Gotta crash now--g'night! :)
Click to expand...
OMG!! I asked for a lesson and you gave me a whole course. Wicked.
It will be a day or so, going to help my parents out with flooring.
Now I have to absorb all this. You put a lot on my plate, me being a newbie. Lol. I'll handle it. Thank you once again.
 
Just sharing info here. If it's not helpful, let me know and I'll try to do better, or just ignore me. ;)

One way to see whether the dd commands work during testing is to first write something to the partition. So, doing it in edify with "fota":
Code: 
run_program("/sbin/sh", "-c", "echo test > /dev/block/platform/msm_sdcc.1/by-name/fota");
This writes a string "test" to the fota partition. We can make sure the partition is nonzero:
Code: 
assert(sha1_check("/dev/block/platform/msm_sdcc.1/by-name/fota") != "57b587e1bf2d09335bdac6db18902d43dfe76449");
See below for the explanation of this command.

Then zero the partition as before using dd. Note that "dd" should technically exit with an error because the fota has fewer writable bytes than /dev/zero has zeros. Zeros will still be written, but if you put the run_program in a conditional statement like if/then/else/endif, beware of that. If you want the command to return without that error, you can specify the size to write. The fota partition on the LG Tribute (which is HasH_BrowN's target for now) is 32MiB, so:
Code: 
run_program("/sbin/busybox", "dd", "if=/dev/zero", "of=/dev/block/platform/msm_sdcc.1/by-name/fota", "bs=1048576", "count=32");
Then we can check the partition is zeroed:
Code: 
assert(sha1_check("/dev/block/platform/msm_sdcc.1/by-name/fota") == "57b587e1bf2d09335bdac6db18902d43dfe76449");
The string "57b587e1bf2d09335bdac6db18902d43dfe76449" is just the SHA-1 checksum of 32MiB of zeros. So in other words, first we "assert" that the partition is not 32MiB of zeros. Then we "assert" that it is after "dd".

Do the same for the other partition, misc, which is 16MiB on Tribute. SHA-1 checksum of 16MiB of zeros should be "3b4417fc421cee30a9ad0fd9319220a8dae32da2".
If these work, then just remove the commands before the "dd" command.

Sorry, I don't have time to actually test these out myself, so I hope that they make sense and that I didn't make mistakes. :)
 
:)

Okay, here's the bonus-bonus: you can actually manually run an update-binary executable from a shell prompt, whether that's booted-up from custom recovery or normal Android.

Of course, you would NOT want to do this on a flashable .zip file that contains commands/expressions that would mess with your currently running Android environment and is the exact reason why you typically "flash" things from a custom recovery. But, you can certainly use this feature to test simple scripts and figure-out syntax, etc. where you're not actually putting anything at risk or doing any thing dangerous or invasive.

Here's a copy/paste of the information about doing this (the source link I got this from has long since gone away--but the internet archive / wayback machine still has it):

Update-binary

META-INF/com/google/android/update-binary

The update-binary can be found in any upgrade.zip file in the location shown above; it is a parser for updater-script found in the same directory.

There is no signature checking in update-binary; recovery performs a signature check over the entire upgrade.zip file and anything inside is presumed safe. The upshot of this is that update-binary can be rebundled into a new zip file and updater-script for used with a custom recovery, or update-binary can be manually executed by the user on a custom zip file. This is useful since the update-binary often contains functions that would otherwise be difficult such as baseband upgrades.

update-binary <api> <pipefd> <zip>

The api is 3, the pipefd is the descriptor used by recovery, the zip file file is the zip file containing the updater-script to be executed. (The update-binary within the zip file is ignored)
Click to expand...

So, to use this feature, you could do this:

first, let's put our test "flashable" .zip file on our Android device:

c:\> adb push test.zip /sdcard/

next, we've got to also put the update-binary executable on the Android device, too, in a place we can execute it from:

c:\> adb push update-binary /sdcard/

now, launch a shell on the Android device:

c:\> adb shell

become root:

$ su

navigate to our selected work area (the /cache directory):

# cd /cache

"install" the update-binary file here in the /cache folder:

# cat /sdcard/update-binary > update-binary

secure it so we can execute it:

# chmod 777 update-binary

now, "execute" / "install" our test.zip file:

# /cache/update-binary 3 0 /sdcard/test.zip

exit when finished testing:

# exit
$ exit
c:\>
Click to expand...

Again, be careful and selective about what commands in your .zip file that you attempt to execute while Android is booted-up normally. You don't want to try to unmount filesystems or other "scary" stuff, eh?

Cheers! :)
 
You must log in or register to reply here.
Back
Top Bottom