[TOOL] Lanchon REPIT: The Data-Sparing Repartitioning Tool For Android

Search This thread
By:
Advanced…
kvevand63

kvevand63

Senior Member
Nov 28, 2012
411
347
Honolulu, Hawaii
Click on the link next to Documentation in the OP. It will take you to the github. Click on to Readme.txt. Everything you need to know is there. In the meantime (and you will find this in Readme.txt), you should have been prompted in TWRP upon the zip flash failure to redirect to /tmp and reflash from there (you will find that the zip has copied there).
 
  • Like
Reactions: Lanchon
Lanchon

Lanchon

Senior Member
Jun 19, 2011
2,755
4,488
leodis said:
Hi, I am following this guide "[Guide/tutorial] Samsung Galaxy S2 i9100 Any version to Android 6/CM13 or 7/CM14" in order to install the rom [ROM][OMS] AICP - 12.1 - N 7.1.1_r6 i9100 Official Nightly builds on my S2 I9100 Intl.
I follow the guide, but when I get to install the file "lanchon-djibe-repit-20170115-system=1G+wipe-data=6G+wipe+f2fs-sdcard=max+wipe+ext4-preload=min+wipe-i9100.zip", which should serve to change the size of the partitions, I get an error message: Install Zip Failed.
I think I have made a mistake by installing the répit file the first time. To try to repair I also used odin, selecting also re-partition and how the pit thr u1_02_20110310_emmc_EXT4.pit file and a rom stocks (up here all right).
Then I redid the root and I tried again, still error with répit Install Zip Failed.
There is no way to solve?
Click to expand...
Click to collapse

hi,

i'm not familiar with that guide, and it looks like the author 'djibe' might have modified and/or preconfigured my REPIT somehow (which is allowed and encouraged when done according to its GPLv3 license). please keep in mind that on this thread you'll only find support for stock REPIT. please report problems only to the correct thread according to the version you are using. thanks!
 
  • Like
Reactions: kvevand63
leodis

leodis

Senior Member
Dec 22, 2009
130
19
Cologno monzese
Lanchon said:
hi,

i'm not familiar with that guide, and it looks like the author 'djibe' might have modified and/or preconfigured my REPIT somehow (which is allowed and encouraged when done according to its GPLv3 license). please keep in mind that on this thread you'll only find support for stock REPIT. please report problems only to the correct thread according to the version you are using. thanks!
Click to expand...
Click to collapse
I apologize, but I have been sent here by # the.gangster in the thread https://xdaforums.com/showpost.php?p=70791810&postcount=347. He thought you could help me, patiently.
 
Last edited:
  • Like
Reactions: Lanchon
the.gangster

the.gangster

Senior Member
Apr 3, 2015
955
1,374
Samsung Galaxy S7
@leodis
Not exactly.
Yes, I sent you here to examine (and solve) your problem. Most likely by myself.
But I also asked you to add either recovery- or repit.logs.
As you didn't, there was nothing to do so I didn't react on your post.
@Lanchon
The creator of the other guide just used the standard repit.zip and renamed it according to what he thought would be the best partitioning approach.
But for a guide like that I don't share his advice at all. He makes people format data with f2fs and sdcard with ext4.
Doing that it is far from standard and most people have to learn that the ROM that they flash afterwards doesn't even support f2fs, LOL.
But anyway, if leodis posted a log I would look at it, as it is just renamed for reconfiguration. He just put his name into it for easier reference within the guide, as think he also referred to another one unmodified.
 
  • Like
Reactions: Lanchon
Lanchon

Lanchon

Senior Member
Jun 19, 2011
2,755
4,488
the.gangster said:
@leodis
Not exactly.
Yes, I sent you here to examine (and solve) your problem. Most likely by myself.
But I also asked you to add either recovery- or repit.logs.
As you didn't, there was nothing to do so I didn't react on your post.
@Lanchon
The creator of the other guide just used the standard repit.zip and renamed it according to what he thought would be the best partitioning approach.
But for a guide like that I don't share his advice at all. He makes people format data with f2fs and sdcard with ext4.
Doing that it is far from standard and most people have to learn that the ROM that they flash afterwards doesn't even support f2fs, LOL.
But anyway, if leodis posted a log I would look at it, as it is just renamed for reconfiguration. He just put his name into it for easier reference within the guide, as think he also referred to another one unmodified.
Click to expand...
Click to collapse

those using f2fs will be bitten back by its lack of tools: when it's time to migrate to emulated storage, they'll have to wipe.

but whatever that guy has done it's not my job to know or investigate. in general i won't support tools distributed by 3rd parties, even if it's maybe my tool. i hope this position is understandable and sane.

and btw, thanks for providing continuing support for everybody using REPIT!! :)
 
Last edited:
  • Like
