[TOOL] Lanchon REPIT: The Data-Sparing Repartitioning Tool For Android
- Thread starter Lanchon
- Start date
+Lanchon I changed zip name lanchon-repit-20170115-system=2+wipe-data=6+wipe-sdcard=max-preload=min+wipe-i9100.zip but keeps saying invalid system name, any ideas. Running 6.0.1 Bliss
Sent from my GT-I9100 using XDA-Developers Legacy app
Sent from my GT-I9100 using XDA-Developers Legacy app
Last edited:
@jimbomodder
First of all:
check the readme on the github documentation for the syntax! It changed already with builds as of 2016-09-23. Now units (like G) are mandatory for size definitions.
If it still fails, and I assume it will as you might run it from within a recovery, that doesn't have the full toolset that is needed: post the recovery.log or the repit.log (again: please read the documentation).
First of all:
check the readme on the github documentation for the syntax! It changed already with builds as of 2016-09-23. Now units (like G) are mandatory for size definitions.
If it still fails, and I assume it will as you might run it from within a recovery, that doesn't have the full toolset that is needed: post the recovery.log or the repit.log (again: please read the documentation).
@Lanchon
Hey man! I flashed your RePit to I9305, 11GB free space up to 13GB!
Good result. No any error.
I can't flash custom rom, system.img is small sized. (My USB port broken) How to back stock partition size? Would you make a backup for me?
*I know, my lang is bad. sorry.
Hey man! I flashed your RePit to I9305, 11GB free space up to 13GB!
Good result. No any error.I can't flash custom rom, system.img is small sized. (My USB port broken) How to back stock partition size? Would you make a backup for me?
*I know, my lang is bad. sorry.
Hi lolala1,@Lanchon
Hey man! I flashed your RePit to I9305, 11GB free space up to 13GB!
I can't flash custom rom, system.img is small sized. (My USB port broken) How to back stock partition size? Would you make a backup for me?
*I know, my lang is bad. sorry.
Nobody makes a backup for you.
But if you want to completely go back to stock sizes (and if the originally provided partition size data for that device were correct) then you can do the following:
in case you did that (and it sounds like that):
tombstones=same-cache=32M+wipe-system=1G-preload=min+wipe-data=max
now do:
cache=1G+wipe-system=1.5G-preload=560M+wipe-data=max
In case you also changed tombstones size, also revert that to stock by using tombstones=256M.
So you should end up with something like that:
lanchon-repit-20170115-cache=1G+wipe-system=1.5G-preload=560M+wipe-data=max-i9305.zip
or
lanchon-repit-20170115-tombstones=256M-cache=1G+wipe-system=1.5G-preload=560M+wipe-data=max-i9305.zip
Good luck.
Thanks man! Successfully RePit! :highfive: My stock partition get back! :good:
lanchon-repit-20170115-tombstones=256M-cache=1G+wipe-system=1.5G-preload=560M+wipe-data=max-i9305
I see you support the galaxy s5 (klte). I would like to help in porting to the Note 3 (hlte).
I've checked the scripts and it looks like some simple editing but you also include identifiers. Is there some commands I need to run from terminal to get all the pertinent information? df dh mount. Would probably need to find all the models for the device too in order to make it universal for the phone. I know a few, but not all.
Thanks
I've checked the scripts and it looks like some simple editing but you also include identifiers. Is there some commands I need to run from terminal to get all the pertinent information? df dh mount. Would probably need to find all the models for the device too in order to make it universal for the phone. I know a few, but not all.
Thanks
@evilvoice
as I understand it:
Just like for other newer devices, klte support was withdrawn for safety-reasons after the S5 was suspected to have signed GPTs. Although that decision has been made based upon a search method that could also reveal false positives, no one prooved the opposite yet.
For port requests of new models (or for checking what information is collected for that) you can run (or look at) this tool. device-dump. Can be run by flashing a zip, or adb methods as described there. So if you want to port it yourself it should still deliver all information needed, if you are still on stock partition layout.
as I understand it:
Just like for other newer devices, klte support was withdrawn for safety-reasons after the S5 was suspected to have signed GPTs. Although that decision has been made based upon a search method that could also reveal false positives, no one prooved the opposite yet.
For port requests of new models (or for checking what information is collected for that) you can run (or look at) this tool. device-dump. Can be run by flashing a zip, or adb methods as described there. So if you want to port it yourself it should still deliver all information needed, if you are still on stock partition layout.
@the.gangster I'll check it out. It may be a while, but anything I find out, I'll post here and let you know progress. I may be the only one who wants it for the phone lol.
I'll check on some of this stuff you posted. It seems it'll have to be trial and error. I do have a pit file just in case
I'll check on some of this stuff you posted. It seems it'll have to be trial and error. I do have a pit file just in case
Last edited:
@evilvoice
sadly it won't tell you. AFAIK @Lanchon hasn't found a clear proof yet. Otherwise all the devices wouldn't be "suspected" any more.
In (at least) one of the links you can see him grep the combination of strings like 'GPT' and 'sign' successfully on a device that obviously doesn't enforce GPT signatures and runs fine.
But I remember he once described a way to kind of test it with only reducing one of the partitions for only the minimum (granularity) size, explaining in theory (!!!) a way to recover after a brick. But can't remember the exact device any more. And nevertheless this was still kind of risky.
So if it is not already well-known in your device forums whether the hlte has signed GPTs, it might be safer to wait for Lanchon to respond to an official port request. Even if this might take quite a long time, as he's been very busy recently.
sadly it won't tell you. AFAIK @Lanchon hasn't found a clear proof yet. Otherwise all the devices wouldn't be "suspected" any more.
In (at least) one of the links you can see him grep the combination of strings like 'GPT' and 'sign' successfully on a device that obviously doesn't enforce GPT signatures and runs fine.
But I remember he once described a way to kind of test it with only reducing one of the partitions for only the minimum (granularity) size, explaining in theory (!!!) a way to recover after a brick. But can't remember the exact device any more. And nevertheless this was still kind of risky.
So if it is not already well-known in your device forums whether the hlte has signed GPTs, it might be safer to wait for Lanchon to respond to an official port request. Even if this might take quite a long time, as he's been very busy recently.
Last edited:
Firstly thank you for the awesome tool :good:
I successfully repit my N7000 and at first with DiskInfo it showed correct information. But I don't know how later on the sdcard mount point changes to something weird. Iirc the only thing I did was to install ES Explorer. Any idea?
Update: I resolved this by explicitly specify sdcard partition size instead of just putting "max".
I successfully repit my N7000 and at first with DiskInfo it showed correct information. But I don't know how later on the sdcard mount point changes to something weird. Iirc the only thing I did was to install ES Explorer. Any idea?
Update: I resolved this by explicitly specify sdcard partition size instead of just putting "max".
Attachments
Last edited:
This issue happens sometimes randomly, with my i9100 too - whether with Repit or a pit file via Odin. No idea why.
Hello.
Thanks also for the good tool, I already used it successfully for increase the data partition on my old SGS2 with Android 4.1.2.
Now I want yet to switch off journaling on ext4 for make the old SGS2 runs more faster.
Please, answer to me: Can I switch off journaling by using Lanchon repit tool?
Thanks also for the good tool, I already used it successfully for increase the data partition on my old SGS2 with Android 4.1.2.
Now I want yet to switch off journaling on ext4 for make the old SGS2 runs more faster.
Please, answer to me: Can I switch off journaling by using Lanchon repit tool?
Last edited:
this is caused by your ROM. it has nothing to do with REPIT.
explicitly specifying sdcard partition size has absolutely no effect on this.
no you can't.
you also can't fry eggs with REPIT.
if you want a faster phone, first switch to a TRIM-enabled OS, such as CM or lineage.
then do a manual fstrim or wait 48 hours with the phone turned on.
if that is not enough, switch /data to f2fs.
this is the REPIT thread: do not ask **ANY** questions about any of this here.
NO EXCEPTIONS.
really... NO EXCEPTIONS!!!
thanks!
hey, I have a galaxy s2, i9100, I got twrp 3.1 on it, but I can't install roms or run repit cause for some odd reason it crashes/reboots after a few minutes in recovery
I don't know why, battery is over 60%.
I have no OS now. trying to repit and then I want to install xenonhd and gapps + magisk.
I don't know why, battery is over 60%.
I have no OS now. trying to repit and then I want to install xenonhd and gapps + magisk.
I have a Samsung S2 i777 just tried to install the lanchon-repit-20170115-system=1G-data=same-sdcard=max-preload=min+wipe-i777. The phone is rooted and I have ODIN installed and stock recovery. When I boot into recovery I get an error saying failed to mount /system (Invalid argument) I had this since I tried to use ODIN to resize using a PIT file; I would like to install a new ROM. I hope the lanchon would be able to fix this but although I can wipe data and cache in recovery when I tried to apply update from SD card I get installing update and then E:error in /tmp/sideload/package.zip (Status 255) E:Failed to mount /system (Invalid Argument) Installation aborted. Any ideas how to resolve this?
One step forward and one step backwards. I found a tar file for the i777 and flashed (ODIN) that at the same time as the pit file. Now the phone will boot and it does have the new larger storage. However the tar file was the original Android 2.3. I rooted the phone again and went into recovery but when you select the external SD card it shows an empty folder and so the 7..1.2 Rom that is ZIP'd on there I cannot flash. I need to do some more reading how to move forward from there. Any quick hints welcome, at least I've got rooting and resizing completed.
One step forward and one step backwards. I found a tar file for the i777 and flashed (ODIN) that at the same time as the pit file. Now the phone will boot and it does have the new larger storage. However the tar file was the original Android 2.3. I rooted the phone again and went into recovery but when you select the external SD card it shows an empty folder and so the 7..1.2 Rom that is ZIP'd on there I cannot flash. I need to do some more reading how to move forward from there. Any quick hints welcome, at least I've got rooting and resizing completed.
Last edited:
I am still stuck. Does anyone have a link to a valid i777 tar file? The stock recovery won't see any files on the SD card. I tried internal storage but then it says there is an error checking the ZIP. I tried a few alternative ZIP files so I think the recovery is the issue. I can still get to ODIN so if I could find a more up to date tar file I can flash that way. ANYONE?
READ THE DOCS!!!! i will not cut and paste the docs here, read them where they are published.
you just wasted my time (and other's too), so i have no desire to help you.
good luck
Similar threads
- Poll
Top Liked Posts
-
There are no posts matching your filters.
-
69Lanchon REPIT: The In-Device Data-Sparing Repartitioning Tool For Android
REPIT is a simple, safe, device-only, data-sparing, and easily portable repartitioning tool for Android devices:
- device-only: just flash a zip file in recovery to repartition the device.
- simple: rename the zip file before flashing to configure your choice of partition sizes, file systems, wipes, etc.
- safe:
- a correctly ported REPIT can never hard-brick your device.
- before starting, REPIT checks for the existence of all the tools that will be needed for the task at hand, verifies that the current partition layout passes several sanity checks, checks and fixes all the involved file systems, and verifies that the new partition layout will meet its sanity checks too. REPIT performs a dry-run of the complete repartitioning process to detect possible problems early on.
- if REPIT fails, it will nonetheless try to restore your device to a working in-between state.
- my estimate is that around 1000 users have already repartitioned with REPIT with no incidents of data loss, boot loops or soft bricks (2016-04).
- easily portable: a simple configuration file is all that is needed to port REPIT to a new device.
Documentation (HELL YEAH, read this!) -> HERE
Downloads -> HERE
this is a user discussion thread. post here for general discussion and user support.
for official support create a Github issue, but only of you have read the docs.
new versions will not be announced here.
please 'watch' the Github project to receive notifications.
special thanks to the.gangster.
XDA:DevDB Information
Lanchon REPIT, Tool/Utility for all devices (see above for details)
Contributors
Lanchon
Source Code: https://github.com/Lanchon/REPIT
Version Information
Status: Stable
Created 2016-04-13
Last Updated 2019-06-077UPDATE: AFH hosting is back up and i've reuploaded the latest release.
hopefully now the downloads work. thanks @the.gangster!!!
linky...
https://www.androidfilehost.com/?w=files&flid=1199747
hi,
well, it's not that it didn't work lol! cache was intentionally left out of the resizable set. you've seen the comments and the 4X discussion so you know exactly why.
i wouldn't do the experiments anyway. in the Honor there is something useful to be gained: 1 extra GB to a 4GB /data, which is a lot. in the S2 cache is 100MB. cache is unused nowadays, so the only logical thing to do is shrink it. plus you want something left, like 32MB. so we will risk devices for 68MB? not on my watch
secure wipe is a very complex issue and there's an awful big can of worms there, believe me. it'll try to paint a picture.
ssds have a bunch of 'trim' commands. there's ERASE and DISCARD, and later TRIM was added, all with slightly different semantics. ans they all come in standard and secure flavors. most recently you can come across the standard non-queued commands or the new queued variants.
the non-secure flavored commands are performance-oriented: they are hints to help the ssd. the drive can ignore them if it wants. it can ignore requests for short ranges but honor requests for large extents, or whatever.
more recently devices can implement DRAT and RZAT (deterministic read after trim and read zero after trim), ending the previous non-deterministic behavior. take a look:
http://www.t13.org/documents/uploadeddocuments/docs2010/e09158r2-trim_clarifications.pdf
but there are a million bugs in ssd firmware so linux blacklists broken functionality. like RZAT in many drives (you can google it), even if the drive says it supports it.
in any case RZAT drives just alter the FTL (flash translation layer) structures to unmap the block, they don't erase flash, so your data is typically still there but normally inaccessible. and there is probably even a history of previous snapshots of the block, not just the latest.
that's where the secure commands enter the picture: supposedly the firmware must actually erase from flash all copies of the targeted blocks. in reality, firmwares are so buggy i wouldn't trust them for that, except maybe if the drive is intel brand.
back to the real world... the exynos:
>Does the wipe trigger some type of NAND erase cycle? This would be problematic on n7000 given the hard brick issues with NAND firmware there, and on the n7000 IIRC the ioctl() is filtered and purposely ignored, maybe this is also an issue with i9100? I don't recall.
you are living in the past. more than two years ago i started arguing that non-secure trim commands should in all probability work fine and could be used to speed up the S2 family. rationale is complex but you can google my threads about it. no-one listened so 2 years ago i learned to build kernels and did some tests with volunteers and began publishing trimming kernels (google i9100 trim for a bit of history). finally in 2016 trim was finally added to official CM 13, 12.1 and 11.
you could be trimming your device without knowing: if you are using recent official CM, you are already trimming. many other kernels switched to trim too.
but... in the S2, secure trim kills the eMMC, so only non-secure variants are issued by trim kernels. secure erase is not a possibility.
i don't know if the eMMC is RZAT, but i wouldn't trust the firmware anyway. if you want to wipe, dd is your best option. but don't use zeros!!! some ssd's compress data. use a pseudo random stream instead. after all, non-secure trim is not very different from a write, in the best case, so just write for safety and be done with it.
yes, dd won't wipe reserved blocks. no way to do that except:
-MAYBE... an eMMC full reset (including bootloader) by resizing the boot partitions (google) which is very dangerous and can easily hard brick the device.
-putting a power drill to you beloved S2
regarding what repit does:
-it trims only if the kernel has trim enabled.
-and it trims only ext4 partitions.
thanks!5i wont be able to look at this for about a week. but...
- look into i9100 config, there ull find everything explained. then base your config on a simpler config, such as i9300 i seem to remember?
- a heap is a set of movable partition (deemed movable by you) that are CONTIGUOUS on the disk surface, possibly separated among themselves only by unallocated space if at all. note that partition NUMBERS within a heap need not be ascending or contiguous, but usually are.
- partitions that cant be moved (bricking) or are dangerous to move or for which there are no good reasons to move must not be members of a heap.
- a device can have many heaps defined on it, but usually there is no need for more than one. each heap has unmovable start and end sectors on disk. heaps cannot share free space among themselves: each one is a separate world.
- each heap has start and end sectors defined, and the possibly unordered sequence of partition numbers that are its members, declared in disk surface order.
from your message here:
fota should be raw. it could be made ext4 to make it resizable, but given its little size, it is probably best left alone. the smallest size for an ext4 partition is 8MB, so youd save only 2MB for the complexity. so dont. raw means it can be moved but its content are an obscure blob that repit will never alter (including its size).
recovery should be raw if movable. given that the device will be in an semi bricked state if relocation of recovery is interrupted, recovery should actually not be part of a heap at all.
so it is best to leave recovery and fota alone and out of the heap. the only reason to make them part of the heap would be finding out that there is a lot of unused and unpartitioned space after fota in the disk surface. youd have to weight the danger in moving recovery against the benefit of the gained space. none of my published setups move recovery. for heap end, you typically define a sector number. but for this case, you could use repit's finding of physical disk end, which can vary from device to device according to the flash component the phone OEM was able to source at the time of manufacture.
so looks like your heap should be partitions 14 to 17, with hard-defined heap start and end sectors. or you can tell repit to start the heap after partition 13 and end it before partition 18, which i seem to remember is what i usually did for most devices.
persist should be raw (and thus keep). moreover: i remember i think i created a way for a partition to not be configurable. persist should be that: it should default to raw and users must not be able to change its type or content. it only participates in the heap to let the cache donate space to system and data (which requires moving persist).
the other 3 partitions should be relatively obvious. they should be configurable, with defaults to their factory filesystem types, unchanged sized, and kept content. its easy for someone who wants to get rid of the cache to add -cache=min++wipe or whatever it was, i dont really remember at the moment.
if you need further help, maybe its best if u PM me your whatsapp so i send u audio messages, as i cant really spend time typing these days4
no, but you can. you have 2 options:
-take the problem to the xda thread that caused it, and ask for help there.
-or go to the REPIT site and read and understand the complete documentation. this is the REPIT thread and we do things differently here: we provide full documentation -which cost me a lot of time to write, btw- instead of spoon-feeding users with obscure solutions that they don't understand. this is precisely to avoid users getting into situations like the one you are in.
your issue is probably that you changed the file system type of /sdcard using REPIT and you don't even know you did because you blindly followed instructions you didn't understand. if this is true, you could solve this issue either with TWRP or REPIT.
please don't ask "how do i do that?" on this thread. it's all in the docs. if you prefer to be spoon-fed, please go to the other thread.
thanks!
