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

Root Proposal/Theory for External SD storage solution on F6

Is it just me or does the camera not wanting to work nor Snapchat stories want to load . Also, things that need to install on emulated doesn't work .. So Xposed update doesn't work... Why do I need Xposed? It's for pandora.. I'm going to format my sd card and install everything again.
Are you running a KK rom?
If so, you probably need the right cam fix. Look in the appropriate threads.
And you should check whether you'd need workarounds for my hack. Check the 1st post of my thread and the post to which -kksdfix.zip is attached.

As for Xposed, you would normally install that first before applying my hack. Xposed needs to access /data before my hack is activated during boot. So for it to work, its files need to be both in internal storage and on the SD card. If Xposed is installed first, its files would've been copied (thus in both places) and it should work when the hack mounts the external volume over the internal one because both volumes contain the files. I hope that makes sense. Since you've already installed the hack, you could uninstall it, boot with the internal storage, install Xposed (to the internal storage), and reinstall the hack (and workarounds). Alternatively, I think Xposed provides a zip that can be installed in recovery. If you use that, Xposed would be installed to internal storage. And if you boot with the hack active and install Xposed from within the app, it would be installed to the external volume. I hope that makes sense.
 
Upvote 0
Just checked the zip file. Tried downloading. The md5 matches with the one I have:
85d0979f1a50ab18f220f76d2d7e45db DataOnSD-sensorfix.zip

Tried flashing. Got the following as expected:
Code:
===< DataOnSD Sensor Fix Installer >===
===< by WarrantyVoider @ Android Forums >===
===< Extracting script >===
===< Mounting /system >===
===< Installing script >===
===< Done >===

So things look okay on this end.
I haven't been able to get my hands on the f6 that was having that problem. We have 4 of them in our family. All with your hack. Hopefully I can get the phone and try again soon.
 
Upvote 0
Warrantyvoider,
Im running the Experion ROM with your hack via initd install cuz I have busybox. Im using a 64GB microSD card with no problem. The problem I do have is my compass doesn work or respond at all. Ive attempted to install your sensor hack in recovery, but it states failed during the installation.
States "Error flashing zip '/sdcard/SD Card/DataOnSD-sensorfix.zip'

Any ideas why this is?
 
Upvote 0
Warrantyvoider,
Im running the Experion ROM with your hack via initd install cuz I have busybox. Im using a 64GB microSD card with no problem. The problem I do have is my compass doesn work or respond at all. Ive attempted to install your sensor hack in recovery, but it states failed during the installation.
States "Error flashing zip '/sdcard/SD Card/DataOnSD-sensorfix.zip'

Any ideas why this is?
It's been a while, but I don't think the init.d version supports automatic loading of the script in -sensorfix.zip. With init.d supported by the rom itself, the main script is loaded by the rom as early as the rom chooses. So if the rom loads init.d scripts early, workarounds should not be needed.

If somehow you do need a sensor fix with the init.d version, you can install manually. The sensor-fix script could then be loaded by the init.d loading mechanism provided by the rom (after the main script, obviously). Take the restart_sensord.sh inside the -sensorfix.zip, put into the init.d folder, rename the script into a proper form, and change the ownership/permissions (just your typical way to manually install an init.d script). Let me know if you need more help with that.
(Edit: sorry, restart_sensord.sh needs to have a few lines removed before it can be used as an init.d script directly. My mistake.)

The other option is to use the binary version and the -sensorfix.zip workaround. The installation failure sounds to be the issue reported by @dublus in post #597. If you go this route, check my replies in #598 & #600 and let me know which specific error you get.
 
Last edited:
  • Like
Reactions: Krlypumaa
Upvote 0
I also have an odd issue, after setting up my apps and xposed mod etc and just lettin everything take to the system I boot into recovery run the hack Zips needed boot back into system and all is well I've even posted screen shots showing internal memory is well over 1.27 so I'm happy as can be. UNTIL I add an app or do pretty much anything else I noticed after a reboot for various reasons that my internal memory reads 1.27 again.
 
