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

Search This thread

Lanchon

Senior Member
Jun 19, 2011
2,751
4,487
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
 

samarium

Senior Member
Jun 24, 2010
337
123
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.
 

Lanchon

Senior Member
Jun 19, 2011
2,751
4,487
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.

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!
 

samarium

Senior Member
Jun 24, 2010
337
123
Thanks for the detailed reply.

I'm currently using i9100 CM12.1 & n7000 CM13/Nightowl, and have been trimming vfat partitions.

Now you remind me, I do recall reading threads about trim safe a while ago, but I think I was more irritated at the time by the seemingly random kernel crashes & process terminations that eventually were tracked down to kernel interrupt fp register save/restore, and went down the Sony path for a while while the n7000 was unusable. Amusingly, the n7000 now has CM13, while the Sony Z Ultra is languishing and isn't looking good for CM13 at the moment.

While I agree that for general SSDs, zero blocks could be compressed, and blocks could be deduped, do you really think this is happening in n7000/i9100 emmc? I dont expect so, seems they seem too old. I agree that a /dev/urandom would be a better if= than /dev/zero for dd, however this is going to use much more power, and I'm usually wiping a phone with limited time and power.

I'm not trying to protect from something as serious as direct flash chip access, just want to be reasonably sure that whatever was on the phone has been overwritten and is not easily available to standard and even mildly esoteric extraction methods.
 

Lanchon

Senior Member
Jun 19, 2011
2,751
4,487
Thanks for the detailed reply.

I'm currently using i9100 CM12.1 & n7000 CM13/Nightowl, and have been trimming vfat partitions.

Now you remind me, I do recall reading threads about trim safe a while ago, but I think I was more irritated at the time by the seemingly random kernel crashes & process terminations that eventually were tracked down to kernel interrupt fp register save/restore, and went down the Sony path for a while while the n7000 was unusable. Amusingly, the n7000 now has CM13, while the Sony Z Ultra is languishing and isn't looking good for CM13 at the moment.

While I agree that for general SSDs, zero blocks could be compressed, and blocks could be deduped, do you really think this is happening in n7000/i9100 emmc? I dont expect so, seems they seem too old. I agree that a /dev/urandom would be a better if= than /dev/zero for dd, however this is going to use much more power, and I'm usually wiping a phone with limited time and power.

I'm not trying to protect from something as serious as direct flash chip access, just want to be reasonably sure that whatever was on the phone has been overwritten and is not easily available to standard and even mildly esoteric extraction methods.

ok. then i would format in ext4 and trim. you can use repit for doing both in a single shot, but you need a trimming kernel. take a dd snapshot of one or a couple of short pieces of the partition, both before and after the operation. compare them and post here, i'd surely like to know :).

but... keep in mind that there are several different emmcs out there in the S2s, so you'd need to validate for each one. which reminds me, also post your device emmc IDs! use the eMMC brickbug check app for instance.

regarding the /dev/urandom vs /dev/zero thing, i'm not religious, i don't hold unwarranted beliefs about what i don't know. i investigate, i have no gut feelings on stuff :)

but if you want to know: i'm a bit obsessive, i certainly would have done at least something if i was coding the FTL, even if it is old. if your design is RZAT, the least you can do is trim the block instead of writing it when data is all zeros. you may think this would slow the emmc down, but this can be implemented in pseudo-zero time: writing usually entails generating some kind of checksum of the data. so note the magic checksum that corresponds to an all-zero block, and only if the checksum of the data being written matches the magic, actually check for all-zero data before writing. of course this can be 'attacked' by intentionally generating checksum collisions but who cares. the time saved by not garbage collecting, not using a free block, and not writing the block with all-zeros certainly pays for the checksum comparison against the magic value. also note that straight brute force comparison of all blocks is mostly ok too, as most written blocks will fail early anyway (ie, after one or a couple of bytes).

of course The One True Solution(R) is to encrypt the phone before using it...... assuming that you can actually wipe the key when you need to lol. ideally the key is in a separate hardware keystore adept at wiping keys. but on the S2 it just in the same eMMC :). so this is a bit like explaining where the universe came from by saying that god created it, and then conveniently forget to explain where did god come from lol.

the power drill solution still mostly works on the S2 though :)
 
Last edited:

darkz16

New member
Oct 7, 2008
1
0
Pls help
##################################
Lanchon REPIT
A Data-Sparing Repartitioning Tool
Version: 2016-04-15
Device: i9100
Copyright 2016, Lanchon (GPLv3)
####################################

