Database Info

[Q&A] Mounts2SD - Storage & Memory Management

Mounts2SD - Storage & Memory Management
The Opening Post (OP) has been moved to a new DevDB Section
This Thread has been assigned as an Q&A.
You should see a new pane above where you can navigate this project.

About dalvik-cache? It remains in phone memory?

Hi I cant understand How to use it ! any guide ?!

denzel09 said:
About dalvik-cache? It remains in phone memory?
Click to expand...
Click to collapse
dalvik-cache remains, so does all of the app related data. Only the APK's is moved.
Taki2011 said:
Hi I cant understand How to use it ! any guide ?!
Click to expand...
Click to collapse
First of all you need a custom rom. If you have a stock rom it will not work since you need a rom that will allow custom scripts during boot.
You will also need to know how to use ADB (An android tool for communicating with your phone. It is used to enter the android shell and also to transfer files to and from the phone, among other things).
And last, you will need at least 2 or 3 partitions on your sdcard (Otherwise it's a waste of time, although the script is build to adapt for these scenarios). One as a regular fat32 sdcard partition, one for the sd-ext and one for the cache. (Use ext2 for the last two. ext3 will eat your card to fast)
Here is the steps (You need to have ADB working on your computer).
Copy/Paste the script content into a file editor and safe the file with the name "99mounts2sd"
Plug your phone to your computer using a usb cable (Select charge only on your phone))
Open a terminal on your computer (In windows use "run" and type "cmd")
Type in shell: "adb shell mount -o remount,rw /system"
Type in shell: "adb push <path to script> /system/etc/init.d/"
Type in shell: "adb shell chmod a+x /system/etc/init.d/99mounts2sd"
Reboot your phone
The first time you boot your phone using the script it will take some time, because the script needs to copy all of your APK's from internal storage to the sd-ext partition.

The script has been rewritten. Better checks and more options has been added.

Great script
Sent from my GT-S5570 using Tapatalk

It didn't work for me, I made the files made sure they were in the right place and rebooted but booted normally. No delay on first boot and still seems to not be using the other two partitions on my sd card. i used cwm4 to partiton my SD card and it is partitioned correctly (3 partitons). I see the script says "log" I don't know where the log is stored or how to view it. Thanks.

To see the log, type in the terminal: "logcat | grep mounts2sd". Download a terminal or use ADB.
Also run the command "df -h" to see what is mounted where.
Sent from my HTC Desire using xda premium

thanks for the share.

#7 @dyehya
It seams that logcat has a very limited lifetime. In order to get the log info, you would have to get it during boot.
Instead I have updated the script to do this itself. Update your script and config file content with the new above code.
In the config file set VAR_DEBUG="yes" and reboot your phone. Now enter a terminal and type "cat /var/mounts2sd.log | grep mounts2sd" which will show you all the messages from the script, and possible errors, if any.

I am not sure what is going on in boot. I just saw your replies and haven't had a chance to update the script and mess with the phone. I do know that when I was playing with it before it kept using the busybox minimal that was in the kernel loaded in sbin I tried copying your version of busybox into bin and xbin (and now reverted back) but it would still use the one in sbin. What I would really like to do and would recommend is you design the script where you can put busybox in a certain location and the script will use that version over any other versions. I am still learning with all this and despite being able to create the files throw them in the correct places I don't know the code well enough to do this myself. Thanks again for all your help.

Ok i have changed the script so that it now forces the usage of /system/xbin/busybox or /system/bin/busybox and ignores /sbin/busybox
Place a full busybox version in one of the system bin folders, update the script and see what happends.
Otherwise paste a copy of "df -h" and "cat /data/mounts2sd.log | grep mounts2sd" here so that I can see what it does during boot.

Thanks for this. Just flashed the ICS beta 0.1 with your a2sd embedded. Just a suggestion, I added $CMD_CHMOD 777 $CMD_BUSYBOX at line 260, just after the affectation of CMD_BUSYBOX.
For now, it seems to work very well !

virus2013 said:
Thanks for this. Just flashed the ICS beta 0.1 with your a2sd embedded. Just a suggestion, I added $CMD_CHMOD 777 $CMD_BUSYBOX at line 260, just after the affectation of CMD_BUSYBOX.
For now, it seems to work very well !
Click to expand...
Click to collapse
That I don't get? $CMD_CHMOD is undefined at line 260 and why use busybox to change permissions on itself?

