I'll make this one quick, so I know the userdata.img that comes with stock images is just a blank image that's sole purpose is to format your userdata partition for you, and that you can use fastboot format userdata for the same result, however is it the same deal with the cache.img file? Is the cache file just a blank image used for formatting the cache partition of your device or does it actually contain some data that the device needs to function? Thanks!
I have yet to flash either and have had no problems. I wipe both through twrp before booting up for the first time.
There is nothing of importance in either.
danarama said:
There is nothing of importance in either.
Click to expand...
Click to collapse
So in this sense, formating or erasing the cache is the same effect as flashing the cache.img?
H4X0R46 said:
So in this sense, formating or erasing the cache is the same effect as flashing the cache.img?
Click to expand...
Click to collapse
Yes and no.. Sort of.
The image itself, I don't really know why it exists. When you fastboot flash those images, it does a format first. Actually flashing the image afterwards has no benefit.
They could just put the format commands in the flash-all script. Perhaps they've done it for those who don't use the script to encourage them to format by flashing the image. Only thing I can think of. Or maybe those images are big enough that they wrote 0 byte data over existing data blocks that exist after the format to make them more secure, because really, a format or erase doesn't destroy data. It just makes it inaccessible by the average user. So it could be that they're overwriting a small section of data in the partition as that is the only way to destroy data.
Anyway, it should be rare that you need to format those partitions..
Formatting just erase allocation table, flash an empty.img overwrite and really cleans the data.. I think..
_____________________________________Read more write less and be smart
danarama said:
Yes and no.. Sort of.
The image itself, I don't really know why it exists. When you fastboot flash those images, it does a format first. Actually flashing the image afterwards has no benefit.
They could just put the format commands in the flash-all script. Perhaps they've done it for those who don't use the script to encourage them to format by flashing the image. Only thing I can think of. Or maybe those images are big enough that they wrote 0 byte data over existing data blocks that exist after the format to make them more secure, because really, a format or erase doesn't destroy data. It just makes it inaccessible by the average user. So it could be that they're overwriting a small section of data in the partition as that is the only way to destroy data.
Anyway, it should be rare that you need to format those partitions..
Click to expand...
Click to collapse
Yea it really is kind of confusing that they add these blank images, would it be a safer bet in this case to use the erase command as opposed to format? Or is it a better idea to just flash these blank images? They really made it confusing by adding them. I also have a 64GB nexus 6, so after flashing the userdata.img, it shows I only have 32GB! It requires a factory reset that, as you know, takes AGES on this device! In short, should the format command be used in more rare circumstances as opposed to erase or using the img file?
Use format to fix your issue. The images are known to cAuse this.
Related
I just saw an interesting thread in the development section that explains an alternative to the Death SPL. The method there lets you flash ANY rom on any SPL, but I dont really understand how it works.
The thread can be found here: http://forum.xda-developers.com/showthread.php?t=704560
So basically, you shrink the cache partition to allow for more room for the actual ROM(which partition does that go in?)?
To do this do we edit the boot.img in the ROM update.zip? What else do we do?
Could someone explain this in a way a 9th grader could understand?
kingkurry said:
Could someone explain this in a way a 9th grader could understand?
Click to expand...
Click to collapse
Take file by firerat, flash file. omgroflpartitons.
If you don't understand the instructions as they are, wait for it to be perfected before you try anything. This will probably end up being integrated into releases that need it, so you don't need to worry about the specifics at the moment.
Will that patch file work for all ROMs. He said its only been tested with CyanogenMod 5. And I want to understand what im doing, not just do it without thinking about it...
Also, does the recovery patcher decrease the size of the partition that holds the recovery image?
Does it permanently change the size of the recovery partition?
When you flash a ROM, what partition is it being flashed too? Is this the one being increased in size?
What does the boot.img in an update.zip package hold, and is that copied to the boot partition?
Sorry but my curiosity is killing me
OK well to break it down we have 6 partitions on the internal memory:
Misc - Here be dragons
Recovery - Contains recovery system (+seperate recovery kernel) - recovery.img lives here
Boot - Contains kernel & important initialization stuff - boot.img lives here
-------------
System - Contains the whole android system (the "ROM", if you like).. everything else from an update.zip apart from the boot.img
Cache - Used by system and recovery for temporary storage
Userdata - Contains all personal data, downloaded apps, settings etc.
The first three partitions must be left at the default size so don't worry about them.
What this patch does is pass a command to the kernel which remaps the 3 large partitions at boot time. Since we're flashing system images from recovery, we also need to pass the same command to the recovery kernel before attempting to flash the main system, or we'd be writing to one place then telling the kernel to look for it in another.. bad idea.
This method allows any partition setup you like, but the most useful at the moment (and this is the way firerat has set up his scripts to suit cm5) is to make the /system partition just the right size for the "ROM" with a bit of breathing space, make the /cache partition a minimal size for the recovery system to use, then have /userdata fill the remaining space so we can load it up with apps. Since we've reduced cache to a minimal size, it's redirected at boot time to a place on the sdcard instead.. this give us maximum space to divide between /system and /data with no wastage.
Does that help at all..?
Thanks dude. That does help a lot.
Just wondering though, how much breathing space do u need in the system partition?
What does the recovery system use the cache partition for and how do we know what "a minimal size for the recovery system to use" is?
Is it possible to reduce the userdata partition to the minimum possible size a partition can be(if i recall correctly it was 128kb) and use an ext partition on your SD card instead?
If we shrink the Cache partition a lot, does this mean we have to use linux swap to compensate for the lowered amount of cache?
Also do we have to remap the partitions every time we flash a new ROM?
And what are the "dragons"?
kingkurry said:
And what are the "dragons"?
Click to expand...
Click to collapse
He's saying that it's just there. There could be anything from nothing there to a text document containing the ingredients to the cure of AIDs.
Well what about every thing else? Can you guys help me with that? Also what is the total size of all 3 of the big partitions combined?
I have a bunch of images I wish to flash to my Nexus for the data and system partition.
I am using the "adb shell flash_image partition image" method.
Whenever I try to flash the data partition I get a "can't find data partition". System, recovery and cache partitions can be flashed without any issues using the same command.
Any ideas ? I'm pretty newbie at this.
Thanks
That is because it is userdata instead of just data.
daveid said:
That is because it is userdata instead of just data.
Click to expand...
Click to collapse
Now I just feel stupid ... thanks a lot
I know some people may read this and call me a n00b, or whatever....deal with it lol
I'm coming from a Nexus S, and this is my first android with the new unified storage, rather than the old method that was partitioned for rom storage and sd/usb storage. I just flashed a Nexus 4 factory image for the first time ever, and when I did all my files on my storage partition were wiped. This includes my nandroids, all my apk backups, titanium backups, my roms, kernels, gapp zips, pictures, music.....EVERYTHING!!!!!!! When I rebooted, there was not ONE file on my phone that wasn't part of the factory image!! When I did a factory flash on my nexus s, since there were separate partitions, my storage was completely untouched. The only thing similar that would wipe it was a bootloader unlock. This is (obviously) no longer the case. My only saving grace is that at least half my apks are stored in my box account (thank you box for the free 50gb for registering with an LG device ) and my pics were set to auto-sync with ubuntu one. Everything else is lost forever, though
IF YOU HAVE TO FLASH A FACTORY IMAGE, BE SURE TO BACK UP YOUR STORAGE PARTITION FIRST!!!!
You have been warned
Assuming you used the flash-all script, just remove the -w option
I flashed back to stock, radio, system, boot loader etc, but just didn't flash the data partition (or whatever its called) and the internal SD was untouched.
Admittedly I got stuck in a boot loop, but I just powered off, booted in to boot loader and flashed TWRP from fast boot. Factory reset and cleared cache and I still had everything saved
Sent from my CM10.1 Nexus 4
crachel said:
Assuming you used the flash-all script, just remove the -w option
Click to expand...
Click to collapse
nope. i flashed each individual .img file the userdata.img is what wiped the storage....apparently the device thinks the two are connected. maybe they really are....i'm not an expert in this area, to say the least.
Tom540 said:
I flashed back to stock, radio, system, boot loader etc, but just didn't flash the data partition (or whatever its called) and the internal SD was untouched.
Admittedly I got stuck in a boot loop, but I just powered off, booted in to boot loader and flashed TWRP from fast boot. Factory reset and cleared cache and I still had everything saved
Sent from my CM10.1 Nexus 4
Click to expand...
Click to collapse
yup...you're correct!! twrp knows the difference between actual userdata and storage...it seems that fastboot does NOT know the difference, unfortunately. I figured since twrp is safe to wipe the data with, fastboot should be too.
hp420 said:
nope. i flashed each individual .img file the userdata.img is what wiped the storage....apparently the device thinks the two are connected. maybe they really are....i'm not an expert in this area, to say the least.
Click to expand...
Click to collapse
I think the title "userdata" should have given you a clue about what it was going to do, i.e. flash over the user data and erase what was previously there
Sent from my CM10.1 Nexus 4
Tom540 said:
I think the title "userdata" should have given you a clue about what it was going to do, i.e. flash over the user data and erase what was previously there
Sent from my CM10.1 Nexus 4
Click to expand...
Click to collapse
As I said before, my last android was a Nexus S that was partitioned, so the data was separate from the usb/sd storage space. When I flashed the userdata.img on my Nexus S it didn't delete all my sd/usb storage....only the rom's data partition. Based on my previous experience, and considering this is the first time I've flashed a factory image to my Nexus 4, why would the name "userdata" give me any clue that something other than the "userdata" would be wiped???? Even if you don't take my previous experience into account, why would the name "userdata" ever have anything to do with "sd/usb data"???? userdata and sd storage are two separate things. Yes, they are stored in the same partition now, but that doesn't mean they are the same thing. userdata is tied to your rom, and your sd storage is for any additional personal files you decide to store there.
The problem is that the fake SD is on /data/media, so flashing a data IMG overwrites the entire partition and deletes your stuff. Lgnpst doesn't though, not sure why. Perhaps try that next time or just don't flash data.
Sent from my LG-LS970 using xda app-developers app
There are also very clear guides on here that tell you that flashing userdata will clear everything. Flash everything except that one next time.
Sent from my Nexus 4 using Tapatalk 4 Beta
Finally I've got everything installed and set up and logged in, etc, after reviving from brick. But then I just realized... This is a 128GB phone and things are saying I'm low on space (kinda)...
Anyone have any idea what can cause this or how to fix? The only thing in my mind that might be relevant is that the Data partition is in F2FS when before my huge issue I had it in EXT4? The OP level 2 support guy used a 7.1.1 factory image to revive my device. Can this matter?
Settings/Storage it's showing SYSTEM is taking up 89GB?!?!?!
Mixplorer says all of Internal Storage is only using 1.62GB or so
Desktop shows the phone as having 24.8GB storage in TOTAL with 6.9GB used
I don't know how to interpret these screenshots at all or what to do about it...
Edit: A full TWRP backup of every partition checked in the options is 7.75GB in total (as displayed in Windows), system image & all!
Edit2: Also in TWRP, there is no option for resizing the Data partition (which is f2fs, every other partition is EXT4) ...
If no one has any ideas... This is the only thing that seems like it makes sense to try doing to switch data from f2fs to ext4 and hopefully not have to clean flash? https://forums.oneplus.net/threads/...-without-losing-internal-storage-data.439999/
But if that doesn't work, and a regular clean flash doesn't work, that's what I'm most concerned about before even messing with it... JUST got it all set up perfectly after reviving from bricked state...
Switch to ext4, as its the most common Linux' file system. f2fs seems to be the culprit. And you'd better done a clean flash.
Erase userdata partition from fastboot and then format it (also via fastboot). Should work.
Don't forget to make a backup of you existing data (including internal).
As warned by many, F2FS is unstable and causes many errors. Try switching to Ext4, via ADB. This ought to give you the corrected partitions.
Confirmed
Just posting to confirm the above messages.
i converted my system to ff2fs and my system was taking up a little over 40Gb.
Reverting back to ext4 sorted it
Long story short, I've been trying to get into my internal storage via TWRP but its saying that there are 0MB in the internal storage and that there is nothing in the sdcard folder
I've tried formatting it, hasn't worked
I've tried changing the format to FAT and then back to EXT4
then after that didn't work i tried the same but with EXT2 , it showed the amount of storage but still didn't let me see what was inside of the sdcard folder, whenever i'd go in there its just completely empty
Can I please have some help with this, I've been stuck on this for a couple hours now
Ouch! Please don't say that you just formatted userdata (/data).
You've just killed all your data on your phone.
No, I'm not that experienced with TWRP and I don't know which versions under which circumstances it can mount userdata.
I use custom recoveries and just presume that I can't mount userdata in them.
In the normal system (which mounts and decrypts) I use normal tools to sync or backup.
Renate said:
Ouch! Please don't say that you just formatted userdata (/data).
You've just killed all your data on your phone.
No, I'm not that experienced with TWRP and I don't know which versions under which circumstances it can mount userdata.
I use custom recoveries and just presume that I can't mount userdata in them.
In the normal system (which mounts and decrypts) I use normal tools to sync or backup.
Click to expand...
Click to collapse
I didn't format data it self i meant that i factory reset it, sorry i should of been a lot more clear on that
Oh, ok.
Well, in any case, if it's encrypted you need to mount it not with a simple "mount" command but something fancier using dm.
They don't try to make it easy to do.
Unless you're destroyed your system and you're trying to recover your data, whatever you're trying to do is best done in the normal system.
never mind i found a fix for it
well not really a fix just a way around it
thanks for the help ^^
SoftieIsVibing said:
never mind i found a fix for it
well not really a fix just a way around it
thanks for the help ^^
Click to expand...
Click to collapse
I had the same issue so I flashed a raw firmware after taking full system backup. Now TWRP is working fine.