Database Info

Need help with vold.conf for cupcake apps to sd

I am trying to work with haykuro to get apps on sd for his cupcake roms, but I ran into a problem. They replaced mountd with vold, and there is no known documentation on how to format the config file. This does not seem to be the same vold that is used on SUN or other unix operating systems. If anyone has any useful info, please share it with me so I can look into this further.

Maybe this will get you started...
*EDIT* didnt read your post correctly... Didnt see that it was not related to the Sun version.
Darkrift,
Maybe the vold.conf in the android system is similar to the vold.conf in my Solaris 10 Sparc Server.....
Code:
> > For Solaris 8, you have to fake a change on the vold.conf
> > configuration file, otherwise the HUP signal is ignored:
> >
> > touch /etc/vold.conf
> > + pkill −HUP vold
>
> I stopped vold & commented out the one /etc/vold.conf line:
> # use rmdisk drive /dev/rdsk/c*s2 dev_rmdisk.so rmdisk%d
If you want vold to automatically mount an usb mass
storage device on a reboot (or a re−start of vold, or the above
mentioned touch / SIGHUP sequence), you have to make sure to remove
the comment character from the "use rmdisk" line in /etc/vold.conf.
Study some of the Sun Solaris docs I have listed below and maybe you will find the right recipe you are looking for...
Sun Solaris USB Flash Drive Mount Command
Solaris 10 - System Administration Guide - Devices and File Systems
Hope this helps...
I'm on Gtalk as AndroidSamurai if you have any questions.
While I'm at it, this is the command to mount a floppy in Solaris...
Code:
mount -f pcfs /dev/diskette /mnt
/mnt is the mount point

Here is what is currently in the file:
Code:
## vold configuration file for Sapphire
volume_sdcard {
## This is the direct uevent device path to the SD slot on the device
media_path /devices/platform/msm_sdcc.2/mmc_host/mmc1
emu_media_path /devices/platform/goldfish_mmc.0/mmc_host/mmc0
media_type mmc
mount_point /sdcard
ums_path /devices/platform/usb_mass_storage/lun0
}
I tried adding:
Code:
volume_apps {
## This is the direct uevent device path to the SD slot on the device
media_path /dev/block/mmcblk0p2
media_type mmc
mount_point /system/sd
}
with no luck. And yes, I tried doing the media_path in the same format as the first one, which also did nothing.

Would the "mount_point" not be "/sdcard"?
I cannot work the terminal on my G1 bc of the keymapping error preventing me from using "/"...
Would it not be:
Code:
media_path /dev/block/mmcblk0p1
seeing that a fat partition(vfat) would be "p0" ?
Have you tried looking at "vold/mmc.c and vold/mmc.h" ?
Also try looking at the following:
Code:
vold/volmgr_ext3.c
vold/volmgr_ext3.h
vold/volmgr_vfat.c
vold/volmgr_vfat.h
If you would please e-mail me the vold.conf in a zip archive so I can play around with it a little...
Sorry, my resources are a little bare at the current time due to a surge knocking out all my equipment.
Email Me
or find me on GTalk under androidsamurai.....

No, i am trying to add apps to sd, which go in /system/sd/app. this would mount my second partition (ext2) /system/sd

Let me also state that the top part is working. that is what loads the sdcard to /sdcard. what I am trying to do is load the second partition to /system/sd by adding a *second* block to the file, which is not working.

Hi Darkrift,
I don't have a second partition on my sd card nor have I installed any of the cupcake builds so I can't test my thoughts myself but thought I'd share them with you...
Have you tried browsing to the directory referenced by the original vold.conf? I was just wondering how this structure compares to a device using a partitioned sd card? Maybe a comparison would give us some clues as to how the new volume manager works.
Mine looks like this:
sys/devices/platform/msm_sdcc.2/mmc_host:mmc1/mmc1:d516
With no other similarly name directories below the msm_sdcc.2 level.

Why don't we use Fat32 partition as extra memory? why can't we run application from a Fat32 partition?

#1 FAT32 doesn't support case-sensitivity, and that is enabled on the internal FS's
#2 extfs is way better than FAT
#2 FAT sucks

@wellsie: I think the problem is the name I am giving it "volume_apps {
" but if i change it to volume_sdcard { like the first one, it adds those config options to teh top block. Also I have tried adding all different versions of the media path (in /dev, in /system/devices and more) with no luck.
@funbacon: Joushou's ideas make sense, but neither of those are the reason. Each application installed on the G1 has an owner, group and set permissions. That is part of the "sandbox" that keeps apps from accessing each others files. Fat has no permissions, so an app on fat would not be able to have the needed permissions to be used.

