FORUMS
Remove All Ads from XDA

[TOOLS][ZIPS][SCRIPTS] osm0sis' Odds and Ends [Multiple Devices/Platforms]

13,646 posts
Thanks Meter: 30,105
 
By osm0sis, Recognized Developer / Recognized Contributor on 18th April 2013, 12:37 AM
Post Reply Email Thread
18th January 2016, 02:46 AM |#491  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 30,105
 
Donate to Me
More
Quote:
Originally Posted by slimcyril

@osmosis please what's the benefits of using the xposed toggler ?

For future reference, if I didn't write it or package it it's probably out of the scope of this thread (and you should be asking in the thread you got it from), but I do happen to remember the zip you're talking about.

I think the point was to disable it simply from recovery if it gets stuck bootlooping or on the animation or something. That was before Xposed had the button combo disabling.
 
 
20th January 2016, 07:32 PM |#492  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 30,105
 
Donate to Me
More
Quote:
Originally Posted by osm0sis

Looks like 2016 will hold a lot of script breakage and rewrites:
https://plus.google.com/+OpengappsOrg/posts/FJ2v1kNxzHV

I'm already noticing some weirdness with sed not working at all like it should on my N7 2013.

Update: http://forum.xda-developers.com/andr...1/post64901718

We'll just have to tough it out with our broken scripts until N, I guess.
The Following 3 Users Say Thank You to osm0sis For This Useful Post: [ View ]
20th January 2016, 07:49 PM |#493  
SteveMurphy's Avatar
Recognized Contributor
Flag Atlanta
Thanks Meter: 2,693
 
More
Quote:
Originally Posted by osm0sis

Update: http://forum.xda-developers.com/andr...1/post64901718

We'll just have to tough it out until N, I guess.

Thanks for checking and updating us. Seems as though the descent to become unhelpful like Apple has accelerated since L, and especially M.

Or, perhaps I'm over exaggerating, although I doubt it.
21st January 2016, 10:14 PM |#494  
Senior Member
Thanks Meter: 124
 
More
@osmosis I m unable to mount my filesystem in rw mode, I have used so many scripts in order to remount it rw, terminal emulator displays that's its in rw mode but when I chmod a file in xbin or try to to create a folder it displays read-only filesystem. I flashed your cwm-sdfixpermission script but it failed in recovery. I m using s3 Verizon with the latest safestrap recovery. Please help !!!
21st January 2016, 10:22 PM |#495  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 30,105
 
Donate to Me
More
Quote:
Originally Posted by slimcyril

@osmosis I m unable to mount my filesystem in rw mode, I have used so many scripts in order to remount it rw, terminal emulator displays that's its in rw mode but when I chmod a file in xbin or try to to create a folder it displays read-only filesystem. I flashed your cwm-sdfixpermission script but it failed in recovery. I m using s3 Verizon with the latest safestrap recovery. Please help !!!

No. This is not your tech support thread. Ask in Q&A, or maybe the SuperSU thread if you're using the betas.

... You're not even mentioning the right osm0sis
The Following 2 Users Say Thank You to osm0sis For This Useful Post: [ View ]
21st January 2016, 10:24 PM |#496  
Captain_Throwback's Avatar
Senior Member
Flag The Nothing
Thanks Meter: 22,613
 
10
Donate to Me
More
Quote:
Originally Posted by Captain_Throwback

In this installer, do you clean up /tmp at the end of the script? Because after flashing this, I'm missing a large portion of my recovery log . I'm wondering if the SuperSU installer does the same thing . . .

@osm0sis

So when flashing the Busybox zip as part of a ROM install, the method used is similar to how SuperSU is bundled in a ROM install - the zip is added to its own folder, and the shell script is unzip and run directly from the updater-script, like this:
Code:
ui_print("Installing Busybox..."); ui_print(" ");
package_extract_dir("busybox", "/tmp/busybox");
run_program("/sbin/busybox", "unzip", "/tmp/busybox/UPDATE-Busybox.Installer.v1.24.1-ALL-signed.zip", "META-INF/com/google/android/*", "-d", "/tmp/busybox");
run_program("/sbin/busybox", "sh", "/tmp/busybox/META-INF/com/google/android/update-binary", "dummy", "1", "/tmp/busybox/UPDATE-Busybox.Installer.v1.24.1-ALL-signed.zip");
It's only when yours and the SuperSU zip are run using this method that the log gets truncated, due to the issue explained by @_that in the SuperSU thread.
The Following User Says Thank You to Captain_Throwback For This Useful Post: [ View ] Gift Captain_Throwback Ad-Free
21st January 2016, 10:27 PM |#497  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 30,105
 
