• 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

i'm using TWRP v2.6.3.0



WarrantyVoider said:
There should be no need to reboot in between. But it should be safe to do so. I'm trying to figure out at what stage the installation went wrong. I'll try to install TWRP on my Nook Color and check whether it's a problem there.

In the meantime, if anyone has used CWM to do the flashing, please report whether it was successful.

I think for people on stock roms, using adb+scripts might be easiest if they don't intend to backup with a custom recovery. Custom recoveries won't help with backup once new data are on the SD card anyway. I'll write up a more detailed guide for the adb method later.

Does anyone know what versions of TWRP and CWM are used for this phone?
Click to expand...
 
Thanks. I get 2.6.3.0 on the Nook Color as well. I can duplicate the problem, so it looks like it's caused by a difference between TWRP and CWM rather than a difference between my testing platform and this phone. Hopefully it's a simple fix after I see how the TWRP environment is different.
 
First, thanks to stigmax2 for reporting the problem with TWRP and others for confirming.

I made the scripts inside the zips not depend on physical partition locations (except for the partition on SD). I am not sure if doing that actually fixes the problem. So if anyone who tries these new zips can report back (which recovery, whether they work, and screen message: "Done", "Failed", or neither), it would be helpful.

If these still fail, then I'd have to dig into the actual CWM or TWRP for this phone because the zips work fine on my Nook Color. In that case, it would take more time to come up with a fix.

Once I get confirmation that these work, I'll update the other posts.
 

Attachments

no prob.. thank you for creating the scripts!

I'll give these zips a try when I get home tonight and report back


[
QUOTE=WarrantyVoider;6730558]First, thanks to stigmax2 for reporting the problem with TWRP and others for confirming.

I made the scripts inside the zips not depend on physical partition locations (except for the partition on SD). I am not sure if doing that actually fixes the problem. So if anyone who tries these new zips can report back (which recovery, whether they work, and screen message: "Done", "Failed", or neither), it would be helpful.

If these still fail, then I'd have to dig into the actual CWM or TWRP for this phone because the zips work fine on my Nook Color. In that case, it would take more time to come up with a fix.

Once I get confirmation that these work, I'll update the other posts.[/QUOTE]
 
I tried the install zip and got the following...

Installing DataOnSD....
Done.
Updating partition Details...
E:Unable to mount '/data'



stigmax2 said:
no prob.. thank you for creating the scripts!

I'll give these zips a try when I get home tonight and report back


[
QUOTE=WarrantyVoider;6730558]First, thanks to stigmax2 for reporting the problem with TWRP and others for confirming.

I made the scripts inside the zips not depend on physical partition locations (except for the partition on SD). I am not sure if doing that actually fixes the problem. So if anyone who tries these new zips can report back (which recovery, whether they work, and screen message: "Done", "Failed", or neither), it would be helpful.

If these still fail, then I'd have to dig into the actual CWM or TWRP for this phone because the zips work fine on my Nook Color. In that case, it would take more time to come up with a fix.

Once I get confirmation that these work, I'll update the other posts.
Click to expand...
[/QUOTE]
 
OK. The "unable to mount" message is from TWRP. The DataOnSD-install.zip doesn't touch /data at all. You can see whether the mounter binary is installed by first mounting /system (Mount->select System->back to main menu) and then checking existence of /system/bin/vold-original (Advanced->File Manager->select system folder->select bin folder->see if vold-original exists).

If it's okay, try the -uninstall zip. If it says "Done." also, you can check whether vold-original is gone. As for the -copy zip, it will need to mount /data. I am not sure if you're having a problem with your /data partition. Can you mount /data with Mount->select data? Did you enter recovery from the powered-off state by using physical buttons? Anyway, if your /data partition is okay, then go ahead and try the -copy zip and let me know what happens.
 
Okay, I tried recovery this time but not from the hard keys.

upon getting to TWRP
Updating partition detail....
Running Boot Script...
Finished running boot script...

i went to the mount screen and system was not mounted so i checked that off. went to advanced and browsed and saw /system/bin/vold

Installing DataOnSD...
Done.
Updating partition details...

checked to see if /system/bin/vold-original is there and it was.
next i tried to the uninstall zip and got the following.

Installing '/sdcard/dataonsd-uninstall.zip'...
uninstalling dataonsd...
Failed.
Updating partition details...

checked file manager and still saw /system/bin/vold-original