Oh yeah, permissions aswell
I have been too long in unix, so i just expect that to be there
But i believe that fits under the "FAT sucks" category

I agree with that one

C'mon. I know someone has gotta have some ideas or maybe know how to browse the source and figure stuff out more than I could. I tried checking out the source but its fairly foreign to me. I know a little scripting, but not much as far as coding goes. I really would like to help get apps-to-sd working in cupcake but this is a major stumbling block for that.

I just want to say that even i am not proficient on this type of stuff i voluntere to test whatever setup you come up with.
I really apreciate your work on this as this is the only reason I have not moved to haykuros or anybodys cupcake build.
So thanks tanks to every body for pitching in.
oh by the way, If you set it up i will donate to the cause!!!!!

I'll try and look at the code over the weekend...family time comes first though so it may have to wait until next week when I'm at work ;-)

I think the main problem is the naming convention for a new "block". sdcard is already in use, and adding a second one just adds to the first one. I think there might be "sdcard2" or something else that it is expecting. I tried just naming it whatever I wanted hoping that would work but it didnt seem to.

im with carlos im not a good with all that code stuff, but im down to test whatever u come out with,
also for i heard haykuyo is coming out with a fix for the physical keyboard soon

If you are speaking about "Keyboard Fix" in the terms of the Keyboard Mapping being messed up, then chack out the first post of the Sapphire/Magic G1 Port thread... Keyboard mapping has been fixed.
I honestly cannot believe that Google hasn't had any hits on the android site about this problem yet...

Instead of partitioning, maybe we can try this other method for apps to sdcard.
http://forum.xda-developers.com/showpost.php?p=3402719&postcount=683
http://forum.xda-developers.com/showpost.php?p=3402947&postcount=687
This method creates an ext2 filesystem object as a file under the fat32 filesystem so there would be no need to partition.
I'm doing my taxes today, but if I get a chance to play around with it, I'll try to implement this tomorrow. Looks pretty straightforward.

well, nobody would know about this problem unless they are breaking the rules. A, having a rom which we should not have, and B, making changes to the OS and "hacking" it to read apps somewhere its not supposed to. Android should not have 2 partitions, so this is not something they would even answer.

[HOWTO][exFAT][CM10.1] Working 64GB ext sdcard with fuse-exfat (1.0.1) + FIX broken