Upvote 0
I also have an odd issue, after setting up my apps and xposed mod etc and just lettin everything take to the system I boot into recovery run the hack Zips needed boot back into system and all is well I've even posted screen shots showing internal memory is well over 1.27 so I'm happy as can be. UNTIL I add an app or do pretty much anything else I noticed after a reboot for various reasons that my internal memory reads 1.27 again.
My hack checks for a few simple things at boot. Two main ones: 1) whether the external ext4 volume is mountable, and 2) whether the Dalvik cache folder exists. The external volume can sometimes become unmountable if there are file system corruptions, errors, or inconsistencies. The dalvik-cache folder can be removed if the recovery's wipe-dalvik function is used. I've discussed and documented both of these potential issues before. Check my SD hack thread for details.

To deal with (1), try using -fsck-ondemand.zip. To deal with (2), use -wipe-dalvik.zip. Read the posts to which the zips are attached. If these don't solve your problem, then maybe you have some other more serious issues. Check your system stability, SD card integrity, etc. Good luck.
 
Upvote 0
Ya I don't think this is you're hack doin anything wrong I paid for links to sd and foldermount everything was fine but somewhere along the line after days of flashing, booting/rebooting and setting up in different order and noticed after I tried to install any app that needs reboot messes with other apps etc I can't reboot or il get hung. I even looped a lil while flashing once in TWRP. Ya somthing is wrong with my system but why after a full wipe does all this stick? Gotta be mounting and or bootloader issues. I mean what else could it be right?

I can run foldermount though it doesn't extend much memory I tell ya, but if an app xposed, linkd2sd etc. requires a reboot its a no go. Oddly enough rekey reboots my system at setup and no probs there. Ya Im soooooo stumped.

My bad just thought about somthing, I gave the app Root not Rom but RootToolbox a go and accidently pressed system RO Only, that was 30 wipes and reflashes ago but I wonder if that did something you can't just wipe away you know? But ok man as always you're the man bra thanks for gettin back with me. Looks like I'm deffinetlu gonna need that new phine. Hope the LG Leon has a custom recovery lokified I'm praying. If not maybe Alcatel isn't ass hard ass on locking up bootloaders and whatknot.

I knoticed they're are some Dev tools in Accesability options can I delve into anything in there or how should/could I check whats up with my system? Logcats barely run anymore since all this started. Can't run addaway niether, idk just anything that needs mounting throws my system off bad. Gotta be hardwear issue right? Wouldn't firmware be fixed after wiping everything? And I formats wipe reboot recovery so there's no OS too so………..
 
Last edited by a moderator:
Upvote 0
It's been a while, but I don't think the init.d version supports automatic loading of the script in -sensorfix.zip. With init.d supported by the rom itself, the main script is loaded by the rom as early as the rom chooses. So if the rom loads init.d scripts early, workarounds should not be needed.

If somehow you do need a sensor fix with the init.d version, you can install manually. The sensor-fix script could then be loaded by the init.d loading mechanism provided by the rom (after the main script, obviously). Take the restart_sensord.sh inside the -sensorfix.zip, put into the init.d folder, rename the script into a proper form, and change the ownership/permissions (just your typical way to manually install an init.d script). Let me know if you need more help with that.

The other option is to use the binary version and the -sensorfix.zip workaround. The installation failure sounds to be the issue reported by @dublus in post #597. If you go this route, check my replies in #598 & #600 and let me know which specific error you get.


This is my error from running the unaltered script directly (non binary)
===< DataOnSD Sensor Fix Installer >===
===< by WarrantyVoider @ Android Forums >===
===< Extracting script >===
===< Extraction failed >===
E:Error executing updating binary in zip '/sdcard/SD Card/DataOnSD-sensorfix.zip'...
Error flashing zip '/sdcard/SD Card/DataOnSD-sensorfix.zip'...
Updating partition details...

Ive tried the manual extraction of restart_sensord.sh into the init.d folder, renamed it to Sensord (no need to change permissions as they seem good to go). Still no go.

Ive checked the file multiple times to make sure its not corrupted. I think youre correct. Something loads prior that prevents this script from being even extracted. In the active ROM, Im able to extract the zipfile, open it, and make changes...
 