also tried the copy zip right after and got the following
Installing '/sdcard/dataonsd-copy.zip'...
copying data for dataonsd...
Failed.
UPdating partition details...


There was one more thing i tried after i restored my system...i tried to run the copy zip on a non hardkey recovery boot and the copy was successful. Then i tried to run the install zip and it failed.

let me know if you want me to try anything else. I can restore my system back to normal pretty quick.



WarrantyVoider said:
OK. The "unable to mount" message is from TWRP. The DataOnSD-install.zip doesn't touch /data at all. You can see whether the mounter binary is installed by first mounting /system (Mount->select System->back to main menu) and then checking existence of /system/bin/vold-original (Advanced->File Manager->select system folder->select bin folder->see if vold-original exists).

If it's okay, try the -uninstall zip. If it says "Done." also, you can check whether vold-original is gone. As for the -copy zip, it will need to mount /data. I am not sure if you're having a problem with your /data partition. Can you mount /data with Mount->select data? Did you enter recovery from the powered-off state by using physical buttons? Anyway, if your /data partition is okay, then go ahead and try the -copy zip and let me know what happens.
Click to expand...
 
Hey WV I have been playing around with the new version of your hack. Here are some things I encountered:

- I tried the new method out first on GT's Xperion rom (4.1.2 JB). I used the manual method (copy,rename files). I had re-formatted my sd card, clean install of the rom (I was using the old hack on this rom) and after following instructions and re-booting it worked, no problems. I ran it this way for about 2 days.

- I then tried using it on Hroarks KitKat (4.4.2) with the LG apps. Here I encountered several problems and I have been unable (so far) to get it to work. I tried with the manual method like I did with Xperion rom, after rebooting no-go, bootlooped. So I next tried with the terminal method. I used SManager first, and encountered an issue where after executing the first few commands when trying to run the "sh installer.sh both" it would inform me that I wasn't at superuser/root. SManager clearly stated on the prompt line F6:root (superuser) # so it was telling me I was running as root but then saying I wasn't, which I dont understand. Also if I put su instead of sh (as su installer.sh both) it would respond something like mkrm temp not available (thats not the exact line sorry). I tried with ADB, and Terminal. They gave me the same errors. But Terminal, when I entered 'su' left it at android user $. When I tried the installer.sh, it gave the not running as 'superuser/root' bit. AGain, I dont understand exactly why when every other indicator (I could move/change system files, the ADB and SManager prompts, using apps that required root etc...) was showing full root. (Installed SuperSU, what the rom was pre-rooted with, I also tried Towelroot to see, and also Superuser .apks, one by Cyanogen and one ChainDD all same results). I then tried the zips,your new ones. The copy was succesful, the install (mount) said it was successful but I was stuck in a boot loop. When I attempted the uninstaller, in the text box it said 'failed' but TWRP reported 'Success'! lol talk about split personality! One final thing I tried was I installed the old hack (sensord, debuggerd) which worked on the first boot. So I removed the 'copy' bit, reverted the files back to the originals and installed mount_data (renamed vold, etc). After rebooting I was once again in a boot loop. It seems the 'vold' method has issues on KK, i have been researching why (still am) and maybe the way KK handles the sdcard is causing the issues (but I dont know why exactly). I was also looking into stuff about LOKI, SElinux, issues with the way 'root' is running (the one pre-installed), FUSE, etc but still no love for me on 4.4.2 yet! I did have to use the KK SD card fix, had problems with files on the card until I did.

I havent tried on CM11 yet, but I might later. I was trying to get it working on straight KK 4.4.2 first. In any event, worked out of the box on 4.1.2 JB, no luck with KK. (previous ver. still works)

It does seem a bit quicker on JB than before, excellent work! Thanks for striving for more excellence! The one thing I meant to do was try out Xpose, but I forgot. I might just run through that once to see before messing around with KK again.
 
Okay... lots of helpful information, excellent! stigmax2 and crm701, thank you both for testing and giving feedback. There are several different issues here:

  • installations in TWRP (and maybe CWM, but perhaps no one uses it on this phone anymore)
  • hroark13's KK rom boot loop
  • superuser prompt issue
  • maybe others, I'll think about them later.
