Related
So I was thinking...
df -h
/dev/block/mmcblk0p25------402.6M-----124.5M----257.3M-----33%---/system
/dev/block/mmcblk0p26------1.3G--------356.0M----886.5M----29% ---/data
/dev/block/mmcblk0p27------198.3M------35.7M----152.4M-----19%---/cache
Click to expand...
Click to collapse
We have roughly 2 gigs internal on our phones. Using CM7, my /system partition is over 60% empty. Why not install another rom beside it?
My idea is to partition the storage space into multiple directories that symlinks back to the original partitions only when booted.
For example, The partitioning could look like this:
/system------5M
/data--------5M
/cache------5M
/system1----200M
/data1------650M
/cache1-----100M
/system2----200M
/data2------650M
/cache2-----100M
Click to expand...
Click to collapse
The system would boot past splash1, where a screen similar to this could show up:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Depending on your selection, it would boot with either /system1 or /system2, symlinked to the original /system.
I know that it is possible to change your mtd partitions, it is a very commonly used hack on the G1 developed by Firerat and lbcoder (thread). If we can take this concept and take it a step further and create our own partitions, this seems feasable.
Some thoughts/concerns:
-both roms would have to use the same kernel as the kernel is one of the first things to boot.
-space for apps might be a bit tight for some, so A2SD might need to be used
-we would need a modified recovery image in which you have to specify which /system a rom would be copied to
-sharing /data and /cache might be possible, but might lead to problems with dramatically different roms.
-how would we go about setting up the screen to select which rom to boot?
-the closest thing to dual booting that we can do now would be /sd-ext based roms like old HD2 roms or Enomther's rom from before we had perm root
My programming knowledge is limited to HTML and flash, and I am a linux noob so I can't do much more than build a rom from source or changing out/modifying some png's for a theme.
If my idea seems feasible somebody else would have to code it. If you can come up with a better idea for dual boot, then by all means, share
mejorguille said:
So I was thinking...
We have roughly 2 gigs internal on our phones. Using CM7, my /system partition is over 60% empty. Why not install another rom beside it?
My idea is to partition the storage space into multiple directories that symlinks back to the original partitions only when booted.
For example, The partitioning could look like this:
The system would boot past splash1, where a screen similar to this could show up:
Depending on your selection, it would boot with either /system1 or /system2, symlinked to the original /system.
I know that it is possible to change your mtd partitions, it is a very commonly used hack on the G1 developed by Firerat and lbcoder (thread). If we can take this concept and take it a step further and create our own partitions, this seems feasable.
Some thoughts/concerns:
-both roms would have to use the same kernel as the kernel is one of the first things to boot.
-space for apps might be a bit tight for some, so A2SD might need to be used
-we would need a modified recovery image in which you have to specify which /system a rom would be copied to
-sharing /data and /cache might be possible, but might lead to problems with dramatically different roms.
-how would we go about setting up the screen to select which rom to boot?
-the closest thing to dual booting that we can do now would be /sd-ext based roms like old HD2 roms or Enomther's rom from before we had perm root
My programming knowledge is limited to HTML and flash, and I am a linux noob so I can't do much more than build a rom from source or changing out/modifying some png's for a theme.
If my idea seems feasible somebody else would have to code it. If you can come up with a better idea for dual boot, then by all means, share
Click to expand...
Click to collapse
Lol that's pretty cool idea
Sent from my Liquid Metal using XDA App
Bounty in place for this! I really share your dual boot vision. Very badass idea. If someone will work on it, im in bounty $20
Sent from my HTC Vision using XDA App
That would be difficult. bcoz,
1. Need WP7 drivers for G2/DZ devices
2. source/ROM compatible for G2/DZ (WP7 is not open, hehe m$)
3. A botloader.
Innocent Devil said:
That would be difficult. bcoz,
1. Need WP7 drivers for G2/DZ devices
2. source/ROM compatible for G2/DZ (WP7 is not open, hehe m$)
3. A botloader.
Click to expand...
Click to collapse
Lol who said I wanted windows 7? The picture up there is an example of a dual boot solution for old windows mobile phones. I was more interested in being able to run CM7/MIUI/liquid metal etc at once with minimal effort to change between them. And I'm pretty sure that WP7 doesn't use /system, /data, and /cache partitions.
Very cool idea .if you deside to do it I will be more than happy to help out in any way I can . Even if its not likely to work . It's still going to be a lot of fun trying .lol .cm and sense together . Or meego perhaps?
Sent from my HTC Vision using XDA App
mejorguille said:
Lol who said I wanted windows 7? The picture up there is an example of a dual boot solution for old windows mobile phones. I was more interested in being able to run CM7/MIUI/liquid metal etc at once with minimal effort to change between them. And I'm pretty sure that WP7 doesn't use /system, /data, and /cache partitions.
Click to expand...
Click to collapse
BAM!! +1000
Sent from my Liquid Metal using XDA App
awesome idea
I think this is a genius idea, and would have incredible implications if achieved. I also would be willing to donate to anyone who pulls off a functional and reproducible dual boot.
bahmanxda said:
Very cool idea .if you deside to do it I will be more than happy to help out in any way I can . Even if its not likely to work . It's still going to be a lot of fun trying .lol .cm and sense together . Or meego perhaps?
Sent from my HTC Vision using XDA App
Click to expand...
Click to collapse
Me wants!!!! 2.4 as a daily,.... 3.0 for the eye candy!!!
Is there anything you genius'/genii/clever people can take from Kendon's Dualizer? http://www.villainrom.co.uk/forum/s...Dualizer-Dual-Boot-System&highlight=dual+boot
mejorguille said:
So I was thinking...
We have roughly 2 gigs internal on our phones. Using CM7, my /system partition is over 60% empty. Why not install another rom beside it?
Click to expand...
Click to collapse
Excellent idea!
My idea is to partition the storage space into multiple directories that symlinks back to the original partitions only when booted.
For example, The partitioning could look like this:
The system would boot past splash1, where a screen similar to this could show up:
Depending on your selection, it would boot with either /system1 or /system2, symlinked to the original /system.
Click to expand...
Click to collapse
There is already a multiboot bootloader installed on the phone which selects from two boot partitions... "boot" and "recovery". There is virtually no difference between them except for what is actually stored within the partitions.
I know that it is possible to change your mtd partitions, it is a very commonly used hack on the G1 developed by Firerat and lbcoder (thread). If we can take this concept and take it a step further and create our own partitions, this seems feasable.
Click to expand...
Click to collapse
You certainly could add or remove partitions from an MTD device using that approach, UNFORTUNATELY THOUGH, Vision does NOT HAVE an MTD device. It has an eMMC.
The eMMC also happens to be a bit of a WEIRD one. At the front of the eMMC there is a *fake* partition table, which is defined by the SPL. I am not aware of any way to alter this partition table except by modifying the SPL.
So repartitioning may not work.
However, symlinks WILL work.
Some thoughts/concerns:
-both roms would have to use the same kernel as the kernel is one of the first things to boot.
Click to expand...
Click to collapse
Nope. Put one kernel in the boot partition, the other one in the recovery partition. When you want to boot the second system image, simply boot into "recovery".
-space for apps might be a bit tight for some, so A2SD might need to be used
Click to expand...
Click to collapse
Easy
-we would need a modified recovery image in which you have to specify which /system a rom would be copied to
Click to expand...
Click to collapse
Trivial
-sharing /data and /cache might be possible, but might lead to problems with dramatically different roms.
Click to expand...
Click to collapse
Cache shouldn't be any problem, just wipe it on boot. Userdata would have to be manipulated in the exact same manner as system.
-how would we go about setting up the screen to select which rom to boot?
-the closest thing to dual booting that we can do now would be /sd-ext based roms like old HD2 roms or Enomther's rom from before we had perm root
Click to expand...
Click to collapse
Already answered. Boot recovery to boot the second system.
My programming knowledge is limited to HTML and flash, and I am a linux noob so I can't do much more than build a rom from source or changing out/modifying some png's for a theme.
If my idea seems feasible somebody else would have to code it. If you can come up with a better idea for dual boot, then by all means, share
Click to expand...
Click to collapse
Ok, now how I would do this is actually fairly simple to implement;
The boot image contains the basic structure of the root filesystem and sets up and mounts system and data.
It simply needs to be changed like this;
Destroy mountpoints "/system" and "/data".
Create new mountpoints "/base-system" and "/base-data".
Change the mounts for the system and data partitions to be mounted at the new mountpoints.
Create SYMLINKS "/system" --> "/base-system/system1" and "/data" --> "/base-data/data1" on the *first* boot image (to be installed to the "boot" partition), and "/system" --> "/base-system/system2" and "/data" --> "/base-data/data2" on the *second* boot image (to be installed to the "recovery" partition).
And that should basically do it.
This can also be used to boot Maemo/MeeGo.
This guy is already working on it, it is suppose to release soon.
http://forum.xda-developers.com/showthread.php?t=847423
I can't wait.
bahmanxda said:
Very cool idea .if you deside to do it I will be more than happy to help out in any way I can . Even if its not likely to work . It's still going to be a lot of fun trying .lol .cm and sense together . Or meego perhaps?
Click to expand...
Click to collapse
Not likely to work?!?! lol that's not very encouraging
DarkPyroGuy 09 said:
This guy is already working on it, it is suppose to release soon.
http://forum.xda-developers.com/showthread.php?t=847423
I can't wait.
Click to expand...
Click to collapse
Nah, booting from the sdcard isn't what I'm trying to accomplish. I want something on internal NAND, it would perform better (Look at the HD2).
riahc3 said:
This can also be used to boot Maemo/MeeGo.
Click to expand...
Click to collapse
It could, but as far as I'm aware there is no active effort of porting meego to the G2. Development stopped on the HD2 port, and now that nokia is out of the picture I imagine meego will die down.
There is already a multiboot bootloader installed on the phone which selects from two boot partitions... "boot" and "recovery". There is virtually no difference between them except for what is actually stored within the partitions.
Click to expand...
Click to collapse
Very good point, but would getting rid of a functional recovery be very practical? How would you approach rom upgrades? a PC based update system like ODIN for samsung phones? Fastboot? Or maybe you mean installing a new, separate boot partition.
You certainly could add or remove partitions from an MTD device using that approach, UNFORTUNATELY THOUGH, Vision does NOT HAVE an MTD device. It has an eMMC.
The eMMC also happens to be a bit of a WEIRD one. At the front of the eMMC there is a *fake* partition table, which is defined by the SPL. I am not aware of any way to alter this partition table except by modifying the SPL.
So repartitioning may not work.
However, symlinks WILL work.
Click to expand...
Click to collapse
Yeah we definitely don't want to mess with the SPL. I remember all the bricks from haykuro's SPL for having an incompatible radio/spl/recovery combination.
Nope. Put one kernel in the boot partition, the other one in the recovery partition. When you want to boot the second system image, simply boot into "recovery".
Click to expand...
Click to collapse
Again, I really wouldn't be happy loosing the recovery image. I mean, if you screw something up, boot to recovery, wipe, and reflash and you are good. If we replaced the recovery, to fix a problem you would have to be near a pc, boot to fastboot, wipe all, flash a recovery, boot to recovery, install a rom (or directly a PC10IMG.zip). I.E., the process would not be very noob friendly.
Cache shouldn't be any problem, just wipe it on boot. Userdata would have to be manipulated in the exact same manner as system.
Click to expand...
Click to collapse
When you wipe cache it takes considerably longer to boot, so maybe we should create separate cache partitions.
Already answered. Boot recovery to boot the second system.
Ok, now how I would do this is actually fairly simple to implement;
The boot image contains the basic structure of the root filesystem and sets up and mounts system and data.
It simply needs to be changed like this;
Destroy mountpoints "/system" and "/data".
Create new mountpoints "/base-system" and "/base-data".
Change the mounts for the system and data partitions to be mounted at the new mountpoints.
Create SYMLINKS "/system" --> "/base-system/system1" and "/data" --> "/base-data/data1" on the *first* boot image (to be installed to the "boot" partition), and "/system" --> "/base-system/system2" and "/data" --> "/base-data/data2" on the *second* boot image (to be installed to the "recovery" partition).
And that should basically do it.
Click to expand...
Click to collapse
Thanks for the detailed post dhkr234, you bring up a lot of good points and your method would be the easiest to implement, but unless I'm understanding something wrong, it would be not very friendly to the end user with no recovery image.
[QUOTE
Yeah we definitely don't want to mess with the SPL. I remember all the bricks from haykuro's SPL for having an incompatible radio/spl/recovery combination[/QUOTE]
I disagree... I think this is exactly what needs to be worked on. The devs eventualy got the G1 safe to flash the spl... and what's a few bricks if it means we can resize any and every partition on the device! Some one with some real skill with spl programing can figure it out... I have faith!
On a side note if we could "hack" the spl and re-partition the eMMC maybe we could reformat it to a faster file system... like they did at the factory and why our 4gig turned into 2... I would gladly trade that for 1gig if it is twice as fast! (Especially if I could change back)
Sent from my HTC Vision using XDA App
TheNewGuy said:
[QUOTE
Yeah we definitely don't want to mess with the SPL. I remember all the bricks from haykuro's SPL for having an incompatible radio/spl/recovery combination
Click to expand...
Click to collapse
I disagree... I think this is exactly what needs to be worked on. The devs eventualy got the G1 safe to flash the spl... and what's a few bricks if it means we can resize any and every partition on the device! Some one with some real skill with spl programing can figure it out... I have faith!
On a side note if we could "hack" the spl and re-partition the eMMC maybe we could reformat it to a faster file system... like they did at the factory and why our 4gig turned into 2... I would gladly trade that for 1gig if it is twice as fast! (Especially if I could change back)
Sent from my HTC Vision using XDA App
Click to expand...
Click to collapse
Yeah, but on the G1's we have JTAG to bring it back to life. And the eMMC partitioning the 4 gigs in 2 is irreversible. CM7 already increased its efficiency though EXT4 instead of EXT3
mejorguille said:
Yeah, but on the G1's we have JTAG to bring it back to life. And the eMMC partitioning the 4 gigs in 2 is irreversible. CM7 already increased its efficiency though EXT4 instead of EXT3
Click to expand...
Click to collapse
Yea that's basically were I got the idea.... but there has to be something like Jtag for the G2. I mean our phones aren't born with all this great stuff! LOL they start out completely bare and the OS,spl,bootloader,and who knows what else gets added on.. so it has to exist. And I know the 4gigs to 2 is irreversible but what about formatting the 2gigs we have down to one? With the right partition layout( I don't use any where near the 1.3 gigs I have on apps) we could cut it in half and still have enough room. And this would all just be one of the possible things to do if we had a hacked spl like the G1.
But I am no dev and I can't complain(or help)... just thinking out loud.
Sent from my HTC Vision using XDA App
Well i had an idea since we don't use the /cache partition, well i don't i was thinking we could use it as RAM.
Any ideas are welcome
LOL no ideas huh.....
Me either.... i wont give up tho i know for sure there is a way...
Hi
If you want a challenge try to get senors working on cm7.
Sent from my XT720 using XDA Premium App
how would that effect the ability to download market apps if its not available?
mchlbenner said:
Hi
If you want a challenge try to get senors working on cm7.
Sent from my XT720 using XDA Premium App
Click to expand...
Click to collapse
Its built on Korean right... lol i haven't even looked at it yet.... i would really like to get a fully 100% kick ass pure android working first.....
Call it a learning experience.
Because everything i know i learned here watching guys like Mz and KhP.
i need to get this finished first..
still imagine unlocking 100mb of ram bro.... cause thats what the /cache is man swap or RAM if i get that unlocked ouuuuuuuuuuuuuuuuuuuuu
mrmako777 said:
how would that effect the ability to download market apps if its not available?
Click to expand...
Click to collapse
Go away kid you bother me............
no effect.... no relevance for that matter LOL
but maybe you could help me.....
Has anyone really been far even as decided to use even go want to do look more like?
And if they did.... what about if they accidentally the whole thing?
mrmako777 said:
how would that effect the ability to download market apps if its not available?
Click to expand...
Click to collapse
hellmonger said:
no effect.... no relevance for that matter LOL
Click to expand...
Click to collapse
I don't know about that. In other ROMs, with the Dalvik on /cache larger apps, e.g. Angry Birds, wouldn't download (not enough space) when the /cache partition was to full.
You could maybe make a swap file on /cache (and an additional swap file on /data) and throw in some of the other useless small partitions. But that's still going to require fastboot.
I like using /cache for /data/dalvik-cache though and I used to get pretty close to filling it. CyanogenMod is sort of nice in that it will actually split the cache between /cache/dalvik-cache and /data/dalvik-cache with /cache/dalvik-cache holding the system apps and /data/dalvik-cache holding the downloaded cache.
3rdstring said:
I don't know about that. In other ROMs, with the Dalvik on /cache larger apps, e.g. Angry Birds, wouldn't download (not enough space) when the /cache partition was to full.
Click to expand...
Click to collapse
I was reading today on reddit that some people divert /cache to the sdcard so that large downloads work. I haven't tried it though.
Mioze7Ae said:
I was reading today on reddit that some people divert /cache to the sdcard so that large downloads work. I haven't tried it though.
Click to expand...
Click to collapse
Hmm.. Dunno about this one as well. but I never had that error, and I usually download the ROMs via my phone.
good luck! then we wont have to partition our sd card for swap anymore! possibly better battery life than swap on sd as less power is needed too!
Before you judge I'm running iceandfire 3.0 overclock at 900 and getting 13,566 to 14,000.
This build is stupid fast.
One issue sensors no big deal you can't do it I will find someone who can.
Sent from my XT720 using XDA Premium App
hellmonger said:
Go away kid you bother me............
no effect.... no relevance for that matter LOL
but maybe you could help me.....
Has anyone really been far even as decided to use even go want to do look more like?
And if they did.... what about if they accidentally the whole thing?
Click to expand...
Click to collapse
Like 3rd string mentions, cache size determines the size of an app you can download from the market as the market uses /cache as a repository to download/install apps...at least that's what I've noticed
Sent from my Milestone XT720 using Tapatalk
mchlbenner said:
Before you judge I'm running iceandfire 3.0 overclock at 900 and getting 13,566 to 14,000.
This build is stupid fast.
One issue sensors no big deal you can't do it I will find someone who can.
Sent from my XT720 using XDA Premium App
Click to expand...
Click to collapse
come on he wasnt saying he did not want to help... cant you read what Hellmonger said carefully? anyway, wouldnt it be good if you could use cache as swap? makes things more complete now that there are already so many good roms for our phone. since we are almost making 2.2 perfect, why not just do a little more, instead of leaving it there and starting to work on 2.3 where theres much more work left to do...
So i think Mz has the right idea..
But do we really have to set it up as swap the whole point ois to get this set up as ram so we dont have to fast boot anymore....
mrmako777 said:
Like 3rd string mentions, cache size determines the size of an app you can download from the market as the market uses /cache as a repository to download/install apps...at least that's what I've noticed
Sent from my Milestone XT720 using Tapatalk
Click to expand...
Click to collapse
The app will be downloaded to /sdcard/Download folder
kernel dont have swap support, so you can't use it from kernel layer. maybe you may find some swap functions in dalvik virtual machine layer, but I don't sure is there any
fjfalcon said:
kernel dont have swap support, so you can't use it from kernel layer. maybe you may find some swap functions in dalvik virtual machine layer, but I don't sure is there any
Click to expand...
Click to collapse
still no luck...
my goal is to stop the whole fastbot thing and use that cache partition as RAM, i already know how to set the download cache directory to SD card
on my ROM it's already implemented...
/cache as Ram.....
We really need to pull our bootloaders and decomplile them to see if there's a way to do the fastboot ourselves. The people that have looked the hardest at the bootloader are on Milestone A853, but according to them they don't have a working "fastboot boot" so that code pathway is missing from their studies.
What we need to find out is what the pathway through the bootloader is that ends up with booting a custom boot.img from RAM (i.e. does fastboot boot go through the entire boot stack or not and if it does how does it convince it to skip the check). In other words I have two mental two models for how fastboot works:
Model 1
Start boot process
Read flags that direct boot to fastboot
Load and execute fastboot bootloader
fastboot reads kernel from USB into memory
fastboot continues boot using the kernel in memory
Model 2
Start boot process
Read flags that direct boot to fastboot
Load and execute fastboot bootloader
fastboot reads kernel from USB into memory
fastboot sets up the phone for boot of the memory-loaded kernel
fastboot restarts boot process
Read flags that direct boot to load and execute the kernel from RAM
So the question is which one is correct? Does fastboot boot continue the current boot process, or does it alter the next boot? That's the big question. If it's model 2, here's an outline for a possible attack:
Attack for Model 2
Normal boot of blessed kernel through sh_hijack.sh
hijack loads a new kernel from the phone into memory
hijack sets up the phone for boot of the memory-loaded kernel
hijack set boot flags for fastboot boot
hijack restarts boot process
Boot memory loaded kernel
So how do we figure out if XT720 uses #1 or #2?
FYI: these are the A853 decompiled bootloaders: https://gitorious.org/droid/reversed (see the asm folder inside the source tree--we need this for XT720 so that we can understand what fastboot boot is doing)
I believe a 2nd had beem complied but it would not boot radio and we don't have a baseband made.
Sent from my Milestone using XDA Premium App
Alright everyone... future development for the Epic will start moving quickly, and I ask that everyone PLEASE watches this and pays attention to eliminate future questions. This video explains MTD. Please keep discussion going, as I'd like to see this on the first page for everyone.
WATCH THIS:
http://www.youtube.com/watch?v=ds9rwAoI2IQ
Don't be afraid to subscribe and give it a thumbs up
Thanks for this, users are going to be quite confused, and this will help a lot.
For those who might be a bit more interested in the differences:
BML and MTD's main difference is how they access the flash memory. Flash file systems, like YAFFS2, are designed to access the raw memory, without anything particularly fancy sitting in between, while block file systems, like RFS, EXT4, and others, operate on block-level storage devices. This is why your hard drives and SSDs use file systems like EXT4 - they have controllers that expose the block layer. The same applies to your OneNAND device in your Epic.
Samsung's OneNAND product in this device uses what they call XSR - "XSR is a layer between filesystems and NAND devices that uses logical sector relocation to prevent too many overwrites of the same block and to relocate bad blocks." There are two layers to that: "BML (Block Management Layer) are the devices on bottom of XSR exatly on top on NAND low level drivers.", and "STL (Sector Translation Layer) are the logical devices on top of XSR" (for data partitions). In using MTD, XSR is essentially eliminated completely. That's not to say the tech is gone, as Odining back to stock (as QB points out) is plenty possible, but it's no longer in use.
MTD stands for Memory Technology Device, and is "a new type of device file in Linux for interacting with flash memory". It "was created to provide an abstraction layer between the hardware-specific device drivers and higher-level applications". Its purpose is, was to put an end to the translation - flash memory devices like the OneNAND device in our Epics are not block-level devices, so why try to shoehorn them? In combination with the more 'direct', so to speak, access to the memory device that MTD provides, flash file systems like YAFFS2 handle all the optimization required for proper data handling. In a way, they combine the functions of something like Samsung's XSR and a traditional file system.
YAFFS "is a robust log-structured file system that holds data integrity as a high priority", and a "secondary YAFFS goal is high performance". I'm sure some of you will be wondering what read/write performance will look like after the transition - I am too. But that will come.
Don't be afraid of change, folks.
References:
http://movitool.ntd.homelinux.org/trac/movitool/wiki/RFS
http://en.wikipedia.org/wiki/Memory_Technology_Device
http://en.wikipedia.org/wiki/YAFFS
Great video as always qbking77.. This actually gives me a reason to hold off a little longer on getting a new device..
this is incredibly good news so the question is if its possible to run cwm and change the file system like how we already do between rfs and ext4 but now to yaff s? qb king mentioned odin but I would assume it what I mentioned could be possible.
Sent from my SPH-D700 using XDA App
ddrbeastappv1 said:
this is incredibly good news so the question is if its possible to run cwm and change the file system like how we already do between rfs and ext4 but now to yaff s? qb king mentioned odin but I would assume it what I mentioned could be possible.
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
I'm sure the awesome devs we have will figure out a way, hell I'd like to contribute if I get some time as well. We might have to start with odin, but we are already able to change file structure by simply flashing a rom. Definitely going to have to do some research.
Semi Nerd Rage! Lol not really (Told you gameboyking24)
Guys, the conversion from RFS to EXT4(vice versa) is not the same way you'd go about getting to YAFFS2. Take it as this way, BML is a race track where only rfs and ext4 can race(in theory) while MTD is a track umpteen miles away where yaffs2 resides racing alone(in theory). BML and MTD both the same as they serve the same purpose but handle it in a different means. They are exactly what they've been explained as but in simpler terms they are partition maps. Not a filesystem. Our filesystems reside on the mapping of a BML or MTD as of recent partition map which allows us to customly resize partitions where we see fit. If and when you decide to make the move to MTD all things BML are restricted to you until you odin and repartition back to BML. So it's at the moment not the matter of a dev making an RFS to YAFFS2 zip, unfortunately there is a lot more involved and put into this whole process.
Sent from my Epic 4G
Thank you Apro. I understand a little better now but I am unfortunately fearful of Odin since i've swapped at least 7 epics at the sprint store because I either fail at the odin process or fail at installing drivers ><
Sent from my SPH-D700 using XDA App
ddrbeastappv1 said:
Thank you Apro. I understand a little better now but I am unfortunately fearful of Odin since i've swapped at least 7 epics at the sprint store because I either fail at the odin process or fail at installing drivers ><
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
Oh it's no problem at all man. I would for the meantime stay away from MTD for a bit until there is a lot more going on, so you've a stable failsafe rom over on that format.
It gets 2100 in quadrant.
So when the roms that work on MTD tables come out, will we first have to use Odin to repartition/ flash the roms in odin as opposed to clockwork. I saw mentioned that it would be possible to flash back to stock in odin to get BML back. My question more simply phrased, how will we convert from BML to MTD?
counterfeit187 said:
So when the roms that work on MTD tables come out, will we first have to use Odin to repartition/ flash the roms in odin as opposed to clockwork. I saw mentioned that it would be possible to flash back to stock in odin to get BML back. My question more simply phrased, how will we convert from BML to MTD?
Click to expand...
Click to collapse
flash using an update.zip
And I thought odining back to stock was hard enough XD
Looks like I chose the right phone was very tempted to get the evo ^^
Sent from my OG Epic
I like the part at the beginning where you touch your phone obsessively.
Does a ROM have to support MTD and is it only in the kernel for that? Will the ROM be able to be used on either BML or MTD at that point?
This is some really exciting stuff. I am planning on keeping the epic until the new LTE phone roll out, and this has given me some hope for ICS and CM9.
Thanks to all the devs that put in some serious time on this.
kennyglass123 said:
Does a ROM have to support MTD and is it only in the kernel for that? Will the ROM be able to be used on either BML or MTD at that point?
Click to expand...
Click to collapse
As far as I know not necessarily. However it's likely there will be Roms which are more catered for MTD in the separation of sizes. So if it requires more space in /System for essentials to run, it'll likely be an MTD only thing. But if the size of the System partition isn't needed to change then you can run it on either of the two ,as long as the kernel you're using on BML has what the rom needs to properly boot. If that makes sense?
I was going back and forth a bit lol.
AproSamurai said:
As far as I know not necessarily. However it's likely there will be Roms which are more catered for MTD in the separation of sizes. So if it requires more space in /System for essentials to run, it'll likely be an MTD only thing. But if the size of the System partition isn't needed to change then you can run it on either of the two ,as long as the kernel you're using on BML has what the rom needs to properly boot. If that makes sense?
I was going back and forth a bit lol.
Click to expand...
Click to collapse
So current ROMs would likely work on MTD with the right kernel, but ROMs designed on MTD might not work on BML?
Specialksg1 said:
So current ROMs would likely work on MTD with the right kernel, but ROMs designed on MTD might not work on BML?
Click to expand...
Click to collapse
Kind of. For MTD, ROMs need more than just a new kernel: they need a different updater-script and other mtd scripts (like updater.sh and blm_over_mtd.sh). For example, on my MIUI builds, I port from NS4G and Fascinate which use MTD, but if I delete the MTD files and add our kernel and updater-script, it is now bml. Also, most MTD ROMs will work on BML except for ICS or anything that has too big of a /system folder. And with the right modifications, any BML ROM can work on MTD. Hopefully that answers your questions and other peoples'.
xboxfanj said:
Kind of. For MTD, ROMs need more than just a new kernel: they need a different updater-script and other mtd scripts (like updater.sh and blm_over_mtd.sh). For example, on my MIUI builds, I port from NS4G and Fascinate which use MTD, but if I delete the MTD files and add our kernel and updater-script, it is now bml. Also, most MTD ROMs will work on BML except for ICS or anything that has too big of a /system folder. And with the right modifications, any BML ROM can work on MTD. Hopefully that answers your questions and other peoples'.
Click to expand...
Click to collapse
That clears everything up ... leave it to you guys lol Exciting times, good luck and god speed!
New member piping in for the first time. I love all the information that I've been picking up here! Thanks to everyone who participates...
I'm a PC person and this is my first android device, so please bear with me.
When my Tab 4 had the stock rom, it showed 3.28gb as the minimum required to run system blah blah under settings/device/storage
I've now installed a custom rom using TWRP flash.
The rom is supposed to be a lightweight version with a lot of the bloatware removed, but the OS still shows 3.28gb as system space.
Why did the system space not reduce if the OS is slimmed down version ??
Did I flash incorrectly ??, in the PC world if you used a smaller OS image it would give the option to make a smaller OS partition and free up more space for data partitions.
Am I missing something here ??
Do Android roms not resize the partitions ??
Can we resize the partitions manually before installing the rom ??
anyone ??
sid21177 said:
anyone ??
Click to expand...
Click to collapse
Depends on the rom. First off, which model number do you have (Settings > about device > model number)? Secondly, which rom did you install? (I'm going to assume you installed some sort of stock-based rom). To tentatively answer your question, touchwiz roms (i.e. stock based) usually don't free up much space because even though it's a "custom rom" it's in many senses the same thing, many if not all of the same system apps/processes. AOSP-based roms (the most well known tends to be Cyanogenmod and its derivatives) usually free up a lot more space. A quick numerical example: my tablet came with something like 300 or 400 system apps comprising the stock OS. Simply put, I wiped everything and installed cyanogenmod, now the corresponding number is somewhere between 70 to 90 system apps. In other terms Samsung's touchwiz (the stock Samsung version of Android) is hideously bloated, first with all the unnecessary crap (adware, unnecessary apps, gimmicky features, etc.) they include, and also because they essentially built their own android environment (touchwiz) on top of google's stock android. I'm just speaking from what I've picked up from personal experience, I'm sure someone could give you a much better technically in-depth answer than this, but I saw your question and felt bad that you hadn't gotten an answer, so I hope this has helped in any way. If not, well, sorry
thisisapoorusernamechoice said:
Depends on the rom. First off, which model number do you have (Settings > about device > model number)? Secondly, which rom did you install? (I'm going to assume you installed some sort of stock-based rom). To tentatively answer your question, touchwiz roms (i.e. stock based) usually don't free up much space because even though it's a "custom rom" it's in many senses the same thing, many if not all of the same system apps/processes. AOSP-based roms (the most well known tends to be Cyanogenmod and its derivatives) usually free up a lot more space. A quick numerical example: my tablet came with something like 300 or 400 system apps comprising the stock OS. Simply put, I wiped everything and installed cyanogenmod, now the corresponding number is somewhere between 70 to 90 system apps. In other terms Samsung's touchwiz (the stock Samsung version of Android) is hideously bloated, first with all the unnecessary crap (adware, unnecessary apps, gimmicky features, etc.) they include, and also because they essentially built their own android environment (touchwiz) on top of google's stock android. I'm just speaking from what I've picked up from personal experience, I'm sure someone could give you a much better technically in-depth answer than this, but I saw your question and felt bad that you hadn't gotten an answer, so I hope this has helped in any way. If not, well, sorry
Click to expand...
Click to collapse
I installed a custom rom which is about 400mb in size. I assume the initial system partition was set to 3.28gb as the stock rom is a lot larger.
So, I thought that when I install a smaller rom, the space on the device will free up to be used as data storage, like it would on a PC when you image the drive with a smaller OS image.
But there was no change to the system partition size, apparently android custom rom flashes do not touch the partition size, they just reduce the content on the partition
Unless I got this figured out wrong
sid21177 said:
I installed a custom rom which is about 400mb in size. I assume the initial system partition was set to 3.28gb as the stock rom is a lot larger.
So, I thought that when I install a smaller rom, the space on the device will free up to be used as data storage, like it would on a PC when you image the drive with a smaller OS image.
But there was no change to the system partition size, apparently android custom rom flashes do not touch the partition size, they just reduce the content on the partition
Unless I got this figured out wrong
Click to expand...
Click to collapse
Yeah sorry after I answered I read more carefully and saw you were asking more about the partition size, I apologize that was my bad. I'm definitely out of my league here, all I know is bad things (like hard bricks) tend to happen when people try re-partitioning (I'm not saying it isn't possible necessarily, just that it's certainly not to be done lightly or casually)
But there was no change to the system partition size, apparently android custom rom flashes do not touch the partition size, they just reduce the content on the partition
Click to expand...
Click to collapse
Correct to this line. I think this is the core of what you were asking and what I missed.
thisisapoorusernamechoice said:
Yeah sorry after I answered I read more carefully and saw you were asking more about the partition size, I apologize that was my bad. I'm definitely out of my league here, all I know is bad things (like hard bricks) tend to happen when people try re-partitioning (I'm not saying it isn't possible necessarily, just that it's certainly not to be done lightly or casually)
Correct to this line. I think this is the core of what you were asking and what I missed.
Click to expand...
Click to collapse
No issues
If it was a PC I'd tinker around in a heartbeat, with devices & embedded roms its a little more hairy
sid21177 said:
No issues
If it was a PC I'd tinker around in a heartbeat, with devices & embedded roms its a little more hairy
Click to expand...
Click to collapse
you can move apps from the data partition to system, this will give you more free space.
partitioning is also possible, there are custom roms from other devices which do so.
sub77 said:
you can move apps from the data partition to system, this will give you more free space.
Click to expand...
Click to collapse
How to do this ??
https://play.google.com/store/apps/details?id=de.j4velin.systemappmover&hl=de
sid21177 said:
How to do this ??
Click to expand...
Click to collapse
On average how much space can you free up by doing this? Thanks In advance!!!
Sent from my SM-G920T using XDA Free mobile app
xda23 said:
On average how much space can you free up by doing this? Thanks In advance!!!
Sent from my SM-G920T using XDA Free mobile app
Click to expand...
Click to collapse
First you should root your device to get the permissions to write any data to system partition.
Then you can use apps like Titanium Backup, .... to move apps to system partition.
Freeing space depends on the size of the app you are moving.
Don't root to just move apps to system partition. Use a sdcard intead.
You might have seen this guide on XDA, but is out-dated and only seems to work on stock firmware. What about people people running CM13, will it work, or will it brick your device?
This guide is updated and works with CM13 tested by me, it was also written with the i9300 16GB model in mind.
FAQ: next post
I take NO responcebility for any bricks, that's on you. Exactly like rooting, or installing anything 3:rd party (right?). Either is is my responsibility if any data is lost.
If you don't follow the guide, and adventure on your own, there's no one to blame but yourself when **** hits the fan.
Now, let's have a look at my partitions before modifying them (kB):
Code:
Filesystem Total Used Available Use% Mounted on
mmcblk0p8 1032088 17732 1014356 2% /cache
mmcblk0p12 11901576 6355436 5546140 53% /data
mmcblk0p12 11901576 6355436 5546140 53% /sdcard
mmcblk0p10 564416 8964 555452 2% /preload
mmcblk0p9 1548144 632704 915440 41% /system
mmcblk0p3 20144 9568 10576 47% /efs
As you can see, stock paritioning is bad. /preload and /cache has a lot of available space which takes up a lot of unnecessary space.
We can minimize all the partitions and use the space to increase your internal storage, neat; let's do it!
1. Check for buggy eMMC chip
First of all we'll be checking if your chip is possible to SDS (sudden death syndrome) which basicly corrupts your eMMC (internal storage) chip.
This only effects the 16GB model, if you're on another model just skip to the flashing part.
A. Download the app eMMC Brickbug Check app from the Play Store.
B. Check eMMC
Check if your device has the following under eMMC chip:
Type: VTU00M
FwRev: 0xF1
If the values match, you should update to the latest ROM + kernel available ASAP, which should fix SDS, if you don't; your eMMC chip might corrupt under the process of flashing REPIT.
2. Flashing guide
A. Before we begin
- Make sure that you're running the latest version of TWRP (i9300, i9305). Any other recovery and the script will NOT work.
- Do NOT continue if you're running stock, or planning to do so. This script is only tested on official CM13.
- Make sure you're plugged into a power source, and not a computer; or else partitions may fail to un-mount.
- Do a backup of your rare cat images so they don't get lost in the worst scenario.
- (optional) If you want to configure the script, see this.
B. Download required tool
We'll be using ourselves with the tool REPIT made by @Lanchon.
Without it I wouldn't make this guide as it is the only(CN) flexible tool for modifying partitions in Android.
Download the required flashable zip file: [updated 2017-01-22]
- i9300 - here
- i9305 - here
Make sure you DON'T rename it; copy it to your device.
C. Boot into recovery - volume up + home button + power button when powered off
D. Flash the zip file
- This process is a really long one, do NOT interrupt the process.
- If the flashing fails, it may tell you that it copied itself to /tmp, navigate to /tmp and flash the script again.
- If x partition fails to un-mount, try un-mounting it via TWRP > Mount.
Inside TWRP navigate to Install > Navigate to saved REPIT and select > Swipe to confirm flash.
3. Done!
You may now restart your device and verify the extra utilized internal storage.
It's not that hard eh? That's because @Lanchon did a great job on his project available on GitHub. Him and I worked closely on #22 to add support for the i9300.
After re-partitioning (still kB):
Code:
Filesystem Total Used Available Use% Mounted on
mmcblk0p8 32240 4200 26404 14% /cache
mmcblk0p12 13457732 574316 12199796 4% /data
mmcblk0p12 13457732 574316 12199796 4% /sdcard
mmcblk0p10 8048 4120 3520 54% /preload
mmcblk0p9 1548144 638168 909976 41% /system
mmcblk0p3 20144 9568 10576 47% /efs
It seems like we've gained 1.5GB in local storage, hoorah! Totally didn't steal from other partitions
Worth it? (my opinion)
Unless you REALLY need that 1.5GB of extra storage; NO, not at all.
On Android 6+ (CM13) sd-cards are now implemented like normal internal storage. Just buy a 8GB micro sd-card which costs a couple of bucks these days and save yourself some trouble.
Not only that, recently a user possibly got SDS (sudden death syndrome, do your own research) after flashing REPIT. Did my own research and I updated the guide with a step to check for this buggy eMMC chip.
Credit:
- @Lanchon for REPIT.
- @forumber2 for original guide.
QnA:
The questions are kinda copied from the old guide.
Q: Why is /cache a large partition?
A: It's because stock software updates saves in the partition. The partition was extended(CN) when upgrading to Android 4.3, as the update was so large, the cache partition had to be as well. AOSP does NOT use the partition when updating.
Q: What is the /preload partition for?
A: It's only really used if you bought the phone locked. Many mobile operators put in extra apps, and bloatware too in the partition only utilized in stock firmware; and even then... There's some random Samsung crap too. REPIT minimizes the partition.
Q: Any consequences of flashing?
A: Yes, you will NOT be able to install stock firmwares (assuming that you're not running stock). A undo is easy as the script is so flexible.
You will also burn a lot of eMMC life cycles using REPIT so don't do it often, and I hope you've read 1. where I covered the buggy eMMC chip thingy.
Q: Something went wrong with flashing the zip file!
A: Please upload the REPIT log usally found in the folder where you placed the flashable zip file to dropbox, or https://paste.tinyw.in; apparently pastebin doesn't like long logs. Can also be in /tmp. Otherwise you can copy the whole TWRP log found in /tmp/recovery.log, /cache/recovery/log or /cache/recovery/last_log. NEVER copy the whole log and make a post out of it, you're spamming the thread by doing so. Issues with REPIT should NOT be reported here, instead go to the REPIT GitHub page here.
Q: I want to undo these changes!
A: Since @Lanchon is taking over this thread :laugh:, ask him. Sorry for me not doing my homework.
Q: How about the x GB model?
A: They all work, REPIT is designed to assign any leftovers to the partition we use.
More questions? Bring them on.
Reserved #2
May be it's better to give proper credits too considering it was a big mess up in past.
Sent from my "i9300/1+2" powered by Carbon/Temasek
Fueled by 7000mAh ZeroLemon Battery
nicesoni_ash said:
May be it's better to give proper credits too considering it was a big mess up in past.
Sent from my "i9300/1+2" powered by Carbon/Temasek
Fueled by 7000mAh ZeroLemon Battery
Click to expand...
Click to collapse
Woops, I made the guide in notepad++, and accedently removed some lines when editing it; including a better credit to @Lanchon; adding in a new one now.
Hawaii_Beach said:
Woops, I made the guide in notepad++, and accedently removed some lines when editing it; including a better credit to @Lanchon; adding in a new one now.
Click to expand...
Click to collapse
I meant in your op too.
Sent from my "i9300/1+2" powered by Carbon/Temasek
Fueled by 7000mAh ZeroLemon Battery
Btw, is it possible to modify this script somehow so that you can reformat the /cache partition to f2fs? Afaik the minimum size is 100mb.
Sincci said:
Btw, is it possible to modify this script somehow so that you can reformat the /cache partition to f2fs? Afaik the minimum size is 100mb.
Click to expand...
Click to collapse
No, I'm sorry. It is already known, on GitHub: #8.
The minimum size of /cache? The script sets /cache to 32240kB which is 32MB..
nicesoni_ash said:
I meant in your op too.
Click to expand...
Click to collapse
OP?
Hawaii_Beach said:
No, I'm sorry. It is already known, on GitHub: #8.
The minimum size of /cache? The script sets /cache to 32240kB which is 32MB..
Click to expand...
Click to collapse
After I read your conversation with @Lanchon on git, it seems to me that there is no need to wipe data and it will still work, it's that right?
OP - Original Post basically referred to first post.
Sent from my "i9300/1+2" powered by Carbon/Temasek
Fueled by 7000mAh ZeroLemon Battery
nicesoni_ash said:
After I read your conversation with @Lanchon on git, it seems to me that there is no need to wipe data and it will still work, it's that right?
OP - Original Post basically referred to first post.
Click to expand...
Click to collapse
Yes, you don't need to wipe /data. It just makes things faster; as you wont have to move the content around. Without wiping, it will take a longer time to re-partition.
The script will NOT wipe /data except you add +wipe to -data=max (-data=max+wipe-i9300)
OP has so many meanings, it's f***ed.
Hawaii_Beach said:
On Android 6+ (CM13) sd-cards are now implemented like normal internal storage. Just buy a 8GB micro sd-card which basicly costs a couple of bucks and save yourself some trouble.
Click to expand...
Click to collapse
hi, thanks for the guide!
actually, the external sdcard will always be slower than the internal eMMC. also, the extra free space gets auto-TRIMmed in /data, making the whole eMMC (and thus your phone) faster. also, adopted storage diminishes the total reliability of your phone and data (more devices can fail).
in all, i'd recommend anybody with less than 2 or 3GB free space in /data to REPIT; it's safe and easy.
---------- Post added at 05:35 PM ---------- Previous post was at 05:22 PM ----------
Sincci said:
Btw, is it possible to modify this script somehow so that you can reformat the /cache partition to f2fs? Afaik the minimum size is 100mb.
Click to expand...
Click to collapse
REPIT does not support f2fs for now.
(future support will not include wipe without resizing, as f2fs does not support that yet.)
but you can get what you want anyway:
"-cache=0.03125+wipe"
actually means
"-cache=0.03125+wipe+ext4"
given that ext4 is the default FS for "cache".
"wipe" means format, and never mind what was there before. even if it was something that wasn't ext4 at all, it will succeed.
so you can use:
"-cache=0.0976+wipe"
to get exactly 100MiB-sized cache (in ext4)
then, afterwards, use TWRP to format cache in F2FS
and you'd get what you want.
but...
DON'T!!!
dont use F2FS in ANY partition besides /data! it makes NO sense!
F2FS has an overhead of about 100MB, so basically you would be creating a /cache that is unable to hold any files at all. (ext4 has 5MB overhead.)
and why have a dysfunctional /cache? what for? to have problems? incompatibilities?
certainly not performance, because cache is NEVER used in android. so why do it?
it's soft of a crazy fad, like /system in f2fs.
/system, the one partition we never write to, lol
---------- Post added at 05:39 PM ---------- Previous post was at 05:35 PM ----------
nicesoni_ash said:
May be it's better to give proper credits too considering it was a big mess up in past.
Sent from my "i9300/1+2" powered by Carbon/Temasek
Fueled by 7000mAh ZeroLemon Battery
Click to expand...
Click to collapse
thanks!
no credit required!!! the GPL allows him to do as he pleases, as long as he doesn't remove the license or claims copyright.
but anyway, thanks for the credit appreciated!
and thanks for invaluable help to port to i9300!!
---------- Post added at 05:43 PM ---------- Previous post was at 05:39 PM ----------
btw, i should start thanking the people who helped with the ports in the comments of the device port file. so far 2. i will back-credit when i get the time.
and i9305 and others are probably trivially supported, i just need the dumps done.
Lanchon said:
really long stuff going on
Click to expand...
Click to collapse
The thing is that not only could REPIT be ported to i9300, but any other Samsung device, right? They all run TouchWiz; for example s4, s5, s6? Have anyone even checked partitions on those devices?
The thing with partitions and the Android community is that almost no one discusses it. If you do a google on partitions on Android; very Little information / threads exist.
Lanchon said:
hi, thanks for the guide!
actually, the external sdcard will always be slower than the internal eMMC. also, the extra free space gets auto-TRIMmed in /data, making the whole eMMC (and thus your phone) faster. also, adopted storage diminishes the total reliability of your phone and data (more devices can fail).
in all, i'd recommend anybody with less than 2 or 3GB free space in /data to REPIT; it's safe and easy
Click to expand...
Click to collapse
To be honest, I never cared about storage speed (same goes for trim), not a heavy user on my phone, and have never been, just doesn't go well when I'm the operator. As long as it doesn't take 1 year to copy my secret .mp4's (ransom.mp4 and many more), there's no worries.
About failure, it's like running a computer. If you shut down a computer without sending signals (unplug from wall etc), it may damage the harddrive; right? Same here. Right?
Any how, If I ever run out of space on my i9300, I'd just add a sd-card. I don't save anything important on my device that doesn't get backed up via TWRP. But..
that's never going to happen! Because my OnePlus One is coming back from RMA service! (finally after 4 months (not kidding)). kinda off topic, but hey; it's my thread right :good:
Hawaii_Beach said:
The thing is that not only could REPIT be ported to i9300, but any other Samsung device, right? They all run TouchWiz; for example s4, s5, s6? Have anyone even checked partitions on those devices?
The thing with partitions and the Android community is that almost no one discusses it. If you do a google on partitions on Android; very Little information / threads exist.
Click to expand...
Click to collapse
lol about the quote
besides the name playing on samsung's PIT files, REPIT can actually work on any device with TWRP support. but the partition layout in most newer devices is friendly enough not to bother. even the stock i9300 layout is sort of friendly. highly problematic are only the devices that shipped before ICS with android 2.x (galaxy S2) or devices that shipped with non-emulated internal sdcard.
discussion is low volume because partitioning is considered 'dangerous'. and it can be, you can brick if you mess up. the idea of REPIT was to make it safe by encapsulating a bit of knowledge of each device in the device port file. motivation was that S2 users suddenly all needed to repit: their devices stopped working after a nightly flash because of /system being too small, it was a mess, lol.
btw, since you asked before, that's the reason why porting is needed: because you can't trust users not to make mistakes with full freedom. users that want full freedom have other tools: gdisk, parted, mkfs.xxx, resize2fs, etc.
Lanchon said:
lol ab...
Click to expand...
Click to collapse
Yeah, I know that other devices doesn't even need to touch the partitions, as it is a waste of time. (so is this??)
edit: still, maybe I want a extra 1.5gb on my s6 Active or whatever.
edit: by for today, it's 00:00 here..
discussion is low volume because partitioning is considered 'dangerous'. and it can be, you can brick if you mess up. the idea of REPIT was to make it safe by encapsulating a bit of knowledge of each device in the device port file. motivation was that S2 users suddenly all needed to repit: their devices stopped working after a nightly flash because of /system being too small, it was a mess, lol.
Click to expand...
Click to collapse
Dangerous!? I've seen way more people fu** their IMEI number (including ME on MINE i9300) by doing something dumb to the /efs content (totally didn't try to unlock the phone), that's dangerous. (got 0049)
The phone was just lying round until I got around to fix it, not going to get into details as XDA doesn't allow this stuff. It was really fustrating as people said that reflashing stock would get back the IMEI (should apparantly work, etc etc).
yet again side tracked, but i'm the operator right? :good: :highfive:
@Lanchon
Since we are talking abt partitions, I would like to ask a question that's not related to this tool but the other way mentioned in first post by flashing a zip file with manually entering the size in script file.
I tried that a while back on my s3 and it worked great. I was on kitkat that time and it was fine till lollipop came. So I flashed lollipop but since the system size was only about 500mb, it failed to flash so I made another zip with system size to 800mb and flashed it again. Although everything went fine but after flashing a new rom or restoring my old backup phone always showed some encryption error and asked to factory reset and even after doing that, still showed the same error even though I never encrypted anything. So the only option was to flash stock with pit file and change the partitions to stock size and then restore or flash a new rom.
I was never able to partition my phone after that coz that error always came back. I have op2 now so all molding goes on it and s3 is like a backup phone but I am still interested to know what was that all about and what could I do to fix that or whether my emmc worn out?
Sent from my "i9300/1+2" powered by Carbon/Temasek
Fueled by 7000mAh ZeroLemon Battery
Hawaii_Beach said:
Dangerous!? I've seen way more people fu** their IMEI number (including ME on MINE i9300) by doing something dumb to the /efs content (totally didn't try to unlock the phone), that's dangerous. (got 0049)
The phone was just lying round until I got around to fix it, not going to get into details as XDA doesn't allow this stuff. It was really fustrating as people said that reflashing stock would get back the IMEI (should apparantly work, etc etc).
yet again side tracked, but i'm the operator right? :good: :highfive:
Click to expand...
Click to collapse
well... effing the bootloader i way worse than borking /efs, believe me.
now, trying to hack /efs WITHOUT A BACKUP (!!) is big jesus f*cking christ sh*t u talking lol!!!
Lanchon said:
well... effing the bootloader i way worse than borking /efs, believe me.
now, trying to hack /efs WITHOUT A BACKUP (!!) is big jesus f*cking christ sh*t u talking lol!!!
Click to expand...
Click to collapse
Hahahaha yep. Didn't know the risk dude.
nicesoni_ash said:
@Lanchon
Since we are talking abt partitions, I would like to ask a question that's not related to this tool but the other way mentioned in first post by flashing a zip file with manually entering the size in script file.
I tried that a while back on my s3 and it worked great. I was on kitkat that time and it was fine till lollipop came. So I flashed lollipop but since the system size was only about 500mb, it failed to flash so I made another zip with system size to 800mb and flashed it again. Although everything went fine but after flashing a new rom or restoring my old backup phone always showed some encryption error and asked to factory reset and even after doing that, still showed the same error even though I never encrypted anything. So the only option was to flash stock with pit file and change the partitions to stock size and then restore or flash a new rom.
I was never able to partition my phone after that coz that error always came back. I have op2 now so all molding goes on it and s3 is like a backup phone but I am still interested to know what was that all about and what could I do to fix that or whether my emmc worn out?
Sent from my "i9300/1+2" powered by Carbon/Temasek
Fueled by 7000mAh ZeroLemon Battery
Click to expand...
Click to collapse
well i cannot answer about scripts and procedures unknown to me but...
an encrypted disk typically is made of 2 things:
-the encrypted disk 'surface' or area (ie: the data)
-and metadata (data describing the data, ie: data describing the encrypted disk)
metadata typically contains:
-cipher info
-and the disk surface encryption key (generated at random), itself encrypted with the access key (such as a passphrase).
why the indirect key? without it:
-changing the passphrase (say, your phone lock pattern) would be a very dangerous operation that would require reading, reencrypting and writing the complete disk, would take a huge amount of time and would drain your battery completely
-erasing the disk would similarly take a long time.
with it:
-when changing the passphrase you just need to reencrypt the surface key with the new passphrase and rewrite the metadata.
-when erasing, just wipe the metadata.
for example the metadata in recent android phones with hardware backing store for keys probably contains:
-cipher info
-and the disk surface encryption key (generated at random), itself encrypted with a secondary key (also random).
the secondary key lives in the hardware keystore. it's generated there and can never leave that processor. the keystore will decrypt the surface key during boot, only if the main processor informs the right passphrase (say, the PIN or pattern). a 4-digit PIN would be very easy to bruteforce, except that the keystore throttles down guesses, and can even wipe the key (rendering the disk forever unreadable) after so many bad guesses.
the keystore should be tamper-proof: a silly small processor, but resistant to voltage spike attacks, rays, etc and decapping to read the storage, to pick up signals in traces, to inject signals in traces, to chip modifications, etc. think of it as the chip in any recent credit card or even some sim cards, but on the main circuit board.
anyway back to metadata in android: it needs to be stored somewhere. the obvious place is an ultra small metadata partition containing just the raw metadata, no file system or anything of the like. this is simple and works great, except for one detail: older phones don't have this partition. basically this means that an android upgrade couldn't give you encryption.
so android can use a "crypto footer": with this scheme the encryptable partition (say /data) has a file system that is 16KiByte short of filling the actual partition, and the 16KiB footer follows. the footer is the metadata.
when you repartitioned before, you probably created a file system that used the complete partition area. there was no space left for the footer, so encryption couldn't be enabled.
you could have solved your issue today by flashing repit with all-default parameters: repit always resizes the encryptable partition's file system to make room for the footer, if not already there.
in REPIT, these commits add general and ext4-particular support for crypto footers:
https://github.com/Lanchon/REPIT/commit/591961adb180a6a03594053a846b698240b4d507
https://github.com/Lanchon/REPIT/commit/de3d3af9813afef7de3a798ce5314c0fb210e30f
https://github.com/Lanchon/REPIT/commit/5c3360b572ff25c7c01d796cabb9400066451ec3
this configures the footer on the i9300:
https://github.com/Lanchon/REPIT/blob/f46b0aafdfeb7860be17a315b4aceb43966325f9/device/i9300.sh#L85