Last edited:
Upvote 0
My issue goes beyond Warranty Voiders hack I have so crazy mounting issue goin on I can't use any type of app that need to mount durring reboot its cause other apps craziness as well its something to do with mounting I can Mount my initial flashes to setup shop if you will but that's it no rebooting or I'm hung in the ROMS Boot logo. So ya no xposed installer links2sd or data hack fron warranty voider. My issue is Hell idk what other than some kind of mounting issue and I'm not sure its fix able I wouldn't know where to start on sonthing like a mounting issue. Its very weird to say the least. I wish I could set up links2sd I just paid for it a couple days before this all started. Only thing I can think. Of is I hit RO on accident that's when all this started but total as wiping hasn't wiped this mountung issue and obviously can't so is my issue hardware? Ahhhhhhhh!!! Idk
 
Upvote 0
Ive tried the manual extraction of restart_sensord.sh into the init.d folder, renamed it to Sensord (no need to change permissions as they seem good to go). Still no go.

Ive checked the file multiple times to make sure its not corrupted. I think youre correct. Something loads prior that prevents this script from being even extracted. In the active ROM, Im able to extract the zipfile, open it, and make changes...
It seems your recovery environment is different than mine. I've already tested the zip in hroark13's TWRP. I'll check pressy4pie's CWM again when I can. Maybe I've missed something.

For your original compass problem, check to see if there's some other cause. The issue with sensord affects compass, magnetic field sensor, and accelerometer. So auto-rotation would be affected. Try disabling the hack to make sure the sensors work without the hack. If the problem is indeed caused by sensord, you can manually reset it with console commands:
su
stop sensord; sleep 1; start sensord
exit
 
Upvote 0
@The-Truth
Since your problem doesn't have to do with my hack or an implementation based on JVene's idea, it's probably outside the scope of this thread. Unfortunately, I can't help you with Link2SD or Foldermount because I have no experience with them.

You can still use my -fsck-ondemand.zip to check the external ext4 partition, to make sure the volume is not corrupt. And when you flash a new rom, consider not using TWRP's factory reset. TWRP's factory reset supposedly wipes data, cache, dalvik, and sd-ext. It's normally fine, but since you'll be using "sd-ext" for special data and there's no standard for what the format of "sd-ext" is supposed to be (ext3 for hroark13's version for the F6), I'd personally not let TWRP deal with it automatically. Ext2/3/4 are supposed be somewhat compatible under some circumstances, but when you add selinux to the mix, there's a higher chance something doesn't work the way you'd expect. Instead, I'd do advanced wipe of data, cache, and dalvik. If you need to wipe "sd-ext" also, use the "rm -rf" option in the settings and do advanced wipe of sd-ext separately. This is probably not what other veteran rom testers would bother with, but it's what I'd do without further analyzing what actual code is run to perform each function.

As for potential mounting problems, it's possible to mount each partition manually to check whether it is mountable. If the partitions are too messed up to fix manually, you might need to do the unbricking procedure to start over with a clean slate.

Hope the above makes sense. Good luck.
 
  • Like
Reactions: viperdink
Upvote 0
Ya I know to set up xposed and everything that doesn't apply to ext SD at first then boot into recovery flash can fix and kernel while cache and delvica. As I have stated the same issues apply to links2SD just anything that mounts upon reboot so the problems not you're hack its something to do with my phone itself its not mounting things properly which causes a frees at Carbons boot logo so........ Ya issue goes beyond you're hack man for sure. Its so odd I can reboot without any hangups and run my system fine even use foldermount! My guess is because it does require a reboot to to set up. And I already stated thank you for can fix works perfect!!!!

~~~

Funny I got the data on SD hack workin, do I need to run the init.d script that comes with it or is it like just meant for everything/apps etc. that you download and setup before you run the hack? All I flashed was Data on SD & the install zip and it works I have more internal memory but if I add any other apps at his point my internal data reverts back to 1.27G again, So that's why I'm asking whats up with the init.d script?, which I attempted to run figuring its something needed to be an at boot. I use Smanager and open the init.d script to he hack and its not recognized. You have a method/way I should go about this in order to gain more apps without loosing the hack? Not being able to add apps and keep hack kinda defeats purpose of the hack. Make no mistakes I'm blaiming myself not the hack that's why I'm asking if you know how I could go about adding apps from this point after running the hack on and still have hack intact?

~~~