- TWRP.
It looks like based on stigmax2's info, the first zip after getting into recovery works fine. Afterwards, something prevents the second one from working. If this hypothesis is right and this is the only cause of the problem, then one should be able to get into recovery (making sure internal /data is intact), flash the -copy zip, reboot back into recovery (again keeping internal /data intact), flash the -install zip, and reboot into rom. If there's no failure at each step, the hack should in theory work.

Next is to figure out why TWRP on this phone locks me out after my first zip is flashed. I have no such problems with v2.6.3.0 or CWM v6.0.4.8 on my Nook Color. TWRP allows queuing zips, so what happens when two or more zips are queued (-install first, followed by -uninstall, and then maybe even -copy just for kicks)? My guess is some file system becomes read-only. So please check this. Just after entering TWRP, do Advanced->Terminal Command->Select Folder->type "mount" in box then press enter. The output is a bunch of lines with each in this format: <device> on <mountpoint> type <fs_type> (<options>). I want to know the options for lines where <mountpoint> is "/" or "/tmp" or "/system" or "/data" (if they exist). For example, on my NC, the only such line is "rootfs on / type rootfs (rw)", so "/" has (rw). Next, go back to main menu and flash a zip, say -install. Then go back into Terminal Command again and press enter (it should run "mount" again). Check the lines again and let me know if any option is changed or if any such line is added.

- KK boot problem
I don't think the conflict is with KK per se, as the hack works on my NC's CM11. According to crm701, my old version didn't cause boot problems. Two things are different with this version. One, this version hijacks "vold" whereas the previous does "debuggerd". Two, the mounter is a binary rather than a shell script. To check whether "vold" vs. "debuggerd" is the problem, do the manual installation of the binary mount_data as in post #253, but in step 4, use "debuggerd" instead of "vold" (i.e. "debuggerd" -> "debuggerd-original" and "mount_data" -> "debuggerd"). No need for the copier script part. Check if using debuggerd causes a boot loop. If the rom still can't boot (and I suspect this is the case), then the cause is probably my binary in the rom's environment. To check that, I'd probably have to make a test binary that can output some debugging info. To check whether hijacking of "vold" causes a problem, use the script_caller binary and debuggerd script in post #220, except use "vold" instead of "debuggerd" (i.e. "vold" -> "vold-original" and "script_caller" -> "vold" and in /system/etc/DataOnSD, rename "debuggerd" to "vold"), and skip the "sensord" part.

-Superuser prompt issue
This conflict is likely a detection problem in my script. I'm trying to support the environment in stock rom, which has a very limited set of tools. At a command prompt after "su", what's the exact string returned by running "id"?

If there are other issues, I'll have to deal with them later. The three above are more like show stoppers, so I hope I can resolve them quickly.
 
WarrantyVoider said:
Okay... lots of helpful information, excellent! stigmax2 and crm701, thank you both for testing and giving feedback. There are several different issues here:

  • installations in TWRP (and maybe CWM, but perhaps no one uses it on this phone anymore)
  • hroark13's KK rom boot loop
  • superuser prompt issue
  • maybe others, I'll think about them later.
- TWRP.
It looks like based on stigmax2's info, the first zip after getting into recovery works fine. Afterwards, something prevents the second one from working. If this hypothesis is right and this is the only cause of the problem, then one should be able to get into recovery (making sure internal /data is intact), flash the -copy zip, reboot back into recovery (again keeping internal /data intact), flash the -install zip, and reboot into rom. If there's no failure at each step, the hack should in theory work.

Next is to figure out why TWRP on this phone locks me out after my first zip is flashed. I have no such problems with v2.6.3.0 or CWM v6.0.4.8 on my Nook Color. TWRP allows queuing zips, so what happens when two or more zips are queued (-install first, followed by -uninstall, and then maybe even -copy just for kicks)? My guess is some file system becomes read-only. So please check this. Just after entering TWRP, do Advanced->Terminal Command->Select Folder->type "mount" in box then press enter. The output is a bunch of lines with each in this format: <device> on <mountpoint> type <fs_type> (<options>). I want to know the options for lines where <mountpoint> is "/" or "/tmp" or "/system" or "/data" (if they exist). For example, on my NC, the only such line is "rootfs on / type rootfs (rw)", so "/" has (rw). Next, go back to main menu and flash a zip, say -install. Then go back into Terminal Command again and press enter (it should run "mount" again). Check the lines again and let me know if any option is changed or if any such line is added.
Click to expand...

