-
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
- Thread starter JVene
- Start date
-
- Tags
- lg optimus f6
If that's the error I think it is, (334 or something), then you should clear your play store and Google play services data then sign out and back in to your Google account. There's a tutorial on YouTube if you're having trouble.
Had to change download location in 1MM settings ...I'll try that as well though
WarrantyVoider
Android Enthusiast
Good! Thanks for the report. So the home and quick buttons are okay too? I know the script wouldn't cause the problem, but I want to make sure it's not some kind of conflict. With your old setup I guess there was some kind of conflict so it didn't work the first time. I won't try to look into what was causing the problem that time since with a clean(er) environment you were able to get it to work.
Work is not done yet. Still need to make a more reliable solution to delay loading of sensord. But I reserve the right to disappear if and when I run into a stumbling block I can't overcome.
This is made to work for 4.1+. It might work with lower versions too, but I can't say because I haven't tried. Technically, the solution shouldn't care about the Android version since it is mostly a Linux thing. I set my compilation target to API level 16 (4.1 JB) because I think starting with that version, executables are compiled to be position independent. I could set the API level to anything but I just went with the lowest that supports position independent code. My code is not using any of Android's API so which version shouldn't matter. In other words, my implementation has no idea about file structures in different Android versions. It only tries to deal with partitions.
Anyway, now that I know it works, I'll write up my findings and methods in more technical details. Before that, I still have a few problems to solve.
Thanks again for doing testing. It saves me time from having to wipe my phone and to get a Windows environment set up in case I need kdz.
WarrantyVoider
Android Enthusiast
Thanks. What rom(s) are you using on those phones?
If the parse error is storage related, it might be the way the rom maps the partition. Some roms support sd-ext (2nd partition on SD formatted as ext2/3/4) which might cause mapping problems. I think in this case there would a problem downloading any app. Does this problem happen when you try to download without any SD expansion? If the problem arises only when trying to download large apps, another possibility is the market trying to store download outside of /data like in /cache or in external_SD (i.e. fat32 partition on SD). There are probably more possibilities. Please keep me updated if you find out more information.
Again, thanks for testing and reporting.
All buttons working (home, Q, power). I noticed that on the first boot after setting up your mod that the settings didn't stick until I rebooted, i.e. the app's shortcuts on desktop (the ones I DL'ed testing if I could download stuff, the ones already there remained), the settings for the knock on/off, force GPU, etc. reset. On the third boot everything was gravy. I dont think its a glitch or anything, just due to the original swap, everything settling in. The apps didn't go *POOF*, they were there in the app drawer. So just an FYI for anybody else trying this that, for me, the third boot and after was the go point. Third boots the charm.
In trying to get the perfect (or as close to) setup for gaining more storage, looking through various forums and other people's different approaches (with varying degrees of success) plus what I experimented with, your solution, even "unpolished", would make other people vary excited...I am sure you could build a zip that does the steps required. Seems like thats the easy part. Few files renamed, switched, and added and Presto! That would also take care of the reboots (not 3, just install, and the next boot would be it, not that its even a problem but would be more natural). Maybe down the road add some simple SD or I/O tweaks... The possibilities! Lol
Anyway, I haven't done it yet, but after taking the SD card out (with phone off) it should revert back to internal at the point before the swap right? Or is that an issue at this stage?
Almost forgot, the play store worked after I cleared the cache but before It would stick on downloading (even though I downloaded an app AFTER the first one stuck so..). After cache was cleared seems ok...and the 1 Mobile Market app's original setting downloads to "external", after setting it to "internal" seems to be working.
In trying to get the perfect (or as close to) setup for gaining more storage, looking through various forums and other people's different approaches (with varying degrees of success) plus what I experimented with, your solution, even "unpolished", would make other people vary excited...I am sure you could build a zip that does the steps required. Seems like thats the easy part. Few files renamed, switched, and added and Presto! That would also take care of the reboots (not 3, just install, and the next boot would be it, not that its even a problem but would be more natural). Maybe down the road add some simple SD or I/O tweaks... The possibilities! Lol
Anyway, I haven't done it yet, but after taking the SD card out (with phone off) it should revert back to internal at the point before the swap right? Or is that an issue at this stage?
Almost forgot, the play store worked after I cleared the cache but before It would stick on downloading (even though I downloaded an app AFTER the first one stuck so..). After cache was cleared seems ok...and the 1 Mobile Market app's original setting downloads to "external", after setting it to "internal" seems to be working.
Works on CM 4.4.4 (Hroark13). All buttons etc, same as on KK 4.4.2. I had to use the KitKat SD fix. I hadn't realized that the SD card would be locked like on KK442, I thought with CM it wouldn't be an issue. After installing the fix, upon reboot system A-OK.
screenshots
Attachments
WarrantyVoider
Android Enthusiast
Thanks for doing more testing. Glad to hear it works with CM11 on this phone. I have the next version ready that I hope will work more reliably. I'll see about uploading it later.
If you remove the SD card with the phone off, when you power on the phone it should boot with internal storage like you expect. Another way to make the phone boot with internal /data without removing the SD is to make the script not executable (600, -rw-------).
It makes sense using this hack/mod you need to make apps store data internally, which is actually mapped to the external SD partition. I was hoping with enough external-as-"internal" /data storage KK's SD restriction wouldn't be an issue. So when you say SD card would be locked on CM11, what happens? Without the SD fix, is the ext4 partition on SD still mounted correctly as /data? If not, then I need to figure out how Android sets the lock. If it is mounted correctly and is working, is the problem only related to apps trying to access the external fat32 partition? I'll look into this a bit more to see how the restriction affects what I'm doing. Thanks for your testing and information. Very helpful.
The multiple boot thing could be due to timing. This "hack" sorta sets up a race between the script mounting the /data partition and other services accessing /data. On first boot file copying took enough time that other services might have started using /data. The 2nd boot I'm not sure whether there was some kind of caching going on. On mine it worked, but I noticed more files being opened and the system accessing files I had deleted before the reboot (so files were obviously not there but were checked or whatever). So perhaps that delayed the booting a bit. So if that makes sense, after the 3rd boot those issues went away. In my current version, I am making the script boot even earlier. Doing that, I find I don't need to delay the normal loading of sensord. So if this tweak works with other roms too, then the installation would be simpler with only one binary and one script, just like before my testing build.
If you remove the SD card with the phone off, when you power on the phone it should boot with internal storage like you expect. Another way to make the phone boot with internal /data without removing the SD is to make the script not executable (600, -rw-------).
It makes sense using this hack/mod you need to make apps store data internally, which is actually mapped to the external SD partition. I was hoping with enough external-as-"internal" /data storage KK's SD restriction wouldn't be an issue. So when you say SD card would be locked on CM11, what happens? Without the SD fix, is the ext4 partition on SD still mounted correctly as /data? If not, then I need to figure out how Android sets the lock. If it is mounted correctly and is working, is the problem only related to apps trying to access the external fat32 partition? I'll look into this a bit more to see how the restriction affects what I'm doing. Thanks for your testing and information. Very helpful.
WarrantyVoider, nice job on the script and packaging this into something more user-friendly.
I hadn't been back to this thread since I had solved my problem, but decided to check on it yesterday. Coincidentally, I had been having the sensor issue for a few weeks, but I thought my sensor just died, because I SWEAR it was working when I first implemented the mod. Maybe I just didn't notice it for a while.
Anyway, sticking "stop sensord" prior to the mount command and "start sensord" after it works fine and is clean enough for me.
I see you've decided to hijack the boot process at a different point. Is this for compatibility with Xposed? Before I had discovered JVene's hack, I was also hijacking debuggerd by replacing it with a shell script and then executing the original binary at the end of the script. I think this is all that's necessary - no binary (script_caller) required. For some reason I moved away from this and started using JVene's method. Maybe because I like how it guarantees that the mount is performed prior to zygote loading.
I hadn't been back to this thread since I had solved my problem, but decided to check on it yesterday. Coincidentally, I had been having the sensor issue for a few weeks, but I thought my sensor just died, because I SWEAR it was working when I first implemented the mod. Maybe I just didn't notice it for a while.
Anyway, sticking "stop sensord" prior to the mount command and "start sensord" after it works fine and is clean enough for me.
I see you've decided to hijack the boot process at a different point. Is this for compatibility with Xposed? Before I had discovered JVene's hack, I was also hijacking debuggerd by replacing it with a shell script and then executing the original binary at the end of the script. I think this is all that's necessary - no binary (script_caller) required. For some reason I moved away from this and started using JVene's method. Maybe because I like how it guarantees that the mount is performed prior to zygote loading.
WarrantyVoider
Android Enthusiast
Logged on to upload the next version, possibly an alpha release. But since likwid2 seems to have done some experiments on this concept as well, it might be good to discuss my method a bit before unleashing my current implementation onto the masses.
Yes, "stop sensord" and then "start sensord" would be a simpler workaround. At that time I was working on the compatibility issue with Xposed, so I thought maybe I could kill two birds with one stone. Restarting sensord would have been an easier fix, but I was thinking that method wouldn't be as portable to other platforms/roms if they have other services/daemons loaded in a different way.
You're right that my motivation for going to another entry point was for compatibility with Xposed. Xposed seems to want control over app_process. It doesn't recognize itself as installed if I change the file. I don't want to have to modify Xposed so I try to get my binary/script loaded before app_process. In my test build, I targeted debuggerd. In my current version, I'm hijacking vold. debuggerd loads before app_process but I'm still unsure the script will finish mounting before sensord starts. Here, like I said, my concern isn't actually sensord per se, but any service that might access /data because I can't know what every other custom rom is doing. vold loads before debuggerd so it seems to be a better candidate. Before I was worried that vold's handling of partitions on SD would interfere with my mounting script, but now I don't think that'd be the case. I used debuggerd because I figured it's less likely to cause a boot problem for other testers. Two things going for vold. One, vold is the first process loaded from /system that's owned by root. servicemanager is the first process loaded from /system but is owned by system. Two, vold belongs to the "core" class as does servicemanager in init.rc. debuggerd and zygote both belong to the "main" class. As far as I know, services belonging to the same class may be started at the same time and in init.rc, "core" is loaded before "main" (obviously, since servicemanager has to be started before the other services). So, vold seems like a good candidate.
As for guaranteeing mount before zygote, I'm not sure it matters much in practice. Since multiple services are loaded and started by init, any one of those could hold files open in /data, as sensord does. sensord belongs to the "late_start" class, and the fact it can already open files before our script finishes mounting means the shell script runs too slow or too late. Therefore, I want to run the script even before app_process. I suppose doing everything in C like JVene wanted would probably be better, but it's a lot harder to modify and debug that way.
One more point. If all we want is to solve the storage problem on this phone, there might be an easier way. In init.f6mt.rc, we see /system/etc/init.qcom.post_fs.sh loaded as the "core" class and as root. So if it does what I think it does, we can just do mounting there. No modification to any binary necessary and no likely boot issues if the script only does sensible things. I haven't tried so I don't know if that works at all. Just a thought.
likwid2, just want to thank you first. JVene's information was enough to make the idea work, but I'd have had to prepare for a bit of experimentation. Your confirmation that it works convinced me to try implementing directly on my phone and sped up my involvement.
Yes, "stop sensord" and then "start sensord" would be a simpler workaround. At that time I was working on the compatibility issue with Xposed, so I thought maybe I could kill two birds with one stone. Restarting sensord would have been an easier fix, but I was thinking that method wouldn't be as portable to other platforms/roms if they have other services/daemons loaded in a different way.
You're right that my motivation for going to another entry point was for compatibility with Xposed. Xposed seems to want control over app_process. It doesn't recognize itself as installed if I change the file. I don't want to have to modify Xposed so I try to get my binary/script loaded before app_process. In my test build, I targeted debuggerd. In my current version, I'm hijacking vold. debuggerd loads before app_process but I'm still unsure the script will finish mounting before sensord starts. Here, like I said, my concern isn't actually sensord per se, but any service that might access /data because I can't know what every other custom rom is doing. vold loads before debuggerd so it seems to be a better candidate. Before I was worried that vold's handling of partitions on SD would interfere with my mounting script, but now I don't think that'd be the case. I used debuggerd because I figured it's less likely to cause a boot problem for other testers. Two things going for vold. One, vold is the first process loaded from /system that's owned by root. servicemanager is the first process loaded from /system but is owned by system. Two, vold belongs to the "core" class as does servicemanager in init.rc. debuggerd and zygote both belong to the "main" class. As far as I know, services belonging to the same class may be started at the same time and in init.rc, "core" is loaded before "main" (obviously, since servicemanager has to be started before the other services). So, vold seems like a good candidate.
As for guaranteeing mount before zygote, I'm not sure it matters much in practice. Since multiple services are loaded and started by init, any one of those could hold files open in /data, as sensord does. sensord belongs to the "late_start" class, and the fact it can already open files before our script finishes mounting means the shell script runs too slow or too late. Therefore, I want to run the script even before app_process. I suppose doing everything in C like JVene wanted would probably be better, but it's a lot harder to modify and debug that way.
One more point. If all we want is to solve the storage problem on this phone, there might be an easier way. In init.f6mt.rc, we see /system/etc/init.qcom.post_fs.sh loaded as the "core" class and as root. So if it does what I think it does, we can just do mounting there. No modification to any binary necessary and no likely boot issues if the script only does sensible things. I haven't tried so I don't know if that works at all. Just a thought.
Xposed replaces the stock app_process with a modified version, which is why replacing it with JVene's breaks Xposed. JVene mentioned trying to get his functionality included in the Xposed source, but I guess nothing came of it. One option is to add "zinit" functionality to the Xposed app_process source and build it.
The reason JVene was concerned about ensuring completion of the copy and remount of /data prior to zygote loading is that once zygote loads, a whole mess of processes start accessing /data, including apps that access databases that don't like to be copied while open.
I'm not an expert on the Android boot process, but I'm assuming services are loaded concurrently. If they are, then hijacking somewhere other than app_process wouldn't guarantee that the copy and mount are performed prior to zygote loading. If they aren't loaded concurrently, then it's not a concern as long as you hijack a service that loads before zygote.
FWIW, I stuck an lsof command prior to killing sensord in my boot script and the only files open on /data were 4 files by sensord. It's possible that another service had already opened and closed files on /data, but it wouldn't be an issue unless something important was written to the files.
Edit: Nice find on init.qcom.post_fs.sh. I had initially looked for a call to a script on /system, but I wasn't very thorough and missed that. For this platform, that's probably the cleanest place to run a boot script (assuming it executes before zygote loads).
The reason JVene was concerned about ensuring completion of the copy and remount of /data prior to zygote loading is that once zygote loads, a whole mess of processes start accessing /data, including apps that access databases that don't like to be copied while open.
I'm not an expert on the Android boot process, but I'm assuming services are loaded concurrently. If they are, then hijacking somewhere other than app_process wouldn't guarantee that the copy and mount are performed prior to zygote loading. If they aren't loaded concurrently, then it's not a concern as long as you hijack a service that loads before zygote.
FWIW, I stuck an lsof command prior to killing sensord in my boot script and the only files open on /data were 4 files by sensord. It's possible that another service had already opened and closed files on /data, but it wouldn't be an issue unless something important was written to the files.
Edit: Nice find on init.qcom.post_fs.sh. I had initially looked for a call to a script on /system, but I wasn't very thorough and missed that. For this platform, that's probably the cleanest place to run a boot script (assuming it executes before zygote loads).
WarrantyVoider said:
Your welcome, glad to help! I got this F6 as a 2nd phone, mostly for fun-type things, and the storage was a serious damper on an otherwise great phone (considering price). As I stated previous, your swapmod is like a soothing balm on the friction burn of no storage and I can mess around without worrying (too much) about jamming the phone up.[/over-elaboration off}
The kitkat SD fix,from what I gathered, changes the permissions so that the SDcard can be accessed by user-installed APK's. Before the fix, no swap. Nothing seemed to happen. Same phone internal, with the fat32 position as external. After I used the fix, ext4 internal, fat32 external as expected. I used the fix on both KK (4.4.2) & CM11 (4.4.4)
here is the program I used
https://play.google.com/store/apps/details?id=nextapp.sdfix&hl=en
That's funny you mentioned /system/etc/init.qcom.post_fs.sh, I was using a modhack that enabled init.d to work proper when I was using Mounts2SD. All the other init.d's solutions I had tried failed to run the M2SD script properly (not sure why). After some thread exploration and trial-n-error I came to:
[SCRIPT/ZIP][N9005][4.4.2] Init.d Support wi… | Galaxy Note 3 | XDA Forum
The method worked, but it broke swapping functionality. I flashed back my nandroid and swap returned. I dont know what the problem was, but it was something I encountered, and when you mentioned qcom.post.fs.sh, I figured I would mention it.
WarrantyVoider said:
Phone goes back to as-was with card out. Side note, I was messing around, used the init.d hack above (trying to install Killjoy mod)and on reboot I still was swapped, but the init.d wasn't working AND lost sensors. Restored my nandroid (when the sensors were working) but I had to re-flash the ROM to regain them (still had data on the EXT4 which came back).
Also, I enabled ART (CM11 ROM), and it worked with your mod, so there's that.
WarrantyVoider
Android Enthusiast
Having to rebuild Xposed each time a new version is released is too much maintenance work. Xposed needs to take control of Android's class loading mechanism, so it has legitimate reason to control app_process. I decided to move away from app_process because my concern is technically init services rather than Android itself.
The way I see it, init launches a bunch of services at boot and zygote/app_process is just one of them. It's like a race to see who gets to /data first. When I learned about the problem with the sensors, I took a look at the situation with ps and lsof like you. As it turns out, in this race, zygote is big and slow. sensord is the first to cross the finish line. lgdrmserver comes in 2nd (whatever lg's drm is), but it's far enough behind by a couple of seconds that it's really not a challenger for our mounting script. zygote is nowhere in sight. Since then, I focus my attention to beating sensord and whatever services other roms/platforms may use. I think on this phone, your solution is actually very sensible, assuming stopping and starting sensord has no ill effect. I got greedy in trying to tackle a bigger problem when others reported my initial implementation not working on KK. One concern I do have is if we slow down our scripts, say, if we use e2fsck before mount. So I keep thinking about the best approach. By the way, using vold without hindrance to sensord, I find in my lsof log that sensord opens the ".err" file and the two "profile" files but not the two "fifo" named pipes. Sensors seem to work. So I think if I do mounting in compiled code, the compiled code will probably always win the race.
As for init.qcom.post_fs.sh, I got intrigued by it with crm701's info. It looks like it got beat by both sensord and lgdrmserver and that's all. Since it seemed to open some database file, I'm not sure what effect stopping and starting lgdrmserver would have. So I'm not going to look there.
WarrantyVoider
Android Enthusiast
I want to take a deeper look at the problem with KK's SD restriction. I think the nice thing about having a large /data partition is not having to worry about using files on the external SD at all. This may require me to actually test on a rom with that restriction, but unfortunately, my Nook Color's CM11 doesn't seem to prevent my hack from working and my stock F6 is needed for remote support this week.Your welcome, glad to help! I got this F6 as a 2nd phone, mostly for fun-type things, and the storage was a serious damper on an otherwise great phone (considering price). As I stated previous, your swapmod is like a soothing balm on the friction burn of no storage and I can mess around without worrying (too much) about jamming the phone up.[/over-elaboration off}
The kitkat SD fix,from what I gathered, changes the permissions so that the SDcard can be accessed by user-installed APK's. Before the fix, no swap. Nothing seemed to happen. Same phone internal, with the fat32 position as external. After I used the fix, ext4 internal, fat32 external as expected. I used the fix on both KK (4.4.2) & CM11 (4.4.4)
here is the program I used
https://play.google.com/store/apps/details?id=nextapp.sdfix&hl=en
That's funny you mentioned /system/etc/init.qcom.post_fs.sh, I was using a modhack that enabled init.d to work proper when I was using Mounts2SD. All the other init.d's solutions I had tried failed to run the M2SD script properly (not sure why). After some thread exploration and trial-n-error I came to:
[SCRIPT/ZIP][N9005][4.4.2] Init.d Support wi… | Galaxy Note 3 | XDA Forum
The method worked, but it broke swapping functionality. I flashed back my nandroid and swap returned. I dont know what the problem was, but it was something I encountered, and when you mentioned qcom.post.fs.sh, I figured I would mention it.
Phone goes back to as-was with card out. Side note, I was messing around, used the init.d hack above (trying to install Killjoy mod)and on reboot I still was swapped, but the init.d wasn't working AND lost sensors. Restored my nandroid (when the sensors were working) but I had to re-flash the ROM to regain them (still had data on the EXT4 which came back).
Also, I enabled ART (CM11 ROM), and it worked with your mod, so there's that.
Thanks for all the info again. Looking at some of the things others have done, it's like I'm a few steps away from doing init.d myself. Don't most custom roms have init.d support? Are they not supporting what you want to do properly? If you want to try, make a "00testopenfiles" script in /system/etc/init.d with executable permission:
Code:
#!/system/bin/sh
F=/cache/initd_test.txt
ps >> $F
lsof >> $FGood to know ART works. Now if only LG/T-mobile/MetroPCS would release the KK update for this phone...
Hey WV, so I had planned on basically going through the main three ROM types and I installed GT's Xperion ROM and Freedom kernel (4.1.2 JB). Letting you know works fine.
Concerning what I have been encountering with init.d. I ran your file and the first three were (all under root) init, kthreadd, ksofttirqd/0. I seem to be having issues with permissions though, I attached a link to the logcat, (I have never tried using dropbox like this before so I hope it works ok) Maybe you could take a look? It seems a lot of problems with permissions? I want to go try it on the kitkat ROMS, but the issue seemed to be the same across the different ROMs. From what I can see, it looks like sometimes things cant be written to /system. Also, I used uni-init to check if init.d was working (just puts a test file in init.d and then checks for it) It wouldnt work until I turn init.d "on" with the app. Then it worked, but I lost sensors, and settings back to default...(Still showing everything was swapped).I have been running down so many things, and playing around, I lost track a bit (lol). I think everything ties in together, maybe something I did (even though I stopped shotgun blasting and started doing things one at a time to see what happens. So I plan on doing this with the other roms, before I do let me know if theres anything you want me to try/do while I am here (re: Game Theory 4.1.2 JB with his OC kernel)
Heres the dropbox link to log: https://drive.google.com/file/d/0B2bzCt4-IFWxOXUxbU9adzJKU3M/edit?usp=sharing
Concerning what I have been encountering with init.d. I ran your file and the first three were (all under root) init, kthreadd, ksofttirqd/0. I seem to be having issues with permissions though, I attached a link to the logcat, (I have never tried using dropbox like this before so I hope it works ok) Maybe you could take a look? It seems a lot of problems with permissions? I want to go try it on the kitkat ROMS, but the issue seemed to be the same across the different ROMs. From what I can see, it looks like sometimes things cant be written to /system. Also, I used uni-init to check if init.d was working (just puts a test file in init.d and then checks for it) It wouldnt work until I turn init.d "on" with the app. Then it worked, but I lost sensors, and settings back to default...(Still showing everything was swapped).I have been running down so many things, and playing around, I lost track a bit (lol). I think everything ties in together, maybe something I did (even though I stopped shotgun blasting and started doing things one at a time to see what happens. So I plan on doing this with the other roms, before I do let me know if theres anything you want me to try/do while I am here (re: Game Theory 4.1.2 JB with his OC kernel)
Heres the dropbox link to log: https://drive.google.com/file/d/0B2bzCt4-IFWxOXUxbU9adzJKU3M/edit?usp=sharing
WarrantyVoider
Android Enthusiast
Oops, I didn't tell you what to do with the ps and lsof information. ps shows a list of running processes and lsof a list of open files. My suggestion of running them in init.d was to check the state of the booting process when init.d runs the commands. In particular, if files on /data are open, mounting the external partition over /data will likely fail or cause problems. So look in the output of lsof for any files in /data. For example, sensors would fail to work if sensord has already opened files (fifo_* named pipes) in /data/misc/sensor when we try to mount a partition to /data. ps output helps tell us what processes are running up to that point. For example, I did some work on yet another implementation over the weekend. So far, I implemented part of my original script in C. I compared using shell scripts and compiled code, each with app_process and vold (I skipped debuggerd because vold happens earlier in the boot process) as the entry point. I found that with app_process and shell scripts, the partition is mounted after sensord has been started. So if sensord opens files on /data first, sensors won't work after we mount the new /data. With the other three combinations, mounting occurs before sensord is started. Consequently, sensors work in those cases without a need to delay loading or to restart sensord.
By the way, in my testing release where I hijacked debuggerd and sensord, I only let the script sleep for one second before loading sensord. It was a quick way to see if the method works. I think in a custom rom and/or with other mods, more things could be competing for time during boot-up. It's possible that's the reason in those cases sensors stop working, if other boot processes cause delay of partition mounting enough that sensord, even after one-second delay, opens files first. That's my hypothesis.
As for the problems with init.d, I'm not sure. Custom roms can add init.d support by using init.rc. They can control exactly when and how processes are loaded. With add-on mods, a way to exploit the existing booting process is needed to add init.d support. Not all methods will work. And what you can do in a script depends on how soon that script is run. The permission problems you're seeing could be caused by that. Running programs don't expect the underlying file systems to be yanked out. Another possibility is during the initial file copying, files weren't coped correctly. But if there's no problem with the files normally but problems show up when you change the booting process, then I'd guess it's the former possibility.
Right now I'm rethinking how to do the initial file copying part properly. Doing so during boot is actually trying to copy a live file system. If copying doesn't take very long, there's chance everything works out. But there's no guarantee other processes won't start accessing or modifying the files, causing inconsistency. The safer thing is probably do copying in recovery. Instead of a script to run in recovery, I think it makes more sense to extract the files on /data directly from a backup. Anyway, I haven't spent any time on this idea yet.
If you have your existing /data partition copied and working on your SD card, I can send you the binary for the mounting part. Not sure if it would solve your existing problems with other mods you're using, but since it runs just a bit earlier in the booting process, perhaps it's a bit more reliable. I can do that tomorrow.
By the way, in my testing release where I hijacked debuggerd and sensord, I only let the script sleep for one second before loading sensord. It was a quick way to see if the method works. I think in a custom rom and/or with other mods, more things could be competing for time during boot-up. It's possible that's the reason in those cases sensors stop working, if other boot processes cause delay of partition mounting enough that sensord, even after one-second delay, opens files first. That's my hypothesis.
As for the problems with init.d, I'm not sure. Custom roms can add init.d support by using init.rc. They can control exactly when and how processes are loaded. With add-on mods, a way to exploit the existing booting process is needed to add init.d support. Not all methods will work. And what you can do in a script depends on how soon that script is run. The permission problems you're seeing could be caused by that. Running programs don't expect the underlying file systems to be yanked out. Another possibility is during the initial file copying, files weren't coped correctly. But if there's no problem with the files normally but problems show up when you change the booting process, then I'd guess it's the former possibility.
Right now I'm rethinking how to do the initial file copying part properly. Doing so during boot is actually trying to copy a live file system. If copying doesn't take very long, there's chance everything works out. But there's no guarantee other processes won't start accessing or modifying the files, causing inconsistency. The safer thing is probably do copying in recovery. Instead of a script to run in recovery, I think it makes more sense to extract the files on /data directly from a backup. Anyway, I haven't spent any time on this idea yet.
If you have your existing /data partition copied and working on your SD card, I can send you the binary for the mounting part. Not sure if it would solve your existing problems with other mods you're using, but since it runs just a bit earlier in the booting process, perhaps it's a bit more reliable. I can do that tomorrow.
lol wow dude! So do you program or is it just a hobby? I mean, I don't really understand alot of the technical details. I mostly picked up bits and pieces from here and there. I guess what I was doing was causing issues because of the way the system handles the various process' when it boots then. Maybe I was thinking that the whole was swapped over to the SD card. Its just /data mounted on there. I might have went beyond the scope of what you were intending? /Data is on the external, some of the stuff I was playing with were not expecting that. I was wondering though, would any of this apply?
Talking about mounting the external SD with permissions:
[GUIDE] How to mount ext4 formatted MicroSD … | Android | XDA Forums
Or maybe I am not understanding whats really going on! lol happens a lot
Talking about mounting the external SD with permissions:
[GUIDE] How to mount ext4 formatted MicroSD … | Android | XDA Forums
Or maybe I am not understanding whats really going on! lol happens a lot
WarrantyVoider
Android Enthusiast
Well, I program and it's a hobby. I'm actually quite new to Android, so it's a learning process for me. A lot of times developers don't discuss their methods, so sometimes you can't find out how to resolve incompatibility unless you look at the source. Fortunately, in open source projects, you can do that but it just takes time. Anyway, don't worry about the technical details. JVene was gone before I arrived, but he was detailed in documenting his findings and concepts that I benefited from them. Maybe they are verbose for typical users, but they are helpful for me because I'm trying to learn how things work. So you don't need to worry about the technical details. Take away from them what you need. Maybe someone else who reads the thread later might like to have that information.
Here's the summary. The concept in this project is to make the system use the partition on the external SD as /data. Other mods/apps that don't care where files are physically located except that they are where they are supposed to be in /data should work fine in theory. My goal with my different implementations is to get the partition mounted as early as possible before anything else starts accessing files in /data.
Okay, here's the binary I talked about. First unstall the old implementation by reversing the steps you took to install. Or just restore the /system partition with your backup. Inside the zip is a file called "mount_data". Copy it to /system/bin and change owner/permissions to (0:2000, 755) as usual. Then rename "vold" to "vold-original" then "mount_data" to "vold". Like I said, this only mounts the ext4 partition with ".LGF6DataOnSD_DO_NOT_REMOVE" on it. The program by itself won't copy files from internal storage to external SD, so make sure your data previously copied from internal storage to existing SD card with the previous script are still good and functioning. I hope this method has fewer chances of conflict with other things.
Here's the summary. The concept in this project is to make the system use the partition on the external SD as /data. Other mods/apps that don't care where files are physically located except that they are where they are supposed to be in /data should work fine in theory. My goal with my different implementations is to get the partition mounted as early as possible before anything else starts accessing files in /data.
Okay, here's the binary I talked about. First unstall the old implementation by reversing the steps you took to install. Or just restore the /system partition with your backup. Inside the zip is a file called "mount_data". Copy it to /system/bin and change owner/permissions to (0:2000, 755) as usual. Then rename "vold" to "vold-original" then "mount_data" to "vold". Like I said, this only mounts the ext4 partition with ".LGF6DataOnSD_DO_NOT_REMOVE" on it. The program by itself won't copy files from internal storage to external SD, so make sure your data previously copied from internal storage to existing SD card with the previous script are still good and functioning. I hope this method has fewer chances of conflict with other things.
WarrantyVoider
Android Enthusiast
Yeah, for end users, it'd be easier to use a flashable zip, or an apk, or at least an installation script. Right now I consider this still in development, and it's easier for me to zip up what I have and upload. People who know how to manually install this would have the knowledge to recover if something goes wrong. If I need to package this for more people, then I'll invest some time to make installation easier. I don't even know if anyone is waiting for an easier-to-install release, so for now I'm just working at my own pace.
Xt51
Android Enthusiast
Good idea.
Blackflag4
Well-Known Member
I'm sure a lot of people still want this work around and would love a flashable zip.
Stock T-mobile F6, rooted with Towel Root, SuperSU installed.
I followed the steps in Post #220 and used MiniTool to set up the partitions on a SanDisk Ultra 32 gig card.
After formatting the card, I copied all the files from the "DataOnSD" zip (expanded) to the root of the Fat32 partition.
Then booted the phone, and moved/renamed the files as described in #220 and set permissions using ES File Explorer. I rebooted, and.....Nothing.
The FAT32 Part. shows, but the INIT file at the root of the FAT32 Part. never gets deleted and the internal storage stays at 1.72G. I tried several reboots, but nothing happens.
Anyone have any suggestions? I appreciate the help.
I followed the steps in Post #220 and used MiniTool to set up the partitions on a SanDisk Ultra 32 gig card.
After formatting the card, I copied all the files from the "DataOnSD" zip (expanded) to the root of the Fat32 partition.
Then booted the phone, and moved/renamed the files as described in #220 and set permissions using ES File Explorer. I rebooted, and.....Nothing.
The FAT32 Part. shows, but the INIT file at the root of the FAT32 Part. never gets deleted and the internal storage stays at 1.72G. I tried several reboots, but nothing happens.
Anyone have any suggestions? I appreciate the help.
WarrantyVoider
Android Enthusiast
Okay, I looked into the possibility of doing a flashable zip. Based on my brief study, edify only lets me copy a new file. What I need is to rename a file the rom is already using. I still need the original file to do its job so I can't simply replace it. I also can't just bundle a new one because I doubt it is universal for various roms. I would also need a way to copy files from internal storage or a backup archive to the external SD card. It's probably doable, but I'd have to spend some time understanding how to hack it. My intention is to first provide users some way to install this, using as few other tools as possible (so no need to install a new recovery and/or other paid apps just to solve the storage problem). In other words, flashable zips won't get a high priority. I'll revisit this possibility after I get other things I want to do working.
Right now, I have an installation shell script for people who are not afraid of the console. I also tried copying files to the external ext4 partition directly from a CWM backup and so far it appears to be working. I read somewhere TWRP archives are basically tar files also, so they are possibly compatible as well. I'll have more time over the weekend to finish testing, so hopefully I'll have this ready for upload by then.
If the INIT file is still present (assuming it's not somehow read-only), then your /data files were never copied to the ext4 partition on the external SD. Assuming you correctly installed the files, I'd say most likely the external partition(s) failed to mount. So first check whether the phone can see the partitions: with the file manager, see whether /dev/block/mmcblk1p1 (also /dev/block/vold/179:33) and /dev/block/mmcblk1p2 (also /dev/block/vold/179:34) exist. Next is to check whether the partitions are mountable. If you're comfortable with a command prompt (adb shell, terminal emulator, or ssh), you can try manually mounting the partition to see whether it works:
"su" asks for superuser permission. After that, each line should produce no errors.
If other people have problems also, I'll consider writing a test script to make it easier to troubleshoot, after I release my next version.
Right now, I have an installation shell script for people who are not afraid of the console. I also tried copying files to the external ext4 partition directly from a CWM backup and so far it appears to be working. I read somewhere TWRP archives are basically tar files also, so they are possibly compatible as well. I'll have more time over the weekend to finish testing, so hopefully I'll have this ready for upload by then.
If the INIT file is still present (assuming it's not somehow read-only), then your /data files were never copied to the ext4 partition on the external SD. Assuming you correctly installed the files, I'd say most likely the external partition(s) failed to mount. So first check whether the phone can see the partitions: with the file manager, see whether /dev/block/mmcblk1p1 (also /dev/block/vold/179:33) and /dev/block/mmcblk1p2 (also /dev/block/vold/179:34) exist. Next is to check whether the partitions are mountable. If you're comfortable with a command prompt (adb shell, terminal emulator, or ssh), you can try manually mounting the partition to see whether it works:
Code:
su
mkdir /cache/tempdir
mount -t ext4 /dev/block/vold/179:34 /cache/tempdir
umount /cache/tempdir
rmdir /cache/tempdir
exit
exitIf other people have problems also, I'll consider writing a test script to make it easier to troubleshoot, after I release my next version.
GameTheory
Android Expert
I wont be getting involved in your project due to time, but I'll give you the basic rundown to make it flashable.
First add the following to your edify script...
Where "FILENAME" is the name of your shell script...
Code:
package_extract_file("FILENAME.sh", "/tmp/FILENAME.sh");
set_perm(0, 0, 0777, "/tmp/FILENAME.sh");
run_program("/tmp/FILENAME.sh");Now create the shell script and place it in the root of your flashable zip.
In the shell script you can run commands, like to rename the file do the following...
Lets say the file you wish to rename is called "Warranty", but you want to rename it to "Voider".
Add the following to the shell script based on the location of the file...
Code:
#!/sbin/sh
# Mounting system
busybox mount -o remount,rw -t auto /system
# Renaming file
mv /system/etc/Warranty /system/etc/Voider
# Setting permissions
chmod 755 /system/etc/VoiderTo test create a bogus file in a system directory on your phone and do the above to make sure it works as intended.
It's been a while, but I've done it this way in the past with no problem.
You can achieve everything you mentioned in the first paragraph with a flashable zip by using edify script in combination with a shell script like my example above.
Good luck bro.
