Related
Hi everyone, this is my first thread
I recently rooted my 16gb WiFi only nexus 7. After installing 3 different roms (touchwiz, cyanogenmod 10, and xenon HD) I didn't like touch wiz or cyanogenmod, and I'm currently running xenon HD. However, when I opened my storage today, of said I had 3.6gb remaining. I thought it may have been all the apps, so I factory reset it, reset the partition, and deleted all data via recovery mode. That gave me about 1 more gigabyte. I opened ES file explorer and deleted everything there. I still have only 4.6 gigabytes usable. Anyone else have this issue?
Thanks
Sent from my Nexus 7 using xda app-developers app
Well, I deleted some old backups and now I have 7.5 gb of storage, which should do for now. But I still have that 6 GB leftover, anyone know whats wrong?
Thanks
Sent from my Nexus 7 using xda app-developers app
OK. Now I mucked around in the mounting/unmounting stuff, and now it won't boot. It's stuck at the Google screen. Someone help please???
Sent from my Nexus 7 using xda app-developers app[/QUOTE]
You are not the only person who has experienced this.
Bottom line is you need to rebuild the /data filesystem, which necessitates getting everything off of it including any nandroid backups plus anything worth saving in /sdcard
Either the "format data" option in TWRP, or using fastboot.
Code:
fastboot erase userdata
fastboot format userdata
I've had the latter create short file systems - and also not create short file systems.
Whatever causes this it seems to depend on prior state in the filesystem, even though I don't think things should behave this way. I've also had TWRP's "Format data" menu option create new, empty, & corrupted ext4 file systems. Ugh - I hope your luck is better than mine.
Note that you can run "df -k /data" in the recovery (after you have created the new filesystem by either method) to find out how big it is; better to check things are OK right away, rather than after you've put effort into restoring things or flashing ROMs.
Long boring thread, but related.
http://forum.xda-developers.com/showthread.php?t=2184486
good luck
Edit: no point in restoring the wedged /data backup. I hope you have earlier backups.
bftb0 said:
You are not the only person who has experienced this.
Bottom line is you need to rebuild the /data filesystem, which necessitates getting everything off of it including any nandroid backups plus anything worth saving in /sdcard
Either the "format data" option in TWRP, or using fastboot.
Code:
fastboot erase userdata
fastboot format userdata
I've had the latter create short file systems - and also not create short file systems.
Whatever causes this it seems to depend on prior state in the filesystem, even though I don't think things should behave this way. I've also had TWRP's "Format data" menu option create new, empty, & corrupted ext4 file systems. Ugh - I hope your luck is better than mine.
Note that you can run "df -k /data" in the recovery (after you have created the new filesystem by either method) to find out how big it is; better to check things are OK right away, rather than after you've put effort into restoring things or flashing ROMs.
Long boring thread, but related.
http://forum.xda-developers.com/showthread.php?t=2184486
good luck
Edit: no point in restoring the wedged /data backup. I hope you have earlier backups.
Click to expand...
Click to collapse
I basically have nothing I need on my tablet, so I'm fine deleting everything on it, if that's what you mean. I'll try, but thanks:good:
nicetaco said:
I basically have nothing I need on my tablet, so I'm fine deleting everything on it, if that's what you mean. I'll try, but thanks:good:
Click to expand...
Click to collapse
Wait, is that for getting back the storage or actually letting it boot up? Because right now the storage is the least of my concerns.
What I described is for getting back lost space (by recreating from scratch the ext4 filesystem in the userdata partition).
As it doesn't touch either the boot partition or the system partition, your tablet should certainly be able to boot. If you don't do a restore of /data from a backup, the result will be like a factory reset of whatever rom you had on the tablet.
Just make sure to check the size of the data partition before you start re-customizing or restoring data from backups to make sure that you got the full size of the partition.
bftb0 said:
What I described is for getting back lost space (by recreating from scratch the ext4 filesystem in the userdata partition).
As it doesn't touch either the boot partition or the system partition, your tablet should certainly be able to boot. If you don't do a restore of /data from a backup, the result will be like a factory reset of whatever rom you had on the tablet.
Just make sure to check the size of the data partition before you start re-customizing or restoring data from backups to make sure that you got the full size of the partition.
Click to expand...
Click to collapse
Ughhh its still not turning on...
nicetaco said:
Ughhh its still not turning on...
Click to expand...
Click to collapse
Please re-read this quote from your 2nd thread in this fiasco.
Nico_60 said:
How do you want to know what's happening to your device if don't tell us which commands you have done exactly with fastboot and why ?
Click to expand...
Click to collapse
If you screwed around with your system partition and it wouldn't boot before, then with a freshly formated and empty /data filesystem, of course it still will not boot. The instructions I provided in this thread only involved the userdata partition!
But you didn't say "I did such and such and it still hangs during the initial boot phase where the X logo is flashing on the screen"; instead you said:
"Ughhh its still not turning on".
WTF? Has your problem now morphed into a dead battery problem, or is the language you are using just incredibly imprecise?
Anyway, Flash a new ROM using the custom recovery. Any ROM - you pick. Maybe not that Xenon ROM or whatever it is called. See if the new ROM boots. And then immediately after it boots, check to see what size the /data partition is.
And if you come back into this thread anymore please be specific about what you are attempting and exactly what symptoms you are observing.
good luck
bftb0 said:
Please re-read this quote from your 2nd thread in this fiasco.
If you screwed around with your system partition and it wouldn't boot before, then with a freshly formated and empty /data filesystem, of course it still will not boot. The instructions I provided in this thread only involved the userdata partition!
But you didn't say "I did such and such and it still hangs during the initial boot phase where the X logo is flashing on the screen"; instead you said:
"Ughhh its still not turning on".
WTF? Has your problem now morphed into a dead battery problem, or is the language you are using just incredibly imprecise?
Anyway, Flash a new ROM using the custom recovery. Any ROM - you pick. Maybe not that Xenon ROM or whatever it is called. See if the new ROM boots. And then immediately after it boots, check to see what size the /data partition is.
And if you come back into this thread anymore please be specific about what you are attempting and exactly what symptoms you are observing.
good luck
Click to expand...
Click to collapse
OK. I tried to install a new rom, but I can't because I have USB debugging off, which I can't turn on
bftb0 said:
You are not the only person who has experienced this.
Bottom line is you need to rebuild the /data filesystem, which necessitates getting everything off of it including any nandroid backups plus anything worth saving in /sdcard
Either the "format data" option in TWRP, or using fastboot.
Code:
fastboot erase userdata
fastboot format userdata
I've had the latter create short file systems - and also not create short file systems.
Whatever causes this it seems to depend on prior state in the filesystem, even though I don't think things should behave this way. I've also had TWRP's "Format data" menu option create new, empty, & corrupted ext4 file systems. Ugh - I hope your luck is better than mine.
Note that you can run "df -k /data" in the recovery (after you have created the new filesystem by either method) to find out how big it is; better to check things are OK right away, rather than after you've put effort into restoring things or flashing ROMs.
Long boring thread, but related.
http://forum.xda-developers.com/showthread.php?t=2184486
good luck
Edit: no point in restoring the wedged /data backup. I hope you have earlier backups.
Click to expand...
Click to collapse
Thank you, bftb0!
I was looking around for this after I discovered my lack of space. I read about it before, but couldn't dig up the post. Thanks for informing us! Enjoy the thanks!
nicetaco said:
OK. I tried to install a new rom, but I can't because I have USB debugging off, which I can't turn on
Click to expand...
Click to collapse
ADB is available in the custom recovery... so long as you have the right drivers installed on your PC. And that is NOT controlled by some setting in the most recent ROM that you flashed - it is always running in the custom recovery.
One of the quirks about ADB in the recovery with the Nexus7 is that it claims a different USB address than "ADB Composite Interface" that the regular OS does. This might mean that ADB works correctly with the regular OS booted, but not when the custom recovery is booted, depending on what drivers you have installed. Yes, you need yet another driver installed even though they are both "ADB" connections. But that is a Windows driver issue, not a problem with the N7.
You can also use an OTG cable and a USB drive with TWRP if that is easier. Put your ROM on the memory stick and then use TWRP's "external memory". To be most compatible, make sure the USB stick is formatted in a FAT format. (I don't know if TWRP can handle NTFS).
upichie said:
Thank you, bftb0!
I was looking around for this after I discovered my lack of space. I read about it before, but couldn't dig up the post. Thanks for informing us! Enjoy the thanks!
Click to expand...
Click to collapse
I wonder if I can I trade them in for some coupons or something
@bftb0, I was not able to use adb while in TWRP but i found THIS and it was the solution, what do you think about this "fix"?
bftb0 said:
ADB is available in the custom recovery... so long as you have the right drivers installed on your PC. And that is NOT controlled by some setting in the most recent ROM that you flashed - it is always running in the custom recovery.
One of the quirks about ADB in the recovery with the Nexus7 is that it claims a different USB address than "ADB Composite Interface" that the regular OS does. This might mean that ADB works correctly with the regular OS booted, but not when the custom recovery is booted, depending on what drivers you have installed. Yes, you need yet another driver installed even though they are both "ADB" connections. But that is a Windows driver issue, not a problem with the N7.
You can also use an OTG cable and a USB drive with TWRP if that is easier. Put your ROM on the memory stick and then use TWRP's "external memory". To be most compatible, make sure the USB stick is formatted in a FAT format. (I don't know if TWRP can handle NTFS).
I wonder if I can I trade them in for some coupons or something
Click to expand...
Click to collapse
Holy crap I forgot about the OTG cables. Thanks, I'll try it!
nicetaco said:
Holy crap I forgot about the OTG cables. Thanks, I'll try it!
Click to expand...
Click to collapse
Thank you so much. That did it.
First problem fixed through XDA developers
Enjoy my thanks
Nico_60 said:
@bftb0, I was not able to use adb while in TWRP but i found THIS and it was the solution, what do you think about this "fix"?
Click to expand...
Click to collapse
The ADB daemon - "adbd" is definitely sitting there running inside the custom recovery. Even if you can't communicate with it because of a lack of a driver, you should nevertheless be able to see it as an unknown device in the PC's device manager.
I have done the same hack - hand editing the .INF file - with both the Google SDK drivers and the Asus drivers, and in both cases it worked fine (one driver for everything: ADB in the OS, ADB in TWRP/CWM, and fastboot with the bootloader).
I have also used the Google SDK driver without modification plus the XDA Universal Naked driver. That means using the Google driver for fastboot and ADB when the OS is booted, and the XUN driver for custom recoveries only.
At the present time the ONLY driver I have installed is a hacked version of the Asus drivers.
Win 7 complains about signing when doing this (for the Asus drivers for sure, I can't remember if the Google driver is signed or not).
As I mentioned, Win 7 Pro x64. I suppose the whole "violated signing" might make life even more difficult with Win 8 though.
bftb0, did you personally experience the problem of losing space on the internal memory? I tried your advice, but it didn't work. I'm on PAC(man) ROM. I booted into TWRP, did the data wipe (not factory reset, the full wipe that wipes the everything) but I still only have 13 gb available (on my 32 gb Nexus 7). I rebooted into TWRP and did a factory reset AND wipe data, but I am still missing half of my internal memory.
Do you need to do this on the stock ROM for it to work? Any other tips would be greatly appreciated.
upichie said:
bftb0, did you personally experience the problem of losing space on the internal memory? I tried your advice, but it didn't work. I'm on PAC(man) ROM. I booted into TWRP, did the data wipe (not factory reset, the full wipe that wipes the everything) but I still only have 13 gb available (on my 32 gb Nexus 7). I rebooted into TWRP and did a factory reset AND wipe data, but I am still missing half of my internal memory.
Do you need to do this on the stock ROM for it to work? Any other tips would be greatly appreciated.
Click to expand...
Click to collapse
Yes, it really did happen to me.
After it happened I took the trouble to download 4 different versions of TWRP (2.4.1.0-2.4.4.0), and I re-created the ext4 filesystem with:
- each of the different versions of TWRP and
- fastboot format userdata
after each, I did a "e2fsck -f -n <block-device>" on the (unmounted) userdata partition to see that they were clean, and I also dumped the output of "tune2fs -l <block-device>" to a file for comparison. Other than things that I would expect to be different (e.g. partition UUID identifier strings and timestamps), I noticed no differences. And also, I couldn't reproduce the problem for the life of me.
Above you mention full "data wipe". In TWRP (v2.4.1.0), this is presented as a separate button in the "Wipe" sub-menu where it (the last button in the first column) is labeled "Format Data". I suppose this is what you mean, but thought I would be explicit to avoid any confusion. (The "factory reset" procedure in the two custom recoveries - both CWM and TWRP - can not possibly re-create the ext4 filesystem in /data, as the /data/media/0 SD card files are in there. But the "Format Data" button does destroy & recreate the whole filesystem).
If you press on this button and at the same time capture the output of the "ps" command, you will see that TWRP recovery invokes the /sbin/make_ext4fs in the following way
Code:
make_ext4fs -l -32768 /dev/block/mmcblk0p<PARTNUM>
(CWM probably uses a different external command as it does not seem to have a "make_ext4fs" command in it's ramdisk. Probably mke2fs with ext4 options on the command line)
Anyways, I can't say I have my finger on exactly how to resolve the problem as I can not re-created it. But it did happen to me.
One thing you can try rather than using TWRP's "make_ext4fs" command (underneath that button "Format Data") is to reboot into the bootloader from TWRP, and do the file system formatting in fastboot instead of TWRP, as in:
Code:
fastboot format userdata
(noobs: caution, this is a full userdata wipe)
and then bop back into the recovery and check things with "tune2fs" report
Code:
tune2fs -l /dev/block/mmcblk0p<PARTNUM>
My 32G N7 shows a total block count of 7503608 (x 4k/block = 29.3 GiB) doing this.
As I mentioned before, it's a good idea to check to see you have the right size before you start restoring stuff to avoid wasting time. You can do it above with "tune2fs -l", or because TWRP seems to want to mount /data and /sdcard when it boots, just run
adb shell df -k /data
to get a report of total and used size.
Sorry this isn't more definiitve. I would have spent more time looking at this, but it is tedious as you need to unload the whole d*mn SD card in order to experiment. Thank goodness my 30GB partition only has about 10Gigs of stuff on it.
good luck
bftb0 said:
Yes, it really did happen to me.
After it happened I took the trouble to download 4 different versions of TWRP (2.4.1.0-2.4.4.0), and I re-created the ext4 filesystem with:
- each of the different versions of TWRP and
- fastboot format userdata
after each, I did a "e2fsck -f -n <block-device>" on the (unmounted) userdata partition to see that they were clean, and I also dumped the output of "tune2fs -l <block-device>" to a file for comparison. Other than things that I would expect to be different (e.g. partition UUID identifier strings and timestamps), I noticed no differences. And also, I couldn't reproduce the problem for the life of me.
Above you mention full "data wipe". In TWRP (v2.4.1.0), this is presented as a separate button in the "Wipe" sub-menu where it (the last button in the first column) is labeled "Format Data". I suppose this is what you mean, but thought I would be explicit to avoid any confusion. (The "factory reset" procedure in the two custom recoveries - both CWM and TWRP - can not possibly re-create the ext4 filesystem in /data, as the /data/media/0 SD card files are in there. But the "Format Data" button does destroy & recreate the whole filesystem).
If you press on this button and at the same time capture the output of the "ps" command, you will see that TWRP recovery invokes the /sbin/make_ext4fs in the following way
Code:
make_ext4fs -l -32768 /dev/block/mmcblk0p<PARTNUM>
(CWM probably uses a different external command as it does not seem to have a "make_ext4fs" command in it's ramdisk. Probably mke2fs with ext4 options on the command line)
Anyways, I can't say I have my finger on exactly how to resolve the problem as I can not re-created it. But it did happen to me.
One thing you can try rather than using TWRP's "make_ext4fs" command (underneath that button "Format Data") is to reboot into the bootloader from TWRP, and do the file system formatting in fastboot instead of TWRP, as in:
Code:
fastboot format userdata
(noobs: caution, this is a full userdata wipe)
and then bop back into the recovery and check things with "tune2fs" report
Code:
tune2fs -l /dev/block/mmcblk0p<PARTNUM>
My 32G N7 shows a total block count of 7503608 (x 4k/block = 29.3 GiB) doing this.
As I mentioned before, it's a good idea to check to see you have the right size before you start restoring stuff to avoid wasting time. You can do it above with "tune2fs -l", or because TWRP seems to want to mount /data and /sdcard when it boots, just run
adb shell df -k /data
to get a report of total and used size.
Sorry this isn't more definiitve. I would have spent more time looking at this, but it is tedious as you need to unload the whole d*mn SD card in order to experiment. Thank goodness my 30GB partition only has about 10Gigs of stuff on it.
good luck
Click to expand...
Click to collapse
.
I'm a total command prompt beginner here, so could you explain where I'm doing the fastboot format command? In a terminal on the device? Using adb on my windows machine? I tried all that I could think of, but none of it worked. No form of wiping the device (yes, via "format data" in TWRP) seems to work. I'm still missing half of my storage.
EDIT: Okay, so I ran the command--I had to have the device in the bootloader, duh. Unfortunately, it still did not work. When recreating the file system, it said there was a total of ~3.5 million blocks--half what I saw reported in the other thread. Not surprising, since I'm missing half of my storage. How come this is working for other people but not me? I tried doing both at the same time, but to no avail. This is getting stupid.
upichie said:
EDIT: Okay, so I ran the command--I had to have the device in the bootloader, duh. Unfortunately, it still did not work. When recreating the file system, it said there was a total of ~3.5 million blocks--half what I saw reported in the other thread. Not surprising, since I'm missing half of my storage. How come this is working for other people but not me? I tried doing both at the same time, but to no avail. This is getting stupid.
Click to expand...
Click to collapse
Arrgh. Did you do the "fastboot erase userdata" first?
Here's what the fastboot format looked like on my device when I did this last (3/13):
Code:
$ fastboot erase userdata
******** Did you mean to fastboot format this partition?
erasing 'userdata'...
OKAY [ 4.974s]
finished. total time: 4.979s
$ fastboot format userdata
erasing 'userdata'...
OKAY [ 4.454s]
formatting 'userdata' partition...
Creating filesystem with parameters:
Size: 30734811136
Block size: 4096
Blocks per group: 32768
Inodes per group: 8192
Inode size: 256
Journal blocks: 32768
Label:
Blocks: 7503616
Block groups: 229
Reserved block group size: 1024
Created filesystem with 11/1875968 inodes and 161774/7503616 blocks
sending 'userdata' (139197 KB)...
writing 'userdata'...
OKAY [ 33.733s]
finished. total time: 38.194s
As I said, I was unable to reproduce the problem even though I tried. But it almost seems like the creation of the new filesystem is inferring something from somewhere (but where?) about the userdata partition size which is incorrect. Almost like it happens because of something it sees in the prior filesystem (which is being destroyed). So it becomes irreproducible unless you can recreate the same starting condition.
There's other mysterious crap going on here too. See the output above? The part where it says "sending 'userdata' (139197 KB)" ? It will say this no matter where you run the command from, and there is no 139 MB "userdata.img" file in the folder it runs from!!! 139 MB? For a filesystem which is empty when you mount it?
I don't know. Here's one more thing to try, though. In addition to doing the "erase" & "format" commands, perhaps you could actually flash the userdata image from the stock ROM
Code:
fastboot erase userdata
fastboot format userdata
fastboot flash userdata userdata.img
and then when you boot to the custom recovery, perform a "factory reset" - or try doing the "Format Data" thing in TWRP after (or before?) the above steps.
If none of this works, I suppose you could try the equivalent sorts of things with CWM and see if you get a different result.
You don't need to permanently install CWM with a hard flash - you can just soft-boot it for a single session:
Code:
fastboot boot recovery-clockwork-touch-6.0.2.3-grouper.img
Sorry this is so vague, but you know how it goes - you stumble into a problem, start fooling around until it gets fixed - and because you weren't really expecting the problem in the first place, you haven't written down the exact conditions and steps. Like I said, I tried to re-create the problem a variety of ways - but failed at that effort.
good luck
I've been flashing N7 with no issues as recently as over the weekend. Today I tried to flash a new ROM and it failed. Tried a second, different ROM, same result. Do not know what I did. Any thoughts?
Error log would help greatly.
How do I get/generate the log? Haven't had to do it before.
Thanks,
Paul
The logs= errors displayed on the screen provided by the interface you use to flash the rom (recovery, computer...)
Does this help any?
TWRP V2.4.4.0
Updating partition details
E: Unable to open zip file
Error flashing zop
Updating partition details...
do I need to create a partition? Never get more details despite the tease.
Thanks,
First -
Try and download a different (NEWER) TWRP. Re-flash TWRP. Try again
or
Have you tried completely wiping the device? And pushing a ROM from ADB or using a USB OTG and Memory stick?
I had issues with my nexus becoming VERY unstable. Leading to issues.
I completely, and I mean completely, wiped. To the point that all that device basically had was a recovery, and a bootloader.
I proceeded to flash again, BOOM all fixed up.
Is there a new TWRP?
I did a factory restore after wiping everything thing, if that is what you mean?
It was working as expected last week, don't know what I did to screw it up
Boot recovery try the operation, choose advanced then copy log to sdcard. The paste the log results.
sent via electromagnetic radiation.
ibsk8 said:
Boot recovery try the operation, choose advanced then copy log to sdcard. The paste the log results.
sent via electromagnetic radiation.
Click to expand...
Click to collapse
Did this, and it said it copied but I am unable to locate it. It says 0\media\data But that folder structure doesn't exist, at least according to file expert
Will a complete wipe/restore create a partition?
pmgreen said:
Will a complete wipe/restore create a partition?
Click to expand...
Click to collapse
None of the instructions currently found in this forum alters the partitioning of the N7. Not fastboot & not the custom recovery, either.
You are chasing a red herring I think. That message you see is about the recovery performing a scan to check to see if there is a change in file systems (or partitioning of external devices) ... which might have occurred in preceding (custom recovery) operations, but didn't in this particular case.
pmgreen said:
Does this help any?
TWRP V2.4.4.0
Updating partition details
E: Unable to open zip file
Error flashing zop
Updating partition details...
Click to expand...
Click to collapse
Focus your efforts here; it certainly looks like a first-order problem.
bftb0 said:
None of the instructions currently found in this forum alters the partitioning of the N7. Not fastboot & not the custom recovery, either.
You are chasing a red herring I think. That message you see is about the recovery performing a scan to check to see if there is a change in file systems (or partitioning of external devices) ... which might have occurred in preceding (custom recovery) operations, but didn't in this particular case.
Focus your efforts here; it certainly looks like a first-order problem.
Click to expand...
Click to collapse
Think reinstalling TWRP would help? It was working fine so I'm a bit stumped what changed and why
pmgreen said:
Think reinstalling TWRP would help? It was working fine so I'm a bit stumped what changed and why
Click to expand...
Click to collapse
You can also soft-boot a recovery without actually flashing it, e.g.
Code:
fastboot boot custom-recovery.img
I suppose you could then poke around and see if it is having troubles mounting any of the normal partitions (/data, /system, or /cache). Look in the kernel boot log of the recovery (cat /proc/kmsg or "dmesg") to see if anything looks strange, etc.
There have been a couple of reports from folks who developed problems that looked like eMMC flash media errors - loss of partitions, failure to mount /data, et cetera. At the moment though, your symptoms are very generic and non-specific, as in "it doesn't boot".
I suppose you saw no errors at all reported on the screen during that stock-install-via-fastboot procedure?
bftb0 said:
You can also soft-boot a recovery without actually flashing it, e.g.
Code:
fastboot boot custom-recovery.img
I suppose you could then poke around and see if it is having troubles mounting any of the normal partitions (/data, /system, or /cache). Look in the kernel boot log of the recovery (cat /proc/kmsg or "dmesg") to see if anything looks strange, etc.
There have been a couple of reports from folks who developed problems that looked like eMMC flash media errors - loss of partitions, failure to mount /data, et cetera. At the moment though, your symptoms are very generic and non-specific, as in "it doesn't boot".
I suppose you saw no errors at all reported on the screen during that stock-install-via-fastboot procedure?
Click to expand...
Click to collapse
The only error is that it can't open the zip. I've tried downgraded TWRP, then upgrading back. Tried flashing the existing rom.
Nothing has worked. The N7 is functional, just will not allow me to flash
pmgreen said:
The only error is that it can't open the zip. I've tried downgraded TWRP, then upgrading back. Tried flashing the existing rom.
Nothing has worked. The N7 is functional, just will not allow me to flash
Click to expand...
Click to collapse
Well, if the source material can't be opened, then there is nothing to be flashed.
So maybe it is better to call this a "can't open files" problem instead of a "can't flash" problem.
Are there any special characters in the file name ... or spaces? If so, try renaming the file so the name only contains [a-z], [A-Z], [0-9] plus dash, underscore, and dot.
The other thing that can happen is if you drop a file in /data/media/0 as the root user, it will show up under /sdcard, but can't be read by non-privileged users via the /sdcard/ path. I'm not sure what the exact details are here - much less why this would effect the recovery (as you would expect everything to be running as root there) - but you can detect this problem by using a terminal emulator, and looking for differences in ownership or file permission:
Code:
$ su
# cd /data/media/0
# ls -ld *
use chown and chmod as appropriate to fix files as needed
bftb0 said:
Well, if the source material can't be opened, then there is nothing to be flashed.
So maybe it is better to call this a "can't open files" problem instead of a "can't flash" problem.
Are there any special characters in the file name ... or spaces? If so, try renaming the file so the name only contains [a-z], [A-Z], [0-9] plus dash, underscore, and dot.
The other thing that can happen is if you drop a file in /data/media/0 as the root user, it will show up under /sdcard, but can't be read by non-privileged users via the /sdcard/ path. I'm not sure what the exact details are here - much less why this would effect the recovery (as you would expect everything to be running as root there) - but you can detect this problem by using a terminal emulator, and looking for differences in ownership or file permission:
Code:
$ such
# cd /data/media/0
# ls -ld *
use chown and chmod as appropriate to fix files as needed
Click to expand...
Click to collapse
Thanks bftb, you are correct it's a can't open zip. No error than fail and it can't open the zip. It says updating partition but nothing changes
The file names are from the developers, once of which I recently successfully flashed. Tried coping the log to the SD card, but unable to find /data/media/0. Do I need to recreate a partition?
(FYI there was an auto-correct typo in my prior post - "su" not "such". Derp)
pmgreen said:
Do I need to recreate a partition?
Click to expand...
Click to collapse
No. (There is no way to do that with the tools we have anyway)
Unless what you mean by "recreate" is rebuild/reinitialize a filesystem in a partition - that's a possibility.
You need to try and figure out why you can't read files.
As a workaround, you can put files on a USB key (FAT formatted, not NTFS) and using TWRP access them by putting the USB key on the other end of a OTG cable.
Your posts are a bit vague - I can't even tell if you have tried other ROM files, whether you checked them to see if they are the correct size/checksum, etc.
pmgreen said:
Tried coping the log to the SD card, but ...
Click to expand...
Click to collapse
At this point, your best approach is still to follow the initial advice of 'ibsk8'. Look in the log file for any further details about errors that occurred.
The logs are typically in /cache/recovery/ or (while the custom recovery is running) in /tmp
Use "adb pull" to get the log file to your PC and have a look at it. If you can't find anything obvious in there, then cut-n-paste the file to http://pastebin.com and provide the link to us.
bftb0 said:
At this point, your best approach is still to follow the initial advice of 'ibsk8'. Look in the log file for any further details about errors that occurred.
The logs are typically in /cache/recovery/ or (while the custom recovery is running) in /tmp
Use "adb pull" to get the log file to your PC and have a look at it. If you can't find anything obvious in there, then cut-n-paste the file to http://pastebin.com and provide the link to us.
Click to expand...
Click to collapse
I am not familiar using ADB pull. Tried using a root file manager to access the log but don't see.
Greatly appreciate your help, let me know what other info I should paste.
Thanks,
Hi,
I urgently need help for my nexus 7 that has stopped charging or recognising even the original ASUS usb cable (have tried many others as well, same result). I'm currently charging it via the method of powering it of and plugging it in without the android os running. I have even tried to connect it to my PC in bootloader mode. I have the custom trinity kernel install and want to return my device to stock kernel and os state. However I do have TWRP and need help from there to install the stock image. I have previously tried many thing such as completely wiping the system and clearing any caches in TWRP. Also I have seen that in TWRP it recognises my usb (connected via OTG cable).
So could anyone please help me with returning my nexus 7 back to stck state using TWRP.
And is there also a way of unrooting my device without using PC (using TWRP instead)?
-- Update -- I have no OS installed (tried to delete custom kernel) --
Thanks in advance.
Nexus 7 state:
- custom trinity kernel
- TWRP
- USB connection to PC not working
There should be help for you here in this sticky in this Q&A forum:
http://forum.xda-developers.com/showthread.php?t=1907796
Note 2 - Nexus 7 - Charge - Player 5.0 - Fascinate
<><><><><><><><><><>
Read twice, flash once
USB doesn't work > can't use adb
ezas said:
There should be help for you here in this sticky in this Q&A forum:
http://forum.xda-developers.com/showthread.php?t=1907796
Note 2 - Nexus 7 - Charge - Player 5.0 - Fascinate
<><><><><><><><><><>
Read twice, flash once
Click to expand...
Click to collapse
Thanks for replying, but the problem is that I can't use adb (can't connect with PC), the only thing I can do is access TWRP and usb storage (via OTG in TWRP). So I need the stock rom in a "rom" like format so I can flash it using TWRP. Could anyone please tell me another way or give the stock rom in a format that TWRP can flash (ASAP plz). Thanks in advance
The easiest thing (of course) would be if somebody put together a flashable return-to-stock ROM. I've done it before for other devices, but haven't gotten around to doing it for the N7.
You didn't really say whether you were talking about (a) "exactly stock", or whether you wanted (b) a stock recovery put back in place, or whether you were (c) also trying to get the bootloader re-locked.
Case (c) can not be done using anything except fastboot (unless you previously recorded your bootloader while it was in a locked state), so I'll just assume that you are talking about (a) and (b), and that you are going to leave the bootloader unlocked - or you had already locked your bootloader after rooting and installing a custom recovery.
I see that you are trying (in another thread) to get somebody to make you a Nandroid backup of /system from a pure stock ROM. That would be one way of doing things (making sure that you get a grouper image if you have a grouper (WiFi) or a tilapia image if you have a tilapia N7 (3G) device). And while we are on the subject, I'll throw out another way you can do just that:
- The Google "factory" system.img files are in a sparse ext4 format that can not be directly mounted (e.g. using a loopback mount) in Linux. But, the Android toolkit includes a utility (for Linux) called "simg2img" (aka Sparse IMaGe to IMaGe) which can convert the sparse ext4 "system.img" image file to a regular ext4 format image file. This could be created, mounted via a loopback (using Linux, of course), and then a "tar" backup of the whole shebang is made. The TWRP and CWM nandroid backup images are just TAR archives. So If you grok what I am telling you, you have the power to create your own "Nandroid" /system backup file directly from the factory images. (Windoze-only doods need not apply.)
If you take this route, then you only need the recovery image plus the hacked "Nandroid" backup to "restore" directly to a pure stock device using only a custom recovery. (The recovery partition can be overwritten while the recovery is running because the partition is not "in use" after the boot completes - the recovery kernel and ramdisk live entirely in memory while they are running.)
But as I noted above, this will not re-lock the bootloader. It will put stock software back on the device, though.
If you intend to save anything off the device, do it before you begin this. The stock recovery "factory reset" procedure clears the ENTIRE /data partition including the pseudo-SD card area.
good luck
how would you do the procedure
bftb0 said:
The easiest thing (of course) would be if somebody put together a flashable return-to-stock ROM. I've done it before for other devices, but haven't gotten around to doing it for the N7.
You didn't really say whether you were talking about (a) "exactly stock", or whether you wanted (b) a stock recovery put back in place, or whether you were (c) also trying to get the bootloader re-locked.
Case (c) can not be done using anything except fastboot (unless you previously recorded your bootloader while it was in a locked state), so I'll just assume that you are talking about (a) and (b), and that you are going to leave the bootloader unlocked - or you had already locked your bootloader after rooting and installing a custom recovery.
I see that you are trying (in another thread) to get somebody to make you a Nandroid backup of /system from a pure stock ROM. That would be one way of doing things (making sure that you get a grouper image if you have a grouper (WiFi) or a tilapia image if you have a tilapia N7 (3G) device). And while we are on the subject, I'll throw out another way you can do just that:
- The Google "factory" system.img files are in a sparse ext4 format that can not be directly mounted (e.g. using a loopback mount) in Linux. But, the Android toolkit includes a utility (for Linux) called "simg2img" (aka Sparse IMaGe to IMaGe) which can convert the sparse ext4 "system.img" image file to a regular ext4 format image file. This could be created, mounted via a loopback (using Linux, of course), and then a "tar" backup of the whole shebang is made. The TWRP and CWM nandroid backup images are just TAR archives. So If you grok what I am telling you, you have the power to create your own "Nandroid" /system backup file directly from the factory images. (Windoze-only doods need not apply.)
If you take this route, then you only need the recovery image plus the hacked "Nandroid" backup to "restore" directly to a pure stock device using only a custom recovery. (The recovery partition can be overwritten while the recovery is running because the partition is not "in use" after the boot completes - the recovery kernel and ramdisk live entirely in memory while they are running.)
But as I noted above, this will not re-lock the bootloader. It will put stock software back on the device, though.
If you intend to save anything off the device, do it before you begin this. The stock recovery "factory reset" procedure clears the ENTIRE /data partition including the pseudo-SD card area.
good luck
Click to expand...
Click to collapse
Thanks for the information. I do want my device (grouper WiFi) to go back to factory state (c - get rid of superSU and busybox). However I do have some questions regarding the creating nandroid backup by your method. As I have Ubuntu 12.10 installed, how would I do the procedure? And what do you mean by "mounted via a loopback"? Also is it only "system.img", what about "boot.img", "recovery.img" and "userdata.img"?
Is it possible that you could maybe give me the nandroid backup.tar as I am not much experienced, I would really appreciate it.
Thanks in advance.
Well if a (stock) factory reset erases the /data partition, userdata.img sorta doesn't matter, right?
boot.img and recovery.img are just binary blobs, so they could be taken from the factory image and used "as is" as part of your hand-assembled "Nandroid Backup"
That only leaves system.img - previously discussed.
$ sim2img google-factory-sparse-system.img ext4.system.img
$ sudo /bin/bash
# losetup /dev/loop0 ./ext4.system.img
# mkdir /mnt/Foo
# mount -t ext4 -o ro /dev/loop0 /mnt/Foo
# cd /mnt/Foo
# tar cf /home/newb/fakenandroidsystem.tar .
# cd /home/newb
# chown newb.newb fakenandroidsystem.tar
# umount /mnt/Foo
# rmdir /mnt/Foo
# losetup -d /dev/loop0
# exit
$
You will need to either find the sim2img utility as a prebuilt or download it and build it. You might need to fool with tar command-line options during the archive creation - I notice that the TWRP nandroid tar archives (system.emmc.ext4.win) seem to have absolute pathnames rooted at "/" rather than "/system". Don't know if this is significant or not.
good luck
PS it goes without saying that you need to be extremely careful about giving up root when doing this: imagine that you restore a bad /system image along with a stock recovery - you will have an unbootable device that can not be rooted without hardware repair of the USB. You might want to initially do a test restore or two without overwriting the custom recovery
with the stock version. And keep a flashable ROM on the SDcard, too. Once you have everything working correctly, only then should you restore the recovery back to stock.
Do I load the nandroid direct to my USB device (connect via OTG and then flash in TWRP) after converting the .img and from what path in ubuntu shell am I writing those commands?
Sounds like you don't have adb set up there is a ppa to set it up for you Google for it. Then try to run adb devices and it should show up
Sent from my PG86100 using Tapatalk 2
There is no problem with adb as it did work before (when USB port did work), it doesn't even show up in device manager(windows) anymore. I cannot connect with my device to my PC via USB as the port is faulty nor does it charge with the oem wall charger when system is one. I can only charge it when the system is completely turned off and then when I plug it in PC/wall charger via USB. However I can access my USB drive via OTG only in TWRP and this is only way I can flash/restore to stock system. I want to return it to stock to send it back to google (exchange).
My stock/unlocked nexus 7 2012 updated to android 4.4.0 KRT16S after being idle about 12 hours, i picked it up and just a couple minutes into browsing it started rebooting on it's own.
The weird things don't end here, since after every reboot it goes back to the exact same state it was before: if it were done updating an app, or I enabled ADB or turned off the wifi or whatever, and then suddenly reboots, all these things would go to the state they were before (WIFI on, ADB off, changes in apks, even files sideloaded).
I tried to clear the cache through recovery, but it didn't work, I also tried sideloading the ota update to 4.4.2, but it won't find the file in the root folder, as it just disappears. When i went to the nexus tool kit i was not able to unlock the bootloader, or to factory reset( not even from the device itself) or do anything to get out of this situation.
The only thing i can do for now is turn the tablet off and do nothing with it.
Has anyone an idea i can try?
Can really nobody help?
Sent from my Nexus 4 using Tapatalk
You have to create a hypothesis and then perform an experiment that tests that hypothesis. (There's a ferociously complicated processor and millions of lines of code involved; nobody is going to put their finger on the exact cause of a vaguely described problem from across the internet)
For instance:
Hypothesis A: There is a significant hardware problem which causes spontaneous reboots, and it doesn't matter what software is running for the fault to appear.
Test A: Plug the tablet in to the charger and boot it in to the recovery. Let it sit a while. Does it spontaneously reboot?
Hypotheses B: There is a software problem with the ROM I am using that causes sponateous reboots.
Test B: Back up your data, wipe the tablet, install a brand new ROM, and use it for a while. Does it still reboot?
Hypotheses C: The userdata partition got corrupted somehow which causes it to remount automatically in read-only mode. (Changes are not persistent and the ROM reboots all the time as a result)
Test C: Similar to test B, but destroy the userdata partition and reformat it using fastboot. Put a new ROM on a USB memory stick and use the OTG mounting features of the recovery to deliver a new ROM to the tablet. Is it still rebooting?
See how that goes?
Not trying to be mean or anything, but the lack of responses are probably due to several things; the leading candidate of which is that you mentioned using a toolkit - a sure sign of lack of understanding of how most of this stuff actually works.
It's OK to not understand everything - all of us are learning all the time, and everybody has to start at the beginning. Toolkits surely make some jobs faster - at the cost of hiding the details of how things actually work - and making their users helpless when something goes wrong. Try to avoid them if you can.
good luck
Thank you for the long and elaborate response! I will be the first to admit that I have limited knowledge about these things but the main reason that I used the toolkit was that everything else I tried failed. Of course, as you said there are plenty of things I could have tried, and I tried to explain everything I did to make the job easier for someone to help me out, surely not to let my questions unanswered!
So thank you for the answer, and i'll try everything as soon as possible and keep it posted up
Sent from my Nexus 4 using Tapatalk
Ok after a series of tests, and by the looks of it I think that the right hypothesis is number C, every time it boots back up it loses every change in the system. In the few minutes the tablet stays on, I managed to download the ota update to 4.4.2 but once it rebooted itself into recovery it said no command, hence the files it downloaded were erased and this was also the reason why I couldn't install the update via recovery myself, every time I put the update into the root folder and rebooted into recovery, it told me no command available. And the files would just disappear. The only option i'm left with is to destroy the user data partition using fastboot ( a method i'm not familiar with, but that i'm willing to try) I'll look for a guide, or if you be so kind to recommend one i'd be extremely thankful!
Sent from my Nexus 4 using Tapatalk
Googsx said:
Ok after a series of tests, and by the looks of it I think that the right hypothesis is number C, every time it boots back up it loses every change in the system. In the few minutes the tablet stays on, I managed to download the ota update to 4.4.2 but once it rebooted itself into recovery it said no command, hence the files it downloaded were erased and this was also the reason why I couldn't install the update via recovery myself, every time I put the update into the root folder and rebooted into recovery, it told me no command available. And the files would just disappear. The only option i'm left with is to destroy the user data partition using fastboot ( a method i'm not familiar with, but that i'm willing to try) I'll look for a guide, or if you be so kind to recommend one i'd be extremely thankful!
Sent from my Nexus 4 using Tapatalk
Click to expand...
Click to collapse
Normally user-level changes would be recorded in the /data partition, so if it got corrupted some way AND the OS mounts that filesystem with a errors=remount-ro then that would explain lack of persistence.
However, not every OS or recovery boot uses the same mount options. I'm looking at a CM boot right now and I don't see that
Code:
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 rw,seclabel,nosuid,nodev,noatime,errors=panic,user_xattr,acl,barrier=1,nomblk_io_submit,data=ordered 0 0
But anyway, if you are going to reformat your "userdata" partition, try and rescue everything off of the tablet.
Is the recovery boot stable? If so, you might want to use "adb pull" to recursively pull everything off of the /sdcard. If it doesn't reboot every couple minutes, that could be of some use for backing up the /sdcard. Otherwise it will be impossible if your ROM reboots every 2 minutes.
Yes you can use fastboot to format the userdata partition. You can also use "mke2fs" as a shell command (that is, with adb) when the recovery is running.
TWRP 2.6.3.1
Code:
mke2fs
Usage: mke2fs [-c|-l filename] [-b block-size] [-f fragment-size]
[-i bytes-per-inode] [-I inode-size] [-J journal-options]
[-G meta group size] [-N number-of-inodes]
[-m reserved-blocks-percentage] [-o creator-os]
[-g blocks-per-group] [-L volume-label] [-M last-mounted-directory]
[-O feature[,...]] [-r fs-revision] [-E extended-option[,...]]
[-T fs-type] [-U UUID] [-jnqvFKSV] device [blocks-count]
.
If you use an ext2/3/4 filesystem formatter (e.g. mke2fs) running under the recovery, you need to be very very careful about specifying the exact partition name (e.g. /dev/block/mmcblk0p9 for GROUPER - data might be at a different partition number on a Tilapia device).
You can check by doing a
Code:
adb shell ls -l /dev/block/platform/sdhci-tegra.3/by-name/*
the userdata partition is "UDA".
BTW, before you go nuking your data partition, it might be useful to check to see if it is actually corrupted. For instance, with TWRP you can unmount all partitions, and then check using the program "e2fsck" :
Code:
C:\> adb shell
# e2fsck -f -n /dev/block/mmcblk0p9
the above command will perform a check (p9 = grouper /data partition) without attempting to make any repairs. You'll know if there are any problems: you will get page after page of error messages. If the filesytem is free of errors, you will only see 8-10 summary lines.
bftb0 said:
Normally user-level changes would be recorded in the /data partition, so if it got corrupted some way AND the OS mounts that filesystem with a errors=remount-ro then that would explain lack of persistence.
However, not every OS or recovery boot uses the same mount options. I'm looking at a CM boot right now and I don't see that
Code:
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 rw,seclabel,nosuid,nodev,noatime,errors=panic,user_xattr,acl,barrier=1,nomblk_io_submit,data=ordered 0 0
But anyway, if you are going to reformat your "userdata" partition, try and rescue everything off of the tablet.
Is the recovery boot stable? If so, you might want to use "adb pull" to recursively pull everything off of the /sdcard. If it doesn't reboot every couple minutes, that could be of some use for backing up the /sdcard. Otherwise it will be impossible if your ROM reboots every 2 minutes.
Yes you can use fastboot to format the userdata partition. You can also use "mke2fs" as a shell command (that is, with adb) when the recovery is running.
TWRP 2.6.3.1
Code:
mke2fs
Usage: mke2fs [-c|-l filename] [-b block-size] [-f fragment-size]
[-i bytes-per-inode] [-I inode-size] [-J journal-options]
[-G meta group size] [-N number-of-inodes]
[-m reserved-blocks-percentage] [-o creator-os]
[-g blocks-per-group] [-L volume-label] [-M last-mounted-directory]
[-O feature[,...]] [-r fs-revision] [-E extended-option[,...]]
[-T fs-type] [-U UUID] [-jnqvFKSV] device [blocks-count]
.
If you use an ext2/3/4 filesystem formatter (e.g. mke2fs) running under the recovery, you need to be very very careful about specifying the exact partition name (e.g. /dev/block/mmcblk0p9 for GROUPER - data might be at a different partition number on a Tilapia device).
You can check by doing a
Code:
adb shell ls -l /dev/block/platform/sdhci-tegra.3/by-name/*
the userdata partition is "UDA".
BTW, before you go nuking your data partition, it might be useful to check to see if it is actually corrupted. For instance, with TWRP you can unmount all partitions, and then check using the program "e2fsck" :
Code:
C:\> adb shell
# e2fsck -f -n /dev/block/mmcblk0p9
the above command will perform a check (p9 = grouper /data partition) without attempting to make any repairs. You'll know if there are any problems: you will get page after page of error messages. If the filesytem is free of errors, you will only see 8-10 summary lines.
Click to expand...
Click to collapse
Ok before I start with all this i have to say a few things! The tablet now started rebooting even in recovery! and also since the first time it started rebooting I tried enabling usb debugging, but as I explained earlier after every reboot every change disappears, meaning usb debugging is not enabled when i enter the recovery! Will I be able to do anything at all with fastboot if the usb debugging is not enabled? If not do I have any other option?
Googsx said:
Ok before I start with all this i have to say a few things! The tablet now started rebooting even in recovery! and also since the first time it started rebooting I tried enabling usb debugging, but as I explained earlier after every reboot every change disappears, meaning usb debugging is not enabled when i enter the recovery! Will I be able to do anything at all with fastboot if the usb debugging is not enabled? If not do I have any other option?
Click to expand...
Click to collapse
The settings you (try to) apply when the ROM is running (eg the USB debugging toggle) do not affect the recovery. The entire point of a recovery is to have a standalone boot that doesn't depend on other partitions.
Having said that, the use of a "pseudo" SD card that is actually part of the userdata filesystem sometimes does cause problems for the recovery - it tries to mount /data to get you access to ROM files, nandroid backups, etc. I recall getting my N7 into a condition where TWRP's touch interface wouldn't come up because of problems with the userdata partition. But, adb was still available as was fastboot (in the bootloader mode). Also, I was not having spontaneous reboots.
The fact that you are observing spontaneous reboots in the recovery indicates that you might have Hypothesis A going on - flaky hardware. At a minimum however, it means you will not be able to run any long duration backups... for instance, trying to make a rescue backup of your SD card.
You could try and do
Code:
fastboot erase userdata
fastboot format userdata
with the tablet in bootloader mode. Obviously this step will destroy all of your data.
If your tablet is still spontaneously rebooting after that (in the recovery) then your only option will be to return it for repair (motherboard replacement).
Ok, I'm officially in trouble. I have a SM-G900F rooted with towelroot, SuperSu and BusyBox installed. I tried flashing with Mobile Odin Pro the latest NG2 firmware to keep root and not trip Knox. It failed twice (or three times), both times I was able to restore the original firmware with desktop Odin (http://forum.xda-developers.com/galaxy-s5/help/mobile-odin-pro-4-20-issues-t2834671).
Then something strange happened: I noticed that on 4G I had only data but no signal bars (http://forum.xda-developers.com/galaxy-s5/help/help-4g-data-signal-bars-t2837031). Then I had problems connecting to Wifi and a message appeared telling me I am in "Factory Mode" and some things are limited.
It was clear that my EFS partition is corrupted. I installed Root Explorer and there is nothing in my EFS folder (still I can use the phone in 2G/3G/4G for data and 2G/3G for calls but no Wifi).
I have 2 backups for EFS: one is made using Samsung Tools (http://forum.xda-developers.com/galaxy-s3/development/efs-samsung-tool-universal-support-t2602325) and it's an efs.img file, the other is made using some EFS backup tool and it's just a copy of exactly what was in EFS folder (a few folders and files). I tried using Samsung Tools to restore the backup but no luck. When I restart the phone, EFS folder is still empty.
I rebooted in recovery mode and it said "failed to mount /efs". That's probably why Samsung Tools can't do it's job but I'm not sure. At this moment I'm not sure of anything. I think that someone with some knowledge (knowledge that unfortunately I'm missing) can help me fix this.
I really need for some help, so any ideas are welcomed.
Thank's,
Mihai Raducan
..
fffft said:
No TWRP backup, huh? How did I know that was going to be the case? 10 demerits. Okay, you seem to have been on the right track in recognizing that your EFS partition was unmounted and therefore inaccessible in recovery mode.. but you didn't mount it? You didn't give us much detail to work with, but assuming that you have a custom recovery like TWRP, you could go to the advanced /mount menu and check the mount EFS partition. Or if you don't have that option for some reason, mount it yourself e.g.
.
Click to expand...
Click to collapse
It's only stock recovery, no TWRP or CWM.
I didn't mount the EFS partition before because I didn't know how. I'll follow your guide and report back.
Regarding the exact copy of EFS (efs.img): It's done with Samsung Tools but never had a chance to test it, so... I don't know. But let's take it one at a time. First problem: mount efs partition.
PS: My Windows laptop is playing tricks on me so it's going to take a while to reinstall Windows, adb, etc. But I'll be back.
Thank's.
..
Ok, I installed Adb, phone is recognized.
The first line of code
Code:
# ls -al /dev/block/platform/msm_sdcc.1/by-name
gave me a list with the location of efs (and more). EFS is at dev/block/mmcblk0p12.
The second line of code
Code:
# /sbin/mount /dev/block/mmcblk0p12 /efs
gives me : tmp-mksh: /sbin/mount: not found
Am I missing something?
is img of /efs partition enough for restore?
here, it says, that we need to have 3 partitions for full restore..??..: http://forum.xda-developers.com/showthread.php?t=2737448
dd if=/dev/block/mmcblk0p12 of=/mnt/sdcard/efs.img.ext4
dd if=/dev/block/mmcblk0p13 of=/mnt/sdcard/modemst1.bin
dd if=/dev/block/mmcblk0p14 of=/mnt/sdcard/modemst2.bin
but Samsung tool only makes efs.img..??.. who is right who is wrong?
..
fffft said:
Personally, if an EFS backup program made an image (.img} file and it was the same size as your EFS partition I'm sure that it was an exact copy and try writing it back. It's unlikely to make anything worse. But don't blame me if it somehow goes wrong. I'm just describing an option of last resort and commenting on what I would do with my own phone.
You can check the size of your EFS partition with the cat command (EFS should be partition 12)
Code:
$ su
# cat /proc/partitions
.
Click to expand...
Click to collapse
I checked the size of my efs.img and the size of the partition with the command you gave me. They are both 14MB but on a closer look, adb shows 14336 and Windows reports 14680kb. So I don't know....
fffft said:
You're using ADB instead of a terminal emulator app which is a new variable. There are a lot of ADB variants around and I have no idea what your command interpreter (mksh) or you have done with the shell environment.. which may require syntax adjustments.
Not found implies that the /system partition isn't mounted. But it could also be an ADB syntax quirk, path or symlink error, a typo or.. well, could be a lot of things. Perhaps try the syntax below. Or run the command from a terminal emulator instead of ADB shell.
Code:
$ su
# adb shell mount /system
# adb shell mount /efs
.
Click to expand...
Click to collapse
I installed Android Terminal Emulator and Shell Terminal Emulator (PlayStore) but I got the same thing. What's strange is that in both of them when I run the command "adb devices" they both give me nothing while in adb shell on desktop I get a number (as it should).
I understand that the syntax is for a specific terminal emulator. Tell me please what is that terminal emulator (that you know syntax is correct) so I can try with that one.
..
fffft said:
Try this terminal emulator app.
If you have continued difficulties, you should describe step by step what you are doing. In exhaustive detail or as close as you can get to that. Then someone in the forum will have a good basis to see where you are going astray. Or alternately where I made a typo or whatever the impediment turns out to be.
.
Click to expand...
Click to collapse
This is one the apps I tried with.
I'm describing step by step what I do. What I start with: SM-G900F rooted with towelroot, stock recovery, SuperSU and BusyBox installed, Knox 0x0.
I download and install https://play.google.com/store/apps/details?id=jackpal.androidterm.
Using this app:
Code:
su
and it changes to [email protected]:/#
I enter:
Code:
# ls -al /dev/block/platform/msm_sdcc.1/by-name
and it gives me a list with paths to different things. EFS apears to be at /dev/block/mmcblk0p12
I enter
Code:
# /sbin/mount /dev/block/mmcblk0p12 /efs
and it says: "tmp-mksh: /sbin/mount: not found"
When I try
Code:
adb devices
it gives me no number.
I attached a file where you can see what I did.
One more thing: when I enter (stock) recovery, every time it says "Installing system update" for about 20 seconds and then enters recovery where it says "failed to mount/efs : invalid argument". The CSC part is apparently ok.
..
It doesn't work. From ADB it says "mkdir failed for /efs, File already exists".
And from terminal emulator, (with busybox) it asks for an argument (pic atached).
Is there any way of using Odin to fix this, because it seems that nothing works.
fffft said:
Who is right about what? You didn't give much of a context for your question. The OP said that his EFS was corrupt, so we have been talking about EFS which is self contained in partition 12 or exported as efs.img.
Click to expand...
Click to collapse
i thought there could be more to the problem, not just /efs partition, since he said it was clear to him, and not beeing 100% fact..
..
Thank's for your time. I'm flashing now the original firmware (so I can start fresh) and I'll document every step I take. I'll report back.
Ok, I tried flashing the original firmware (ANE2) and this time I can't even get pass the Samsung authentication screen (the first time you boot your phone and asks for language, Google account, etc), It asks me for the Samsung account and password that this phone was registered with) and it tries for a couple of minutes to verify the credentials (on data network) then it fails saying it is a network error.
I tried wipe cache/factory reset (from recovery) and reinstall a different firmware. Same thing. It seems now it's really messed up.
As mentioned earlier, we did not expect a firmware image to fix your EFS. And the EFS is critical to normal phone operation.
The purpose of stock firmware is so that your phone is stable, reduce variables that might interfere and facilitate fixing your EFS. So I'm not why you apparently expected it to be an outright fix in and of itself?
Having installed the stock firmware should help you achieve your remaining goals. Now you need to decide if you are going to install a custom recovery or not. A custom recovery will increment your Knox flag if it isn't already. That affects very little, but it's your decision. It may affect the private mode feature or warranty claims, however many carriers don't care about Knox and E.U. legislation bars Samsung from invalidating a warranty unless they can demonstrate that root damaged your phone.
Whether or not you install a custom recovery, you will want to try writing your 14 MB EFS backup image to your phone. I believe that you'd find it easier to do so with a custom recovery. But it can be done with a stock one too, you will just have to deal with a bit more syntax in the latter case.
.
fffft said:
As mentioned earlier, we did not expect a firmware image to fix your EFS. And the EFS is critical to normal phone operation.
The purpose of stock firmware is so that your phone is stable, reduce variables that might interfere and facilitate fixing your EFS. So I'm not why you apparently expected it to be an outright fix in and of itself?
Having installed the stock firmware should help you achieve your remaining goals. Now you need to decide if you are going to install a custom recovery or not. A custom recovery will increment your Knox flag if it isn't already. That affects very little, but it's your decision. It may affect the private mode feature or warranty claims, however many carriers don't care about Knox and E.U. legislation bars Samsung from invalidating a warranty unless they can demonstrate that root damaged your phone.
Whether or not you install a custom recovery, you will want to try writing your 14 MB EFS backup image to your phone. I believe that you'd find it easier to do so with a custom recovery. But it can be done with a stock one too, you will just have to deal with a bit more syntax in the latter case.
.
Click to expand...
Click to collapse
I didn't expect to fix the problem, I wanted a fresh start so I can try again the adb/terminal emulator commands. But what I didn't expect was not being able to, basically, start the phone. When you first start a new phone (or after a factory reset) it asks you language, Wifi, Google account and, in my case, for a Samsung account that this phone was paired with.
If I try to connect to a Wifi network the phone reboots itself. If not, it tries via data connection. Google credentials are ok but when it tries to verify Samsung credentials it gets stuck saying that it's a network problem and it doesn't go futher. So I get stuck at this point, between booting and actually being able to use the phone. I can't install anything, I can't receive or make phone calls (like before). I can't go to USB debugging so ADB doesn't see the phone.
I don't want to install a custom recovery because my Knox is 0x0 and my warranty is intact. I live in EU but in this case, it's clear that root access is what got me in trouble and brought the phone in this state. Actually not root access got me in trouble, but what I did with root access
raducanmihai said:
I didn't expect to fix the problem, I wanted a fresh start so I can try again the adb/terminal emulator commands. But what I didn't expect was not being able to, basically, start the phone. When you first start a new phone (or after a factory reset) it asks you language, Wifi, Google account and, in my case, for a Samsung account that this phone was paired with.
If I try to connect to a Wifi network the phone reboots itself. If not, it tries via data connection. Google credentials are ok but when it tries to verify Samsung credentials it gets stuck saying that it's a network problem and it doesn't go futher. So I get stuck at this point, between booting and actually being able to use the phone. I can't install anything, I can't receive or make phone calls (like before). I can't go to USB debugging so ADB doesn't see the phone.
I don't want to install a custom recovery because my Knox is 0x0 and my warranty is intact. I live in EU but in this case, it's clear that root access is what got me in trouble and brought the phone in this state. Actually not root access got me in trouble, but what I did with root access
Click to expand...
Click to collapse
The only way to get your phone to work again and gain access to networks/wifi is by installing a new motherboard if you can`t restore the old EFS folder somehow.
Next time try this method to backup and restore your EFS folder http://forum.xda-developers.com/showthread.php?t=2737448 if you are rooted.
raducanmihai said:
I didn't expect to fix the problem, I wanted a fresh start
Click to expand...
Click to collapse
Sorry that you found it a surprise.. but if reinstalling the stock firmware eliminated your phones problems, that would make it a solution, whereas it's a stepping stone. I did try to explain this earlier, where I told you that installing the firmware would not fix your EFS. And the EFS is essential to normal phone operation.
Regardless of the surprise, you are now on a better footing to finish fixing your phone. But for clarity, your problem started when your EFS got corrupted somehow. And your EFS needs to be restored before the problem will be resolved.
On the positive side, you appear to have a EFS backup, even if the backup app won't easily restore it to you phone. If you stick with it.. you just have some minor hurdles remaining - syntax or whatever - in getting your 14 MB EFS backup restored (written) to your EFS partition.
If you want that done painlessly, then pack a case of beer and your phone into a box and ship it to me. And I'll return it fixed. As it seems unlikely that you'd do that though.. then try to provide as much info as you can here and someone will try to help you finish fixing your phone in this thread.
.