I use TWRP 2.6.3.0, the way Hroark13 has it with the KK rom, you can boot into recovery using the 'home' button without wiping /data. It makes things a simpler. On KK 4.4.2 (Hroark13) w/ LG apps. So I believe you meant this for a ROM other than KitKat but I figured maybe it might help. I flashed dataOnSD-copy (success), rebooted TWRP (/data ok),flashed dataOnSD-install. Booted system and was bootlooped. Back into TWRP, flashed -uninstall, which produced a fail. Restored ROM.

I opened Terminal in TWRP, ran mount:
rootfs on / type rootfs (rw),
tmpfs on / dev type tmpfs (rw,seclabel,nosuid, relatime)
devpts on dev/pts type devpts (rw, seclabel,relatime)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw, seclabel, relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw, relatime)
dev/block/mmcblk0p14 on /cache type ext4 (rw, seclabel)
dev/block/mmcblk0p15 on /data type ext4 (rw,seclabel,)
dev/block/mmcblk0p15 on /emmc type ext4 (rw, seclabel, relatime, resuid=1000, data=ordered)
dev/block/mmcblk1p1 on /sdcard type vfat (rw,relatime)
After flashing dataonSD-install, no changes after running 'mount', bootloop on reboot.

- KK boot problem
I don't think the conflict is with KK per se, as the hack works on my NC's CM11. According to crm701, my old version didn't cause boot problems. Two things are different with this version. One, this version hijacks "vold" whereas the previous does "debuggerd". Two, the mounter is a binary rather than a shell script. To check whether "vold" vs. "debuggerd" is the problem, do the manual installation of the binary mount_data as in post #253, but in step 4, use "debuggerd" instead of "vold" (i.e. "debuggerd" -> "debuggerd-original" and "mount_data" -> "debuggerd"). No need for the copier script part. Check if using debuggerd causes a boot loop. If the rom still can't boot (and I suspect this is the case), then the cause is probably my binary in the rom's environment. To check that, I'd probably have to make a test binary that can output some debugging info. To check whether hijacking of "vold" causes a problem, use the script_caller binary and debuggerd script in post #220, except use "vold" instead of "debuggerd" (i.e. "vold" -> "vold-original" and "script_caller" -> "vold" and in /system/etc/DataOnSD, rename "debuggerd" to "vold"), and skip the "sensord" part.
Click to expand...


I performed the above. I set permissions on mount_data, renamed 'debuggerd' and rebooted. Surprisingly, booted fine. Head scratcher? After reverting 'debuggerd' by removing '-original', and rebooting to make sure no loops, I did the steps using script_caller. /bin,set perms.,renamed 'vold'. DataonSD (set perms) in /etc, set perms. and renamed 'debuggerd' to 'vold'. This time system did the bootloop. Indicates a problem with vold?

-Superuser prompt issue
This conflict is likely a detection problem in my script. I'm trying to support the environment in stock rom, which has a very limited set of tools. At a command prompt after "su", what's the exact string returned by running "id"?
Click to expand...

This one returned with uid=0(root), gid=0(root). To be thorough I ran the console (SManager) commands again. All OK up to (sh installer.sh both), which returns "not run as superuser/root". I tried putting 'su' instead of 'sh' which returns "tmp-mksh:both: not found". I tried (sh installer.sh binary), got the "not run as superuser/root".

All above done on Hroark13's KitKat 4.4.2 with LG apps, SD card fix (nextapp SD fix), Chainfire's SuperSU (comes with ROM).

If there are other issues, I'll have to deal with them later. The three above are more like show stoppers, so I hope I can resolve them quickly.
Click to expand...


On a different note, on GT's Xperion rom (JB 4.1.2) mod works great, and I tried out Xposed and everything ran like it was supposed to. So there is that, which is awesome!
I might give this new version of the hack a spin on CM11, to see what results I get...
 
Thanks, crm701! That was tremendously helpful. OK, now looking at the results of your tests, my best guess is all three issues have to do with SELinux being enforcing on KK. hroark13 left it enabled. It's disabled on my Nook Color so maybe that's why everything works on it. I think he built TWRP with KK's boot.img, and if so, that might also explain why my installation scripts inside the zips have troubles. If my hypothesis is right, then I'd suppose my zips would work under CWM with stock roms. If anyone wants to use TWRP to install on stock roms, I guess I can combine -install and -copy in one zip so there's no need for reboot in-between, assuming hroark13's TWRP lets me run the zip at least one time.