===== PRELIMINARY CHECKS =====
info: valid package names: <prefix>[-(system|data|sdcard|preload)=<conf>]...<suffix>
info: valid partition <conf> values: [<size-in-GiB>|same|min|max][+[keep|wipe][+[ext4|vfat|f2fs|swap|raw]]]

----- DEFAULTS -----
system = size:same + content:keep + fs:ext4
data = size:same + content:keep + fs:ext4
sdcard = size:same + content:keep + fs:vfat
preload = size:same + content:keep + fs:ext4

info: parsing package name

----- CONFIGURATION -----
system = size:1.0 + content:keep + fs:ext4
data = size:6 + content:keep + fs:ext4
sdcard = size:max + content:keep + fs:vfat
preload = size:min + content:keep + fs:ext4

info: disabling swap
BusyBox v1.22.1 bionic (2016-01-10 12:49 +0530) multi-call binary.

Usage: dirname FILENAME

Strip non-directory suffix from FILENAME

info: copying package to '/tmp'
cp: '/tmp/lanchon-repit-20160415-system=1.0-data=6-sdcard=max-preload=min wipe-i9100.zip' and '/tmp/lanchon-repit-20160415-system=1.0-data=6-sdcard=max-preload=min wipe-i9100.zip' are the same file

[ERROR 1]

Whats wrong
 

samarium

Senior Member
Jun 24, 2010
337
123
ok. then i would format in ext4 and trim. you can use repit for doing both in a single shot, but you need a trimming kernel. take a dd snapshot of one or a couple of short pieces of the partition, both before and after the operation. compare them and post here, i'd surely like to know :).

but... keep in mind that there are several different emmcs out there in the S2s, so you'd need to validate for each one. which reminds me, also post your device emmc IDs! use the eMMC brickbug check app for instance.

regarding the /dev/urandom vs /dev/zero thing, i'm not religious, i don't hold unwarranted beliefs about what i don't know. i investigate, i have no gut feelings on stuff :)

bauner produced a new n7000 IsoRec with TWRP + OTG which I wanted, so while I was installing I tested a few things.

I generated a block binary file with each of the 1kB blocks annotated for the 200MB n7000 cache partition, and dd'd the file to the cache partition prior to each mkfs.

Code:
$ cat blocknull.pl
#!/usr/bin/perl
use strict;

my $count = $ARGV[0];
$count = 1 if $count == 0;
$count *= 1024 if $ARGV[0] =~ /M$/;
$count *= 1024 * 1024 if $ARGV[0] =~ /G$/;

for (my $i = 1; $i <= $count; $i++)
{
	printf "\nBLOCK %10d kB %6d MB %2d GB BLOCK\n", $i, $i / 1024, $i / 1024 / 1024;
	print chr(0) x (1024-43);
}
$

Code:
BLOCK          1 kB      0 MB  0 GB BLOCK
...
BLOCK     204800 kB    200 MB  0 GB BLOCK

Then operated on both vfat and ext4 file systems to determine which of the 204800 block signatures where remaining after various operations.

Code:
# tr -d '\0' < /dev/block/mmcblk0p7 | grep BLOCK.*BLOCK > cache.x.y.desc
...
# wc -l cache.?.?.*
   204800 cache.1.1.dd
   201632 cache.1.2.mkfs.fat32
   197041 cache.1.3.copyfile
   204800 cache.2.1.dd
        0 cache.2.2.mkfs.ext4
   204800 cache.3.1.dd
   197380 cache.3.2.mkfs.ext4.twrp
       60 cache.3.3.fstrim
       60 cache.3.4.copyfile
#

So as expected vfat format doesn't change the underlying data returned, it just gets changed as it is used, as show by the signature counts on cache.1.*

ext4 is more interesting, as I tried a manual mke2fs -t ext4 for cache.2.* and TWRP wipe ext4 for cache.3.*. The TWRP wipe is not using secure discard as can be seen from recovery.log, but things are largely back on track after the first fstrim except for a hole from 131081 kB to 131125 kB.

Code:
recovery.log:
warning: wipe_block_device: Wipe via secure discard suppressed due to bug in EMMC firmware

Maybe more interesting is that even though it seems manual mke2fs -t ext4 does a wipe, when I do a fstrim is still says 180MB trimmed, which I don't expect, some inconsistency in fs metadata setup in mkfs maybe? Doesn't matter to me, 1 or 2 wipes, but seems I will be using mke2fs -t ext4 via terminal and then using TWRP wipe/format as required.