dk_zero-cool said:
That I don't get? $CMD_CHMOD is undefined at line 260 and why use busybox to change permissions on itself?
Click to expand...
Click to collapse
Sorry, I'm tired... :-\
In fact, I just wanna be sure that the busybox in /system/bin was executable as I pushed it into the rom zip. And as chmod was already used upper, I was thinking it could be a good idea. However, I'm not a script writer! ;-)
Sent from my Desire running ICS

Hello Cool,
trying ICS with your script. Here is the output of logcat an df -h command:
Code:
# cat /data/mounts2sd.log | grep mounts2sd
cat /data/mounts2sd.log | grep mounts2sd
12-14 13:05:12.905 V/mounts2sd( 96): Initiating Mounts2SD (v:1.1.1)...
12-14 13:05:12.985 V/mounts2sd( 101): Including configuration file...
12-14 13:05:14.897 V/mounts2sd( 212): Searching for sdcard...
12-14 13:05:15.277 V/mounts2sd( 231): Searching for sd-ext partition (/dev/block/mmcblk0p2)...
12-14 13:05:16.198 V/mounts2sd( 254): sd-ext partition was mounted successfully...
12-14 13:05:16.728 V/mounts2sd( 278): Moving /data/app to /sd-ext/app...
12-14 13:05:17.049 V/mounts2sd( 297): Moving /data/app-private to /sd-ext/app-private...
12-14 13:05:17.209 V/mounts2sd( 305): Searching for the sd-cache partition (/dev/block/mmcblk0p3)...
12-14 13:05:18.050 V/mounts2sd( 326): sd-cache was mounted successfully...
12-14 13:05:18.280 V/mounts2sd( 335): A device is already mounted at /cache. Umounting it...
12-14 13:05:18.420 V/mounts2sd( 341): Moving /cache to /sd-cache...
12-14 13:05:18.440 V/mounts2sd( 342): Done!
df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 202.9M 32.0K 202.9M 0% /dev
tmpfs 202.9M 0 202.9M 0% /mnt/asec
tmpfs 202.9M 0 202.9M 0% /mnt/obb
/dev/block/mtdblock3 250.0M 165.0M 85.0M 66% /system
/dev/block/mtdblock5 147.6M 62.4M 85.2M 42% /data
/dev/block/mmcblk0p2 960.7M 1.2M 959.4M 0% /sd-ext
/dev/block/mmcblk0p2 960.7M 1.2M 959.4M 0% /data/app
/dev/block/mmcblk0p2 960.7M 1.2M 959.4M 0% /data/app-private
/dev/block/mmcblk0p3 295.9M 168.0K 295.8M 0% /sd-cache
/dev/block/mmcblk0p3 295.9M 168.0K 295.8M 0% /cache
/dev/block/vold/179:1
6.2G 4.6G 1.6G 75% /mnt/sdcard
/dev/block/vold/179:1
6.2G 4.6G 1.6G 75% /mnt/secure/asec
This looks good, can you please confirm?
Also, why is /data not on ext partition but on phone memory?
Thanks for the script though!
Cheers, keep up the good work.

jukyO said:
This looks good, can you please confirm?
Also, why is /data not on ext partition but on phone memory?
Thanks for the script though!
Cheers, keep up the good work.
Click to expand...
Click to collapse
That looks as it should.
The whole /data is not moved to the /sd-ext for that simple reason that there are no hboot out there with 0mb /data.
I have options in my script to move both the .apk files (The applications) and the dalvik-cache which are the biggest things in the /data partition. If I moved everything to sd-ext, there would be nothing using the remaining space available on the internal data which is a waste of good space. It's like having an extra room in your house that is not used for anything at all. If we have to have it, we might as well use it
BTW:
You don't have dalvik-cache aktivated. So if you ever need more space on /data, activate it in /system/etc/mounts2sd.conf

dk_zero-cool said:
BTW:
You don't have dalvik-cache aktivated. So if you ever need more space on /data, activate it in /system/etc/mounts2sd.conf
Click to expand...
Click to collapse
Could you provide an example mounts2sd.conf file, so that all settings could be established at first boot. This would make it much easier when updating ROMS.

