So i have rooted my HTC desire phone, now i wonder if is it posibble to remove any stock applications from it, without flashing someones rom.
Apps like, Flick, Footprints, Google Talk, Peep, Quickoffice, Stocks.
This are the apps i would like to remove, or atleast make them stop starting and restarting each time i kill them with some task manager.
Yes, it's possible.
You have to do all the steps of rooting till you'll reach "recovery" mode (just before wipe and flash).
than just run the debugger
Code:
./adb shell
withing the shell
Code:
mount /system
list your apps with:
Code:
ls /system/app
now you can delete app:
Code:
rm /system/app/FriendStream*
and so on
It's good idea to backup your apps on sdcard
Code:
mount /sdcard
mkdir /sdcard/backup
cp /system/app/* /sdcard/backup
after work is finished
Code:
umount /sdcard
umount /system
reboot and you're done
It's good idea to wipe data after removing apps to avoid some junk in app manager.
Wow! Thanks a lot for that!
I was trying adb commands with the phone in USB Disk Drive mode (debugging enabled) and I couldn't touch anything off the /system partition.
It never occurred to me to try in Recovery mode though
by saying it's a good idea to wipe data after removing some apps do you mean hard reset ??? or this just deletes the junk files?????
also do i need to flash the rooted update for this or just enter recovery mode ?
Hi everyone,
my N7 (unlocked, stock, latest OTA, maybe was rooted) is not booting past the Google logo. I can access bootloader and recovery and through custom recoveries adb shell sbin/dmesg. also in stock adb sideload works. but when it is stuck in google logo it is detected as nexus 7 but I can't access it through adb (no devices listed).
What I did already:
stock recovery: factory reset
cwm recovery: wipe dalvik cache, fix permissions
reflashed factory image JZO54K and JOP40D
formatted /system and reflashed
fastboot oem lock & fastboot oem unlock: after this it will show the boot animation for ~7s and reboot
also i waited 20mins after flashing factory images - enough so it at least can show the boot animation
this is what fastboot currently shows:
FASTBOOT MODE
product name - grouper
variant - grouper
hw version - ER3
bootloader version - 4.13
baseband version - n/a
serial number - 015d2109f31c0415
signing - not defined yet
LOCK STATE - UNLOCKED
here are two dmesgs: http://pastebin.com/T8pexUa3 and http://pastebin.com/y2sXSC5n
and here's the video of a startup after fastboot oem lock + unlock: http://www.youtube.com/watch?v=Sj3E3Emkz2U
and here's a log of one flash: http://pastebin.com/z5Bue4jL where everything seems perfectly fine
Some more symptoms: non of openrecovery-twrp-{2.3.3.0, 2.4.0.0, 2.4.1.0}-grouper.img are properly booting (only splash screen is displayed) and when I try to do some tasks like mount /system with cwm 6.0.1.0 or factory reset with twrp 2.2.1 (part of galaxy nexus 7 toolkit) the recovery will freeze so I have to reboot. also cwm gets awfully slow after some tasks.
I am out of my wits, can anyone help? If you give me instructions I can provide more dmesgs.
hi aha27,
Sorry about your problem. You are to be commended though, for the preparation and detail you provided in describing your situation - too bad most are not that thorough.
That video is an unusual bootloop. With "normal" bootloops the kernel stays up and the android layer cycles endlessly in it's startup checks - but your video looks much more like a kernel panic occurs, as the screen goes back to a bootloader display.
I looked briefly through one of your dmesg boot logs, and didn't spot anything unusual. The facts that:
(a) you can successfully re-flash stock roms, including file system re-creation
(b) you can run adb shell commands interactively
is evidence that the kernel has no difficulty booting and that perhaps the flash filesystems are all OK too.
What sticks out is your report that the recoveries also do not proceed completely to show their touchscreen interfaces.
Here is something to try
(1) perform soft-boots of the recovery with fastboot, for example:
fastboot boot openrecovery-twrp-2.3.3.0-grouper.img
As this requires no writing nor reading of the eMMC Flash memory, if it fails to setup the display correctly, perhaps you have a hardware problem that is unrelated to flash memory. (As you tried multiple recoveries, you may have already done this - it wasn't evident whether you flashed your different recoveries or soft-booted them)
Note also that you can run several adb sessions simultaneously, so in separate windows with the recovery running you can certainly be doing
C:\fubar> adb shell logcat > logcat_output.txt
and
C:\fubar> adb shell cat /proc/kmsg > kernel_log_output.txt
[ If you are using cygwin or linux you can spice this up a little, e.g.
$ adb shell logcat 2>&1 | tee logcat_output.txt
$ adb shell cat /proc/kmsg 2>&1 | tee kernel_log_output.txt
... as both of these block waiting for more output, in the latter case you get to see things happening in real time as well as capturing the output for later analysis ]
(2) see if anything is leftover in /proc/last_kmsg on the boot cycle immediately following the "bootloop". It might be possible to jump the device into fastboot mode by pressing Vol-Down the moment the Google logo first reappears. From there, soft-boot a recovery and capture the output of
adb shell cat /proc/last_kmsg
(3) Start your adb server on the PC and launch the "bootloop" and see if you can get a shell before the crash occurs. If you can get one before the crash occurs maybe you will be lucky enough to catch a problem via
adb shell cat /proc/kmsg
or
adb logcat -v threadtime
Note that if you have installed a fresh ROM, you can toggle ADB debugging on by mounting /data and
# mkdir /data/property
# chmod 700 /data/property
# echo -n 'mtp,adb' > /data/property/persist.sys.usb.config
# chmod 600 /data/property/persist.sys.usb.config
(4) I also noted your comment about "freezing if I mount /system". Note that when you flash the factory image, /data and /cache are handled differently than /system, even though all 3 are ext4 filesystems. For the first two, the process is "erase, mkfs, write", whereas for /system all you get is a "erase, write". So here is the deal - if a mke2fs filesystem is created, that means for /data and /cache that the bootloader is actually mounting those partitions (as ext4 filesystems) and restoring into them file by file. Otherwise, a "blob"-type write would just overwrite the newly created ext4 filesystem metadata.
/system is handled differently though - notice in the factory install logs there is no detail about filesystem creation for the /system partition? That's because Google is using a "sparse ext4 image" format for the system.img file, and it can actually write this to the /system partition as a binary blob.
So, on the chance that there is something wrong with the system partition, why don't you manually create the /system filesystem by hand to see if any errors occur? e.g.
mke2fs -T ext4 -m 0 /dev/block/mmcblk0p3
If this proceeds without error, try installing a dev ROM (not a factory ROM) and see if you can get further along.
The one thing which is fortunate about your situation is that you can return your device through flashing to complete factory stock, including locking the bootloader... if returning the device (via a warranty return/RMA) process is an option for you.
Whew that was a lot of typing. I think I am done for the day.
bftb0
bftb0 said:
That video is an unusual bootloop. With "normal" bootloops the kernel stays up and the android layer cycles endlessly in it's startup checks - but your video looks much more like a kernel panic occurs, as the screen goes back to a bootloader display.
Click to expand...
Click to collapse
This is the bootloop occurring once after doing fastboot oem lock / fastboot oem unlock - after the next reboot it stays at the Google logo without rebooting again.
(1) perform soft-boots of the recovery with fastboot, ... As this requires no writing nor reading of the eMMC Flash memory, if it fails to setup the display correctly, perhaps you have a hardware problem that is unrelated to flash memory. (As you tried multiple recoveries, you may have already done this - it wasn't evident whether you flashed your different recoveries or soft-booted them)
Click to expand...
Click to collapse
some were soft-boots some were with flashing of recovery, but CWM recovery hangs in either boot type after mount /sdcard or mount /user and mount /system.
I also tried some different versions of openrecovery-twrp-XXXX-grouper.img and none of it would start up.
Note also that you can run several adb sessions simultaneously, so in separate windows with the recovery running you can certainly be doing
C:\fubar> adb shell logcat > logcat_output.txt
and
C:\fubar> adb shell cat /proc/kmsg > kernel_log_output.txt
Click to expand...
Click to collapse
Ok, when I am in recovery I can mount /system and use /system/bin/logcat but there are only three lines with "scanline" something (do you need this?)
(2) see if anything is leftover in /proc/last_kmsg on the boot cycle immediately following the "bootloop". It might be possible to jump the device into fastboot mode by pressing Vol-Down the moment the Google logo first reappears. From there, soft-boot a recovery and capture the output of
adb shell cat /proc/last_kmsg
Click to expand...
Click to collapse
I couldn't go to fastboot when the Google logo appears but last_kmsg is this -> http://pastebin.com/VkmNdM5d
After oem lock / oem unlock and the reboot (like in the video) I managed to get into fastboot and recovery, here is the last_kmsg -> http://pastebin.com/wR1yptWr
(3) Start your adb server on the PC and launch the "bootloop" and see if you can get a shell before the crash occurs. If you can get one before the crash occurs maybe you will be lucky enough to catch a problem via
adb shell cat /proc/kmsg or adb logcat -v threadtime
Click to expand...
Click to collapse
nope. wasn't able to get a shell although I activated debugging with your procedure:
Note that if you have installed a fresh ROM, you can toggle ADB debugging on by mounting /data and
# mkdir /data/property
# chmod 700 /data/property
# echo -n 'mtp,adb' > /data/property/persist.sys.usb.config
# chmod 600 /data/property/persist.sys.usb.config
Click to expand...
Click to collapse
Still no adb while stuck at Google logo
/system is handled differently though - notice in the factory install logs there is no detail about filesystem creation for the /system partition? That's because Google is using a "sparse ext4 image" format for the system.img file, and it can actually write this to the /system partition as a binary blob.
So, on the chance that there is something wrong with the system partition, why don't you manually create the /system filesystem by hand to see if any errors occur? e.g.
mke2fs -T ext4 -m 0 /dev/block/mmcblk0p3
If this proceeds without error, try installing a dev ROM (not a factory ROM) and see if you can get further along.
Click to expand...
Click to collapse
wow - why would they do that? Anyway, I flashed recovery-clockwork-6.0.2.3-grouper.img and was able to format:
Code:
~ # mke2fs -T ext4 -m 0 /dev/block/mmcblk0p3
mke2fs -T ext4 -m 0 /dev/block/mmcblk0p3
mke2fs 1.41.11 (14-Mar-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
41664 inodes, 166400 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=171966464
6 block groups
32768 blocks per group, 32768 fragments per group
6944 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 39 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
and with adb sideload tried to install pa_grouper-3.00-09FEB2013-203806.zip. But it stopped at "Installing update..." (the cat /proc/kmsg is here: http://pastebin.com/rjd3b1iZ). I tried it again and again it stopped at Installing update, and here is the last_kmsg and the kmsg again: http://pastebin.com/gPBe7JFD and http://pastebin.com/uXHbX3we.
The one thing which is fortunate about your situation is that you can return your device through flashing to complete factory stock, including locking the bootloader... if returning the device (via a warranty return/RMA) process is an option for you.
Click to expand...
Click to collapse
Since everything failed I guess that's my only option, unless there is something in the logs ... maybe you could take another look?
Whew that was a lot of typing. I think I am done for the day.
Click to expand...
Click to collapse
And I am very thankful for your help!
aha,
I am travelling now, so there is a bunch of stuff I can't do easily right now... but I will have a look at the pastebins to see if anything jumps out at me.
Stay tuned.
aha27,
I looked at your pastebins. The only thing that seemed odd was the complaints about the cache partition (mmcblk0p4) in the kmsg logs. But it only appeared one time - hardly compelling.
The only other thing I could suggest is perhaps look in the recovery logs ( /cache/recovery/recovery.log or /tmp/recovery.log) for the recoveries that hang (but you can still communicate with). Maybe there are some crumbs in there that will put you on the correct trail.
FWIW, when I boot my N7 (JOP40D), it does take quite a bit of time for adb to come up - so if the initial OS boot was getting wedged before that happened maybe that explains why you are not seeing it even though you diddled with /data/property/persist....
I haven't looked into this, but is it possible to modify default.prop in the ramdisk so that the adb service gets started earlier? You would have to unpack & repack a boot image to do this. Actually, now that I think of it, you could just modify the "adbd" service definition in the /init.rc file in the ramdisk so that adb is not contingent on a getvar/setvar variable. Perhaps that would get adb running earlier in the OS boots that are hanging, and you might have a chance of observing more things.
I seem to be running out of ideas. With a lot more work, you could implement all sorts of unattended/blind captures though. For instance, a "one-shot" service definition can call a script that starts yet another script - but puts the 2nd one into the background. That way the oneshot service does not block init - and the second script can do strange things such as periodically record dmesg output or logcat output into files in /tmp and then copy them to the /sdcard once it is mounted. This would give you a way to observe stuff going on in the Android boot (after the fact) even if you can't gain realtime access via adb. But, this does require that you unpack, modify, and re-pack boot images.
Well, there's a few ideas. They seem to require progressively more work, though.
Good luck with your tab.
Thanks thanks thanks, but ...
Thank you very very much for the time you invested in my problem, :good:
but this:
bftb0 said:
aha27,
I haven't looked into this, but is it possible to modify default.prop in the ramdisk so that the adb service gets started earlier? You would have to unpack & repack a boot image to do this. Actually, now that I think of it, you could just modify the "adbd" service definition in the /init.rc file in the ramdisk so that adb is not contingent on a getvar/setvar variable. Perhaps that would get adb running earlier in the OS boots that are hanging, and you might have a chance of observing more things.
I seem to be running out of ideas. With a lot more work, you could implement all sorts of unattended/blind captures though. For instance, a "one-shot" service definition can call a script that starts yet another script - but puts the 2nd one into the background. That way the oneshot service does not block init - and the second script can do strange things such as periodically record dmesg output or logcat output into files in /tmp and then copy them to the /sdcard once it is mounted. This would give you a way to observe stuff going on in the Android boot (after the fact) even if you can't gain realtime access via adb. But, this does require that you unpack, modify, and re-pack boot images.
Click to expand...
Click to collapse
is too time consuming for me and as the tab is not too old, I will reflash it with stock, lock it and send it back. Initially I thought it could be solved, then I hoped that you could help me proving it is a hardware problem, so I'd have no problem getting it replaced, but let's see what Google tells me.
Good luck with your tab.
Click to expand...
Click to collapse
Thank you. Although it is off-topic: I talked to Google support (Germany) and they were absolutely not helpful. On the contrary, after I told them that I unlocked it to flash the previous image they told me, that as I have voided my waranty the could not guarantee that the tab will be replaced. And: they won't tell me (even after I asked twice), which options I'll have and what they will costcost, if it's a problem due to unlocking thus not covered by guarantee. That was no nice exceperience so far.
Well, if it turns out that Google/Asus refuses to do anything for you (seems hard to imagine, but I suppose all things are possible) and they return the tablet to you in the same condition, send me a PM or come back to this thread.
best
bftb0 said:
Well, if it turns out that Google/Asus refuses to do anything for you (seems hard to imagine, but I suppose all things are possible) and they return the tablet to you in the same condition, send me a PM or come back to this thread.
best
Click to expand...
Click to collapse
Hi I have almost the same problem, the thing is I'm using Mac and i don't have pc.
And my mac can't recognize my n7. I have installed TWRP v2.4.3.0
Please advice me.
Thank you
coszy said:
Hi I have almost the same problem, the thing is I'm using Mac and i don't have pc.
And my mac can't recognize my n7. I have installed TWRP v2.4.3.0
Please advice me.
Thank you
Click to expand...
Click to collapse
fastboot and adb work perfectly on the Mac.
http://developer.android.com/sdk/index.html
In fact, of the three platforms (Windows, Linux, Mac) setting up fastboot/adb on the Mac requires the least effort.
stuck on google logo after factory reset
My Nexus 7 locked up, got it to the recovery screen and did a factory reset. now I am stuck in a loop... it opens to the black screen with GOOGLE and stays there. I can get it to the bootloader screen but nothing more. Help please... I am NOT tech saavy!
mac20132 said:
My Nexus 7 locked up, got it to the recovery screen and did a factory reset. now I am stuck in a loop... it opens to the black screen with GOOGLE and stays there. I can get it to the bootloader screen but nothing more. Help please... I am NOT tech saavy!
Click to expand...
Click to collapse
I sent mine to Google and got a new one ...
I'm trying to wipe and format a microSD card that I have plugged in via OTG and already have it wiped with this;
Code:
dd if=/dev/zero of=/dev/block/sda
Now I'm looking into how to recreate a MBR and partition table and it says to use the parted command, which I'm glad about as I'm familiar with the command from using Ubuntu but it's not installed and I can not find any instructions on how to get it. Can anyone explain how to install it? I know I could just plug the SD card into a computer and do it but I'm having fun doing all this on a tablet. Lol
Bump
Anyone?
I have got the same question, any other solutions?
This is the most complete information I have found yet, but it doesn't work. Either from me messing something up or it not being correct for the Nexus 7 being that it was made two years ago. http://www.droidforums.net/forum/htc-droid-eris/78650-internal-storage-partitions-screwed-up.html
I pushed all six files to /sbin/ with no errors and changed their permissions with no issues but I restart the tablet and none of the six files are in /sbin/
Just for the heck of it I extracted the six files to the SD card in the tablet, CD'd to it and used chmod 0755 on all six files then tried to run it and this is what I get.
Code:
[email protected]:/storage/emulated/legacy/folder # parted
sh: parted: not found
127|[email protected]:/storage/emulated/legacy/folder # ls
e2fsck
mke2fs
parted
resize2fs
sdparted
tune2fs
... how can you NOT find that?
herqulees said:
... how can you NOT find that?
Click to expand...
Click to collapse
Depending on how your PATH env var is set, the current directory might or might not be being searched for program load(s). So indicating the current directory explicitly with a leading "./" such as
$ ./parted
will certainly work (if a read & execute bit set on file, and the filesystem is not mounted -noexec ) .
But...
...if those files are dynamically linked rather than statically linked, and the appropriate link-libraries they reference come up missing during run-time linking it is possible to still see a "not found" message. Sort of a red-herring error message, but there you go.
I just looked in TWRP's /sbin (ramdisk) just now. Don't see parted in there.
[Edit] I do see the string "fdisk" inside the busybox executable though! - maybe boot into recovery and see what
busybox fdisk /dev/block/sda
gets you? (I suppose result depends on whether or not TWRP kernel plumbs the device into place.)
Perhaps the quickest solution is to simply use a PC and media reader to do the partitioning from a PC instead of the N7. You might even want to boot a "Live CD" version of Linux to get at the tools you need. (BTW, I think that Ubuntu's Live CD mounts a fuse FS over the top of the RO DVD/CD, so you can even download and install packages as needed).
I managed to get everything to work by doing this:
1. Using this app https://play.google.com/store/apps/details?id=com.beansoft.mount_system&hl=en I remounted /system as RW
2. Using the CyanogenMod File Manager I copied the parted file to /system/bin (from the root of the SD card)
3. Then using the File Manager still, go to the Properties of the parted file and go to Permissions and under R, W, and X put a check mark in the three boxes bellow each. (I don't know which ones it needs permissions for so I just give it permissions to everything, kinda frowned upon to do but I trust this program so...)
By doing this you can completely stay out of command line, but at the same time you're installing a command line program so you shouldn't be afraid of the command line in the first place. Lol.
Note: After this you can go to a terminal window and type su to get root access then type
Code:
parted /dev/block/sda
you will of opened your external memory card, now use parted as you would normally.
Not sure if this will help anyone else, but I searched forever trying to figure out how to write into the system folder using Terminal Emulator on the Note 3 to no avail. I found a slew of posts that said to type "mount -o rw,remount /system" to achieve this. When I used this command it didn't return any errors so I assumed it worked, however no files ended up being copied and pasted to the location I wanted. I found numerous other examples that were supposed to enable writing to the system as well, but none of them worked. I finally figured out how to get it to work on my Note 3 by typing "mount" in terminal emulator and noticing that at the very beginning of the string that was returned was "rootfs". So if you are wanting write to your system using Terminal Emulator on the VZW Note 3 here is what ended up working for me:
Code:
mount -o remount,rw rootfs
to return to read only enter:
Code:
mount -o remount,ro rootfs
I wanted to figure this out because a bug in TWRP v2.6.3.0 maimed my efs partition and bricklooped my phone. Even flashing the Stock Developer tar by Beans wouldn't bring it out of the brickloop. I was able to get out of the brickloop by following this thread, but even though my phone booted up and the IMEI # was correct, my /efs folder was missing in action. This caused odd things to happen like my lock screen not functioning and the power button instantly turning the phone off instead of bringing up the power menu. I discovered this was because the phone was placed into something called "factory mode" and that to fix it you needed to edit some files in the efs folder, which were completely missing on my device. Member js0uth graciously sent me his efs folder from his Developer Note 3 and when I copied it to my phone it began to function normally again (big shout out to js0uth!). However, this folder was completely deleted once again after a reboot. So now you can see why I was looking for a way to copy these files using Terminal Emulator. I ended up making a Tasker profile with the Secure Settings plugin that automatically copies the files from my ext SD card to my system folder on boot of the device. In order to mount, copy/paste the files while retaining the correct permissions from the folder that js0uth sent me, and unmount the system I had the set up my Secure Settings command as follows:
Code:
mount -o remount,rw rootfs;cp -Rpf /storage/extSdCard/efs/* /efs/;mount -o remount,ro rootfs
So now I have a livable workaround for my problem until I can discover a way for the phone to rebuild my own /efs folder.
Edit: See radionerd's post for a permanent fix to this issue and be sure to hit thanks under his name if it helps you.
I did the same to my DE. Corrupted EFS about a month ago after a few flashes using TWRP 2.6.3.0. Boot loops for 28 hours of hell until I followed your tracks to the trick that deleted my corrupted EFS folder, and created a new empty folder. I guess this would wipe out IMEI, Mac, and more in models that store phone specific data in EFS. We lucked out I've read that our phones have that info in a few other folder not EFS
Since wiping EFS I have run stock ROM, CM11, and now bean V6. I didn't see the factory mode popup until recently. I noticed that the screen will flash when leaving or entering cell service.
My corrupted EFS was 3MB. I'm curious what's the size of the EFS folder from js0uth?
Were you able to enter the factory mode on string? something like this?
Code:
# echo -n ON > /efs/FactoryApp/factorymode
this is from an S3
Thanks for documenting your steps to recovery.
radionerd
radionerd said:
My corrupted EFS was 3MB. I'm curious what's the size of the EFS folder from js0uth?
Click to expand...
Click to collapse
It's 1.04 MB. Sorry for taking so long to respond. I thought I had it set up to send instant emails for replies to this thread, but apparently I didn't.
radionerd said:
Were you able to enter the factory mode on string? something like this?
Code:
# echo -n ON > /efs/FactoryApp/factorymode
this is from an S3
Click to expand...
Click to collapse
Setting the Factorymode folder to ON is actually what disables that mode. Seems backwards I know, but when it's set to OFF (or if the folder is completely missing as in my case) that warning message will display. If that folder is intact on your phone then you should be able to use a string to disable or enable Factorymode.
It got worse before it got better
bodieism said:
It's 1.04 MB. Sorry for taking so long to respond. I thought I had it set up to send instant emails for replies to this thread, but apparently I didn't.
No worries, I went from an annoyance of no lock screen to bricked for over 6 weeks. This happened after trying to do an EFS backup.
I've learned a lot since back then, My DE is back 100%, EFS is repaired. I think we ran the same script which actually points to the wrong mount in our phones. It brought us out of bootloops, but efs was pointed to block12. Qualcom snapdragon Note-3's use mmblk0p11 to load /efs.
If you still have to load the tasker script, I think I figured out an easy fix to rebuild your original efs folder.
I would backup mounts first, delete /efs folder. Then run the original script, but this time change from 12 to 11.
Code:
adb shell
su
mke2fs /dev/block/mmcblk0p11
mkdir /efs
mount -t ext4 /dev/block/mmcblk0p11 /efs
Bet that would do the trick
Here is my thread
Click to expand...
Click to collapse
^ That did do the trick! :good:
Phone is back to 100% working order :highfive:
In recovery mode I am not able install any ROMS, theres the error Failed to mount /efs (Invalide argument)
I can only flash stock roms using odin, everything works on stock roms except for the wifi, after connecting/disconnecting multiple times, the wifi stops responding and wont work in the future
---------------------------------------------------------------------------------------------------------------------------------------------
(( SOLVED ))
First thing you should do, is to backup your EFS if you still have it.
I had mine but it wasn't mounting properly.
In order to back it up, please download terminal emulator on a rooted device and follow this video
I would try to back it up, even if you think the efs is messed up... worst case scenario is you end up where you started, not worse off.
---------------------------------------------------------------------------------------------------------------------------------------------
Your device needs to be rooted.
1.) Download SDK tools here - Scroll down to the bottom and "Get just the command line tools"
2.)Install TWRP , Find your device, download the .tar and flash it using ODIN
Boot in to recovery, in TWRP you want to go to mount, make sure system, esf are checked.
3. If you installed SDK tools, go to c:\android tools\SDK tools. hold shift and right click on the area inside the folder and select run command line from here.
4.) In cmd, type
Code:
ADB devices
ADB Shell
SU
mke2fs /dev/block/mmcblk0p10
mount -w -t ext4 /dev/block/mmcblk0p10 /efs
5.) You should be good!!!