FYI, EMMC IDs PNG attached.
 

Attachments

  • Screenshot_20160422-000001.png
    Screenshot_20160422-000001.png
    94.9 KB · Views: 574
Last edited:

Lanchon

Senior Member
Jun 19, 2011
2,751
4,487
bauner produced a new n7000 IsoRec with TWRP + OTG which I wanted, so while I was installing I tested a few things.

I generated a block binary file with each of the 1kB blocks annotated for the 200MB n7000 cache partition, and dd'd the file to the cache partition prior to each mkfs.

Code:
$ cat blocknull.pl
#!/usr/bin/perl
use strict;

my $count = $ARGV[0];
$count = 1 if $count == 0;
$count *= 1024 if $ARGV[0] =~ /M$/;
$count *= 1024 * 1024 if $ARGV[0] =~ /G$/;

for (my $i = 1; $i <= $count; $i++)
{
	printf "\nBLOCK %10d kB %6d MB %2d GB BLOCK\n", $i, $i / 1024, $i / 1024 / 1024;
	print chr(0) x (1024-43);
}
$

Code:
BLOCK          1 kB      0 MB  0 GB BLOCK
...
BLOCK     204800 kB    200 MB  0 GB BLOCK

Then operated on both vfat and ext4 file systems to determine which of the 204800 block signatures where remaining after various operations.

Code:
# tr -d '\0' < /dev/block/mmcblk0p7 | grep BLOCK.*BLOCK > cache.x.y.desc
...
# wc -l cache.?.?.*
   204800 cache.1.1.dd
   201632 cache.1.2.mkfs.fat32
   197041 cache.1.3.copyfile
   204800 cache.2.1.dd
        0 cache.2.2.mkfs.ext4
   204800 cache.3.1.dd
   197380 cache.3.2.mkfs.ext4.twrp
       60 cache.3.3.fstrim
       60 cache.3.4.copyfile
#

So as expected vfat format doesn't change the underlying data returned, it just gets changed as it is used, as show by the signature counts on cache.1.*

ext4 is more interesting, as I tried a manual mke2fs -t ext4 for cache.2.* and TWRP wipe ext4 for cache.3.*. The TWRP wipe is not using secure discard as can be seen from recovery.log, but things are largely back on track after the first fstrim except for a hole from 131081 kB to 131125 kB.

Code:
recovery.log:
warning: wipe_block_device: Wipe via secure discard suppressed due to bug in EMMC firmware

Maybe more interesting is that even though it seems manual mke2fs -t ext4 does a wipe, when I do a fstrim is still says 180MB trimmed, which I don't expect, some inconsistency in fs metadata setup in mkfs maybe? Doesn't matter to me, 1 or 2 wipes, but seems I will be using mke2fs -t ext4 via terminal and then using TWRP wipe/format as required.

FYI, EMMC IDs PNG attached.

>it seems manual mke2fs -t ext4 does a wipe
it shouldn't. mke2fs -i thought- doesn't trim unless invoked with a specific option. repit invokes with the flag:
https://github.com/Lanchon/REPIT/blob/master/repit-fs-ext4.sh#L51

as to the question of why your markers were cleared anyway, i've no answer.

>even though it seems manual mke2fs -t ext4 does a wipe, when I do a fstrim is still says 180MB trimmed
some kernels inform the newly trimmed space: if you run trim twice you'll get "0 bytes trimmed" the second time.
other kernels (like CM's i9100) always inform (and presumably trim) the full partition free space, so 180MB is ok. if you run trim twice you'll get the same number of bytes both times.

>things are largely back on track after the first fstrim except for a hole from 131081 kB to 131125 kB.
here are some candidate causes:
a) ext4 fs is based on 'blocks' with each block being a constant number of sectors. it makes sense that fstrim should work on whole blocks. also, when ext4 writes a 'short block', ie one not completely filled with data, some sectors and the end of the block might remain unused. it makes sense for ext4 not to write these sectors at all. but the complete block will be marked as used given that the block is the granularity for that, so no sector in the block will be trimmed by fstrim. so some pre-format data might survive in these short blocks after fstrim by this mechanism, which could explain what you observed.
b) another cause could be that the emmc might ignore trim requests for spans shorter than some size or for misaligned spans (remember that erases are performed in large chunks) giving rise to the observed data survival. when formatting no data survives because partitions are position- and size-aligned to 1MB or 4MB, which might be enough to guarantee trim. (i find this explanation unlikely, but who knows.)