uzi2 said:
Could you provide an example mounts2sd.conf file, so that all settings could be established at first boot. This would make it much easier when updating ROMS.
Click to expand...
Click to collapse
You don't need a .conf file now - it's not used. You simply install the zip and then use the m2sd commands in terminal to make changes (see instructions in OP - type m2sd help for more info)

uzi2 said:
Could you provide an example mounts2sd.conf file, so that all settings could be established at first boot. This would make it much easier when updating ROMS.
Click to expand...
Click to collapse
The config files is deprecated and replaced with the "m2sd" command, as said above. Settings is saved to /data/.m2sd which means that it keeps your settings when you flash new ROM's as long as you don't wipe data.

[Q] Mounting userdata partition on PC

Hello all,
Last night I ran the following command (with the phone in recovery and everything unmounted) to back up my Nexus 5's userdata partition to my computer:
Code:
adb pull /dev/block/platform/msm_sdcc.1/by-name/userdata
My phone is encrypted, so I use "cryptsetup --type=plain open" to obtain a plaintext version on /dev/mapper/my-nexus-backup. But I cannot mount the mapped device using "mount"! It complains that iit can't find the filesystem.
So, how would I mount such an image? Or, even better, what's the best way to dd it back to the userdata partition on the device?
And yes, next time I will just use a Nandroid, even if it means having to erase things to make room.

See if @rootSU or @bitdomo can help. They're gurus at this type of stuff
Sent from my Nexus 5 using XDA Free mobile app

Sorry, where are you mounting exactly? Are you trying to mount an image on a Linux box after the pull?
If not can you please share the full step of commands and what you expect to happen please?
Sent from my Nexus 5 using Tapatalk

rootSU said:
Sorry, where are you mounting exactly? Are you trying to mount an image on a Linux box after the pull?
If not can you please share the full step of commands and what you expect to happen please?
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
Hey rootSU. I pulled the image from my phone, decrypted it, and tried to mount it:
Code:
$ adb pull /dev/block/platform/msm_sdcc.1/by-name/userdata
$ su
# losetup /dev/loop1 userdata
# cryptsetup open --type plain /dev/loop1 nexus
Enter passphrase:
# mount /dev/mapper/nexus /mnt/tmp
mount: wrong fs type, bad option, bad superblock on /dev/mapper/nexus,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
I'm not sure why that doesn't work. It's just ext4, right? I'd still find it instructive to figure out how to mount it; hopefully you can shed some light?
As far as getting the image back on the device's partition, I was a bit stuck, because there's obviously no room on the device to copy it to. I finally figured out a method involving netcat. Essentially I forwarded a local TCP port to my device (in recovery) using adb, then used netcat to feed dd the image.
Code:
$ adb forward tcp:4444 tcp:4444
$ adb shell
# nc -l -p 4444 -e dd of=/dev/block/platform/msm_sdcc.1/by-name/userdata
This will hang as it waits for an inbound connection. From a second shell:
Code:
$ dd if=userdata | nc localhost 4444
My 28GiB image took around 6 hours (!) to complete. Nandroid is probably the way to go.

Nandroid won't backup sdcard but you can use foldersync to back that up.
Yes it is just ext4
I've never done anything like this before with an encrypted device but my assumption was if you adb pull a file, it would decrypt it on the fly.. Does it not?? If it does, I'd just dd it to an img.
Sent from my Nexus 5 using Tapatalk

rootSU said:
Nandroid won't backup sdcard but you can use foldersync to back that up.
Yes it is just ext4
I've never done anything like this before with an encrypted device but my assumption was if you adb pull a file, it would decrypt it on the fly.. Does it not?? If it does, I'd just dd it to an img.
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
Nope, in this case, userdata is the encrypted *device*; in any case TWRP knows nothing about the encryption. The pull was identical to using dd to copy the file. Of course, if you wanted to decrypt your device without wiping data, you could probably have TWRP decrypt the data partition, then dd or pull the resulting /dev/block/dm-0 file (which is equivalent to my /dev/mapper/nexus file I created). Haven't tried it though; ain't nobody got time for that.
I wonder why it wouldn't mount. Oh well. I'm just happy that my device is the way it was yesterday.

I'd love to have a play with this but I just don't have the time to start encrypting and decrypting stuff
Out of interest what about adb whilst in android?
Sent from my Nexus 5 using Tapatalk