I guess the reason boot loop occurs with the "vold" case but not the "debuggerd" case could be because my code runs before the actual vold code in the former but after in the latter. Perhaps vold affects the permissions to access the partition? I guess without proper access rights, the SELinux-enforcing kernel rejects my access, causing failure to boot.

There's an app called "SELinux Mode Changer" that can set permissive mode at boot, but I don't know if it runs early enough to help my mounter binary. I can target debuggerd like I did before, but I am not sure whether that really solves the problem since crm701 has reported other issues with my old test build under KK (needing SDfix to function?). So, crm701, does everything work right (including sensors) if you install mount_data as debuggerd (and the actual debuggerd -> debuggerd-original) like you tried? And if not, what happens if you do so in SELinux-permissive mode? If you do try running in permissive mode, does the console script ("sh installer.sh both") work then?

I'm not too familiar with SELinux, but I'll study it a bit to see whether I can obtain the necessary privileges so the kernel would accept my hack as a system process. And if the real problem is not with SELinux, then I'd have to do more tests to find the cause.

Edit: Found this: http://source.android.com/devices/tech/security/se-linux.html
"In Android 4.4, SELinux was made enforcing for the domains for several root processes: installd, netd, vold and zygote. All other processes, including other services and all apps, remain in permissive mode to allow further evaluation and prevent failures in Android 4.4."
That's why the vold method fails but the "debuggerd" method at least boots. I think someone tried my original implementation (using JVene's app_process) on KK and reported a boot loop. It makes sense now. So of the three entry points I've targeted, app_process (zygote), debuggerd, and vold, only debuggerd would be allowed to continue booting. The other issues still remain, but at least it's making a little more sense now.
 
I tested the sensors with sensor box (playstore). All sensors check OK. The buttons all work. I rebooted a couple of times to double check. I was reading Hroark13's post on the KK beta 4 (version I've been using) and, according to his list of features, it is supposed to be a un-secured kernel with init.d added back in (think he may have removed it in an earlier version). But init.d still doesnt work, unless I use a mod or app. Also, I have tried before to get selinux switcher to work but it has the buttons (enable,permissive) greyed out. After a few minutes a message pops up saying selinux is either not installed or already permissive. But if I check /sys/fs/selinux/enforce file, it reads "1"which I believe is 'true'. I think the issue may be in how he ported the rom (different build etc), the role LOKI plays in bypassing the bootloader etc.
I have been playing around in trying to turn selinux to 'permissive', trying to do it with terminal commands. But it seems that BusyBox doesnt have those needed selinux commands built in. So I've been trying to find a version that does. Apparently a version can be compiled (cross-compiled?) using a toolchain, but I haven't dipped my toes into those waters yet...Been trying to find a preconfigured way to change it or something without compiling (building?) a kernel, but I dont know if it can be done that way without rebuilding the kernel.It seems that once the kernel is compiled,some of the kernel's settings can only be changed by rebuilding it. I did came across this:

[MOD][P905] selinux permissive on stock kernel LTE QUALCOMM ONLY! - Post #1 - XDA Forums

on xda about a possible workaround. Its "supposed" to be for the Samsung Galaxy note 12.2 etc, but I was going to give it a try. Maybe I might be able to bungle through to get it working,if it doesnt straight away.

Also, I am going to try your swap mod on the CM11 ROM (Hroark13 again lol he travels in all the rom circles) because I believe that its kernel may truly be un-secure. I wont know till I try.

Thanks for your work WV. Maybe you might be able (and have the inclination) to whip up a kernel in the future. Just putting it out there ;)
 
Have you tried adding
Code: 
ro.boot.selinux=permissive
to build.prop to see if that works? I was reading the source code of "init", and it seems to be one of the things it looks for. As for BusyBox, are you able to use one from the play store? It'd seem odd the version included would be too old to support selinux. Android's "toolbox" should support the necessary commands though. Perhaps hroark13 just didn't symlink them. You can try to run the commands this way:
Code: 
busybox getenforce
or
Code: 
toolbox getenforce
It looks like hroark13's init.d support is invoked early in the boot process. So if init.d works, there may not be a need to hijack any process. I was hoping for a more universal solution. If we need to target each rom individually, we can just edit init.rc, repack boot.img, and reapply loki. But if all custom roms have init.d running early enough to not cause a conflict with accessing the /data partition, a solution via init.d would be simple enough.

