I'm wanting to write some edify code to wipe data, dalvik and cache. I think i've got the right idea for data and dalvik, but I'm not certain on cache.
Here's my following code for data and dalvik wipe. Is this the standard for wiping data? Do i need to delete everything from data and not just in the app directory?
Code:
mount("ext4", "EMMC", "/dev/block/mmcblk0p37", "/data");
delete_recursive("/data/app");
delete_recursive("/data/dalvik-cache");
unmount("/data");
Also, i'm going to assume i can mount the cache, but i didn't know the block to mount it.
Any help would be greatly appreciated.
Edit: Thanks to this post, i was able to figure out the block i needed for cache. I would still like to know if this is the proper way of "wiping" the data, cache or dalvik-cache. Should i be formatting instead?
I'm not very familiar with edify, so I may be wrong, however I'll try to help by pointing some issues you may find when investigating this subject.
First look on the code above ... In general, it seems to be ok. Btw I can see that you are not trying to wipe /data but /data/app only...
To fully wipe data partition you shall run delete_recursive("/data"); and after that no additional dalvik-cache wipe will be necessary, as it lies on data so it will be deleted along with it.
Instead of recursive files deletion you may try format command or even some variation of mke2fs... it will create completely new filesystem instead of performing large amounts of delete i/o operations on the old one, along with not deleting filesystem stats, etc.
Hovewer, you have to know that running delete_recursive("/data"); or even format("/data") or something similiar seems to be not the best idea - be aware that real location of files from /sdcard is /data/media which is then bound with FUSE driver to /sdcard during the boot, so it acts like an sd memory BUT it still lies along with all your "regular" data files on /data partition. Doing such a recursive deletion will result in losing not only files from /data, but also from /data/media = /sdcard, which is probably not the thing we want to happen ;]
You may want to figure out how to avoid this, as you may lose the data which you didn't want to lose (for example: nandroid backups, if you keep them on /sdcard)! I personally don't know the exact solution and don't have time and possibility to figure it out at the moment
Also, please be aware that Android has the "wipe" command built-in, put "wipe" in terminal emulator to find out the syntax. I am not sure but it may avoid the sdcard when wiping automatically, as it is native android tool and it may be adapted for Android's file stricture.
Last but not least, you can find out device-partition pairs by inputting such a command via terminal or adb shell (seeking for a device name which is mounted as /cache in example below):
Code:
cat /proc/mounts | grep cache
esgie said:
I'm not very familiar with edify, so I may be wrong, however I'll try to help by pointing some issues you may find when investigating this subject.
First look on the code above ... In general, it seems to be ok. Btw I can see that you are not trying to wipe /data but /data/app only...
To fully wipe data partition you shall run delete_recursive("/data"); and after that no additional dalvik-cache wipe will be necessary, as it lies on data so it will be deleted along with it.
Instead of recursive files deletion you may try format command or even some variation of mke2fs... it will create completely new filesystem instead of performing large amounts of delete i/o operations on the old one, along with not deleting filesystem stats, etc.
Hovewer, you have to know that running delete_recursive("/data"); or even format("/data") or something similiar seems to be not the best idea - be aware that real location of files from /sdcard is /data/media which is then bound with FUSE driver to /sdcard during the boot, so it acts like an sd memory BUT it still lies along with all your "regular" data files on /data partition. Doing such a recursive deletion will result in losing not only files from /data, but also from /data/media = /sdcard, which is probably not the thing we want to happen ;]
You may want to figure out how to avoid this, as you may lose the data which you didn't want to lose (for example: nandroid backups, if you keep them on /sdcard)! I personally don't know the exact solution and don't have time and possibility to figure it out at the moment
Also, please be aware that Android has the "wipe" command built-in, put "wipe" in terminal emulator to find out the syntax. I am not sure but it may avoid the sdcard when wiping automatically, as it is native android tool and it may be adapted for Android's file stricture.
Last but not least, you can find out device-partition pairs by inputting such a command via terminal or adb shell (seeking for a device name which is mounted as /cache in example below):
Code:
cat /proc/mounts | grep cache
Click to expand...
Click to collapse
Thanks a bunch! I didn't even think about the sdcard getting wiped...
=Death259;48255914]Thanks a bunch! I didn't even think about the sdcard getting wiped...
Click to expand...
Click to collapse
What you can do is extract and call a bash script and recursively remove all content from /data excliding the media folder (sdcard)
Also dalvik is in /data already so wiping data automatically wipes dalvik
Related
When ever I do a nandroid backup i partially backup my system as my "apps" "apps-private" & dalvik-cache" folders are on my /system/sd partition ( /dev/block/mmcblk0p2 ).
To fully backup i need to somehow backup my "/system/sd" along with my nandroid backup.
Now If i copy all the stuff to "/sdcard" I loose all my file permissions, so its not an option.
One option is to use "dd" command which will say something like this
Code:
dd if=/dev/block/mmcblk0p2 of=/sdcard/nandroid/SDBACKUP.img
( the final-full script will generate today's date-time for name etc. etc. )
what will be achieved with this, is that it will create an exact binary copy of the EXT3 partition maintaining all the permissions etc. in that point of time. with same "dd" command you can re flash this img file back to your EXT3 partition.
It all sounds good, but there is a problem and I need someone to help me out here. currently the "dd" which is available in busybox is crippled as it can only handle File->File (byte wise) copy and No Partition -> File or vice-versa .
If anyone out there has a proper build environment ready for building binaries for android( I dont have it set up ) and can build full "dd", I'll be really thankful. you can find dd in GNU Fileutils(If you can build stuff for linux you know where i am pointing you).
If someone has any other ideas to achieve this please comment.
you can do that with adb.
Adb pull /system/sd/* c:\
Or use the ADB File explorer
Then just adb push it back when you need it
why don't you mount /system/sd and /sdcard from recovery and do 'cd /system/sd && tar czpf /sdcard/ext-backup/`date +%F-%I.%M`.tar.gz *'. This backup will be much smaller than your 'dd' backup.
eventually, its needs to be built into nandroid backup.
Seems lovely!
What are the commands to restore this backup (devsk)?
devsk said:
why don't you mount /system/sd and /sdcard from recovery and do 'cd /system/sd && tar czpf /sdcard/ext-backup/`date +%F-%I.%M`.tar.gz *'. This backup will be much smaller than your 'dd' backup.
eventually, its needs to be built into nandroid backup.
Click to expand...
Click to collapse
Any reason we couldn't do this with a command from BetterTerminal or a script from GScript? Looks like you could backup without remounting, but would need to remount r/w to do a similar script to restore from the backup.
Could someone with some programming chops (devsk??) type out the necessary commands for the doing backup and restore from terminal? I would do it, but my skill with linux is not up to it.
Backup for Root Users does this really well. If you choose to, it will back up both the apks and the data associated with the applications so you don't lose any save game progress or preferences and will save it on Fat32 partition of your sdcard so you can just transfer it to your computer for a more secure backup.
Zappza said:
Seems lovely!
What are the commands to restore this backup (devsk)?
Click to expand...
Click to collapse
Code:
cd /system/sd && tar xzpf /sdcard/ext-backup/<gzip_file_to_restore>
You need to change <gzip_file_to_restore> to the actual file name which you want to restore e.g. if you want to restore 2009-07-23-06.04.tar.gz to your ext partition, you would do:
Code:
cd /system/sd && tar xzpf /sdcard/ext-backup/2009-07-23-06.04.tar.gz
This will restore the ext partition backup I took at 6:04pm on 23rd Jul. This code assumes that you have your ext partition mounted on /system/sd and fat32 partition mounted on /sdcard already. If not, you need to say 'mount /sdcard' and 'mount /system/sd' before the above.
Remember that the safest way to backup and restore filesystems is through the recovery console. So, I do a nandroid backup followed by the above tar czpf ('c' is for create) command to backup. This puts my complete backup on the first fat32 partition. Then, I do the reverse (restore from nandroid backup, and fire the above xzpf ('x' is for extract) command to restore my ext partition) to restore a ROM to its working condition.
Thanks this does seem a far better approach . I'll try it and update
My_Name_Is_Neo said:
Thanks this does seem a far better approach . I'll try it and update
Click to expand...
Click to collapse
It is dog slow though! All because of the CPU not able to handle the compression from gzip. It compresses nicely and produces a smaller gzip file but takes a while.
I like where this thread is headed...
subscribed, can't wait to see where this goes.
devsk said:
It is dog slow though! All because of the CPU not able to handle the compression from gzip. It compresses nicely and produces a smaller gzip file but takes a while.
Click to expand...
Click to collapse
I noticed! At first I thought that it did not work at all. Is it possible to disable the compression?
I think removing the "z" from the command and naming the file .tar instead of .tar.gz will not compress it.
My_Name_Is_Neo said:
I think removing the "z" from the command and naming the file .tar instead of .tar.gz will not compress it.
Click to expand...
Click to collapse
that's right. Backup will be faster but bigger. I am looking at another command to see if we can pass a -fast option to gzip.
devsk said:
Code:
cd /system/sd && tar xzpf /sdcard/ext-backup/<gzip_file_to_restore>
You need to change <gzip_file_to_restore> to the actual file name which you want to restore e.g. if you want to restore 2009-07-23-06.04.tar.gz to your ext partition, you would do:
Code:
cd /system/sd && tar xzpf /sdcard/ext-backup/2009-07-23-06.04.tar.gz
This will restore the ext partition backup I took at 6:04pm on 23rd Jul. This code assumes that you have your ext partition mounted on /system/sd and fat32 partition mounted on /sdcard already. If not, you need to say 'mount /sdcard' and 'mount /system/sd' before the above.
Remember that the safest way to backup and restore filesystems is through the recovery console. So, I do a nandroid backup followed by the above tar czpf ('c' is for create) command to backup. This puts my complete backup on the first fat32 partition. Then, I do the reverse (restore from nandroid backup, and fire the above xzpf ('x' is for extract) command to restore my ext partition) to restore a ROM to its working condition.
Click to expand...
Click to collapse
Okay, so I saw this thread and decided to repartition my card to resize my ext3 partition to a smaller size and add a swap partition just in case I want to use it in the future. I've been wanting to do this for a while, but have been putting it off because I didn't want to lose all my data on my ext3. So I followed your instructions and I kept getting 'tar: empty archive' errors no matter what I tried (czpf .tar.gz, cpf .tar, cd /system/sd then tar cpf, creating the backup folder beforehand, etc.). So I did some googling and this is what worked for me. This is just an FYI for others who are having trouble with this as I was.
To backup:
mount /system/sd
mount /sdcard
tar cpf /sdcard/ext-backup/backup.tar system/sd
No compression, so it was really quick. It made a ~180mb file in a few seconds. So I opened up the resulting file in winrar and it kept the folder structure and everything e.g. system->sd->contents of sd folder. So I'm guessing to restore, the command would be like this:
mount /system/sd
mount /sdcard
tar xpf /sdcard/ext-backup/backup.tar
I say I'm guessing because I ended up not needing to restore it. I was able to preserve the data on my ext3 partition after the resize. I did however end up having to format my fat32 partition, but I did a backup on that too.
BTW, I'm on Cyanogen's modded recovery.
you got "empty tar" error because you 1. Either forgot to mount /system/sd OR 2. you forgot the '*' towards the end of the cpf command.
You 'tar xpf ..." command is correct for the 'tar cpf ...' command that you typed above.
Note that you need to be in the right directory while creating the backup and restoring it.
test this last commands and it work well, forgot to mention that was made it thru recovery console, hitting the commands with my PC in CMD.
Thanks for the ideas and discussion in this thread... been wanting to set up something like this for a long time but was being lazy.
Have you guys had any luck with the '--exclude' switch on the tar binary that we've got (busybox link, looks like... at least with the Cyan mod that I'm using)?
I haven't done enough testing but it seems like the '--exclude' switch doesn't do anything/is ignored... I was trying to do something like this to ignore the dalvik-cache directory from my backups but it still includes it in the .tar.gz file:
Code:
cd /system/sd && tar czpf /sdcard/backup/systemsd_$NOW.tar.gz --exclude='/system/sd/dalvik-cache' *
(I am setting $NOW to the datestamp string I want with "NOW=`date +"%Y%m%d-%H%M"`" in my shell script)
I haven't tried the '-X' switch with an exclusion file list yet so I might give that a shot but was just trying to see if others played around some more with any of this stuff, etc.
rub1k said:
Thanks for the ideas and discussion in this thread... been wanting to set up something like this for a long time but was being lazy.
Have you guys had any luck with the '--exclude' switch on the tar binary that we've got (busybox link, looks like... at least with the Cyan mod that I'm using)?
I haven't done enough testing but it seems like the '--exclude' switch doesn't do anything/is ignored... I was trying to do something like this to ignore the dalvik-cache directory from my backups but it still includes it in the .tar.gz file:
Code:
cd /system/sd && tar czpf /sdcard/backup/systemsd_$NOW.tar.gz --exclude='/system/sd/dalvik-cache' *
(I am setting $NOW to the datestamp string I want with "NOW=`date +"%Y%m%d-%H%M"`" in my shell script)
I haven't tried the '-X' switch with an exclusion file list yet so I might give that a shot but was just trying to see if others played around some more with any of this stuff, etc.
Click to expand...
Click to collapse
You might be interested in this thread:
http://forum.xda-developers.com/showpost.php?p=4209412
Thanks much for that... nice job with the script.
I guess I need to do a bit more reading though and figure out if backing up the dalvik-cache is actually necessary (doesn't it get (re-)built at first bootup with a new ROM?)... because if not, I'd like to not bother backing it up (and make the backup smaller and quicker in the process).
rub1k said:
Thanks much for that... nice job with the script.
I guess I need to do a bit more reading though and figure out if backing up the dalvik-cache is actually necessary (doesn't it get (re-)built at first bootup with a new ROM?)... because if not, I'd like to not bother backing it up (and make the backup smaller and quicker in the process).
Click to expand...
Click to collapse
I think you have a point. But we may be looking at a very small %age of disk space compared to the overall backup of the phone. Keep in mind that the nandroid backups are not gzip'ed (because it take them forever to do), so there are bigger savings to be had than just saving on the dalvik cache. For example, data.img in nandroid backup can gzipped to 4MB compare to 12MB.
I have a few questions related to smartphones. Searched and couldn't find anything like I was looking for.
I am vary familiar with PC's and would like to compare in my mind where things reside on a smartphone.
On a smartphone, where does the operating system reside? Is it in the ROM(I know is Read-only-memory)? Or is the ROM similar to the BIOS on a PC and contains the basic instructions to interact with the between software and hardware?
Just having a little problem comparing what is where.
i think its in ROM memory, but there is additonal memory for system/internal apps too.
In my XPlay I have 512mb+400mb.
There isn't anyth like bios but u can flash recovery
From what I know, everything is stored in NAND flash. There is a boot partition which contains the kernel, and a system partition which contains the OS (firmware) itself. Those essentially double as ROM. Technically it's not read-only memory but its contents won't change unless you root your phone and change them yourself.
Also, I don't think an embedded system such as a smartphone would benefit much from having a full-blown BIOS. Hardware initialization, I believe, is done during the boot sequence, not prior to it. Look up "Board support package".
If someone knows more about this subject, feel free to correct me and provide additional information.
I'm quite interested in embedded systems myself, but only have had the opportunity to work with simple microcontrollers.
So basically everything inside is more like a solid state hard drive? Just partitioned for different tasks? I figured the rom was not really a rom. Usually you have to build an interface and cut traces on the board in order to flash a rom.
Are we able to browse the rom? Like with root explorer? Or is that partition "hidden"?
Also, what are the caches for. I am familiar with caches like in ie. But the davlik seems to be persistent. Thanks for the answers so far guys.
Usually when you load a new os, the cache is usually wiped. But with phones, a step is to wipe the caches. Confusing when trying to grasp with the knowledge I have of older electronics. Lol I just called pc's old.
I wish there was some guide already making the comparison but Google can't find it!
Yes, you can browse those partitions in Root Explorer. It will allow you to mount even the /system partition r/w so you can modify the contents.
As for the caches, I'm not sure what exactly gets stored on the /cache partition, but the reason you have to wipe/format it when you flash a new ROM, is because it's separate from the /system partition. That's probably what you meant by "persistent".
It's actually convenient when you think about it. If you want to flash an update of the ROM you are currently using, you probably don't want the cache to be wiped as well. On the other hand, sometimes you may want to wipe just the cache. Same goes for the /data partition, when you are doing a factory reset, for example.
I would also assume that since /system partition normally isn't written to, and /cache and /data are, keeping them separate helps in case the filesystem gets corrupted.
Now you are confusing me.
/system is a folder. Not a partition. It may be in a folder but it is not a partition afaik. There is a root partition which is basically everything you see when you open file explorer that includes the system folder, then any other partitions are mounted under /mnt. Those include /asec /obb /sdcard and /secure. (using what I see in my kf for this example)
So when we flash the "rom" we are really only flashing one partition of a rom that has several partitions. That would be the basic partition containing the system files? We are not flashing the entire rom. Does that sound correct?
In Linux partitions are mounted under directories. So /cache, /data and /system are really just mount points for those partitions. It's understandable that this would confuse you if you haven't had experience with Linux. Windows handles partitions somewhat differently.
When you flash a ROM, you are actually flashing only the system partition. Kernel is flashed to the boot partition, and others (cache, data, sdcard, etc.) are used by the system itself.
DeVelox said:
In Linux partitions are mounted under directories. So /cache, /data and /system are really just mount points for those partitions. It's understandable that this would confuse you if you haven't had experience with Linux. Windows handles partitions somewhat differently.
When you flash a ROM, you are actually flashing only the system partition. Kernel is flashed to the boot partition, and others (cache, data, sdcard, etc.) are used by the system itself.
Click to expand...
Click to collapse
Yes i have a little knowledge, albeit very little, of Linux. But if it is an actual partition it will also show under /mnt after you mount it, correct? That is how you tell if it is an actual partition. I do realize that the others partitions like /sdcard are being automatically mounted. And you can browse them through the /sdcard folder or /mnt/scard.
/cache is no where under /mnt or any subs of any partitions that are mounted so that tells me the /cache folder that shows under root is actually only a folder. Well there is a cache subdirectory underone of the partitions under /mnt but the contents are different than the contents of the cache folder running off of root.
Sorry bout all of the questions. I have done a lot to my phone and kf. I just like to know what it's being affected when when I do what I am doing. And why I am doing what I am doing.
Like i said before, the term rom confused me as when i was flashing roms on other devices I was having to build a hardware interface and cut traces on the board, sometimes install jumpers across traces. All of that to flash "roms". This was on xboxes and satellite receivers mainly.
No, /mnt is just a directory like any other. In fact, it is rarely used for mounting purposes in modern Linux distributions.
When you open /cache, /data or /system in Root Explorer, please check the "x MB used, y MB free" line at the top. You will notice that it shows different values for each of those directories. That should be enough to convince you that they are indeed partitions, and not ordinary directories.
You will also notice that, for example, /etc shows the same used/free info as /system. That is because /etc is actually a symlink to /system/etc.
You should read up more on Linux, or just take my word for it.
P.S. If you have Terminal Emulator app installed, try the "df -h" command. It will list all the partitions, their mount points, and used/free space info. Mind you, only entries starting with "/dev/block" are actual partitions, tmpfs is something else.
I see said the blind man. I also found this as an example of the partitions on my kf.
Scrolling down I see all of the active partitions.
http://kindlefirenews.org/expand-app-storage-on-the-kindle-fire/
Thanks for the explanations. But I will say that ROM it's a misnomer!
Open a console on your android and type "df".
You will see the partitions.
Here's the scenario: say you try out encryption on a ROM, either because your employer makes you or because you want the extra security. What happens when you can root your phone, like we can (easily) with the S3, and you want to flash a different ROM? The problem you will find yourself in very quickly is that you cannot do a successful wipe. You can't format an encrypted /data in CWM or any other recovery. If you cannot format /data, you can't flash a ROM - it fails, because /data is encrypted, and it cannot proceed. It turns out none of the recoveries can format an encrypted /data. You also cannot reverse encryption once you've done it. You're stuck, all because you flipped the switch on encryption.
I found myself in this problem as others have in many other forums (like this one for the GNex) (and another one, more detailed).
I also tried, admittedly somewhat out of desperation, the soft-brick instructions here. That didn't work because Nand Erase All fails. You can flash on top, and luckily you can use your same password to decrypt your /data (which I did) but you're still not going to have a clean ROM. Dirty flashes = lots of problems down the road.
I finally found a simple way to do this and wanted to save anyone else the trouble of digging. You can do it using CWM and adb and a few commands. Credit goes Shawn Webb's blog and utkanos on FreeNode's irc at #cyanogenmod.
Here is how to do this on our Verizon S3:
In CWM, wipe cache
adb shell
mke2fs -t ext4 /dev/block/mmcblk0p15
mount /data
mount /dev/block/mmcblk1p1 /data/media
If adb doesn't work in CWM, reboot recovery. You might need to create /data/media after mounting /data in order to do the last step, which I opted not to do. I hope this saves someone else a few hours of frustration, and I also hope that someday one of our recoveries can handle formatting encrypted data. Until then... I'm just not using encryption, period. There already is a lot of documentation against it, and this is one more reason in my book.
Thanks for this. I fell into the same scenario yesterday but after reading a lot of helpful posts from people like yourself I have managed to solve the issue. Basically I found two ways of doing it, one is as you have suggested and the other is by just replacing the custom recovery with the stock recovery. The SGS3 toolkit available on XDA made the 2nd option just slightly simpler for me and by spending less than 10 mins (excluding time for backups and downloads) the issue was resolved.
Just to share this option to save others from the headache of looking for a solution:
1) Get the toolkit
2) Install drivers as recommended and follow instructions to choose the build, or closest build, for your S3
3) Restore stock recovery with toolkit via ODIN (follow instructions)
4) After rebooting, go into Android and reset to factory settings, this would bring you to the stock recovery and wipe
5) Restore custom recovery with toolkit via ODIN (follow instructions)
6) Restore your system (luckily for me I had a nandroid backup before I encrypted)
Note: I did "lose" my internal sdcard files (pictures/documents). But I backed that up on my external sdcard before starting the process. My sdcard was not encrypted.
kitleon said:
Thanks for this. I fell into the same scenario yesterday but after reading a lot of helpful posts from people like yourself I have managed to solve the issue. Basically I found two ways of doing it, one is as you have suggested and the other is by just replacing the custom recovery with the stock recovery. The SGS3 toolkit available on XDA made the 2nd option just slightly simpler for me and by spending less than 10 mins (excluding time for backups and downloads) the issue was resolved.
Just to share this option to save others from the headache of looking for a solution:
1) Get the toolkit
2) Install drivers as recommended and follow instructions to choose the build, or closest build, for your S3
3) Restore stock recovery with toolkit via ODIN (follow instructions)
4) After rebooting, go into Android and reset to factory settings, this would bring you to the stock recovery and wipe
5) Restore custom recovery with toolkit via ODIN (follow instructions)
6) Restore your system (luckily for me I had a nandroid backup before I encrypted)
Note: I did "lose" my internal sdcard files (pictures/documents). But I backed that up on my external sdcard before starting the process. My sdcard was not encrypted.
Click to expand...
Click to collapse
You just saved my month. Drop me a message if I can get you a beer via paypal for this.
Cheers!
THANKS!
olm3ca said:
Here's the scenario: say you try out encryption on a ROM, either because your employer makes you or because you want the extra security. What happens when you can root your phone, like we can (easily) with the S3, and you want to flash a different ROM? The problem you will find yourself in very quickly is that you cannot do a successful wipe. You can't format an encrypted /data in CWM or any other recovery. If you cannot format /data, you can't flash a ROM - it fails, because /data is encrypted, and it cannot proceed. It turns out none of the recoveries can format an encrypted /data. You also cannot reverse encryption once you've done it. You're stuck, all because you flipped the switch on encryption.
I found myself in this problem as others have in many other forums (like this one for the GNex) (and another one, more detailed).
I also tried, admittedly somewhat out of desperation, the soft-brick instructions here. That didn't work because Nand Erase All fails. You can flash on top, and luckily you can use your same password to decrypt your /data (which I did) but you're still not going to have a clean ROM. Dirty flashes = lots of problems down the road.
I finally found a simple way to do this and wanted to save anyone else the trouble of digging. You can do it using CWM and adb and a few commands. Credit goes Shawn Webb's blog and utkanos on FreeNode's irc at #cyanogenmod.
Here is how to do this on our Verizon S3:
In CWM, wipe cache
adb shell
mke2fs -t ext4 /dev/block/mmcblk0p15
mount /data
mount /dev/block/mmcblk1p1 /data/media
If adb doesn't work in CWM, reboot recovery. You might need to create /data/media after mounting /data in order to do the last step, which I opted not to do. I hope this saves someone else a few hours of frustration, and I also hope that someday one of our recoveries can handle formatting encrypted data. Until then... I'm just not using encryption, period. There already is a lot of documentation against it, and this is one more reason in my book.
Click to expand...
Click to collapse
Just wanted to say thanks very much for this. I'd tried the method of reloading the stock ROM as described by a previous poster, but this way worked.
I did run into a small issue I was wondering if you could shed some light on. When I entered "mount /data", I got the following:
Code:
~ # mount /data
mount: mounting /dev/block/mmcblk0p37 on /data failed: Invalid argument
I bullied ahead and entered the last line "mount /dev/block/mmcblk1p1 /data/media" and got this:
Code:
~ # mount /dev/block/mmcblk1p1 /data/media
mount: mounting /dev/block/mmcblk1p1 on /data/media failed: No such file or directory
However after doing this, I was able to perform a complete wipe of /data using CWM and load a new ROM without issue.
I'd curious to know what might be causing these Invald argument responses.
My Device: HTC One (GSM)
Thanks again! :laugh:
olm3ca said:
Here is how to do this on our Verizon S3:
In CWM, wipe cache
adb shell
mke2fs -t ext4 /dev/block/mmcblk0p15
mount /data
mount /dev/block/mmcblk1p1 /data/media
If adb doesn't work in CWM, reboot recovery. You might need to create /data/media after mounting /data in order to do the last step, which I opted not to do. I hope this saves someone else a few hours of frustration, and I also hope that someday one of our recoveries can handle formatting encrypted data. Until then... I'm just not using encryption, period. There already is a lot of documentation against it, and this is one more reason in my book.
Click to expand...
Click to collapse
I'm trying to follow your instructions but fail at finding out my mount points.
Sorry for the noob question, but who do I find out what the mount points of internal and external SD card are on my device (Samsung Galaxy S4 Mini International 4G)? I found this post
stackoverflow. /questions/6824463/how-to-get-all-the-mount-point-information-for-android-device
which seems to include the answer but I don't know what tool / software they use. I'm no programmer.
My phone is encrypted and doesn't turn on, it doesn't accept my password saying it's wrong, though I know it's correct. OS is Cyanogenmod 10.1 stable. Booting into CWM v6.0.3.7 is possible though.
I appreciate everyone's help.
Stephan
Hi everyone,
I have been thinking of selling my Infinity but I need some confirmation in some things with regards to wiping the device clean.
I am currently running the latest CROMI-X. So what I wanted to do is wipe everything in my internal storage (all the datas or any kind of prints that shows my usage) and then flash back the latest CROMI-X.
So a couple of things in wipe. I am using TWRP 2.5 as of the moment. So if I wanted to achieve the one I mentioned above which kind of wipe should I do?
If I go to Advanced Wipe: I can see that Dalvik Cache, System, cache, Data and Micro SDcard is present there... If I go ahead and check all of these (except for the Micro SD Card) I believe that I this would also delete the OS itself. Am I correct? If this does it, will I still be able to install a ROM for my infinity? There's also the option of Format Data,which I think wipes clean my internal storage (pictures, videos, etc). This won't affect the System, right?
If you guys have a better suggestion on how to actually do this, please let me know as well. I apologize if there's a lot of question here... I just wanted to make sure that I am doing this right as I don't want to brick my device before actually selling it. Thanks.
To delete all user data, format /data. This automatically includes dalvik-cache and /data/media aka /sdcard. You don't need to format /system as it contains only the ROM.
If you are paranoid that a potential buyer could use "undelete" tools and piece together fragments of your data on the block level, then before formatting /data, you can completely overwrite the data partition from the recovery with the following command (in the "advanced" menu or via adb shell): "dd if=/dev/zero of=/dev/block/mmcblk0p8 bs=256k".
I have a Galaxy GIO, which is a fairly old low-end phone. On factory reset, I have about 100MB memory free for apps, and the phone seems to start complaining as soon as I hit the 50MB mark; that's about one or 2 installed applications.
Because I would like to actually be able to, well, use my phone for anything else than calling, I want to move the /data partition to my SD card. I know this'll be slow, but slow still is better than not working at all.
I have done a bit of research, and came around plenty of scripts which claim to mount the second partition of the sd card as /data; none of these scripts work. I have tried 'INT2EXT', 'D2EXT', and I've heard about something called 'A2SD' but I have yet to find a copy of it . To install these scripts I've extracted them, and copied the scripts to '/system/etc/init.d/', after mounting '/system', using ADB.
I for an instant thought maybe my second partition isn't formatted properly, but using adb I am able to successfully mount the ext2 partition as /sd-ext, so I don't see why mounting them as /data should be a problem.
I have also tried to symbollicly link /data to /sd-ext/data and automatically mount my /sd-ext on boot. Obviously this didn't work, because the symbolic link isn't actually saved to disk.
How would I go about moving my data partition to my sd card? I am not affraid of doing some dirty work manually. I am running Cyanogenmod 11.
Binero said:
I have a Galaxy GIO, which is a fairly old low-end phone. On factory reset, I have about 100MB memory free for apps, and the phone seems to start complaining as soon as I hit the 50MB mark; that's about one or 2 installed applications.
Because I would like to actually be able to, well, use my phone for anything else than calling, I want to move the /data partition to my SD card. I know this'll be slow, but slow still is better than not working at all.
I have done a bit of research, and came around plenty of scripts which claim to mount the second partition of the sd card as /data; none of these scripts work. I have tried 'INT2EXT', 'D2EXT', and I've heard about something called 'A2SD' but I have yet to find a copy of it . To install these scripts I've extracted them, and copied the scripts to '/system/etc/init.d/', after mounting '/system', using ADB.
I for an instant thought maybe my second partition isn't formatted properly, but using adb I am able to successfully mount the ext2 partition as /sd-ext, so I don't see why mounting them as /data should be a problem.
I have also tried to symbollicly link /data to /sd-ext/data and automatically mount my /sd-ext on boot. Obviously this didn't work, because the symbolic link isn't actually saved to disk.
How would I go about moving my data partition to my sd card? I am not affraid of doing some dirty work manually. I am running Cyanogenmod 11.
Click to expand...
Click to collapse
I will introduce how to COPY(NOT MOVING) /data partition to /sdcard.
1. You should ROOT First.
2. Use Rootexplorer to Copy /data to /sdcard (WARNING:If your sdcard emulated with /data, Data WON'T copy to SDCARD --You need external Sdcard!)
2-1. if you don't want to use RootExplorer, you can use Android Debugging Bridge(adb)
(Youshould download Android sdks from developer.android.com)
--Command : adb shell su -C cp /data /sdcard/data
3. That's all.
Jason Hyunwoo said:
I will introduce how to COPY(NOT MOVING) /data partition to /sdcard.
1. You should ROOT First.
2. Use Rootexplorer to Copy /data to /sdcard (WARNING:If your sdcard emulated with /data, Data WON'T copy to SDCARD --You need external Sdcard!)
2-1. if you don't want to use RootExplorer, you can use Android Debugging Bridge(adb)
(Youshould download Android sdks from developer.android.com)
--Command : adb shell su -C cp /data /sdcard/data
3. That's all.
Click to expand...
Click to collapse
Thanks, but that's not entirely what I meant. I can manage to move my data to the SD card no problem, but I want my phone to actually use my second partition on my sd card, as the /data partition.
Binero said:
Thanks, but that's not entirely what I meant. I can manage to move my data to the SD card no problem, but I want my phone to actually use my second partition on my sd card, as the /data partition.
Click to expand...
Click to collapse
Oops.. Sorry about that!
First, I am not sure that will work or not, maybe you should try to edit init.*.rc. Which is from boot.mg. I think, maybe mounting sdcard as data is impossible, but you may try editing init.rc(or init.*.rc, * is manufacture). You could unpack your boot img, and you could edit mounting point which is from init.rc!
I hope this thing will help you..
Jason Hyunwoo said:
Oops.. Sorry about that!
First, I am not sure that will work or not, maybe you should try to edit init.*.rc. Which is from boot.mg. I think, maybe mounting sdcard as data is impossible, but you may try editing init.rc(or init.*.rc, * is manufacture). You could unpack your boot img, and you could edit mounting point which is from init.rc!
I hope this thing will help you..
Click to expand...
Click to collapse
I have looked into init.rc, but that only seemed to create the /data mountpoint, but not actually mount to it. I've no idea how to edit the boot image, or what that even is. Is that the filesystem that is built into the kernel?
Binero said:
I have looked into init.rc, but that only seemed to create the /data mountpoint, but not actually mount to it. I've no idea how to edit the boot image, or what that even is. Is that the filesystem that is built into the kernel?
Click to expand...
Click to collapse
Umm.. You should download unpackbootimg or dsixda's Android Kitchen to edit boot.mg. You cannot edit init.rc on Root explore. Use unpack boot.img menu which is from Android Kitchen!
Jason Hyunwoo said:
Umm.. You should download unpackbootimg or dsixda's Android Kitchen to edit boot.mg. You cannot edit init.rc on Root explore. Use unpack boot.img menu which is from Android Kitchen!
Click to expand...
Click to collapse
I'll try that out. Still not sure where to look though. As I said, init.rc does not contain any commands mounting /data.
Binero said:
I'll try that out. Still not sure where to look though. As I said, init.rc does not contain any commands mounting /data.
Click to expand...
Click to collapse
or you could edit look at other *.rc files!
Isn't this what you're looking for?
http://forum.xda-developers.com/galaxy-s2/themes-apps/tool-directorybind-data-to-externalsd-t1410262
sndsnd said:
Isn't this what you're looking for?
http://forum.xda-developers.com/galaxy-s2/themes-apps/tool-directorybind-data-to-externalsd-t1410262
Click to expand...
Click to collapse
I want to mount my sd card to my /data. That simply creates a symbolic link.
Jason Hyunwoo said:
or you could edit look at other *.rc files!
Click to expand...
Click to collapse
There is only 2 rc files, and one of them is specific to my recovery image.