rootSU said:
I'd love to have a play with this but I just don't have the time to start encrypting and decrypting stuff
Out of interest what about adb whilst in android?
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
You would have the exact same results, as the /dev/* files are the physical disks represented as a file. The crypto drivers read/write this block device file to present a decrypted /dev/block/dm-0 device. Then the kernel mounts dm-0 as an ext4 filesystem on /data. All the files I mentioned are pullable with adb, assuming you have sufficient privileges. You don't need fancy tools to read/write them, which is why the netcat hack worked. Thus is the power of Unix!
You can screw around with it if you want in regular desktop Linux with a "device" you make from a bunch of 0s. Do:
Code:
# dd if=/dev/zero of=disk.image count=100000
# losetup /dev/loop0 disk.image
Now you can do "mkfs.ext4 /dev/loop0" and "mount ..." or whatever, and the data will be written to the "device" disk.image.

some time ago I backed up /dev/block/sda from my android 12 phone.
I forgot it was encrypted..
and that it had 34 partitions.
userdata partition WAS sda34.
how can I momentarily mount the backup in android?
losetup is present...

bootloader

Hey guys i have an n8010. When samsung released the leak fw for the 8000 I installed it. It worked pretty well. A few months ago an official update came for the 8010 but im using the 8000 bootloader i cannot install it Is that any solution for recovering the old bootloader? I've tried a lot of thing to solve it but none of them was successful. I've tried this method: http://forum.xda-developers.com/galaxy-note-10-1/help/recovering-n8010-leaked-locked-n8000-t2802516 and a lot of custom roms but i always have a same crash after using it for about 2 days. It says System UIDs Inconsistent, UIDs on the system are inconsistent you need to wipe your data partition or your device will be unstable. And if i press "I'm felling lucky" every app crashes touchwiz ,android everything.
Please help me to solve my problem

kataik95 said:
Hey guys i have an n8010. When samsung released the leak fw for the 8000 I installed it. It worked pretty well. A few months ago an official update came for the 8010 but im using the 8000 bootloader i cannot install it Is that any solution for recovering the old bootloader? I've tried a lot of thing to solve it but none of them was successful. I've tried this method: http://forum.xda-developers.com/galaxy-note-10-1/help/recovering-n8010-leaked-locked-n8000-t2802516 and a lot of custom roms but i always have a same crash after using it for about 2 days. It says System UIDs Inconsistent, UIDs on the system are inconsistent you need to wipe your data partition or your device will be unstable. And if i press "I'm felling lucky" every app crashes touchwiz ,android everything.
Please help me to solve my problem
Click to expand...
Click to collapse
I think your Stuck with the bootloader..
The issue about im feeling lucky thing... I think you have malware on your device... Never heard of or seen nothing like that

hi,
this is my backup of the jb bootloader for the n8013 [n801x]
http://d-h.st/users/moonbutt74/?fld_id=39849#files
cwm flashable
m

moonbutt74 said:
hi,
this is my backup of the jb bootloader for the n8013 [n801x]
http://d-h.st/users/moonbutt74/?fld_id=39849#files
cwm flashable
m
Click to expand...
Click to collapse
Thanks man i havent tried it yet but i hope it will help
Sent from my SM-G900F using XDA Free mobile app

Hi, well I have the n8010 model.
and while you install the version of n8000 leak.
so my bootloader remained in n8000.
and then, after much, I put the rom gnabo v6.
and a few days ago, my note I do not step beyond the samsung logo, stayed stagnant.
try putting on the rom again, but not carrying anything.
I made full format from the recovery of the internal sdcard.
did wipes and try to flash the rom, but not!
I went back to install the 4.4 leak of n8000, but nothing.
and I get the error: failed mount / efs (invalid argument)
that I can do? please help.
sorry for my English, I'm from mexico

FGM 11 said:
Hi, well I have the n8010 model.
and while you install the version of n8000 leak.
so my bootloader remained in n8000.
and then, after much, I put the rom gnabo v6.
and a few days ago, my note I do not step beyond the samsung logo, stayed stagnant.
try putting on the rom again, but not carrying anything.
I made full format from the recovery of the internal sdcard.
did wipes and try to flash the rom, but not!
I went back to install the 4.4 leak of n8000, but nothing.
and I get the error: failed mount / efs (invalid argument)
that I can do? please help.
sorry for my English, I'm from mexico
Click to expand...
Click to collapse
I tried everything but nothing helped. And now i have the same efs problem like you. I hope that somebody can help us

This worked for the galaxy tab 3 10.1
okay,
a while back i helped a user with a similar problem. this was my approach HOWEVER, the following conditions
must be met first.
1 you are able to boot into recovery and maintain normal operation including adb root shell access
2 you are able to charge your tab from a powered off state, mostly to see if you charging animation shows.
that means your kernel is intact-ish
3 you can boot into odin mode.
assuming the partion layouts for your respective devices match the red highlighted sections of this output from parted.
Code:
[email protected]:/ # parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print all
print all
Model: MMC MAG2GA (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
[COLOR="Red"] 1 4194kB 8389kB 4194kB BOTA0
2 8389kB 12.6MB 4194kB BOTA1
3 12.6MB 33.6MB 21.0MB ext4 EFS
4 33.6MB 41.9MB 8389kB PARAM[/COLOR]
5 41.9MB 50.3MB 8389kB BOOT
6 50.3MB 58.7MB 8389kB RECOVERY
7 58.7MB 92.3MB 33.6MB RADIO
8 92.3MB 931MB 839MB ext4 CACHE
9 931MB 2399MB 1468MB ext4 SYSTEM
10 2399MB 2923MB 524MB ext4 HIDDEN
11 2923MB 2932MB 8389kB OTA
12 2932MB 15.8GB 12.8GB ext4 USERDATA
(parted)
AND provided you can get someone competent with access to the respective models to open a root shell
on device or through adb and run the following command,
Code:
[COLOR="Red"]dd if=/dev/block/mmcblk0 of=/sdcard/fix.img bs=1 count=35221668[/COLOR]
AND zip the output fix.img and post it, again for the respective devices.
THEN you can through adb,
adb push fix.img /sdcard/
or
adb push fix.img /sdcard
or
adb push fix.img /data/media/0/
or
adb push fix.img /data/media/0
you can then navigate TO the directory you pushed the image to and execute the following
dd if=fix.img of=/dev/block/mmcblk0
the above approach worked for me in helping another user with a like device.
you assume the same risk you took previously to achieve the state your device is in now.
NOTE- count=35221668 is a hair under the actual end of /efs . you may need to adjust through param and into boot maybe
half way , but then you can just reflash kernel or then do a proper odin flash of stock. the fix.img will NOT be odin flashable.
m

partitions
moonbutt74 said:
okay,
a while back i helped a user with a similar problem. this was my approach HOWEVER, the following conditions
must be met first.
1 you are able to boot into recovery and maintain normal operation including adb root shell access
2 you are able to charge your tab from a powered off state, mostly to see if you charging animation shows.
that means your kernel is intact-ish
3 you can boot into odin mode.
assuming the partion layouts for your respective devices match the red highlighted sections of this output from parted.
Code:
[email protected]:/ # parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print all
print all
Model: MMC MAG2GA (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
[COLOR="Red"] 1 4194kB 8389kB 4194kB BOTA0
2 8389kB 12.6MB 4194kB BOTA1
3 12.6MB 33.6MB 21.0MB ext4 EFS
4 33.6MB 41.9MB 8389kB PARAM[/COLOR]
5 41.9MB 50.3MB 8389kB BOOT
6 50.3MB 58.7MB 8389kB RECOVERY
7 58.7MB 92.3MB 33.6MB RADIO
8 92.3MB 931MB 839MB ext4 CACHE
9 931MB 2399MB 1468MB ext4 SYSTEM
10 2399MB 2923MB 524MB ext4 HIDDEN
11 2923MB 2932MB 8389kB OTA
12 2932MB 15.8GB 12.8GB ext4 USERDATA
(parted)
AND provided you can get someone competent with access to the respective models to open a root shell
on device or through adb and run the following command,
Code:
[COLOR="Red"]dd if=/dev/block/mmcblk0 of=/sdcard/fix.img bs=1 count=35221668[/COLOR]
AND zip the output fix.img and post it, again for the respective devices.
THEN you can through adb,
adb push fix.img /sdcard/
or
adb push fix.img /sdcard
or
adb push fix.img /data/media/0/
or
adb push fix.img /data/media/0
you can then navigate TO the directory you pushed the image to and execute the following
dd if=fix.img of=/dev/block/mmcblk0
the above approach worked for me in helping another user with a like device.
you assume the same risk you took previously to achieve the state your device is in now.
NOTE- count=35221668 is a hair under the actual end of /efs . you may need to adjust through param and into boot maybe
half way , but then you can just reflash kernel or then do a proper odin flash of stock. the fix.img will NOT be odin flashable.
m
Click to expand...
Click to collapse
Well this is how my partitions look like: http://kepfeltoltes.hu/view/140928/partitions2_www.kepfeltoltes.hu_.png

Instructions Matter
kataik95 said:
Well this is how my partitions look like: http://kepfeltoltes.hu/view/140928/partitions2_www.kepfeltoltes.hu_.png
Click to expand...
Click to collapse
K,
i must stress the need for you to follow instructions, hear me out, I am operating on the assumption that you are
an experienced android user.
1 the archive with the bootloader data i provided was a cwm flashable zip file. to attempt a flashing of that file itself
or the img files contained within in any other fashion has likely made your problem worse. i also stated as per the
name of the file that it is for the n8013. it is good to hear that you have made some progress however instructions
are important because,
2 though you have succeeded in using parted through adb you have provided the wrong information.
instead of
parted /dev/block/mmcblk0p8
please run
parted /dev/block/mmcblk0
then at the (parted) prompt running print all wil return the correct information.
I mean the above in the best way, as well to stress the importance of doing these things correctly
to avoid a true hard-bricking of your device. You will need to go hat in hand and request an experienced/competent
user/developer pull the needed data from their device as stated in my previous post.
it is likely that the data pulled from my device may work, but that your device afterwards will register as an n8013.
please re-execute parted through adb as instructed for the needed information and we can move foward from there.
m

moonbutt74 said:
K,
i must stress the need for you to follow instructions, hear me out, I am operating on the assumption that you are
an experienced android user.
1 the archive with the bootloader data i provided was a cwm flashable zip file. to attempt a flashing of that file itself
or the img files contained within in any other fashion has likely made your problem worse. i also stated as per the
name of the file that it is for the n8013. it is good to hear that you have made some progress however instructions
are important because,
2 though you have succeeded in using parted through adb you have provided the wrong information.
instead of
parted /dev/block/mmcblk0p8
please run
parted /dev/block/mmcblk0
then at the (parted) prompt running print all wil return the correct information.
I mean the above in the best way, as well to stress the importance of doing these things correctly
to avoid a true hard-bricking of your device. You will need to go hat in hand and request an experienced/competent
user/developer pull the needed data from their device as stated in my previous post.
it is likely that the data pulled from my device may work, but that your device afterwards will register as an n8013.
please re-execute parted through adb as instructed for the needed information and we can move foward from there.
m
Click to expand...
Click to collapse
Thanks for all the help you gave me but I decided to take my tab to a service, they probably make it work

kataik95 said:
Thanks for all the help you gave me but I decided to take my tab to a service, they probably make it work
Click to expand...
Click to collapse
Sure, no problem. Hope everything works out. :good:
m

moonbutt74 said:
Sure, no problem. Hope everything works out. :good:
m
Click to expand...
Click to collapse
Imagine after 2 services where the could't fix I took to a 3rd. They could fix it so it works its on 4.0.4 in some kind of factory mode (strange). I can not quit from this mode and odin not works as well. In the recovery it says efs is invaild. What is that fw?

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

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

Reserved

Reserved

Good to have a place again to discuss issues or simple questions.
Great tool, that meanwhile left its corner where it grew up (the Galaxy S2 - i9100), meanwhile supporting a growing number of devices.
RELEASES AND CHANGELOG

the.gangster said:
Good to have a place again to discuss issues or simple questions.
Great tool, that meanwhile left its corner where it grew up (the Galaxy S2 - i9100), meanwhile supporting a growing number of devices.
@Lanchon
you accidently linked the downloads to your flashize github instead of the Repit one.
Click to expand...
Click to collapse
lol thanks, mucho copy/pasta, fixed!

Thanks so much!
Perfect tool, used this evening on a old but still used I9100!

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.

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!

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.

samarium said:
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.
Click to expand...
Click to collapse
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

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

just change your current directory to /tmp and try to flash it again from there. (all within the recovery)

Lanchon said:
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
Click to expand...
Click to collapse
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.

samarium said:
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.
Click to expand...
Click to collapse
>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.

darkz16 said:
[...]
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]
Click to expand...
Click to collapse
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

darkz16 said:
[...]
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
Click to expand...
Click to collapse
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!

Lanchon said:
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!
Click to expand...
Click to collapse
Hi Lanchon.
I'm installed this zip but i have the same problem.
I'm copy, before zipping the achive, on the \tmp directory of emmc
What have i do wrong?.
Thanks.

chapito said:
Hi Lanchon.
I'm installed this zip but i have the same problem.
I'm copy, before zipping the achive, on the \tmp directory of emmc
What have i do wrong?.
Thanks.
Click to expand...
Click to collapse
no log, no kernel info, no recovery info. cant help you.

Lanchon said:
no log, no kernel info, no recovery info. cant help you.
Click to expand...
Click to collapse
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

chapito said:
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
Click to expand...
Click to collapse
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!
thanks!

[SOLVED] Help to mount userdata in linux or repair userdata.img

After an Update of Two magisk modules, my Ulefone Armor 11 5G staied stucked on boot logo, I can only enter in recovery or fastboot.
I try to build a TWRP, but it is not able to mount userdata.
I was able to download with the help of mtkclient all the partition on my phone, even userdata , it took 7 hours.
I wanted to load the image in linux but using mount disk imag or using the command sudo mount -o loop userdata.img ~/Armor_11_5G doesn't do anything not even an error message.
I'm wondering if the filesystem was corrupted during the update.
Is it possible to repair the fylesystem like in Windows?
Thanks

did you previously disable encryption and factory reset long time before the modules updates failed?
what do you mean mount doesn't do anything not even an error message? either it give error message or it succeed.

I didn't disable encryption before updating the modules, I already updated this modules many times.
what do you mean mount doesn't do anything not even an error message? either it give error message or it succeed.
Click to expand...
Click to collapse
That is the problem, it doesn't succed and I don't have an error message. The file is 256 Gbyte big, I don't know if it plays a role. I'm using Ubuntu 22

if phone is encrypted that's just 256G garbage. post the output of
Code:
$ parted <file> unit B print

Here are the results of parted
Code:
Error: /home/*****/Public/userdata.bin.img: unrecognised disk label
Model: (file)
Disk /home/osboxes/Public/userdata.bin.img: 249208733696B
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
Thanks