NM I got er working. Now I was making partition bigger than the remainder of the SD card, made it not quitbut almost have of a 16G SD Card now I can download more apps games whatever no prob..damn I love this hack. Hey DM what do you think you or Hroark maybe GT thinking about building a ROM for the Leon I will gladly pay for it whatever you build whoever builds one for it CM one of you geniuses I hope..... Oh I knoticed that storage on SD or whatnot folder in my file manager you said to delete that Warranty Voider? My bad NM I search the forums rather than bother you with my ordeals. Thanks again for this Data on SD hack there 4 zips in all I only needed Copydata zip and install zip. I have found no use for the init.d zip or uninstall zip. Just wanted to thank you I have a ton of memory now.
 
Last edited by a moderator:
Upvote 0
Ive checked the file multiple times to make sure its not corrupted. I think youre correct. Something loads prior that prevents this script from being even extracted. In the active ROM, Im able to extract the zipfile, open it, and make changes...

It seems your recovery environment is different than mine. I've already tested the zip in hroark13's TWRP. I'll check pressy4pie's CWM again when I can. Maybe I've missed something.
Okay, I've checked both versions of hroark13's TWRP (2.6.3.0 & 2.8.0.0) and pressy4pie's CWM (6.0.4.6). As far as I know, those are the recoveries we have available for the F6. For me, the -sensorfix.zip installs fine on all three. So right now I don't know what caused the extraction failure for you and maybe dublus.

If your compass works without the hack but doesn't respond with the hack, let me know and I'll investigate how sensord can cause a problem with the init.d version.
 
Upvote 0
Funny I got the data on SD hack workin, do I need to run the init.d script that comes with it or is it like just meant for everything/apps etc. that you download and setup before you run the hack? All I flashed was Data on SD & the install zip and it works I have more internal memory but if I add any other apps at his point my internal data reverts back to 1.27G again, So that's why I'm asking whats up with the init.d script?, which I attempted to run figuring its something needed to be an at boot. I use Smanager and open the init.d script to he hack and its not recognized. You have a method/way I should go about this in order to gain more apps without loosing the hack? Not being able to add apps and keep hack kinda defeats purpose of the hack. Make no mistakes I'm blaiming myself not the hack that's why I'm asking if you know how I could go about adding apps from this point after running the hack on and still have hack intact
You're welcome. It looks like you've figured out (or read enough to understand), but I'll state it for confirmation.

I've supplied two versions: binary (installed with -copy.zip and -install.zip; uninstalled with -uninstall.zip) and init.d script (installed with -initd.zip; no uninstaller). You use one of the two.

Once the hack is activated, there are two potential issues (as far as I know) for the binary version: sensors not working and emulated SD not writable with a KK rom. I've supplied three zips for the workarounds. You choose one of the three depending on whether you need to deal with one, or the other, or both.