Recompiling a kernel is not too difficult, assuming all pieces are there. LG's kernel source is actually easy enough to work with. What's a bit more challenging is to get an existing and running kernel to accept foreign code. I was doing that to see if I could add functionality to the stock rom. But that's a topic for another day.
 
I was semi-joking about the kernel. That would be pretty specific as opposed to a "universal" (within limits) solution. Now I have not really gone too far yet but I did try the build.prop setting and it did not seem to have an effect (there is a setting in there ro.build.selinux=1. I tried changing that (separate occasions) to '0' but that didint seem to have an effect either. I used toolbox getenforce which returned "enforcing". With toolbox setenforce permissive, it goes to permissive but doesnt hold through reboot. Here is the interesting part (I think). I noticed that when I did the copy it seems to have removed the /data stuff usually there. I mean when I go to /data (or sdcard0,emulated legacy 0, any of those), it just has a couple of folders, download,documents all the usual one are gone. Also, there was a file on the root(partition 1,fat32) of my sd card LGF6DataOnSD. No _INIT at the end, just the first part. Is it possible that /data on the ext4 partition isnt being mounted properly? Maybe its a symptom of something else, I am not sure...

Also, I did try on CM11 (4.4.4) and I didnt get any bootloops but no swap. I will continue to try (on both KK and CM11), but I just wanted to pass this to you in case it might illuminate something.

I almost forgot. For some (unknown to me at the moment) reason, init.d doesn't seem to be working, either in CM11 or KK 4.4.2. I tried testing using the universal init app, but it says that the kernel does not have init.d (both KK 4.4.2 AND CM11). Again I dont know why,just whats been happening to me...
 
Try "ro.boot.selinux=disabled" or "ro.boot.selinux=permissive". According to the source of "init", other values ("enforcing" also recognized) are unknown and init assumes enforcing.

To properly get a hack to work under enforcing mode, I'd need to see how I can set the proper contexts. I'd first need to get my Nook I use for testing to run with selinux enabled. No easy task there as selinux is probably not even compiled into the kernel there.

Could you or anyone do "toolbox getenforce" in TWRP's terminal and let me know the result?

Anyway, if you can get selinux into permissive mode or get it disabled, check if init.d support works then. I'm attaching a flashable zip that uses init.d to mount the external partition. A few things about the zip. It does two things. It copies the mounter script (no binary) to /system/etc/init.d and it copies files from the internal /data to "/sd-ext", which is the external partition on the SD card. The mounter script produces a log file at "/cache/DataOnSD.log.txt" similar to the "init_debug" I posted before. If the hack fails, let me know what the log file says or if one isn't even produced. The copier script is done entirely in edify. no shelling out to a separate script. So hopefully that runs without issues. As before, to get the copying going, remove the tag file ".LGF6DataOnSD_DO_NO_REMOVE" from the external partition (mountable as /sd-ext in TWRP) first. Lastly, there's no uninstaller. To uninstall, simply delete "/system/etc/init.d/00DataOnSD".

If this thing works, I'll update the zip to remove the debug info so that it won't be making a log file at every boot.
Edit: zip removed.
 
toolbox gentenforce followed by
Enforcing

stock rooted rom doesnt have init.d support, right?



WarrantyVoider said:
Try "ro.boot.selinux=disabled" or "ro.boot.selinux=permissive". According to the source of "init", other values ("enforcing" also recognized) are unknown and init assumes enforcing.

To properly get a hack to work under enforcing mode, I'd need to see how I can set the proper contexts. I'd first need to get my Nook I use for testing to run with selinux enabled. No easy task there as selinux is probably not even compiled into the kernel there.

Could you or anyone do "toolbox getenforce" in TWRP's terminal and let me know the result?

Anyway, if you can get selinux into permissive mode or get it disabled, check if init.d support works then. I'm attaching a flashable zip that uses init.d to mount the external partition. A few things about the zip. It does two things. It copies the mounter script (no binary) to /system/etc/init.d and it copies files from the internal /data to "/sd-ext", which is the external partition on the SD card. The mounter script produces a log file at "/cache/DataOnSD.log.txt" similar to the "init_debug" I posted before. If the hack fails, let me know what the log file says or if one isn't even produced. The copier script is done entirely in edify. no shelling out to a separate script. So hopefully that runs without issues. As before, to get the copying going, remove the tag file ".LGF6DataOnSD_DO_NO_REMOVE" from the external partition (mountable as /sd-ext in TWRP) first. Lastly, there's no uninstaller. To uninstall, simply delete "/system/etc/init.d/00DataOnSD".

If this thing works, I'll update the zip to remove the debug info so that it won't be making a log file at every boot.
Click to expand...
 
stigmax2 said:
toolbox gentenforce followed by
Enforcing

stock rooted rom doesnt have init.d support, right?
Click to expand...
Thanks. So hroark13's TWRP runs in enforcing mode, and that's likely why the scripts inside the flashable zips failed. This enforcing/permissive thing is not relevant to the stock roms' Android 4.1.2. The old zips should work after putting TWRP into permissive mode by doing:
Code: 
setenforce 0
at TWRP's terminal. Anyway, I'm attaching another set of zips that do this step automatically so hopefully they take care of the issue with installing on stock roms using TWRP. Please let me know whether they work as expected.

Like crm701 said, stock roms don't support init.d. So init.d scripts won't be run at boot.


For crm701, or anybody who wants to try these zips on KK roms:
I've also added a command to change the context of my mounter binary. Right now I don't know if this is enough to get past SELinux's restrictions though. Normally, this context change will be gone once the system does a file system relabelling. I checked a couple init.rc files. It seemed at boot, relabelling is done to /data and /cache, but I didn't see a relabelling trigger for /system, so hopefully that means the context change will work. So please let me know if a boot loop still occurs.

In addition, I don't know if all files are copied okay. TWRP 2.6.3.0 only offers partial support for SELinux. In particular, none of the tools (busybox and other included binaries) I looked at claim to support SELinux contexts. So if some context on /data needs to be copied, I'll probably need to include another tool in the copier zip.

Edit: zips removed. See a later post for updated zips.
 
How does this hack work with cwm backups? Can I backup and restore the ext 4 partition normally or will it just backup the internal /data? Anyone tried this?
 
but you missed the point.WarrantyVoider picked up on this thread after Jvene brought the concept up (and then stopped posting before coming through with a full working version). WarrantyVoiders implementations (including the one at the top of this page) worked with Xperion ROM. He is attempting to get the newer versions to work properly with the current KK 4.4.2 (Hroark13). His previous iteration (using sensord and debuggerd, and the one before) DO work with 4.4.2, but the hook in app_process causes conflict with Xposed module (and A couple of other issues). He is trying to create a more consistent implementation across different ROMs (and/or across platforms).
 
hello, I've been following this thread for weeks....does the beta work for lg optimus f6 rooted with stock rom? if so what are the steps? U guys are awsom keep up the great work
 
Hye WV,

I just checked out your new zips and the Install completes successfully and the copy also completes successfully but after a reboot i get the lg boot screen. After getting bck into recovery, it's telling me that it's
unable to mount
/data
/data/media
internal storage


also, uninstall failed...
Unable to mount /data


thanks

WarrantyVoider said:
Thanks. So hroark13's TWRP runs in enforcing mode, and that's likely why the scripts inside the flashable zips failed. This enforcing/permissive thing is not relevant to the stock roms' Android 4.1.2. The old zips should work after putting TWRP into permissive mode by doing:
Code: 
setenforce 0
at TWRP's terminal. Anyway, I'm attaching another set of zips that do this step automatically so hopefully they take care of the issue with installing on stock roms using TWRP. Please let me know whether they work as expected.

Like crm701 said, stock roms don't support init.d. So init.d scripts won't be run at boot.


For crm701, or anybody who wants to try these zips on KK roms:
I've also added a command to change the context of my mounter binary. Right now I don't know if this is enough to get past SELinux's restrictions though. Normally, this context change will be gone once the system does a file system relabelling. I checked a couple init.rc files. It seemed at boot, relabelling is done to /data and /cache, but I didn't see a relabelling trigger for /system, so hopefully that means the context change will work. So please let me know if a boot loop still occurs.

In addition, I don't know if all files are copied okay. TWRP 2.6.3.0 only offers partial support for SELinux. In particular, none of the tools (busybox and other included binaries) I looked at claim to support SELinux contexts. So if some context on /data needs to be copied, I'll probably need to include another tool in the copier zip.
Click to expand...
 
You must log in or register to reply here.
Back
Top Bottom