You may try https://www.cgsecurity.org/wiki/TestDisk_Download
I'd be glad for your feedback.

sorry thought it's whole disk, but it's only 232G file therefore parted won't print partition table
does apply to FDE only
assuming this file is dump of single userdata partition, open with HxD editor. if the partition image is not encrypted, you will see lot zeros within first 1024 bytes.
in that case you can check for file system type is ext4 or f2fs.
Code:
$ xxd -l 1080 dump.img | grep 53ef
$ xxd -l 1024 dump.img | grep 1020.f5f2
But most likely the userdata partition is encrypted, therefore no way to recover data offline.
The easiest way not to load Magisk modules is, not to load Magisk. Flashing stock boot.img will solve it.
Beware, in case you disabled encryption beforehand, booting stock boot.img will force encryption. This may take long time without notice.

I never disabled encryption, I don't know if Magisk do it without informing. I used this phone for an year without a problem.
After the update I left the phone on for one night but nothing happens. I tried to reflash the stock boot image, and again a whole night wait, but again nothing happens.
Reading the fstab the file system should be ext4.
The file is the dump of the whole userdata partition of my Ulefone Armor 11 5G.
I did a backup of the whole system before doing any experiment so if the partition table is corrupted maybe if I reflash back the userdata partition with a working partition table I have again access to the datas.

