• 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 was planning to test this release on my phone over the weekend, but the part that needs testing on the phone remains unchanged since my last test and the other part (installation and initialization scripts) was tested on my old Nook Color. So I'm uploading this early. Thanks to GameTheory's tips, I might be able to adapt my script to make a flashable zip without a lot of effort. But that will be later if and when I decide to do that.

Prerequisites:

  1. rooted phone. Root is only required to install file(s) to the /system partition.
  2. Samsung or SanDisk microSD, i.e. card with fast random reading and writing.
  3. partitioning software to make a fat32 (1st) partition and an ext4 (2nd) partition. Use software that does partition alignment for best results.
  4. familiarity with some tool that can be used to install this, e.g. file manager, adb, terminal emulator.
  5. ability to recover from failure in case something goes wrong.
Pre-installation info:
To make this work, two things are needed -- a way to copy files to the SD card when initially setting up the partition, and a way for the system to mount the partition as /data when the device boots up. If you plan to flash zips via recovery, these two things are done by two separate zips, attached to a later post. If not, use the non-flashable zip attached to this post. Inside the non-flashable zip are three files:

  • mount_data: binary file that handles mounting of the ext4 partition. This is required at every boot. Failure to install this properly is highly likely to prevent the phone from booting up.
  • init_script.sh: shell script that handles file copying from the internal storage to the external SD card. This is only used one time to copy files when setting up the SD card at boot time. Before copying, the script checks for the existence of a file named "LGF6DataOnSD_INIT" in the root directory of the first (fat32) partition on the SD card. If the SD card is already properly set up by using my previous script, this init_script.sh is not needed. It's also not needed if you decide to set up the SD card by copying files from a recovery backup archive.
  • installer.sh: shell script for installing in a console. Installation can also be done manually or by a flashable zip, so this is not required.
Installation:

  • Run installer.sh in a console: see post #252.
  • Install manually with a file manager: see post #253.
  • Use flashable zips: see post #259.
Notes:

  • If you use init_script.sh to copy files at boot time, make an empty file named "LGF6DataOnSD_INIT" in the root directory of the first partition (the fat32 partition) on the SD card. This file tells the script to copy files. It will be deleted before file copying begins.
  • If you use the script to copy files at boot time, copying will take a while during the first boot depending on how much data to copy and how fast the SD card is. After files are copied, the phone will reboot by itself. The partition mounting binary will attempt to mount the partition at the second boot. If all is well, the phone should boot up with expanded /data storage.
  • The hack uses the ext4 partition on the SD card as the /data partition. Do not remove the SD card from the phone while the phone is on.
  • As before, the /data partition in the internal storage should remain intact and hidden. To boot with the internal data, power off the phone, remove the SD, and then power on the phone. Reinsert the SD card after boot-up if you need to access data in the fat32 partition. To return to using the external ext4 partition as /data, simply reboot the phone with SD inserted.
  • It's possible to change the mount options (e.g. use the noatime flag) in a script after the partition is mounted.
  • Some third-party roms support sd-ext, which is the 2nd partition on the SD card, the same as used by this hack. It's possible this causes problems. If so, please report and let me know.
Changes from previous versions:

  • Mounting is now done by a binary instead of a shell script. This allows me to try to apply the same mount options to the external partition as those used by the internal one.
  • Mounting is done by targeting vold instead of app_process. This should load earlier during boot-up so as to avoid interfering with the sensors (accelerometer, compass, magnetic field). This should also be compatible with Xposed.
  • After file copying is complete, the phone now reboots. The partition should then be mounted on the next boot-up.
Good luck.
 

Attachments

For those who aren't scared of typing commands in a console, installer.sh is provided. You can get a console using adb shell, terminal emulator, ssh server, or some other options. Some file managers allow you to run a shell command, so they are another possibility. Adb requires installing some extra software on the PC but no additional apps on the phone. Terminal emulator or ssh requires an extra app that can be installed from the Play Store.