Reactions: kvevand63 and the.gangster
leodis

leodis

Senior Member
Dec 22, 2009
130
19
Cologno monzese
the.gangster said:
@leodis
Not exactly.
Yes, I sent you here to examine (and solve) your problem. Most likely by myself.
But I also asked you to add either recovery- or repit.logs.
As you didn't, there was nothing to do so I didn't react on your post.
@Lanchon
The creator of the other guide just used the standard repit.zip and renamed it according to what he thought would be the best partitioning approach.
But for a guide like that I don't share his advice at all. He makes people format data with f2fs and sdcard with ext4.
Doing that it is far from standard and most people have to learn that the ROM that they flash afterwards doesn't even support f2fs, LOL.
But anyway, if leodis posted a log I would look at it, as it is just renamed for reconfiguration. He just put his name into it for easier reference within the guide, as think he also referred to another one unmodified.
Click to expand...
Click to collapse

Unfortunately I realized that I have a much bigger problem. It has ruined the partition table of the ROM. I discovered that the fat storage partition sdcard0 is no longer detected. It seems that there is not. The phone works, more or less. The camera will not, but I downloaded one from the play store.
You can repair it?
 
Lanchon

Lanchon

Senior Member
Jun 19, 2011
2,755
4,488
leodis said:
Unfortunately I realized that I have a much bigger problem. It has ruined the partition table of the ROM. I discovered that the fat storage partition sdcard0 is no longer detected. It seems that there is not. The phone works, more or less. The camera will not, but I downloaded one from the play store.
You can repair it?
Click to expand...
Click to collapse

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!
 
  • Like
Reactions: No-Lags, Nick_Knight, kvevand63 and 1 other person
A

ando roido

Senior Member
Jul 14, 2011
90
7
Maguro with CM 13 gives error