This post has largely been relegated obsolete by my Flashable Mod.
Please see my new post >>HERE<<
I am leaving this up for informational purposes, and for record-keeping.​
[HOWTO][exFAT][CM10.1] Working 64GB ext sdcard with fuse-exfat (1.0.1) + FIX broken
How to get a exFat formatted 64GB external sdcard working with CM10.1 using fuse-exfat & FIX broken card headers
Attribution credits:Original thanks go to originator of the method, smitna in the Galaxy S2 forum, for providing the method. Additional thanks go to shardul_seth (Post 23) for compiling the latest version of the fuse-exfat binaries for ARM, and of course Andrew Nayenko for his efforts in creating GPL'd exFat code (fuse-exfat on google code).[HOWTO][exFAT][WORK IN PROGRESS] Mount exFAT formatted drives and cards​TL;DR - READ THE POST FIRST!:
Download shardul_seth's binaries for fuse-exfat from (Post 23) or the bottom of this post.
Unzip the files into /data/ (requires root)
Open an ADB shell as root (requires USB-Debugging turned on, ADB utility, also at bottom)
Run the following commands: (change mmcblk1p1 to suit your sdcard's partitioning - it might be mmcblk1. DO NOT FSCK WITH blk0, that is your internal card!!!)
Code:
chmod 775 /data/*fat*
mount -o rw,remount /system
echo "/data/mount.exfat-fuse -o rw,dirsync,umask=0 /dev/block/mmcblk1p1 /storage/sdcard1" > /etc/init.d/10exfatsdmount
chown root:shell /etc/init.d/10exfatsdmount
chmod 755 /etc/init.d/10exfatsdmount
Done! Reboot and enjoy.
SHOULD YOU BORK YOUR CARD BY REINSERTING IT (or get "Card Damaged" icon)
Run the included filesystem header patcher script as root (warning: has minimal safety checks, is hardcoded for "mmcblk1p1") to fix the likely corruption: (easily modified)
Code:
/data/fixmyexfat.sh
Reboot. (or run "vold"?)
Proof / What to Expect:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Overview:
An open source project recently reverse-engineered the exFat specification via a fuse driver (ala fuse-ntfs-3g). The first stable reelase was in January, and I am astounded that it hasn't been implemented in CM yet -- aside from the moral and potential legal reasons. A user here at XDA compiled the binaries and posted instructions, I am taking on the lead for putting it all together for others. I am tired of seeing posts dated as late as February 11th saying it is "Impossible" and to give up, or flash another ROM -- you are spreading misinformation and it needs to be stopped. This implementation isn't fully vetted, but it works seamlessly enough for most users.
Even without the fuse driver, it's pretty well known CM10.1 (and CM10) mangle exFat cards -- and to fix them, you need to merely run "chkdsk /f" on the drive from Windows. However, as soon as you plug it back into the phone, it automounts and mangles it again before you can do anything. I found out what was getting mangled, why, and when, and tried to work around it. I found by mounting at boot-time, before vold has a chance to attempt an automount, you can get the system to fully recognize a card. (See screenshots.) Theoretically, this means you can have a SDcard with multiple partitions -- a "dummy" fat32 partition at the start to fool vold with the mount scripts, and the exfat one that you rebind over it. (System -> Storage dynamically updates as long as you don't "unmount" from the GUI.)
The hex dump on the left is the first 512 bytes of a healthy exFat partition, the second from a mangled one. By noting the offsets and exact mangling of (0x000 = "RRaA", 0x1E4 = "rrAa", 0x1FC = 00 00 55 AA), I found out that it was attempting to replicate the "FS Information Sector" Signature of FAT32 - so there is a problem with CM's code somewhere attempting a fsck.fat32 when it isn't appropriate.
CM 10.1 / Android 4.2.1 also completely redid how mountpoints are set up. There are summarized in the "Technical Details" section below. The gist of it is, /data/block/vold/179:96 is the device (e.g. /sda/) and /data/block/vold/179:97 is the first partition (/sda1/). And in CM10.1 (if you had a FAT32 card), the 97 one is mounted to /storage/sdcard1/ via FUSE. However, these block-special files are dynamically generated by vold so are inappropriate to use -- we need to use mmcblk1p1. Depending on how the card is formatted, your mounts may change slightly.
The final challenge is where to put the binaries. I could not chmod make files on the /storage/sdcard0/ mount executable for some reason - by looking at CM10.1's source code I found why. Android moved to using a "fake" vfat partition and MTP under a FUSE layer unify storage space and remove file corruption/mutex issues. Unfortunately, that means it blocks permissions --- hence my recommendation to put the binaries in /data/ which is exposed as ext4. If you absolutely must put the binaries on the internal SDcard, you need to run the chmod commands from /data/media/0/ folder and the permissions will mirror properly. (This is the ext4 original of /storage/sdcard0/ "vfake".)
Technical Details: (mounts, softlink chains)
Code:
[B]ALL-IMPORTANT "FIXER" HEX-PATCHING CODE[/B]
(Reminder: dd = Destroyer of Disks. I take no responsibility.)
echo -e "\xeb\x76\x90\x45"|dd of=/dev/block/mmcblk1p1 conv=notrunc bs=1 count=4 seek=0
echo -e "\xff\xff\xff\xff"|dd of=/dev/block/mmcblk1p1 conv=notrunc bs=1 count=4 seek=484
echo -e "\x1f\x2c\x55\xaa"|dd of=/dev/block/mmcblk1p1 conv=notrunc bs=1 count=4 seek=508
[B]FOR INTERNAL SD CARD, "USER #0"[/B]
/storage/[B]sdcard0[/B] -> /storage/emulated/legacy
/storage/emulated/[B]legacy[/B] -> [B]/mnt/shell/emulated/0[/B] (fuse-fake-fat!)
/data/media/0 (ext4)
/dev/fuse [B]/mnt/shell/emulated fuse[/B] rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
[B]FOR FAT32 EXTERNAL SD CARD[/B]
/dev/block/vold/179:96 /storage/[B]sdcard1[/B] vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
(Notice it is [I]179:96[/I] -- the whole disk is storage. If you had it on Partition1, it would be [I]179:97[/I])
[B]FOR exFAT EXTERNAL SD CARD[/B]
/dev/block/mmcblk1p1 /storage/sdcard1 fuseblk rw,dirsync,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096 0 0
(In this case, it is [I]mmcblk1[B]p1[/B][/I] -- since I partitioned it. However, I have fudged my card before so it was just [I]mmcblk1[/I].)
If you need/want to change between "Floppy" mode (single big disk) and "Hard Disk" mode (with a partition table), I highly recommend using a program called BOOTICE to do it. It supports a number of "quirks" like reordering visibility of NTFS partitions on a Flash Drive, etc. (I will add instructions if there is demand.)
Remaining issues:
Unmounting poses no problems, doesn't corrupt anything. However, upon remounting (eg: vold rescan, physically removing/reinserting the card -> autodetect, or clicking "Mount SD Card" in the GUI), vold will re-mangle the filesystem header. The notification of "Damaged SD Card" also gets displayed and cannot be removed, even if my hotfix script is applied live.There was a version of Vold-exfat floating around for ICS, but that likely isn't compatible for us.​MTP works. UMS however is not currently implemented in the Unofficial Mastamoon build of CM10.1 I use. I therefore cannot test how Windows handles it.Programs like XDA's own "SGS3 Easy UMS" do not work, or work behaves eratically. By a convoluted scheme (Unmounting card from Shell -> Plugging in usb -> clicking "UMS") I was able to see a Read-only CD-Rom drive of my SD card. This seems to be a common issue.
Manual methods like changing the build.prop do not work - you see an *empty* CD-rom drive.​(From what I can gather) Cyanogen 10.1 does not currently allow for plug-and-play fuse modules to allow you to pick your own filesystem just by adding a .ko. Similarly, the exfat-utils (exfatfsck, etc) fail to run (even on a "fixed" card) since DKIOCGETBLOCKSIZE in io.c cannot detect the block size -- you will notice "blkid" doesn't recognize the exfat device either. "Vold" gets confused and mangles the filesystem header.Cyanogenmod needs to be updated to support Fuse modules more gracefully -- and ABSOLUTELY NOT modify the filesystem at all unless prompted.​

Sorry, problem solved.

Flashable mod is up, created new thread in the right section. Check OP for link.

[Q] I think Internal Flash memory of my Android Device has some allocations dead

Greetings dears XDA members!
I read out many many many of posts before postings, and also used "search" feature in order to find a topic like mine, but with no success.
Well, I start to explain my problem..
====
A few days ago, my Samsung Galaxy Tab 2 (10'1)'s tablet caused some reboots without really beings really very common, but now .. reboot frequency has greatly increased since yesterday day.
A quick check using the "Reboot Checker" (you can find it through the Google Playstore: https://play.google.com/store/apps/details?id=jp.chau2chaun2.rebootchecker), and I can see that reboots are really common now as showed by the log reports showed in "RebootCheckerLogReports.png"'s file attachment to my post.
So.. What I do of specials before reboots are produced??
Hmm.. Really nothing, really:
I always deactivate the "AutoUpdate" for Apps from Google Play
Before reboots are encountered, I not installed any applications
I never install applications and Games out of Google Play official market
I just play to few games (like usually I do): Fantasica, Rage of Bahamut, Legends of Cryptids, Arcana Magic, DarkLords, Bingo Blitz, Chaos Drive, and that's all..
All applications I install from Google Play are recommanded/unlocked by AppGratis (and other websites like this)..
I never rooted my system (And I see now, I'll have to do on Day 1 of the purchase of the tablet ... since no-rooted an Android System doesn't permit recovery things at an advanced state..)
So, due to that reboot, I firstly thought that was a memory storage issue like, not enough diskspace. (with all that AppGratis applications, I have less disk storage memory indeed xD).. Then, I uninstalled some apps which I installed some months ago and I less used..
Bad Tought: Reboots hasn't been discontinued... ** sigh **
I think then it was update of Google Apps (like Google+, Google Talkback, Google Mail, Google Youtube etc..), so I updated them from Google Play..
Again, Bad Toughts: Reboots still here.. ** big sigh **
Well.. my hope was then at this state ported to Internet...
So I read many topics on "Unattended Reboots"..
And I finally found something of VERY useful.
On here: http://android.stackexchange.com/qu...-determine-the-cause-of-random-device-reboots
Glad I find that StackExchange question, I now that the "su" (Linux SuperUser if I well understand my Linux course), is not possible under a non-rooted Android (that a stupid behavior for an Operating System that.. But.. Well.. I continue)..
So, I started to think how I will be able to catch this file... and save in a readable folder..
Hopefully, 1 year ago I installed an app named: "ES Explorateur de fichiers" (find out this here: https://play.google.com/store/apps/details?id=com.estrongs.android.pop)
And this great apps was letting me accessing to the wanted file: /proc/last_kmsg
(I shared it to my DropBox linked account, and then I was able to open it on my Windows 7 Computer).
I then provide the log here: https://www.dropbox.com/s/u9ble2ui30io5x8/last_kmsg
So.. In the meantime, I started to analyze the log, and visiblely, my main (and sad) problem is that my Internat Flash Drive is dead.. Since I/O errors are the only main reason to Kernel Panic and reboots..
Well.. My warranty is void since months now.. (well well.. well..)
I then can't RMA the product (the tablet if I understand well).
I don't want wipe datas/cache and anything before try some new XDA tricks.. (I don't expect do much like that, but hey.. Hope is Hope.. my datas aren't important, it's true, it's mainly Game Saves and Unlock keys for AppGratis recommanded applications, but then, if I wipe datas, I will lose ALL of theses free unlocked apps.. This is a thing I doesn't really want, if you mean what I want mean..)
... so... I started to think what we can do for fix bad sectors on Linux (since Android is based on Linux and Dalvik if I (again) understanded well).
I hink that fixing bad sectors allocations it will fix the problem, since if I analyze my Internal storage (called sdcard0) there is sometimes the scan is finished without reboots!
So I was directed on XDA-Developers (which I know that you are famous for your system hacks and morever) here by Google : http://forum.xda-developers.com/google-nexus-5/help/reboot-due-to-kernel-panic-t2553949
I saw this post: http://forum.xda-developers.com/showpost.php?p=48250638&postcount=3
And then a quick search on Google again on the words "Android + fsck the filesystems through adb shell" redirected me to that excellent post: http://forum.xda-developers.com/showthread.php?t=2165870
This is a great information, but... I don't know how to go in recovery mode from my Galaxy Tab 2. So.. I searched on the web for it, and found that: http://forums.androidcentral.com/sa...ing-into-recovery-mode-galaxy-s2-s3-tab2.html
So.. I started blink my eyes, and go for hard work, and since I already in the past installed the Android SDK (for develop personal mobile apps with Titanium Studio, Adobe Cordova, PhoneGap), and do all update especially installed adb..):
Once plugged to my PC and booted in recovery mode, I was able to access to the famous recovery mode
(This was so exciting due to the fact I like the way of it look: especially the Android bot unfixed in the background ^_^).
So, on my PC I started to open a command line in the folder: C:\SpecialAppDevelopper\Google Android SDK\platform-tools
(this is where I installed the Android SDK)
and typed this:
Code:
C:\SpecialAppDevelopper\Google Android SDK\platform-tools>adb devices
This showed me that:
List of devices attached
c16073dc82dc68f recovery
Click to expand...
Click to collapse
So it worked! My device was successfuly attached to ADB !! What an excitation !
I then continued typing other commands:
Code:
C:\SpecialAppDevelopper\Google Android SDK\platform-tools>adb shell
This output that:
[email protected]:/ $
Click to expand...
Click to collapse
Good. Now In this shell access I typed :
Code:
mount /system
Not good here since all I get is a USAGE warning with options recommanded. (like a return of a MAN command..)
[email protected]:/ $ mount /system mount /system Usage: mount [-r] [-w] [-o options] [-t type] device directory
Click to expand...
Click to collapse
Well.. tryied the next command in order to listing report file system disk space usage:
Code:
df
all I got as output was occuped space, not the path of the mounted images...
Well...
Now, I started to reanalyze my last_kmsg log in order to find which path they are..
I found it!
[ 94.965454] C1 [jbd2/mmcblk0p10]
So... I started to return to my ADB commandline window and typing:
Code:
ls -l /dev/block/mmcblk0p10/
This outputed that:
/dev/block/mmcblk0p10/: Not a directory
Click to expand...
Click to collapse
So as it looks a good path, I started typing this:
Code:
e2fsck -n /dev/block/mmcblk0p10
And even if it is the right path (one of the right path, I don't tryied with others...), I got this output:
e2fsck -n /dev/block/mmcblk0p10
e2fsck 1.41.11 (14-Mar-2010)
e2fsck: Permission denied while trying to open /dev/block/mmcblk0p10
You must have r/o access to the filesystem or be root
Click to expand...
Click to collapse
Yeah... I'm not root, cool, even in a Recovery Mode on a non-rooted Android Operating System (Logic in a way, but very difficult to fix problems then occuring then )..
Ok.. So, My mind blinked in an idea when looking at this: You must have r/o access to the filesystem or be root
So.. This is not needed to be root for executing a e2fsck command in Recovery Mode, but in that case I need having access to the filesystem in a READABLE mode. OK.
So, Hope started to bringed back, and I made new Google research, on "mount an android filesystem in recovery mode"
I was then directed here:
- http://forum.xda-developers.com/showthread.php?t=1396864 - Very complex for me, I don't want brick my system.. So I skipped.
- http://androidforums.com/droid-all-...tem-when-trying-adb-push-app.html#post6347416 -
So.. For being root in recovery mode, I can also type the simple command: adb root
Ok... What I do..
And, as expected it doesn't worked for me:
C:\SpecialAppDevelopper\Google Android SDK\platform-tools>adb root
adbd cannot run as root in production builds
Click to expand...
Click to collapse
Ahaha.. Well starting to be hopeless now.. I'm finally just an user of my OWN tablet.. How it's ridiculous.
This is a bit tedious, because all my future Google research in order to find how to simply "mount" a filesystem as readable (and then replace it as it was after the process..) aren't really efficient, I founded nothing of useful..
Nothing usefull but that: http://android.stackexchange.com/a/69307
So, it seems I will be able to mount as readable a filesystem through Production Recovery Mode (the one I'm forced to use then..)..
BUT..
Well.. Now, since I don't know what I can type for mounting my filesystem... as readable just for make a e2fsck... Seriously..
Help me dear gurus, i'm completely lost because my Linux knowledge stop here !

New informations..
I tryied an another method in order to list devices symlinks names:
Another way to check is to use adb to view the devices file system.
Related to this thread: http://forum.xda-developers.com/showthread.php?t=1463756
Thanks to it (even if it isn't how mounting in RW)
So, when plugged in Recovery Mode I typed:
Code:
adb devices
adb shell "ls -R /dev/block"
The -R is because I want have the realpath of each items listed
Well, this was the output:
/dev/block:
loop0
loop1
loop2
loop3
loop4
loop5
loop6
loop7
mmcblk0
mmcblk0boot0
mmcblk0boot1
mmcblk0p1
mmcblk0p10
mmcblk0p11
mmcblk0p2
mmcblk0p3
mmcblk0p4
mmcblk0p5
mmcblk0p6
mmcblk0p7
mmcblk0p8
mmcblk0p9
platform
ram0
ram1
ram10
ram11
ram12
ram13
ram14
ram15
ram2
ram3
ram4
ram5
ram6
ram7
ram8
ram9
/dev/block/platform:
omap
/dev/block/platform/omap:
omap_hsmmc.1
/dev/block/platform/omap/omap_hsmmc.1:
by-name
by-num
mmcblk0
mmcblk0boot0
mmcblk0boot1
mmcblk0p1
mmcblk0p10
mmcblk0p11
mmcblk0p2
mmcblk0p3
mmcblk0p4
mmcblk0p5
mmcblk0p6
mmcblk0p7
mmcblk0p8
mmcblk0p9
/dev/block/platform/omap/omap_hsmmc.1/by-name:
CACHE
DATAFS
EFS
FACTORYFS
HIDDEN
KERNEL
MODEM
PARAM
RECOVERY
SBL1
SBL2
/dev/block/platform/omap/omap_hsmmc.1/by-num:
p1
p10
p11
p2
p3
p4
p5
p6
p7
p8
p9
Click to expand...
Click to collapse
Also, I read from here: http://forum.xda-developers.com/showpost.php?p=44328873&postcount=10
That E2FSCK will better be secure when executed on a named partition, can you confirm me it or no?
Now, I think..
Since, I know on my Windows when a sectors in corrupted or broken state, I can simply tell to the OS (Windows so) that I want it IGNORE it !
How I can do the same things to my Galaxy Tab 2?
It certainly fix my problem like that no?

Well well..
It is not better than it was, I really need advices and moreover help to know what I can do with the "mount" command and plus..
I was at 4'th page of the forum, so I think my thread just goes skip from your eyes, this is why I want up it..
Anyway, I read somewhere there is a lot of commands available.. due to the fact I'm not aware suffisely with Linux, and due to the fact Android recovery commands (and moreover the System) is based on Linux.. I prefer ask here..
So please, please.. answer me

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!