First get the zip into the phone. Extract the zip with a file manager. LG's file manager supports zip files, so there's no need to download an extra one if you don't have it already. On the stock rom, external SD (fat32 partition) is at /storage/external_SD and internal SD (emulated on internal storage) is at /storage/sdcard0 and also aliased as /sdcard. For example, assuming the DataOnSD directory extracted from the zip is in /storage/external_SD, you would then do the following in the console.
If you want to use init_script.sh to copy files:
Code: 
su
cd /storage/external_SD
touch LGF6DataOnSD_INIT
cd DataOnSD
sh installer.sh [I]both[/I]
exit
exit
or if you don't need init_script.sh to copy files:
Code: 
su
cd /storage/external_SD/DataOnSD
sh installer.sh [I]binary[/I]
exit
exit
The argument to use for installer.sh ("sh installer.sh both" or "sh installer.sh binary" in the above examples) depends on what you want to do. Options for installer.sh:

  • binary: install only the binary for mounting the partition.
  • script: install only the script for the initial file copying at boot time.
  • both: install both binary and script.
  • uninstall: uninstall binary and/or script.
  • extract <archive>: extract files from a recovery backup file to the external SD card.
If you already have a recovery backup, you can copy files from there instead of from the internal /data partition at boot time. For example, if a backup is saved by CWM to /stoage/external_SD/clockworkmod/backup/2014-09-12.12.34.56 and the /data partition is saved as data.ext4.tar.a, you would do:
Code: 
su
cd /storage/external_SD/DataOnSD
sh installer.sh [I]extract[/I] /storage/external_SD/clockworkmod/backup/2014-09-12.12.34.56/data.ext4.tar.a
sh installer.sh [I]binary[/I]
exit
exit
After files are installed, reboot for changes to take effect. Good luck.
 
As in previous versions, the files can be installed manually with a file manager capable of editing the /system partition.

Install the binary:

  1. Copy "mount_data" to "/system/bin".
  2. Change permissions to 755 (-rwxr-xr-x).
  3. Change ownership to uid=0 (root) and gid=2000 (shell).
  4. Rename "vold" to "vold-original" and rename "mount_data" to "vold". Make sure the names are right!
If you need to use init_script.sh to copy files, install it:

  1. In "/system/etc" create a new subdirectory "DataOnSD".
  2. Change directory permissions to 755 (drwxr-xr-x).
  3. Change directory ownership to uid=gid=0 (root) if not already.
  4. Copy "init_script.sh" to "/system/etc/DataOnSD".
  5. In "/system/etc/DataOnSD", rename "init_script.sh" to "vold".
  6. Change file permissions to 700 (-rwx------).
  7. Change file ownership to uid=gid=0 (root) if not already.
  8. At the root directory of the first (fat32) partition on the SD card, make an empty file named "LGF6DataOnSD_INIT".
After all files are installed, reboot for changes to take effect. Good luck.
 
WarrantyVoider said:
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:
Code: 
su
mkdir /cache/tempdir
mount -t ext4 /dev/block/vold/179:34 /cache/tempdir
umount /cache/tempdir
rmdir /cache/tempdir
exit
exit
"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.
Click to expand...



Using adb:
I can go through all the commands without errors. ES files explorer confirms the creation of the new directory. Still no joy.
Thanks again.
 
I used rom toolbox's root explorer to do it after using minitool to make the partition. I am definitely not an experienced user when it comes to command line or adb but I'm generally pretty good at figuring stuff out on my own. Worked like a charm. Thanks to jvene for getting the ball rolling and thanks to warranty voider for all your work making it easier for me to implement.
 
