Does anyone notice that? I have a 103mb data.img that I tried to upload and got not a space error. Also tried loading the data.img as system.img with the same error
When trying to load an older 99mb (yes exactly lol) it worked perfectly
did you pull this from your own device?
I've noticing on the rom I'm building (which pushes the limits of /system to load a completeish hero) that sometimes the device will allow you to allocate slightly more or less space. I still don't understand how partitioning works on the device (or why it's in place, I'd like a full single partition instead protected by permissions and avoid having the waste of unused space in boot, or system, or cache... etc...), but again, it seems that your device allows you to cram slightly more if you push it, but once you try to flash it back with fastboot, the specified partition sizes will prevent you from flashing
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?
Hi, I have problem with installation android to my Kaiser (NAND). When I am installing it, It is normal formating system and data, but after attempt of install system it shows me message: tar error: extraction failed: no space left on device. I thought that it format memory, so it should be empty.. I dont get it. Anybody helps?
Thanks..
Mav3rick2 said:
Hi, I have problem with installation android to my Kaiser (NAND). When I am installing it, It is normal formating system and data, but after attempt of install system it shows me message: tar error: extraction failed: no space left on device. I thought that it format memory, so it should be empty.. I dont get it. Anybody helps?
Thanks..
Click to expand...
Click to collapse
The Kernel splits the NAND into 2 partitions (excluding the actual partition for the kernel). The default sizes is 101MB for /system and 150+MB for /data.
Make sure the androidinstall archive's /system folder is under 97MB in size or else the install will fail, or you can change the /system partition size using atools to a larger size while sacrificing /data partition size.
I tried to install Scoot_CyanogenMod_6.1_Rls5.5 (cca 90MB size of file) and same problem... If I tried Scoot_CyanogenMod_7_alpha_RLS1_All_Language (about 112MB size of file) and I set size of system partition to 128MB in atools to my nbh file, same problem.. Iam sad.. I want to use android but I can't... :-(
Have you checked how many bad blocks you have whenever the kernel formats the NAND? It should be disabled during the "Formating..." stage.
If you have excessive bad blocks, try increasing the /system partition as far as you can, then setting /data to your SD card. It's possible your device has too many bad blocks to install android with default settings.
i have a htc kaiser and i have the same problem.
how many mb should i put for data and system with atools?
and..when i save the install-seq.sh where do i put it? in the root of sd?
http://forum.xda-developers.com/showpost.php?p=12145518&postcount=461
please don't double post!!!
me too same probleme.
1) update NBH editor
a) set up all option
b) change System/Data size
c) set System - Nand 2
data SD - partition p2
swap - auto
storage8.static.itmages.com/i/12/1118/h_1353239270_8665672_135471dd01.png
* sd card have only 1 partition 50% fat32 and 50% free space
storage4.static.itmages.com/i/12/1118/h_1353239816_9273632_16b5ec517d.jpeg
2) boot script editor
System NAND p2 Erase
Data Sd partition p2 Erase
Actions: Install system, Fix Permission, Clear Davik chace, Use sd partition
storage6.static.itmages.com/i/12/1118/h_1353239950_6780632_54a5fa768b.png
3)Mixer set Working Dir
add androidinstall.tar
add Module update (for kernels after 23-11)
combine (debian icon)
and save androidinstall.tgz
storage5.static.itmages.com/i/12/1118/h_1353240546_2336238_466987bb88.png
4) copy to SD card
SD: KAISIMG.NBH
SD: andboot/androidinstall.tgz
SD: andboot/install-seq.sh
storage4.static.itmages.com/i/12/1118/h_1353240328_6642646_17fd7c2f78.png
good luck
yes i have solved yesterday with system 128mb to 165mb.
but i will try your setting, is good to make data with sd.
but is see on picture you choose donut, i have choise froyo setting but is good for Scoot_CyanogenMod_7.1 i use this android.
It would appear that the N7 eMMC controller wear-leveling implementation does not enforce page/block erasure during wear leveling re-mapping.
Further, there is no reason to believe that partition boundaries are relevant to the block remapping.
The upshot of this is that pages (containing arbitrary data) that were once in /data can end up in slack space - for instance in the back end of the boot or recovery partitions. (The valid images written in there are megabytes shorter than the full partition sizes). So, don't give folks Nandroid backups - even if a factory reset has been performed prior to the nandroid creation time or the userdata backup removed. (The boot & recovery partitions are captured as full partition dumps, so you get valid images plus slack space)
I ran a simple test yesterday:
- record the boot partition using "dd"
- boot into bootloader and then "fastboot erase boot"
- boot into custom recovery and capture boot partition (again) using "dd"
- restore boot partition (fastboot or nandroid)
Then I examined the boot partition dumps (e.g. using "hexdump" or "strings"). In my case the "erased" boot partition contained (among other stuff) what looked like pathnames for lots of files stored in /data. Clearly that is the type of stuff that would never be found in the boot partition without block remapping. You can also find the same kind of thing going on in the USP partition - have a look if you are curious.
I suppose this has implications for folks "cleaning up" tablets for resale or return - bits of your data lives on in unexpected places...
cheers
Hi all,
Tearing my hair out here (and I have SFA left anyway)
My Father-in-law's SGS i9000 seems to have real issues. Initially problem I was having was that there was an app I could not uninstall- it would reappear on reboot. I initially suspected malware or such, but it appears to be a real problem with the internal memory. I had MIUI installed on it, but wanted to change to a more stock ROM.
First time I really started to worry was when I found that every time I put a new rom onto the internal sdcard, it disappeared at reboot (and thus wasn't there to install when rebooted into CWM)
Since then, haven't had a functioning phone.
adb push to sdcard still not persistent on reboot.
Cannot flash new ROM with ODIN either, although KERNEL changes, filesystem no longer mounts.
I think the version of MIUI I was using used an ext4 lagfix, as inside an adb shell, I can see the partitions:
parted /dev/block/mmcblk0
a "print" lists two partitions:
Number Start End Size Type File system Flags
1 32.8kB 14.4GB 14.4GB primary fat32 lba
2 14.4GB 16.4GB 2013MB primary ext4 lba
rm 1, rm 2
to try to delete the partitions and start again- doesn't work. Nothing happens
If I load partition 2 into parted:
parted /dev/block/mmcblk0p2
print
Model: Unknown (unknown)
Disk /dev/block/mmcblk0p2: 2013MB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Number Start End Size File system Flags
1 0.00B 2013MB 2013MB ext4
Can;t check any partitions as ext4 isn't supported by parted.
I cannot remove any partitions, reformat them or anything.
e2fsck errors as it cant read superblock flags on any of the partitions.
Any other ideas? Anyone?
I don't want to toss the phone out
http://forum.xda-developers.com/showthread.php?t=845708
i dont know if this will help u but u can try this guy instruction. See link above
compacity said:
http://forum.xda-developers.com/showthread.php?t=845708
i don't know if this will help u but u can try this guy instruction. See link above
Click to expand...
Click to collapse
If that worked, it would have been just what I was looking for
I googled the hell out of this problem, and that one never came up, but others I'd seen led me to try that same plan.
Where it fails on my device, is that deleting the partitions in "parted" fails- rm1 followed by rm 2 to delete the partitions. "Print" reveals they're still there.
Any other partition tools worth trying?
I got it back to square one:
Flashed kernel thru Odin with a version of CWM that worked.
reboot into recovery.
Flash update from SDcard- card contents still the same, so could re-flash MIUI.
reboot, bootloop. Re-enter CWM recovery and reflash.
Back to Square One - MIUI 1.12.16 (JVK)
Cannot install anything - nothing is persistent after reboot, even WIFI settings disappear
If it is any help to anyone who knows what they're talking about:
Now that MIUI boots I can look at the filesystem better.
Can anyone point me in the direction of what I should be looking for/trying to do to figure out what is wrong here?
try finding solution here, its PIT stop for i9000 problem
http://forum.xda-developers.com/showpost.php?p=30415128&postcount=1
Mine seems to be a bit tougher than these solutions can deal with.
Tried assorted ROMs over past day. No install works.
Cannot install anything from internal memory, as nothing dropped into that card will remain after a reboot.
Installing anything from an external card just throws up bootloops etc- as the only thing that seems to be able to retained between boots is the kernel/CWM.
If I install a new ROM, first flash says partition table is incompatible and /data will be overwritten (no problems, nothing on it). I accept the inevitable and re-select the ROM.
Reboot bootloops, as expected, reboot into CWM (now a new version with the Kernel), try reflashing the ROM image- Error 0 or 7. Try from External Memory- same. Try sideloading image. Same. All I can do is re-flash the MIUI image on internal SDcard (which works)
It looks like the internal memory refreshes itself from a recovery image at each boot? (I think).
Anyway- can't get anything to stick, except MIUI
edit:
http://forum.xda-developers.com/showthread.php?t=761537&page=3
http://forum.xda-developers.com/showthread.php?t=1230059&page=3
hav u try this 2 link as this is da only thread matches ur MBR problem
compacity said:
did u try any jb kernel out there? as its also ext4 n push it using adb. juz a suggestion though.
Click to expand...
Click to collapse
Good suggestion Logical
I'd thought that also- The JB kernels should support ext4.
No joy though
The version of CWM recovery that is stable with the MIUI install is 5.0.2.7, and it doesn't have any voodoo/lagfix options
When I flash a kernel with a CWM with lagfix, and try to use the CWM lagfix toggles, nothing changes.
Doesn't matter what I select inside CWM, it reads the status from memory as "Lagfix on, Debug off"
The reason I asked about ext4 tools in ADB is that running filesystem commands in a shell just throws up errors I can't seem to fix.
e2fsck just throws up superblock errors (on both /dev/block/mmcblk0 and the partition /dev/block/mmc0p2.
Defining one of the backup superblocks doesn't help- they're all bad.
"parted" doesn't work anymore (i note it isn't in /sbin, so I am picking this kernel doesn't install it), but even when I did have it, "parted" doesn't support ext4. Using "rm" to remove a partition did exactly nothing.
Starting to think the only way forward would possibly be flashing a custom .pit file to define partitions that move the data off an obviously bad block? Above my skill level however LOL
refresh browser see my post above again
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