Donate to Me
More
Quote:
Originally Posted by Captain_Throwback

@osm0sis

So when flashing the Busybox zip as part of a ROM install, the method used is similar to how SuperSU is bundled in a ROM install - the zip is added to its own folder, and the shell script is unzip and run directly from the updater-script, like this:

Code:
ui_print("Installing Busybox..."); ui_print(" ");
package_extract_dir("busybox", "/tmp/busybox");
run_program("/sbin/busybox", "unzip", "/tmp/busybox/UPDATE-Busybox.Installer.v1.24.1-ALL-signed.zip", "META-INF/com/google/android/*", "-d", "/tmp/busybox");
run_program("/sbin/busybox", "sh", "/tmp/busybox/META-INF/com/google/android/update-binary", "dummy", "1", "/tmp/busybox/UPDATE-Busybox.Installer.v1.24.1-ALL-signed.zip");
It's only when yours and the SuperSU zip are run using this method that the log gets truncated, due to the issue explained by @_that in the SuperSU thread.

Ah okay now I'm following you. Okay, since you're really using the zips in an abnormal way here, what's the problem with switching the 0 to 1?
21st January 2016, 10:30 PM |#498  
Captain_Throwback's Avatar
Senior Member
Flag The Nothing
Thanks Meter: 22,613
 
10
Donate to Me
More
Quote:
Originally Posted by osm0sis

Ah okay now I'm following you. Okay, since you're really using the zips in an abnormal way here, what's the problem with switching the 1 to 0?

Not sure what you mean by abnormal - this method was provided by Chainfire himself, including the syntax for the commands, here: http://su.chainfire.eu/#embed-rom

I can change the 1 to a 0 and I'm sure it'll work fine, but thought you'd want it to work universally, since most people are using the instructions he provided for flashing similar zips. No worries - just wanted to bring it to your attention.
The Following User Says Thank You to Captain_Throwback For This Useful Post: [ View ] Gift Captain_Throwback Ad-Free
21st January 2016, 10:33 PM |#499  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 30,105
 
Donate to Me
More
Quote:
Originally Posted by Captain_Throwback

Not sure what you mean by abnormal - this method was provided by Chainfire himself, including the syntax for the commands, here: http://su.chainfire.eu/#embed-rom

I can change the 1 to a 0 and I'm sure it'll work fine, but thought you'd want it to work universally, since most people are using the instructions he provided for flashing similar zips. No worries - just wanted to bring it to your attention.

Ah I see, I didn't realize that was a thing! Cool. Thanks.

Hmm, well it seems like it was just a typo in his instructions and should be stdout, not stdin, so I'll wait and see what Chainfire does about it.

Edit: @Captain_Throwback, I'm still mulling over Chainfire's method for finding the correct FD to the parent ROM zip because it's kind of.. intense, would just the >> fix be acceptable?
22nd January 2016, 01:22 PM |#500  
Captain_Throwback's Avatar
Senior Member
Flag The Nothing
Thanks Meter: 22,613
 
10
Donate to Me
More
Quote:
Originally Posted by osm0sis

Ah I see, I didn't realize that was a thing! Cool. Thanks.

Hmm, well it seems like it was just a typo in his instructions and should be stdout, not stdin, so I'll wait and see what Chainfire does about it.

Edit: @Captain_Throwback, I'm still mulling over Chainfire's method for finding the correct FD to the parent ROM zip because it's kind of.. intense, would just the >> fix be acceptable?

I was able to modify your script and have it working using Chainfire's method. This is what I used (the readlink portion is a direct copy/paste from his updated shell script):
Code:
OUTFD=$2;
ZIP="$3";