..
blockdev: /dev/block/mmcblk0: Device or resource busy
FATAL: unable to reread the partition table (please disable MTP in TWRP's 'Mount'
...


Full TWRP 3.0.2-0 log attached. I have ran from tmp, always checked that MTP is disabled. Phone is not encrypted.
 

Attachments

  • recovery.log
    23.6 KB · Views: 13
P

PackElend

Senior Member
Feb 11, 2013
134
21
Hallo,
short question, there are any side effects when increasing the increasing the app partition (/data) to all remaining internal space and thus decrease the internal SD partition (/SDCcard0) to zero (or almost zero). I will run Android >=6 on my I9100 with extend internal storage (Adoptable Storage) managed by Android.
thx
 
the.gangster

the.gangster

Senior Member
Apr 3, 2015
955
1,374
Samsung Galaxy S7
ando roido said:
Maguro with CM 13 gives error

..
blockdev: /dev/block/mmcblk0: Device or resource busy
FATAL: unable to reread the partition table (please disable MTP in TWRP's 'Mount'
...

Full TWRP 3.0.2-0 log attached. I have ran from tmp, always checked that MTP is disabled. Phone is not encrypted.
Click to expand...
Click to collapse
Seems like the Nexus is really kind of sensitive.
Did you try this already:
MayuraDeSilva said:
...
UPDATE #1: ...However, rebooted, copied the zip file to /tmp directly and flashed it from there. Completed successfully....
Click to expand...
Click to collapse


LegoM305 said:
so....
i don't understand any of this
i just want to increase the system partition on my oneplus one
can someone help?
Click to expand...
Click to collapse
Although requested once it's not supported on the OnePlus One. Read here why (hope you at least understand some of that ;) )

PackElend said:
Hallo,
short question, there are any side effects when increasing the increasing the app partition (/data) to all remaining internal space and thus decrease the internal SD partition (/SDCcard0) to zero (or almost zero). I will run Android >=6 on my I9100 with extend internal storage (Adoptable Storage) managed by Android.
thx
Click to expand...
Click to collapse
For Repit it's ok to reduce it to 8MB (=min). Several people already did that (having a bigger system partition already in place) in favor of a bigger data partition for switching to emulated storage. If you want to go for adoptable storage instead and realize the external SD to be slowing down things, the emulated storage would be a way that works.
 
  • Like
Reactions: Lanchon
P

PackElend

Senior Member
Feb 11, 2013
134
21
the.gangster said:
For Repit it's ok to reduce it to 8MB (=min). Several people already did that (having a bigger system partition already in place) in favor of a bigger data partition for switching to emulated storage. If you want to go for adaptable storage instead and realize the external SD to be slowing down things, the emulated storage would be a way that works.
Click to expand...
Click to collapse
thx for the hint@the.gangster, I've just read through all 16 pages, that sounds very promising (great work) but if I use dropbox etc. I will easily hit the 16GB limit of the build-in storage. How can I combine it with an external SD Card?
Did I understand correctly that I can flash again RR OS on it instead of Lineage OS?
 
O

Olleo

Senior Member
Jun 19, 2010
60
10
Hi,

I have tried to repartitionize i9100 (currently running on NeatROM kitkat 4.4.4). I have used the default i9100 config from the download site and got it failed:

Partition 1 does not end on cylinder boundary.

FATAL: unable to determine usable sector range of block device

[ERROR 1]

E: Error executing updater binary in zip '/emmc/Download/lanchon-repit-20160317-system=1.0-data=same-sdcard=max-preload=min+wipe-i9100.zip'
Error flashing zip '/emmc/Download/lanchon-repit-20160317-system=1.0-data=same-sdcard=max-preload=min+wipe-i9100.zip'

Any idea what's wrong?
 
the.gangster

the.gangster

Senior Member
Apr 3, 2015
955
1,374
Samsung Galaxy S7
@Olleo
First of all you should use the latest release, as there were quite some improvements, including detection of the heap end (especially useful for non-16gb version).
It might also give better advices to certain errors.
Not promising there will be no error with latest version, but noone wants to search for errors that might have been fixed already in later versions.
 
  • Like
Reactions: Lanchon and guest4711
Lanchon

Lanchon

Senior Member
Jun 19, 2011
2,755
4,488
the.gangster said:
Seems like the Nexus is really kind of sensitive.
Did you try this already:




Although requested once it's not supported on the OnePlus One. Read here why (hope you at least understand some of that ;) )


For Repit it's ok to reduce it to 8MB (=min). Several people already did that (having a bigger system partition already in place) in favor of a bigger data partition for switching to emulated storage. If you want to go for adoptable storage instead and realize the external SD to be slowing down things, the emulated storage would be a way that works.
Click to expand...
Click to collapse

hey TG!!!

thanks for your excellent support! sorry that i'm MIA, swamped by work, miss XDA :)
 
  • Like
Reactions: No-Lags, Tmobilefan906, the.gangster and 1 other person
O

Olleo

Senior Member
Jun 19, 2010
60
10
@the.gangster

too late. I've repartitioned it using PIT file and odin already. Nevertheless I've used the most up-to-date version as far as I know.
 
You must log in or register to reply here.

Similar threads

Snoop05
[OFFICIAL][TOOL][WINDOWS] ADB, Fastboot and Drivers - 15 seconds ADB Installer v1.4.3
Replies
2K
Views
7M
abdulkareem786
abdulkareem786
shimp208
[TOOL]Minimal ADB and Fastboot [2-9-18]
Replies
982
Views
5M
sinommo
sinommo
zeppelinrox
  • Poll
[V6U9RC13]For Your Lag(4x) Do it good, Good, GOOD, GOOD! SuperCharge Your Launchaaah!
Replies
24K
Views
7M
rodken
rodken
B
[UTIL][WIN][MT65xx] MTK Droid Root & Tools | MediaTek Android Smartphone
Replies
2K
Views
3M
A
allyalla
obynio
[TOOL] RecoverX (Desktop) - Recovery installer for android
Replies
653
Views
854K
G
gekagal

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 69
    Lanchon
    Lanchon
    Lanchon 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-07
    View
    7
    Lanchon
    Lanchon
    UPDATE: 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=119974
    View
    7
    Lanchon
    Lanchon
    samarium said:
    Tried this on a n7000 recently, tried to resize cache, which didn't work, saw partition structure with modem after cache, and understand your concerns in the comments. I imagine the we could so some experiments like you are doing for the Honor 4, however I'm not at the stage where I want to volunteer my device as potential sacrifice.

    A question on "wipe", how sure are we that "wipe" actually wipes, ie is all the previous data non-recoverable down to a block level?

    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.

    If I have a used ext4 parition, and then format & wipe it then I think a fstrim happens. If I then change it to vfat, and dd the partition, am I able to recover blocks from the original ext4 partition, or does the trim cause the nand to regard the blocks as empty and return 0x0000000 or 0x11111111 or something deterministic?

    I'm looking for a wipe that actually wipes, ext4 and vfat, rather then my current solution which is to dd if=/dev/zero of=/path, which is slow and is difficult to get a progress report, as kill -USR1 is a PITA.
    Click to expand...
    Click to collapse

    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!
    View
    5
    Lanchon
    Lanchon
    i 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 days
    View
    4
    Lanchon
    Lanchon
    leodis said:
    Unfortunately I realized that I have a much bigger problem. It has ruined the partition table of the ROM. I discovered that the fat storage partition sdcard0 is no longer detected. It seems that there is not. The phone works, more or less. The camera will not, but I downloaded one from the play store.
    You can repair it?
    Click to expand...
    Click to collapse

    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!
    View

New posts