Root Proposal/Theory for External SD storage solution on F6

[WarrantyVoider]

@TrevorX5J9
Decided to do a quick check tonight. It looks like the hack works fine on CarbonROM. I simply flashed the rom (not even gapps), booted into it, went back to TWRP to flash -copy.zip and -install.zip, and rebooted. I saw increased space under settings->storage. I didn't bother installing anything. I turned the phone off then on; it still worked. Rebooted; worked. So at this point I'm going to assume the hack is compatible with CarbonROM.

So the problem is probably not SELinux related. Another possibility is your partition is not really ext4. If TWRP somehow formatted your "sd-ext" partition, perhaps the partition ended up being ext2, which doesn't support journaling. Typically, after power loss or sudden reboot, an ext2 file system might become inconsistent and would require a "file system check." This hack doesn't do any checking before mounting (since it expects ext4, which supports journaling). So perhaps there's an error preventing the code from mounting the partition. I don't know if this is what happened for you though. It's just a guess.

If my hypothesis is right and you want to preserve your data, I can maybe make a zip that does a file system check to correct possible errors, archives all files (to the fat32 partition, assuming it's big enough to hold all the files), formats the 2nd partition to ext4, and then restores the files. If my guess is wrong and the cause is actually something else, then you'd need to troubleshoot, perhaps with the adb command prompt, to see where the failure occurs. There were a few posts in this thread with troubleshooting instructions if you're knowledgeable and patient enough.

 

[TrevorX5J9]

@TrevorX5J9
Decided to do a quick check tonight. It looks like the hack works fine on CarbonROM. I simply flashed the rom (not even gapps), booted into it, went back to TWRP to flash -copy.zip and -install.zip, and rebooted. I saw increased space under settings->storage. I didn't bother installing anything. I turned the phone off then on; it still worked. Rebooted; worked. So at this point I'm going to assume the hack is compatible with CarbonROM.

So the problem is probably not SELinux related. Another possibility is your partition is not really ext4. If TWRP somehow formatted your "sd-ext" partition, perhaps the partition ended up being ext2, which doesn't support journaling. Typically, after power loss or sudden reboot, an ext2 file system might become inconsistent and would require a "file system check." This hack doesn't do any checking before mounting (since it expects ext4, which supports journaling). So perhaps there's an error preventing the code from mounting the partition. I don't know if this is what happened for you though. It's just a guess.

If my hypothesis is right and you want to preserve your data, I can maybe make a zip that does a file system check to correct possible errors, archives all files (to the fat32 partition, assuming it's big enough to hold all the files), formats the 2nd partition to ext4, and then restores the files. If my guess is wrong and the cause is actually something else, then you'd need to troubleshoot, perhaps with the adb command prompt, to see where the failure occurs. There were a few posts in this thread with troubleshooting instructions if you're knowledgeable and patient enough.

I already copied everything already off the card. Its on my hard drive right now. Is there a way you can make a zip that copies it off the FAT32 partition and onto the EXT4? I formatted and repartitioned already. It seems to be working now, but I don't know for how long. If I'm correct if you can indeed make a zip to copy data off the FAT32 , which should be accessible by anyone using a SD card reader, and onto the EXT4 every time it stops working we can simply copy off the data, reformat and reflash the hack and our data back on. Although this isn't a permanent solution this is a good workaround until then. With the zip you said you could currently possibly make, and the zip I'm thinking of may/may not work, it could be a solution to every time a user has an issue with the hack. These zips could save a lot of time and trouble for people who did the hack incorrectly. The thing is I have a folder containing the whole phone's OS and data. Is there a way I can restore the data from the folder?

 

[WarrantyVoider]

@TrevorX5J9
I don't think that would work in general. Ext4 has file ownership, permissions, and other attributes that aren't supported on fat32. If you simply copy the files from an ext2/3/4 file system to a Windows file system, all that extra info is lost unless it was saved in some other way. To properly backup, the files should be put in an archive of some sort (basically what CWM/TWRP does).

Once the hack is working properly, there should be almost no need to reformat and reflash. So I don't see a need for such a program. Feel free to convince me otherwise. If the the hack wasn't installed properly, then it's best to correct the installation. There's an unknown number of ways things could have gone wrong, so it's unlikely a zip or a program can be made that can cure all problems. Now a program that can backup and restore the ext4 partition will be useful, but it won't help if you can't mount the partition. All of these things (mounting, backing up, restoring, etc.) can be done manually. I've provided commands for mounting a few pages back.

What I take from your experience is that I wouldn't recommend using TWRP to partition/format/wipe. It might be okay, but I just don't know for sure. It's able to manipulate the "sd-ext" partition, so that means it's able to mess up too. If I ever get around to doing an Aroma installer, I'll consider implementing a SD partitioner/formatter. But I'm in the middle of a more interesting project (to me anyway), so that won't happen until after.

As for backup and restore for general use, I know some people want this feature. I have some crazy/neat idea in mind, but that's further down the pipeline, if I ever get around to it.

 

[su_me]

Just would like to thank everyone on this thread for all the hard work. So glad that i came across these great mods. Confirmed working on xperion 4.1.2 with freedom overclocked kernal. Has serious lag but as posted before im chalking it up to a slow card. This phone is now worth its weight in gold! If your using the f6 this DataOnSD mod is a must. Thanks again for all the hard work. It really does help and is extremely appreciated.

 

[stabinbac]

Add me to the list of incredibly grateful F6 users! I was getting ready to drop another $300+ on a new phone due to the memory issues on the F6.

Method I used:
T-Mobile LG F6, Stock firmware
SanDisk Ultra PLUS 32 GB Class 10 UHS-I
Rooted with towelroot, installed TWRP
formatted disk with gparted: 20 fat32, 10 ext4
Followed instructions for adb and DataOnSD.zip
Pleasantly simple! A little slower when doing read/write intensive tasks, but very acceptable.

Ran into an issue when I discovered my microsd card was bad. Seems like it had an error right where the partition table goes, so reformatting killed it. Deleted one of the partitions using TWRP, and it was scrap (also why I went with gparted on the next card). Even dd tricks in Linux only resulted in unusual garbage results. Luckily Costco let me return it, and I immediately bought an exact replacement for $1 cheaper.

So nice to finally be able to relax and not worry about memory restrictions on this phone. Also nice to get introduced to adb, and some of how android functions

Thank you!

 

[TrevorX5J9]

I had to battery pull as my system was no longer responding. It somehow breaks the hack and I can't mount SD-Ext anymore. @WarrantyVoider Can you get me a zip that compiles everything on my ext4 partition into a zip? Besides this, is it normal that most camera apps, besides the default ones have saving errors? As well as many other apps, say error downloading or saving?

 

[merlin74]

Thanks for this hack. It's really great to have the full SD utilized as internal storage. But I have experience the auto rotation issue after applying the hack. According to discussions, manually stop then start sensord did the trick. Is there a more elegant solution?

 

[WarrantyVoider]

I had to battery pull as my system was no longer responding. It somehow breaks the hack and I can't mount SD-Ext anymore. @WarrantyVoider Can you get me a zip that compiles everything on my ext4 partition into a zip? Besides this, is it normal that most camera apps, besides the default ones have saving errors? As well as many other apps, say error downloading or saving?

I can do that later today or tonight. In the meantime, you can try to do a quick check in TWRP's terminal (Advanced->Terminal Command->Select). Then type "e2fsck -nf /dev/block/mmcblk1p2" and Go. It won't make changes to your data. Look in the output to see if it complains about errors.

No, most normal apps shouldn't have problems saving data. I've been using Amazon Appstore and it doesn't have problems putting things in the right spot. If you continue to have issues after you fix your mounting problem and the app was installed before applying the hack, try to uninstall/reinstall the app to see if it works.

Thanks for this hack. It's really great to have the full SD utilized as internal storage. But I have experience the auto rotation issue after applying the hack. According to discussions, manually stop then start sensord did the trick. Is there a more elegant solution?

Yes, maybe. I now know a possible way that might be universally applicable. I won't know whether it works until I can implement and test it. I rarely see this problem myself, but it's entirely possible some partitions take longer to mount and initialize, so a proper solution to the problem is necessary. Since you've asked, I'll get on it when I get a chuck of time I can devote to development.

 

[TrevorX5J9]

I can do that later today or tonight. In the meantime, you can try to do a quick check in TWRP's terminal (Advanced->Terminal Command->Select). Then type "e2fsck -nf /dev/block/mmcblk1p2" and Go. It won't make changes to your data. Look in the output to see if it complains about errors.

No, most normal apps shouldn't have problems saving data. I've been using Amazon Appstore and it doesn't have problems putting things in the right spot. If you continue to have issues after you fix your mounting problem and the app was installed before applying the hack, try to uninstall/reinstall the app to see if it works.


Yes, maybe. I now know a possible way that might be universally applicable. I won't know whether it works until I can implement and test it. I rarely see this problem myself, but it's entirely possible some partitions take longer to mount and initialize, so a proper solution to the problem is necessary. Since you've asked, I'll get on it when I get a chuck of time I can devote to development.

I've attached the Recovery log. I dont recall seeing any errors, but maybe you can make some sense of this. Sorry that it's all in one big mess.

 

[WarrantyVoider]

Can you get me a zip that compiles everything on my ext4 partition into a zip?

I put these zips together without thoroughly testing them. It takes time to create failure conditions for testing and I only had a little bit of time tonight. So I don't know if these would work for you when they encounter your errors. I decided to break backup and restore into two zips so that you can do necessary checks in between before overwriting stuff. Some notes:
Backup
The backup is saved to an uncompressed tar file named DataOnSD-userdata.tar at the root directory of the fat32 partition. You can look inside the tar file with 7-zip. I didn't bother compressing the backup archive. Obviously, your fat32 needs to have enough free space for the backup. The script does a file system check with automatic repair. I'm not sure if that's enough for your file system errors. If it can fix the errors, you might need to flash the zip twice (first to correct errors and second to continue with backup). If the script in the zip can't fix the errors, it's possible to force the checker e2fsck to correct errors anyway with possible data loss. The command is "e2fsck -y /dev/block/mmcblk1p2". If the damage is serious, you might still run into problems with corrupt files later even if you're able to backup and restore.
Restore
It will format the partition first before copying files back.
Edit: -restore.zip has a minor bug and is removed. See #476 for a fixed zip.

If you're able to backup and recover whatever you need, I'd suggest checking your SD card for problems. Go back a page or two and you can see Frogggy went through a lot of troubleshooting only to find out the SD was bad. It might not be the cause of your problems, but it's good to eliminate that possibility. Good luck.

 

[TrevorX5J9]

I put these zips together without thoroughly testing them. It takes time to create failure conditions for testing and I only had a little bit of time tonight. So I don't know if these would work for you when they encounter your errors. I decided to break backup and restore into two zips so that you can do necessary checks in between before overwriting stuff. Some notes:
Backup
The backup is saved to an uncompressed tar file named DataOnSD-userdata.tar at the root directory of the fat32 partition. You can look inside the tar file with 7-zip. I didn't bother compressing the backup archive. Obviously, your fat32 needs to have enough free space for the backup. The script does a file system check with automatic repair. I'm not sure if that's enough for your file system errors. If it can fix the errors, you might need to flash the zip twice (first to correct errors and second to continue with backup). If the script in the zip can't fix the errors, it's possible to force the checker e2fsck to correct errors anyway with possible data loss. The command is "e2fsck -y /dev/block/mmcblk1p2". If the damage is serious, you might still run into problems with corrupt files later even if you're able to backup and restore.
Restore
It will format the partition first before copying files back.

If you're able to backup and recover whatever you need, I'd suggest checking your SD card for problems. Go back a page or two and you can see Frogggy went through a lot of troubleshooting only to find out the SD was bad. It might not be the cause of your problems, but it's good to eliminate that possibility. Good luck.

OK, thanks. I've lost power a few times, as in a clean shutdown, but battery pull kills the hack. Have you found this to be true as well? I'm getting a Nexus 5 soon anyways, so this won't be a problem for long. I can test new stuff for this forum though after I get it.

 

[TrevorX5J9]

OK, thanks. I've lost power a few times, as in a clean shutdown, but battery pull kills the hack. Have you found this to be true as well? I'm getting a Nexus 5 soon anyways, so this won't be a problem for long. I can test new stuff for this forum though after I get it.

I'm able to mount EXT-SD after using the backup zip. It however doesn't backup. It tells me something is damaged, pertaining to a block or something of the sort. I've attached another log. When I try to boot I get a kernel crash. It sends me to a black screen with some writing at the top.

 

[catchingup]

I shut down completely and could not remount the SD-Ext. Is there a way I can back up all the apps I had without being in Android? I had a ton of apps and I don't want to try to remember everything I had. Or is there a way to remount SD-Ext?

I had problems remounting sd-ext, and I don't even have this hack installed.
I'm using stock rom and link2sd. and out of the blue, after a shutdown or reboot, the 2nd partition of the sd card would not mount unless I used MiniTool and deleted the partition and recreated it with fat32. Otherwise it would give a "no csi structure" error.

This is why I hesitate to install this hack.

What happens when the whole sd card fails? Will one be able to restore the factory rom after doing this hack?

 

[WarrantyVoider]

OK, thanks. I've lost power a few times, as in a clean shutdown, but battery pull kills the hack. Have you found this to be true as well? I'm getting a Nexus 5 soon anyways, so this won't be a problem for long. I can test new stuff for this forum though after I get it.

I can't test this for now as I'm starting to look for a permanent solution for the sensor issue mentioned before and I don't want to create additional points of failure to confuse myself. But you make a good point. The hack doesn't check for file system errors because I need it to boot quickly. Normally, if the system is not in the middle of saving data when a power loss occurs, this issue shouldn't be a big problem. Ext3/4 uses journals, so when the kernel mounts the partition at the next boot, it'll try to update and correct the journals. No data loss. But if you cut power while the system is saving data, the file system becomes corrupt. The rom maker can put a flag to make the system always check and attempt to correct errors at every boot. This happens for internal storage. I did not make the hack do this. I might have made a comment about it in one of my posts. I did try to call a script in my code for this possibility, to do a file system check or to change a mount option. I didn't expect power losses during data writes to happen often, so I didn't do more development on this. Based on your usage pattern, maybe I should consider this a bigger issue.

I'm able to mount EXT-SD after using the backup zip. It however doesn't backup. It tells me something is damaged, pertaining to a block or something of the sort. I've attached another log. When I try to boot I get a kernel crash. It sends me to a black screen with some writing at the top.

It looks like you need to run that command I mentioned ("e2fsck -y /dev/block/mmcblk1p2") to correct the errors first. This is what is run by Android's file system check at boot. So do that in TWRP's terminal and see if you're able to continue with backup afterwards.

 

[WarrantyVoider]

I had problems remounting sd-ext, and I don't even have this hack installed.
I'm using stock rom and link2sd. and out of the blue, after a shutdown or reboot, the 2nd partition of the sd card would not mount unless I used MiniTool and deleted the partition and recreated it with fat32. Otherwise it would give a "no csi structure" error.

This is why I hesitate to install this hack.

What happens when the whole sd card fails? Will one be able to restore the factory rom after doing this hack?

Well, if the SD card fails with my hack, you just power down the phone, remove the SD card, power up the phone, and go back to using the phone with its internal storage. Or you can get a new SD card, use your PC's partition imaging software to copy the backup of your old card (if you've made one) to the new card, put the new card in the phone, and continue with your newly replaced SD. My hack is designed to leave the data in internal storage intact and independent, so the internal data by itself should still be usable unless something (like using button combos to enter recovery) has destroyed it.

I can't speak about Link2SD because I have no experience with it, but the only time I've seen the "no csi structure" error being mentioned was by Frogggy, who, as it turned out, had a bad card. So it'd be good to make sure that's not the cause of any problem.

 

[TrevorX5J9]

I can't test this for now as I'm starting to look for a permanent solution for the sensor issue mentioned before and I don't want to create additional points of failure to confuse myself. But you make a good point. The hack doesn't check for file system errors because I need it to boot quickly. Normally, if the system is not in the middle of saving data when a power loss occurs, this issue shouldn't be a big problem. Ext3/4 uses journals, so when the kernel mounts the partition at the next boot, it'll try to update and correct the journals. No data loss. But if you cut power while the system is saving data, the file system becomes corrupt. The rom maker can put a flag to make the system always check and attempt to correct errors at every boot. This happens for internal storage. I did not make the hack do this. I might have made a comment about it in one of my posts. I did try to call a script in my code for this possibility, to do a file system check or to change a mount option. I didn't expect power losses during data writes to happen often, so I didn't do more development on this. Based on your usage pattern, maybe I should consider this a bigger issue.


It looks like you need to run that command I mentioned ("e2fsck -y /dev/block/mmcblk1p2") to correct the errors first. This is what is run by Android's file system check at boot. So do that in TWRP's terminal and see if you're able to continue with backup afterwards.

I ran the e2fsck and it boots now! Its a tad laggy now however.

 

[catchingup]

well, i flashed this hack finally, and it looks like it works. But it really needs a very fast card. I put in a class 4 4gb just for fun, and it runs like ass haha.

Now i'm going to try to break it by pulling out the battery and removing the sd card.

So let me get this straight...

while this hack is running, the original internal memory is completely ignored/invisible?

 

[catchingup]

damn. auto rotate is broken after the hack...

where do I reset the sensor ? I tried tapping on and off the shortcut, but no worky.

and somehow, when I rebooted, the hack no longer loaded. It went back to the internal memory.

I got the same problem as Trevor. This hack will break on slower and crappy sd cards.
fsck will temporarily fix it.

question is, will an error check flag cause a bothersome delay in faster cards?

 

[TrevorX5J9]

damn. auto rotate is broken after the hack...

where do I reset the sensor ? I tried tapping on and off the shortcut, but no worky.

and somehow, when I rebooted, the hack no longer loaded. It went back to the internal memory.

I got the same problem as Trevor. This hack will break on slower and crappy sd cards.
fsck will temporarily fix it.

question is, will an error check flag cause a bothersome delay in faster cards?

Run the backup.zip in post #460 and afterwards run e2fsck -y /dev/block/mmcblk1p2 in the terminal in TWRP. You should be able to use it after this. This will be a semi-permanent fix until WarrantyVoider makes a zip, that uses "e2fsck -y /dev/block/mmcblk1p2" at every startup to fix any errors.

 

[calvincsa]

WarrantyVoider: I need some help. I installed the DataOnSD file on an LG Realm without doing a backup. Now it's hanging on the reboot 'LG Life's Good' screen, it's been that way for several hours. I even took out the battery and my SD card to force another reboot, nothing..still hangs on the reboot screen.. I can get to the phone's recovery screen but don't have any zip files that I can push to the phone to uninstall DataOnSD. Do you have a zip that I can load to do an uninstall?

I did a manual install using the instructions you posted..

Ran these commands from an ADB shell to the phone.

su
cd /storage/external_SD
touch LGF6DataOnSD_INIT
cd DataOnSD
sh installer.sh both

 

[catchingup]

do you have to uninstall the hack if you want to use a new SD card or can you just run copy.zip again and leave everything else as is?

 

[WarrantyVoider]

Back at my PC and finally able to log in. Let me answer some old questions.

while this hack is running, the original internal memory is completely ignored/invisible?

Yes, this is by design. If you want access to internal storage, you can manually (or use a script to) mount it.

where do I reset the sensor ?
question is, will an error check flag cause a bothersome delay in faster cards?

In my experience, the sensor issue comes up the first time after booting a new rom or wiping cache. Let the rom settle down and reboot. In subsequent reboots the sensors seem to work fine for me. If what I've said is not the case for everyone, perhaps other cards take longer to initialize at boot. The sensors can be manually restarted by issuing commands "stop sensord" and then "start sensord" at a command prompt. It's possible to make the commands run at every boot. I can make a zip later for anyone who needs it, probably tomorrow or next week.

I think an error check would cause a delay, one that could cause issues (beside the sensors). So I'm not sure doing it at every boot is the best solution. Android itself can do the check because it can control what is running and what is not. My hack can't control the booting process, so I can only make it mount the partition as early as reasonably possible. If this file system error issue doesn't happen frequently, I wonder whether it's enough to make a zip so users can manually do a file system check in recovery. The other option is to have a script do a file system check then reboot only when mounting fails. There's a danger of a potential boot loop unless the script does additional checks to avoid that. What's preferable? I have other thoughts on this. Maybe I'll make a separate post once I consider all options I can think of.

do you have to uninstall the hack if you want to use a new SD card or can you just run copy.zip again and leave everything else as is?

You can just copy files. The two zips do independent things. Note that copying in terms of -copy.zip means copying from internal storage. If you want to copy from the old card to the new card, either do it on a PC or if your fat32 partition has large enough free space, try the -backup.zip and -restore.zip I've posted before.

 

[WarrantyVoider]

WarrantyVoider: I need some help. I installed the DataOnSD file on an LG Realm without doing a backup. Now it's hanging on the reboot 'LG Life's Good' screen, it's been that way for several hours. I even took out the battery and my SD card to force another reboot, nothing..still hangs on the reboot screen.. I can get to the phone's recovery screen but don't have any zip files that I can push to the phone to uninstall DataOnSD. Do you have a zip that I can load to do an uninstall?

I did a manual install using the instructions you posted..

Ran these commands from an ADB shell to the phone.

su
cd /storage/external_SD
touch LGF6DataOnSD_INIT
cd DataOnSD
sh installer.sh both

Whoa. Ouch. LG Realm comes with KitKat, doesn't it? Unfortunately, the installer script method only works for JB. KK requires setting proper security contexts which the installer script doesn't do. So far, the only method to install my hack on a KK rom is with zips in #319, using a custom recovery that supports selinux. I've never updated the installer script to support KK because the F6 doesn't have an official KK update and I've never expected anyone to need that method for stock KK.

Does Realm have custom recovery? If it does and you have it installed, you can use the -uninstall.zip in #309 to uninstall. That should allow you to boot and you can then do the uninstall step with the installer script (the one with "sh installer.sh uninstall") to clean up. If you only have stock recovery, then I can't make a zip for you. Stock recovery requires signed zips, and only LG can sign them.

If you left USB debugging on before you rebooted and you can still get an adb shell, there might be hope still. Get root access with "su". Then use "setenforce permissive" to bypass SELinux. The phone should hopefully boot at this point. Then you should be able to uninstall with the installer script. If your USB debugging is off and you can't connect with adb, then I'm sorry to say you're most likely soft-bricked. Look for an unbrick method with LG mobile support tool or something.

I made the hack for F6 and I did not put in a fail safe measure because I tested the hack on F6. If you want to do this hack on another device, you should have contacted me first and I could have helped you with fail safe measures in case of problems. Let me know and good luck.

 

[ksjd0414]

Hey warranty any luck with the rotation bug that occurs sometimes was wondering would it be possible to trigger the auto rotate file after everything has loaded ?

 

[Paydro]

Long time tester, developer and validator first time poster. Wow! To all developers and testers on this project... Awesome, I thank you! I've successfully utilized these scripts and zips on multiple handsets, several ROMs and stock systems. From idea to fully functioning!... It's more than a hobby. ##xdawha