about repit:
repit formats and trims ext4 and f2fs in a single operation.

to wipe /data a single repit should be enough:
-data=+wipe

to wipe /sdcard you can take advantage of repit's capability to convert file systems and do two repits:
-sdcard=+wipe+ext4
-sdcard=+wipe

an idea that comes out of this is that repit could temporarily format in ext4 before formatting in other modes that do not support format-time trimming, such as when wiping vfat and swap. this would make the above 2 steps unnecessary.
 
  • Like
Reactions: fmiller.88005

Lanchon

Senior Member
Jun 19, 2011
2,751
4,487
[...]
info: disabling swap
BusyBox v1.22.1 bionic (2016-01-10 12:49 +0530) multi-call binary.

Usage: dirname FILENAME

Strip non-directory suffix from FILENAME

info: copying package to '/tmp'
cp: '/tmp/lanchon-repit-20160415-system=1.0-data=6-sdcard=max-preload=min wipe-i9100.zip' and '/tmp/lanchon-repit-20160415-system=1.0-data=6-sdcard=max-preload=min wipe-i9100.zip' are the same file

[ERROR 1]

this is very interesting.

the relevant lines are these:
https://github.com/Lanchon/REPIT/blob/master/repit.sh#L318-L322
Code:
    if [ -f "$packageName" ]; then
        if [ "$(dirname $(readlink -f "$packageName"))" != "/tmp" ]; then
            info "copying package to '/tmp'"
            cp -f "$packageName" "/tmp/"
            hint="this package copied itself to '/tmp'; please run it again from there"

the line:
if [ -f "$packageName" ]; then
assures that the file $packageName exists.

but these logfile lines:
Code:
BusyBox v1.22.1 bionic (2016-01-10 12:49 +0530) multi-call binary.

Usage: dirname FILENAME

Strip non-directory suffix from FILENAME
are proof that 'dirname' is being invoked without argument, which means that 'readlink -f "$packageName"' produced an error!

how can 'readlink -f <file>' (which means 'canonicalize') give an error when invoked on an existing file is beyond me. it looks like your implementation of 'readlink' is broken.
what exact recovery are you using? who made it or where is it being distributed?

EDIT:
btw there is a quoting error in the code here but it shouldn't affect this. the line should be:
if [ "$(dirname "$(readlink -f "$packageName")")" != "/tmp" ]; then
 

Lanchon

Senior Member
Jun 19, 2011
2,751
4,487
[...]
cp: '/tmp/lanchon-repit-20160415-system=1.0-data=6-sdcard=max-preload=min wipe-i9100.zip' and '/tmp/lanchon-repit-20160415-system=1.0-data=6-sdcard=max-preload=min wipe-i9100.zip' are the same file

[ERROR 1]

Whats wrong

so i committed what i think is a fix for this problem that i cant reproduce:
https://github.com/Lanchon/REPIT/commit/c7bc3655acc89ee554d1dafe09c7bb9948483c03

and attached is build for you to try.
IMPORTANT: EXTRACT THE ZIP FIRST, DONT JUST FLASH IT!
 

Attachments

  • lanchon-repit-20160422.zip
    801.8 KB · Views: 300

chapito

Senior Member
May 12, 2007
229
20

chapito

Senior Member
May 12, 2007
229
20
no log, no kernel info, no recovery info. cant help you.
Hi.
Forgive me for not giving more information to solve the problem.
Yesterday I could partition the memory.
I had to change the partition type of memory EMMC to vfat and the script to start.
I used the IsoRec TWRP 2.8.7.0.
I used the last script publicated "lanchon-repit-20160415-system=1.0-data=same-sdcard=max-preload=min+wipe-i9100.zip"
Thanks
 
  • Like
Reactions: Lanchon

Lanchon

Senior Member
Jun 19, 2011
2,751
4,487
Hi.
Forgive me for not giving more information to solve the problem.
Yesterday I could partition the memory.
I had to change the partition type of memory EMMC to vfat and the script to start.
I used the IsoRec TWRP 2.8.7.0.
I used the last script publicated "lanchon-repit-20160415-system=1.0-data=same-sdcard=max-preload=min+wipe-i9100.zip"
Thanks

you didn't need to change your sdcard to FAT !!!
you could have used: -sdcard=max++ext4

if only you had read the instructions! that's what they are there for lol
well, it's your data you had to format, not mine! :p
thanks!
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 69
    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
    7
    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
    7
    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.

    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!
    5
    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
    4
    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?

    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!