webender said:
Using adb:
I can go through all the commands without errors. ES files explorer confirms the creation of the new directory. Still no joy.
Thanks again.
Click to expand...
OK I would suggest to try to use my new version by reverting all changes (by renaming/deleting) used by the old version and then installing the binary part of the new one. Then use the attached init_debug.sh as the file copying script. That is, rename it first to init_script.sh if you use the installer.sh method, or use init_debug.sh in place of init_script.sh if you use the file manager method. Then reboot. init_debug.sh will go through the same steps as init_script.sh, except it will produce a log at /cache/DataOnSD.log.txt. After the phone is booted, move /cache/DataOnSD.log.txt to another location, say, the SD card, to take a look. For a successful run, DataOnSD.log.txt should look like this:
Code: 
no /data/.LGF6DataOnSD_DO_NOT_REMOVE ... OK
/dev/block/mmcblk1p2 ... OK
no /cache/DataOnSD ... OK
making /cache/DataOnSD ... 0
making /cache/DataOnSD/ext4 ... 0
mounting /dev/block/mmcblk1p2 at /cache/DataOnSD/ext4 ... OK
no /cache/DataOnSD/ext4/.LGF6DataOnSD_DO_NOT_REMOVE ... OK
making /cache/DataOnSD/vfat ... 0
mounting /dev/block/mmcblk1p1 at /cache/DataOnSD/vfat ... OK
/cache/DataOnSD/vfat/LGF6DataOnSD_INIT ... OK
removing /cache/DataOnSD/vfat/LGF6DataOnSD_INIT ... 0
unmounting /cache/DataOnSD/vfat ... 0
removing /cache/DataOnSD/ext4/* ... 0
removing /cache/DataOnSD/ext4/.* ... 0
copying from /data to /cache/DataOnSD/ext4 ... 0
/cache/DataOnSD/ext4/.LGF6DataOnSD_DO_NOT_REMOVE ... 0
unmounting /cache/DataOnSD/ext4 ... 0
removing /cache/DataOnSD/vfat ... 0
removing /cache/DataOnSD/ext4 ... 0
removing /cache/DataOnSD ... 0
rebooting ...
If the log file /cache/DataOnSD.log.txt is not even created, then the binary is not even invoking the script. Let me know where your log file differs and we can go from there. Later, once the thing is working and you no longer need the log, replace the script with the original init_script.sh, or you can remove the script and /system/etc/DataOnSD altogether since it's only used for file copying. Good luck.
 

Attachments

WarrantyVoider said:
OK I would suggest to try to use my new version by reverting all changes (by renaming/deleting) used by the old version and then installing the binary part of the new one. Then use the attached init_debug.sh as the file copying script. That is, rename it first to init_script.sh if you use the installer.sh method, or use init_debug.sh in place of init_script.sh if you use the file manager method. Then reboot. init_debug.sh will go through the same steps as init_script.sh, except it will produce a log at /cache/DataOnSD.log.txt. After the phone is booted, move /cache/DataOnSD.log.txt to another location, say, the SD card, to take a look. For a successful run, DataOnSD.log.txt should look like this:
Code: 
no /data/.LGF6DataOnSD_DO_NOT_REMOVE ... OK
/dev/block/mmcblk1p2 ... OK
no /cache/DataOnSD ... OK
making /cache/DataOnSD ... 0
making /cache/DataOnSD/ext4 ... 0
mounting /dev/block/mmcblk1p2 at /cache/DataOnSD/ext4 ... OK
no /cache/DataOnSD/ext4/.LGF6DataOnSD_DO_NOT_REMOVE ... OK
making /cache/DataOnSD/vfat ... 0
mounting /dev/block/mmcblk1p1 at /cache/DataOnSD/vfat ... OK
/cache/DataOnSD/vfat/LGF6DataOnSD_INIT ... OK
removing /cache/DataOnSD/vfat/LGF6DataOnSD_INIT ... 0
unmounting /cache/DataOnSD/vfat ... 0
removing /cache/DataOnSD/ext4/* ... 0
removing /cache/DataOnSD/ext4/.* ... 0
copying from /data to /cache/DataOnSD/ext4 ... 0
/cache/DataOnSD/ext4/.LGF6DataOnSD_DO_NOT_REMOVE ... 0
unmounting /cache/DataOnSD/ext4 ... 0
removing /cache/DataOnSD/vfat ... 0
removing /cache/DataOnSD/ext4 ... 0
removing /cache/DataOnSD ... 0
rebooting ...
If the log file /cache/DataOnSD.log.txt is not even created, then the binary is not even invoking the script. Let me know where your log file differs and we can go from there. Later, once the thing is working and you no longer need the log, replace the script with the original init_script.sh, or you can remove the script and /system/etc/DataOnSD altogether since it's only used for file copying. Good luck.
Click to expand...


Ok, If I understand you correctly, this new file gets renamed Vold, and placed in the "/system/etc/DataOnSD" directory.
I did that, and rebooted. Still 1.27GB on internal storage.
I checked the cache directory and found a DataOnSD folder in it. Looked in that and there was nothing, it was empty. No log file. I deleted the DataOnSD folder from the cache folder and rebooted, I wanted to see if it would be created again. This time EVERYTHING WORKED (WooHoo). My internal storage is now 15.79 GB.

Can't thank you enough, can I throw some bit (or doge) your way?
 
That was supposed to be "vold", lower case. But since it's working now, I assume you did everything right.

Normally the script cleans up after itself, but in your case, something probably aborted the script, leaving the folder in /cache. I set a check for the folder because if the folder remains, something has probably gone wrong and I don't want the script to blindly try again. I don't know what caused the script to not clean up. I think you used the "test" version (from post #220). That version loads as "debuggerd" which comes after "vold". vold is the Android component responsible for managing the SD card. So my guess is in your case, mounting happened to fail at that moment as vold was doing something with the SD card (perhaps initializing it). No one else has reported a problem, so maybe it was just a fluke due to timing. Anyway, the new version loads as "vold", which happens before the actual "vold" loads. So hopefully this version is less likely to cause conflict.

I'm glad you were able to resolve your issues. Your appreciation is enough. Normally I take what I need from the internet. Sometimes I am able to give something back. Thanks for the thought.
 
Thanks to GameTheory's tip on calling a shell script in edify, I was able to adapt my installation script without a lot of studying time. Since I was able to put this together quickly, I did not test this on my phone. As before, I tested on a CM11 Nook Color and the zips worked. I did make the necessary changes to the scripts for this phone, but if anyone tries the zips please report whether all three zips work okay.

As the names suggest, DataOnSD-install.zip puts the mounting binary in the proper spot. DataOnSD-uninstall.zip removes changes done by DataOnSD-install.zip. DataOnSD-copy.zip copies files from internal storage to the 2nd/ext4 partition on the SD card.

Notes:

  • The uninstaller does not uninstall changes made by my previous versions. Uninstallation of previous versions needs to be done manually or by advanced restore of /system. Here I'm referring to changes in /system/bin and /system/etc. The data on the SD card don't need to be recopied.
  • As a safety check, the copier does not start if the external partition contains the tag file ".LGF6DataOnSD_DO_NOT_REMOVE". So, to copy over existing files, remove the tag file first.
  • The copier removes all files in the external partition (2nd/ext4) before it starts copying. It neither formats nor checks for errors. If your SD card has errors, please fix them in a PC to avoid problems with your data on the phone.
  • The copier does not show progress. I don't know how to do it with a shell script in edify. And I don't think busybox's tar has the checkpoint option either. As expected, copying will take a while depending on the amount of data and the speed of the SD card.
  • While my binary and other scripts are platform independent, the flashable zips are not. The partition locations are specific to this phone (and maybe other similar models).

Previously, crm701 reported this hack not working with KK without sdfix. That was with a test build (post #220). If someone tries this release with a KK rom, please let me know if it's still a problem. With some custom roms supporting sd-ext as external storage and KK placing restrictions on use of external storage, I wonder if that combination is the cause of the issue. If so, maybe using the 3rd partition instead of the 2nd could work around the issue.

Thanks in advance for any feedback, whichever installation method you use. Good luck.
Edit: for TWRP, use zips in #309.
 

Attachments

Thanks for the files and the instructions WarrantyVoider!
Just ran it on on 4 F6's here and all are working fine. Used the console method via a terminal emulator. Copy times varied. for Some it was quite awhile, so patience is key. At first I thought it wasn't working because the first phone was pretty crammed full... but I left it sit (plugged in) and went to watched a movie. Came back and it was done. The others were more barebones and averaged around 3-4min on the initial reboot screen before rebooting and working.

Thanks again!
 
WarrantyVoider said:
  • As a safety check, the copier does not start if the external partition contains the tag file ".LGF6DataOnSD_DO_NOT_REMOVE". So, to copy over existing files, remove the tag file first.
Click to expand...
Sorry but how do you go about deleting a file from the ext partition?

I've got a shiny new F6 and a 64GB sd card and am stumped by that step.

Also, what would you suggest would be good sizes for the two partitions given a 64GB card?

Thanks!

*Edit - I went ahead and did it the "manual" way per post #253 and it is working like a charm. Thank you very much for this.
 
Glad you got it to work. I'm going to answer your questions in detail anyway in case someone else wonders about the same thing.

If you start with a blank SD card, you wouldn't have that file and you wouldn't need to delete it. The tag file ".LGF6DataOnSD_DO_NOT_REMOVE" is normally put in the root directory of the 2nd/ext4 partition of the SD card after files from internal storage are copied there. This is done by the script automatically. Its purpose is to mark the partition and to tell the mounter binary that this partition contains Android files (wouldn't want to just mount any ext4 partition and hand the partition over to Android blindly). The note I made was in case a user wants to start over and force the script to copy files from internal storage to the SD card again. Under normal circumstances that external partition would be mounted as /data, so to delete that file a user would delete "/data/.LGF6DataOnSD_DO_NOT_REMOVE" on the phone. If for some reason the partition can't be mounted (so the tag file is irrelevant), just put the SD card in a PC and format the partition (since the user is looking to start over anyway).

If you use my copier script to copy files at boot time, there's a need to manually create a trigger file "LGF6DataOnSD_INIT" in the root directory of the 1st/fat32 partition on the SD card. There should be no problem making that file whether on Windows, Mac, Linux, or the phone itself. I require this manual step so that the script doesn't modify the 2nd/ext4 partition if a user unknowingly insert another SD card into the phone. There's no need for this trigger file if a user is using the custom recovery to flash the zip file. I assume the user using recovery to flash anything is not doing things by accident.

As for how to partition, that's up to you. Obviously the ext4 partition to be mounted as /data should be larger than the 1.27 GB or whatever of the internal storage used by the phone. Normally, Android uses the fat32 partition as media storage (pictures, music, movies, etc.). The phone mounts that partition at /storage/external_SD. Android can also use that partition for apps when a user chooses to move apps to SD. Apps can also choose to store their data there with the right permission. They use the media storage in that manner because typically internal storage is limited. Android put basically most persistent user data in various directories under /data, including user settings, user apps, app settings, app data, dalvik cache, etc. After this hack is activated, the entire external ext4 partition is mounted at /data. Android normally makes an emulated SD storage in internal storage by using /data/media (remember Google's own phones have no SD card). On the F6, that emulated SD is also accessible at /storage/sdcard0. In other words, with this hack, files at /storage/external_SD are physically stored in the fat32 partition on the SD card and files at /storage/sdcard0 would be physically stored in the ext4 partition on the SD card (without the hack, files at /storage/sdcard0 are in internal storage). For example, in LG's camera and camcorder apps, there's a setting to change storage location. So with this hack, one choice goes to the fat32 partition and the other goes to the ext4 partition. Since the part of internal storage originally used as /data is no longer accessible with this hack (without manually making them accessible), new files are not physically stored there any more.

So how should one allocate space on the SD card? In a normal use case, a user stores his/her media files on the external SD card (using fat32) and he/she can put that SD card in other devices and have access to his/her files. So in this use case, a large fat32 partition makes sense. On the other hand, you can have a large ext4 partition to store all data. If Android or some apps insist on storing files to "SD", you can make them store in the emulated SD, which also resides in the ext4 partition. The drawback is ext4 is not universally recognized like fat32, so it's harder to get your "media" files out of the phone without the phone (unless you use an OS where ext4 is well supported). In the end, how you want to use the space is up to you. With access to a Linux system (live CD, say), there's also the possibility of resizing partitions later.

I hope everything is clear. Good luck.
 
Thank you for taking the time to go through all that!

I ended up allocating 4.5GB to the ext4 partition and the rest to the FAT32 partition.
The phone will be used by my daughter and, truth be told, she probably doesn't even need more "internal" memory but I couldn't resist the chance to do something new. I think next time these phones are available for $69 I'll get a couple more to have around or give to my boys.

Again, thank you!
 
hello im learning more about cell phones . is there a manual for the hidden menu options on the LGMS500/ LG optimus F6 . i have unlocked and rooted it .

also im trying to learn the codes for this device if there is a sheet with the codes that would be great. i have accessed the hidden menu but i need knowledge about the options in there also pls.

also having trouble enabling the usb host support option .
is there any way i can get a detailed answer on how to do this ?

thank you all in advance . im trying to learn how to become a programmer / developer .

carrier : MetroPCS
 
Thank you much GameTheory
i know how to access the hidden menu already lol
what i mean is there as manual or cheat cheat sheet showing what all the things inside stand for and control ect

sorta like a admin manual to adjust the setting for optimal performance and frequency extending and so forth .

if not i thank you anyways . I am new here and look at forums all the time but never joined any . but im glad i joined here it seems like a great place to gain knowledge about android OS and certain phones :)

also i see you are a rom developer ? im using Android 4.1.2 version . is there a better one i can put in it ?
 
i tried the dataonsd install zip in trwp recovery and think i broke it.
dataonsd install showed successful so i went ahead and tried the copy zip afterwards and it failed.
i tried to back out the changes with the uninstall zip but that failed too.

im not sure what to do. can i do a recovery? my internal storage shows zero

thanks

WarrantyVoider said:
Thanks to GameTheory's tip on calling a shell script in edify, I was able to adapt my installation script without a lot of studying time. Since I was able to put this together quickly, I did not test this on my phone. As before, I tested on a CM11 Nook Color and the zips worked. I did make the necessary changes to the scripts for this phone, but if anyone tries the zips please report whether all three zips work okay.

As the names suggest, DataOnSD-install.zip puts the mounting binary in the proper spot. DataOnSD-uninstall.zip removes changes done by DataOnSD-install.zip. DataOnSD-copy.zip copies files from internal storage to the 2nd/ext4 partition on the SD card.

Notes:

  • The uninstaller does not uninstall changes made by my previous versions. Uninstallation of previous versions needs to be done manually or by advanced restore of /system. Here I'm referring to changes in /system/bin and /system/etc. The data on the SD card don't need to be recopied.
  • As a safety check, the copier does not start if the external partition contains the tag file ".LGF6DataOnSD_DO_NOT_REMOVE". So, to copy over existing files, remove the tag file first.
  • The copier removes all files in the external partition (2nd/ext4) before it starts copying. It neither formats nor checks for errors. If your SD card has errors, please fix them in a PC to avoid problems with your data on the phone.
  • The copier does not show progress. I don't know how to do it with a shell script in edify. And I don't think busybox's tar has the checkpoint option either. As expected, copying will take a while depending on the amount of data and the speed of the SD card.
  • While my binary and other scripts are platform independent, the flashable zips are not. The partition locations are specific to this phone (and maybe other similar models).

Previously, crm701 reported this hack not working with KK without sdfix. That was with a test build (post #220). If someone tries this release with a KK rom, please let me know if it's still a problem. With some custom roms supporting sd-ext as external storage and KK placing restrictions on use of external storage, I wonder if that combination is the cause of the issue. If so, maybe using the 3rd partition instead of the 2nd could work around the issue.

Thanks in advance for any feedback, whichever installation method you use. Good luck.
Click to expand...
 
I couldn't get the zip to work either.

The phone I was flashing was new so I just re-flashed the ROM. The only way to do that is to boot into recovery which will wipe your data. Hopefully you are in the same situation with a newly flashed phone. Once you re-flash the ROM download the files at the end of post #251 and follow the steps in post #253.
 
how can i re-install the rom?

i can not restore because it can not find /data....

update.... hot the system to restore. need to try again
 
stigmax2 said:
i tried the dataonsd install zip in trwp recovery and think i broke it.
dataonsd install showed successful so i went ahead and tried the copy zip afterwards and it failed.
i tried to back out the changes with the uninstall zip but that failed too.

im not sure what to do. can i do a recovery? my internal storage shows zero

thanks
Click to expand...
When you did the copy zip, did you see it return with a printed "Failed." or did you or TWRP somehow interrupt it prematurely? If you saw "Failed.", the script inside the zip should have cleaned up after itself. In either case, the zip should not make any changes to the internal /data partition, which would be mounted read-only. The directories created in the process are made under /tmp, which should be gone when you reboot. So when you reboot back into recovery, you should be able to run any of the three zips.

With just the binary installed (after running the install zip), you should be able to boot the rom still. If for some reason booting fails even though the install zip said "Done.", you should be able to get back into recovery and uninstall. If the uninstall zip for some reason would not run properly, you can do an advanced restore of /system only. Since the internal /data partition should never have been modified, the phone should return to its previous state.

So has anyone successfully used the flashable zips? I've never tested them on the phone with the versions of CWM or TWRP for this phone. Like I said, my testing was done with CWM 6.0.4.8 on a Nook Color. I did check the parameters (physical partition locations of /system and /data) used in the zips are for this phone (same ones used by hroark13's and GameTheory's roms), so in theory they should work. If no one has gotten the flashable zips to work, I would need to figure out where the incompatibility is. So anyone who's tried the flashable zips, please report whether they work for you. So far there are two reports of failure, but without more info it's hard to determine where the problem is.

For anyone reading who is considering doing this, one note about the file copying. You can get an estimate of the time it might take. You know how full the internal /data is. Let's say it's filled to 1000 MB. You can do a benchmark of your SD card to see its random writing performance (random 4k write with e.g. CrystalDiskMark). Let's say the card can do random 4k write at 1 MB/s. File copying won't be all 4k writes. Larger files will be copied at a much faster rate, closer to the sequential writing speed, so 1 MB/s is the worst case scenario. But in the worst case, you're looking at over 16 minutes. In reality, it won't take that long, but keep in mind that upwards of several minutes is a possibility.
 
goitalone, did you do the flashable zip using TWRP also? If I remember correctly, you tried the version at post #220 and that one worked? I want to figure out whether this hack causes a conflict with KK roms available for this phone and whether the flashable zip causes a conflict with recoveries available for this phone.
 
i'm using stock rom and when i used TWRP to install the first zip it was successful without any error message. when i went to try the copy, that failed. did i need to reboot first before trying the copy zip? i also tried the uninstall zip and that failed as well.


WarrantyVoider said:
When you did the copy zip, did you see it return with a printed "Failed." or did you or TWRP somehow interrupt it prematurely? If you saw "Failed.", the script inside the zip should have cleaned up after itself. In either case, the zip should not make any changes to the internal /data partition, which would be mounted read-only. The directories created in the process are made under /tmp, which should be gone when you reboot. So when you reboot back into recovery, you should be able to run any of the three zips.

With just the binary installed (after running the install zip), you should be able to boot the rom still. If for some reason booting fails even though the install zip said "Done.", you should be able to get back into recovery and uninstall. If the uninstall zip for some reason would not run properly, you can do an advanced restore of /system only. Since the internal /data partition should never have been modified, the phone should return to its previous state.

So has anyone successfully used the flashable zips? I've never tested them on the phone with the versions of CWM or TWRP for this phone. Like I said, my testing was done with CWM 6.0.4.8 on a Nook Color. I did check the parameters (physical partition locations of /system and /data) used in the zips are for this phone (same ones used by hroark13's and GameTheory's roms), so in theory they should work. If no one has gotten the flashable zips to work, I would need to figure out where the incompatibility is. So anyone who's tried the flashable zips, please report whether they work for you. So far there are two reports of failure, but without more info it's hard to determine where the problem is.

For anyone reading who is considering doing this, one note about the file copying. You can get an estimate of the time it might take. You know how full the internal /data is. Let's say it's filled to 1000 MB. You can do a benchmark of your SD card to see its random writing performance (random 4k write with e.g. CrystalDiskMark). Let's say the card can do random 4k write at 1 MB/s. File copying won't be all 4k writes. Larger files will be copied at a much faster rate, closer to the sequential writing speed, so 1 MB/s is the worst case scenario. But in the worst case, you're looking at over 16 minutes. In reality, it won't take that long, but keep in mind that upwards of several minutes is a possibility.
Click to expand...
 
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.

Edit: TWRP supports sd-ext, so maybe that could be used to backup the external ext4 partition.

Does anyone know what versions of TWRP and CWM are used for this phone?
 
You must log in or register to reply here.
Back
Top Bottom