As you use the hack, sometimes you need to do a little maintenance. If your external volume becomes unmountable, the hack can't work and the phone will revert to using internal storage (1.27G). For this potential issue, I've supplied -fsck-ondemand.zip. You just "install" it in recovery (it doesn't actually install anything) to attempt to fix the external ext4 partition. You can use it to fix the file system even if you don't use my hack. Another tool I've supplied, -wipe-dalvik.zip, is for those who want to wipe the dalvik cache when using my hack. Read the relevant posts for more info.

The other zips I've released (-backup.zip, -restore.zip, -partition-NN.zip) are just simple utilities to make those tasks easier for users who need them. Most, if not all, of the information can be found in the first post of my SD hack thread or in other posts linked in that post.
http://androidforums.com/threads/sd-hack-for-storage-expansion.908126/

I hope this is clear enough.
 
Upvote 0
Okay, I've checked both versions of hroark13's TWRP (2.6.3.0 & 2.8.0.0) and pressy4pie's CWM (6.0.4.6). As far as I know, those are the recoveries we have available for the F6. For me, the -sensorfix.zip installs fine on all three. So right now I don't know what caused the extraction failure for you and maybe dublus.

If your compass works without the hack but doesn't respond with the hack, let me know and I'll investigate how sensord can cause a problem with the init.d version.

Thanks a lot. OK so I checked and ran your lines:
su
stop sensord; sleep 1; start sensord
exit

It does work! So Ill need to change my TWRP. Im not sure which version, but I thought Im using pressypie's. Perhaps older version. Ill reload or update and post results.
 
Upvote 0
Thanks a lot. OK so I checked and ran your lines:
su
stop sensord; sleep 1; start sensord
exit

It does work! So Ill need to change my TWRP. Im not sure which version, but I thought Im using pressypie's. Perhaps older version. Ill reload or update and post results.
OK, so loading as an init.d script does not guarantee the partition would be mounted before sensord. Thanks for confirming it.
Previously, I mentioned using restart_sensord.sh as an init.d script. I was not quite right. The script restart_sensord.sh cannot be used directly as an init.d script. I did a simple check at the beginning of the script to make sure it runs only when invoked by the binary version of the hack. So to make the script run as an init.d script, that safety check needs to be removed. Sorry about that. It's been a while since I wrote the code.

So now, two ways to deal with the issue. One, switch to the binary version. With this choice, you probably need to figure out how to get -sensorfix.zip to install. I can tell you how to install manually if you're technically inclined. Two, stick with the init.d version. The restart_sensord.sh can be modified to make another init.d script that resets sensord. But the way restart_sensord.sh works is inefficient, because it's made to work with or without BusyBox. Since BusyBox should be available in an init.d script, I'll try to come up with an init.d version of the restart_sensord.sh when I get some free time. If you don't want to wait, edit restart_sensord.sh by removing these three lines:
Code:
if [[ "$1" != "DataOnSD" ]]; then
  exit 0
fi
Then use that as an init.d script as you did before and see whether that works.

Edit:
With BusyBox, the following should restart sensord:
Code:
if pgrep -P 1 /system/bin/sensord; then
  stop sensord
  sleep 1
  start sensord
fi
I am not sure without testing (and I have no sure way to test because I don't get this problem), but I believe it's sufficient to add those lines to the end of the main init.d script. So /system/etc/init.d/00DataOnSD becomes:
Code:
#!/system/bin/sh

# NO WARRANTY OF ANY KIND. USE AT YOUR OWN RISK!

PART_EXT="/dev/block/mmcblk1p2"
TMP_DIR="/cache/DataOnSD"
VALID_TAG=".LGF6DataOnSD_DO_NOT_REMOVE"

if [[ ! -f /data/$VALID_TAG ]] && [[ -b $PART_EXT ]] && [[ ! -d $TMP_DIR ]]; then
  mkdir $TMP_DIR
  mount -t ext4 -o $(grep -m 1 " /data " /proc/mounts | cut -d ' ' -f 4 -) $PART_EXT $TMP_DIR
  if [[ "$?" = "0" ]]; then
  if [[ -f $TMP_DIR/$VALID_TAG ]] && [[ -d $TMP_DIR/dalvik-cache ]]; then
  mount -o bind $TMP_DIR /data
  fi
  umount $TMP_DIR
  fi
  rmdir $TMP_DIR
fi

if pgrep -P 1 /system/bin/sensord; then
  stop sensord
  sleep 1
  start sensord
fi

I hope this is enough to solve the problem. If anyone else using the init.d version requires the sensor workaround or the KK SD permission fix, please let me know and maybe I'll update the init.d installer or make the workaround zips applicable to either version.
 
Last edited:
  • Like
Reactions: The-Truth
Upvote 0
Idk but if you ask me Copy data on SD then Install on SD after setting up you're apps and system seam to be the way to go as far as a pretty simple poceedure all done within recovery/TWRP Etc. I ran the combo hack on my F6 and I did get it to survive a few reboots, and a few additional downloads yet it always seams to revert back to "stock" memory if you will maybe the trick is set up everything you're that you're going to before hack and nothing after, Idk I'm testing the hack I like and that works for me as long as my partition is fresh. I'm running the hack on my new LG Leon as of an hour ago and so far its survived 2 fresh downloads and 1 reboot! I said it before and I will say it again this is just the hack umungst all hacks, all those unaware of this hack who game or just like knowing the memory is there like myself are mission out bigtime. Delve in ppl WV really put some nice work in here everybody!!!!
 
  • Like
Reactions: WarrantyVoider
Upvote 0
yet it always seams to revert back to "stock" memory if you will
Like I've said in my previous posts, when you see the phone "reverts" back to internal storage after a reboot, try:
Reboot into recovery (using whatever app or power menu option).
Flash "DataOnSD-fsck-ondemand.zip".
Reboot into system.

See if this fixes the partition so that the hack can work again. DataOnSD-fsck-ondemand.zip is not an add-on or whatever. It installs nothing to the system. It just runs fsck (file system check) on your external ext4 volume to fix any errors it can so that the volume could be mountable again.

Normally, your ext4 volume should rarely have problems on a stable system. While you're testing/tweaking, it's possible something goes wrong so that the volume gets corrupted. So use the zip to try to fix the file system in that case.
 
  • Like
Reactions: Krlypumaa
Upvote 0
OK, so loading as an init.d script does not guarantee the partition would be mounted before sensord. Thanks for confirming it.
Previously, I mentioned using restart_sensord.sh as an init.d script. I was not quite right. The script restart_sensord.sh cannot be used directly as an init.d script. I did a simple check at the beginning of the script to make sure it runs only when invoked by the binary version of the hack. So to make the script run as an init.d script, that safety check needs to be removed. Sorry about that. It's been a while since I wrote the code.

So now, two ways to deal with the issue. One, switch to the binary version. With this choice, you probably need to figure out how to get -sensorfix.zip to install. I can tell you how to install manually if you're technically inclined. Two, stick with the init.d version. The restart_sensord.sh can be modified to make another init.d script that resets sensord. But the way restart_sensord.sh works is inefficient, because it's made to work with or without BusyBox. Since BusyBox should be available in an init.d script, I'll try to come up with an init.d version of the restart_sensord.sh when I get some free time. If you don't want to wait, edit restart_sensord.sh by removing these three lines:
Code:
if [[ "$1" != "DataOnSD" ]]; then
  exit 0
fi
Then use that as an init.d script as you did before and see whether that works.

Edit:
With BusyBox, the following should restart sensord:
Code:
if pgrep -P 1 /system/bin/sensord; then
  stop sensord
  sleep 1
  start sensord
fi
I am not sure without testing (and I have no sure way to test because I don't get this problem), but I believe it's sufficient to add those lines to the end of the main init.d script. So /system/etc/init.d/00DataOnSD becomes:
Code:
#!/system/bin/sh

# NO WARRANTY OF ANY KIND. USE AT YOUR OWN RISK!

PART_EXT="/dev/block/mmcblk1p2"
TMP_DIR="/cache/DataOnSD"
VALID_TAG=".LGF6DataOnSD_DO_NOT_REMOVE"

if [[ ! -f /data/$VALID_TAG ]] && [[ -b $PART_EXT ]] && [[ ! -d $TMP_DIR ]]; then
  mkdir $TMP_DIR
  mount -t ext4 -o $(grep -m 1 " /data " /proc/mounts | cut -d ' ' -f 4 -) $PART_EXT $TMP_DIR
  if [[ "$?" = "0" ]]; then
  if [[ -f $TMP_DIR/$VALID_TAG ]] && [[ -d $TMP_DIR/dalvik-cache ]]; then
  mount -o bind $TMP_DIR /data
  fi
  umount $TMP_DIR
  fi
  rmdir $TMP_DIR
fi

if pgrep -P 1 /system/bin/sensord; then
  stop sensord
  sleep 1
  start sensord
fi

I hope this is enough to solve the problem. If anyone else using the init.d version requires the sensor workaround or the KK SD permission fix, please let me know and maybe I'll update the init.d installer or make the workaround zips applicable to either version.


Ok, finally found time to go into the init.d loader script and add your lines. Unfortunately it doesnt work. However the manual terminal input of

su
stop sensord; sleep 1; start sensord
exit

remains to be a viable solution even though I need to input this with each reboot.
 
Upvote 0
Ok, finally found time to go into the init.d loader script and add your lines. Unfortunately it doesnt work.
Finally got some time to take a deeper look into this issue. I was able to temporarily reproduce the sensor problem on Xperion (the sensor issue could occur for me at the very first boot after flashing as the rom builds its cache files) with the init.d version of the hack. But in my test, the lines added to the end of the init.d script in post #618 do indeed fix the problem like I expected. There's an inevitable time gap between the moment "mount" is issued in the script and the moment when the volume becomes mounted and usable. I suppose it's possible in your case that "sensord" is loaded during that time. Try adding a slight delay ("sleep 1") in between the original part and the added section:
Code:
#!/system/bin/sh

# NO WARRANTY OF ANY KIND. USE AT YOUR OWN RISK!

PART_EXT="/dev/block/mmcblk1p2"
TMP_DIR="/cache/DataOnSD"
VALID_TAG=".LGF6DataOnSD_DO_NOT_REMOVE"

if [[ ! -f /data/$VALID_TAG ]] && [[ -b $PART_EXT ]] && [[ ! -d $TMP_DIR ]]; then
  mkdir $TMP_DIR
  mount -t ext4 -o $(grep -m 1 " /data " /proc/mounts | cut -d ' ' -f 4 -) $PART_EXT $TMP_DIR
  if [[ "$?" = "0" ]]; then
  if [[ -f $TMP_DIR/$VALID_TAG ]] && [[ -d $TMP_DIR/dalvik-cache ]]; then
  mount -o bind $TMP_DIR /data
  fi
  umount $TMP_DIR
  fi
  rmdir $TMP_DIR
fi

sleep 1
if pgrep -P 1 /system/bin/sensord; then
  stop sensord
  sleep 1
  start sensord
fi
Let me know whether this helps.
 
  • Like
Reactions: scary alien
Upvote 0
Finally got some time to take a deeper look into this issue. I was able to temporarily reproduce the sensor problem on Xperion (the sensor issue could occur for me at the very first boot after flashing as the rom builds its cache files) with the init.d version of the hack. But in my test, the lines added to the end of the init.d script in post #618 do indeed fix the problem like I expected. There's an inevitable time gap between the moment "mount" is issued in the script and the moment when the volume becomes mounted and usable. I suppose it's possible in your case that "sensord" is loaded during that time. Try adding a slight delay ("sleep 1") in between the original part and the added section:
Code:
#!/system/bin/sh

# NO WARRANTY OF ANY KIND. USE AT YOUR OWN RISK!

PART_EXT="/dev/block/mmcblk1p2"
TMP_DIR="/cache/DataOnSD"
VALID_TAG=".LGF6DataOnSD_DO_NOT_REMOVE"

if [[ ! -f /data/$VALID_TAG ]] && [[ -b $PART_EXT ]] && [[ ! -d $TMP_DIR ]]; then
  mkdir $TMP_DIR
  mount -t ext4 -o $(grep -m 1 " /data " /proc/mounts | cut -d ' ' -f 4 -) $PART_EXT $TMP_DIR
  if [[ "$?" = "0" ]]; then
  if [[ -f $TMP_DIR/$VALID_TAG ]] && [[ -d $TMP_DIR/dalvik-cache ]]; then
  mount -o bind $TMP_DIR /data
  fi
  umount $TMP_DIR
  fi
  rmdir $TMP_DIR
fi

sleep 1
if pgrep -P 1 /system/bin/sensord; then
  stop sensord
  sleep 1
  start sensord
fi
Let me know whether this helps.


Thanks! I did try the addition of sleep 1 before your script with no luck.
Im using pressypies TWRP, perhaps an older version. Would changing TWRP versions change any of this?
 
Upvote 0
Thanks! I did try the addition of sleep 1 before your script with no luck.
Im using pressypies TWRP, perhaps an older version. Would changing TWRP versions change any of this?
As far as I know, the recovery ported by pressy4pie is CWM. TWRP was ported by hroark13. I am not sure which one you meant, but I've tested all three (two versions of TWRP) and they all work for me. You should be able to use any one of those for Xperion.

Are you still using the init.d version? When your phone boots up, does it take a long time? I'd suggest trying the binary version because Xperion would apparently load the binary version earlier than it would the init.d version. The commands to stop/start sensord should still be usable, but if the partition becomes available too late, perhaps putting those commands in an init.d script wouldn't be effective (without some long "sleep" time).

As for the zip extraction problem using the binary version, I'm attaching the .md5 checksum file for the latest -sensorfix.zip. Rename the .txt file to .md5. With the .md5 file, the recovery should verify the zip before attempting to flash/install (for TWRP at least, I don't remember whether CWM does so). Let me know if the recovery reports matching md5 but you still get the extraction error.
 

Attachments

  • DataOnSD-sensorfix.zip.txt
    57 bytes · Views: 158
  • Like
Reactions: Gump_Worsley
Upvote 0

BEST TECH IN 2023

We've been tracking upcoming products and ranking the best tech since 2007. Thanks for trusting our opinion: we get rewarded through affiliate links that earn us a commission and we invite you to learn more about us.

Smartphones