readlink /proc/$$/fd/$OUTFD 2>/dev/null | grep /tmp >/dev/null
if [ "$?" -eq "0" ]; then
  # rerouted to log file, we don't want our ui_print commands going there
  OUTFD=0

  # we are probably running in embedded mode, see if we can find the right fd
  # we know the fd is a pipe and that the parent updater may have been started as
  # 'update-binary 3 fd zipfile'
  for FD in `ls /proc/$$/fd`; do
    readlink /proc/$$/fd/$FD 2>/dev/null | grep pipe >/dev/null
    if [ "$?" -eq "0" ]; then
      ps | grep " 3 $FD " | grep -v grep >/dev/null
      if [ "$?" -eq "0" ]; then
        OUTFD=$FD
        break
      fi
    fi
  done
fi

ui_print() { echo -e "ui_print $1\nui_print" >> /proc/self/fd/$OUTFD; }
set_perm() {
  files=$(echo $* | awk '{ print substr($0, index($0,$4)) }');
  for i in $files; do
    chown $1.$2 $i; chown $1:$2 $i;
    chmod $3 $i;
  done;
}
show_progress() { echo "progress $1 $2" > /proc/self/fd/$OUTFD; }
set_progress() { echo "set_progress $1" > /proc/self/fd/$OUTFD; }
I bolded the items I changed. Using just ">>" seems to redirect all the "ui_print" commands to the recovery.log, which ends up just being log spam.
The Following User Says Thank You to Captain_Throwback For This Useful Post: [ View ] Gift Captain_Throwback Ad-Free
22nd January 2016, 01:35 PM |#501  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 30,105
 
Donate to Me
More
Thanks Captain_Throwback! This testing with readlink stuff is new to me, but I worked through it in adb shell and it makes enough sense to me now that I adapted the above to the rest of my usual script so the latter changes aren't necessary. No real functional changes necessary as you can see.

Code:
# embedded mode support
readlink /proc/$$/fd/$2 2>/dev/null | grep /tmp >/dev/null;
if [ "$?" -eq "0" ]; then
  # rerouted to log file, so suppress recovery ui commands
  OUTFD=/proc/self/fd/0;
  # try to find the actual fd (pipe with parent updater likely started as 'update-binary 3 fd zipfile')
  for FD in `ls /proc/$$/fd`; do
    readlink /proc/$$/fd/$FD 2>/dev/null | grep pipe >/dev/null;
    if [ "$?" -eq "0" ]; then
      ps | grep " 3 $FD " | grep -v grep >/dev/null;
      if [ "$?" -eq "0" ]; then
        OUTFD=/proc/self/fd/$FD;
        break;
      fi;
    fi;
  done;
fi;

ui_print() { echo -e "ui_print $1\nui_print" >> $OUTFD; }
show_progress() { echo "progress $1 $2" >> $OUTFD; }
set_progress() { echo "set_progress $1" >> $OUTFD; }
I did touch up Chainfire's new su.img loop mount script more to my liking though and made sure it all works with CMR's toybox implementation (as I'm sure was also his main concern with it), as well as saves us a few steps if we're using a more sensible recovery like TWRP:
Code:
mount /data;
mount /cache;
suimg=$(ls /cache/su.img /data/su.img 2>/dev/null);
if [ "$suimg" ]; then
  umount /su;
  test ! -e /su && mkdir /su;
  mount -t ext4 -o rw,noatime $suimg /su;
  for i in 0 1 2 3 4 5 6 7; do
    case `mount` in
      *" /su "*) break;;
    esac;
    loop=/dev/block/loop$i;
    mknod $loop b 7 $i;
    if [ ! -f "$loop" -o ! -b "$loop" ]; then
      mknod $loop b 7 $i;
    fi;
    losetup $loop $suimg && mount -t ext4 -o loop $loop /su;
  done;
  test -d /su/xbin && target=/su/xbin || target=/su/bin;
else
  mount -o rw,remount /system;
  target=/system/xbin;
fi;
Just reviewing and making the mount changes on my adb and nano installers then I'll have all 3 updated.
The Following 4 Users Say Thank You to osm0sis For This Useful Post: [ View ]
Post Reply Subscribe to Thread

Tags
automation, batch, flashable zip, script, tool

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

Advanced Search
Display Modes