there is no partition table in userdata partition, I just gave you wrong advise. because the phones total storage is 256G, I made wrong assumptions (you can view partition table from file pgpt.bin)
full 1:1 backup is impossible for FBE encryption because encryption keys are stored in TEE. once you factory reset device backup of userdata + metadata becomes useless.
fstab doesn't tell you what file you just have dumped. if you can't find ext4 super magic (#7) it's impossible to loop mount that file (and impossible to decrypt on linux PC)
if you can't fix boot-loop by stock boot.img then it's unrelated to magisk modules. you can however enable adb in default.prop and capture adb logcat during boot-loop for further analysis. you could also inject own script that deletes some files (only DE encrypted files, CE encrypted files requires lock screen credentials aka pin/pattern)

boot this TWRP and get log from adb
Code:
$ fastboot boot recovery.img
$ adb shell twrp decrypt '1234'
$ adb pull /tmp/recovery.log
https://twrp.me/faq/openrecoveryscript.html

full 1:1 backup is impossible for FBE encryption because encryption keys are stored in TEE. once you factory reset device backup of userdata + metadata becomes useless.
Click to expand...
Click to collapse
With mtk client I was able to do the backup of tee1 and tee2 and also of gpt_backup and gpt_main.
$ xxd -l 1080 dump.img | grep 53ef
$ xxd -l 1024 dump.img | grep 1020.f5f2
Click to expand...
Click to collapse
Doesn't produce any results.
I have immediately the command prompt.
you can however enable adb in default.prop
Click to expand...
Click to collapse
How can I do that? Which value should I change in default.prop?

so your "backup" is encrypted. please note Trustonic Kinibi is TEE OS running in secure memory one can't access or backup with mtkclient. the tee partitions in phone storage do not contain any encryption key (none of the partitions does, secure memory is not even a partition). the only crypto related partition is metadata used for keydirectory of metadata encryption (on top of FBE encryption) but it is useless for backup purposes.
yes you can modify default.prop in boot.img, ro.secure=0 should give root access.
https://forum.xda-developers.com/t/...hone-with-broken-screen.2965462/post-85905033
Code:
ro.secure=0
ro.debuggable=1
persist.service.adb.enable=1
in case the default.prop modification is not sufficient, you need additional command to be executed as root.
Code:
# settings put global adb_enabled 1
as you installed magisk, you could use magisk overlay.d/sbin/ for running startup script.
https://forum.xda-developers.com/t/...ithout-losing-your-data.4383255/post-86934375
aIecxs said:
boot this TWRP and get log from adb
Code:
$ fastboot boot recovery.img
$ adb shell twrp decrypt '1234'
$ adb pull /tmp/recovery.log
https://twrp.me/faq/openrecoveryscript.html
Click to expand...
Click to collapse
How about this TWRP? it should be able to decrypt userdata. if decryption failed, provide recovery.log

Until tomorrow I cannot do a logcat and I cannot find my view logcat on my laptop.
I unpacked boot.img with Carliv Image Kitchen and there is no default.prop, that is present in the recovery as prop.default.
Is there a way to backup secure memory of Trustonic?
How about this TWRP? it should be able to decrypt userdata. if decryption failed, provide recovery.log
Click to expand...
Click to collapse
I already tried that version but it cannot decrypt, that' why I'm trying to build my own version of TWRp with the help of the creator of that version of TWRP, but I'm stucked.

oh, you know how to build TWRP with proper FBE + metadata encryption support? have a look at other Oppo devices how they did... good luck.
regarding default.prop in boot.img (it's a symlink to system unfortunately) you can do it the other way
use magisk overlay.d/sbin/
create a boot script that does the thing with resetprop -n <prop_name> <prop_value>
don't use outdated Carliv Image Kitchen! use osm0sis AIK from link above.

oh, you know how to build TWRP with proper FBE + metadata encryption support? have a look at other Oppo devices how they did... good luck.
Click to expand...
Click to collapse
I'm learning.
I try to integrate the decryption service following the suggestion of ADeadTrouser on Github, but the service doesn't want to start and I don't understand why.
I never checked Oppo, I will take a look at them also, thanks for the suggestion.

I think I figured out now the adb logcat at least. hope that helps
https://forum.xda-developers.com/t/accessing-my-phone-with-a-dead-screen.4542763/post-88016019

I tried your script butr nothing happens, the telephone is not listed when I type
Code:
adb devices
and if I type
Code:
adb logcat
I receive the message waiting for device

you might follow the thread

wenyendev said:
You may try https://www.cgsecurity.org/wiki/TestDisk_Download
I'd be glad for your feedback.
Click to expand...
Click to collapse
I run the software on the image and it identify the contents and can read the encrypted and not encrypted part, that means that all the files are there, but I cannot mount in Linux or in TWRP

The fact that I cannot mount in Linux or TWRP the userdata image/partition can be that is corrupted the partition or the file index?
That would also explain why the script for Magisk provided by aIecxs is not able to copy the adb_key from the cache in the data partition.