Related
If I am posting in the wrong place, please advise me on where to post to get help.
I have followed the directions on this forum to root my Sprint Hero Phones with the stock 2.1 using this topic //forum.xda-developers.com/showthread.php?t=694572 (sorry it isn't a link, i do not have permission to post links). I have rooted three Hero's thus far. The first two gave me zero problem. The third one will not do a Nandroid backup. When ran connected USB i can view the log which I will post below. Yes the SD card is empty 2GB free, I tried to reformat the card. It is a problem while backing up the recovery. IF i run it with switches nandroid-mobile.sh -b --recovery then it runs without error but there is no recovery.img file. Therefore, it is obvious it cannot created a recovery.img and that is the part that fails. Can anyone help me with this issue. I am new to root so I don't even know what recovery.img is for? Is that the recovery menu I am in when trying to make this backup?
LOG:
Create Nandroid backup?
Press HOME to confirm,
any other key to abort.
Performing backup : .
nandroid-mobile v2.2.1
Using G1 keyboard, enter a prefix substring and then <CR>
or just <CR> to accept default: Accepting default.
Using - prefix to create a backup folder
mounting system and data read-only, sdcard read-write
checking free space on sdcard
..Dumping boot to /sdcard/nandroid/HT01NHF07567/BCDMRS-20100701-0617/boot.img.....done
.mtd: ECC errors (0 soft, 1 hard) at 0x00380000
error reading recovery: No such file or directory
.Dumping recovery to /sdcard/nandroid/HT01NHF07567/BCDMRS-20100701-0617/recovery.img....mtd: ECC errors (0 soft, 1 hard) at 0x00380000
.error reading recovery: No space left on device
md5sum: can't open '/sdcard/nandroid/HT01NHF07567/BCDMRS-20100701-0617/recovery.img': No such file or directory
mtd: ECC errors (0 soft, 1 hard) at 0x00380000
.error reading recovery: No space left on device
md5sum: can't open '/sdcard/nandroid/HT01NHF07567/BCDMRS-20100701-0617/recovery.img': No such file or directory
.mtd: ECC errors (0 soft, 1 hard) at 0x00380000
error reading recovery: No space left on device
md5sum: can't open '/sdcard/nandroid/HT01NHF07567/BCDMRS-20100701-0617/recovery.img': No such file or directory
.mtd: ECC errors (0 soft, 1 hard) at 0x00380000
.error reading recovery: No space left on device
md5sum: can't open '/sdcard/nandroid/HT01NHF07567/BCDMRS-20100701-0617/recovery.img': No such file or directory
.mtd: ECC errors (0 soft, 1 hard) at 0x00380000
error reading recovery: No space left on device
md5sum: can't open '/sdcard/nandroid/HT01NHF07567/BCDMRS-20100701-0617/recovery.img': No such file or directory
Fatal error while trying to dump recovery, aborting.
Error : Run 'nandroid-mobile.sh' via adb!
Nandroid is corrupted. Try a different one. There is a thread for that error. Just search for it
Per the instruction, i have tried to copy unrevoked to to the sd card again and then run it by "sh /sdcard/unrevoked" shouldn't that copy nandroid to my phone again? If not, does anyone have instructions on how to get a new copy of non corrupted nandroid to my phone?
in the previous post i actually ment to say i ran "flash_image recovery /sdcard/recovery.img"
Shouldn't that recopy nandroid to my phone?
gupter said:
in the previous post i actually ment to say i ran "flash_image recovery /sdcard/recovery.img"
Shouldn't that recopy nandroid to my phone?
Click to expand...
Click to collapse
Yes it will. But you may need to re-download recovery though. Either re-download the same one from the server/website and push it to your sd card again, or download an entirely new/different recovery image. There are several recovery versions floating around this forum.
I'm starting to think there is something wrong with this particular phone. Here is what I got when i tried RA-heroc-1.6.2
/ # flash_image recovery /sdcard/recovery-RA-heroc-v1.6.2-pink.img
flash_image recovery /sdcard/recovery-RA-heroc-v1.6.2-pink.img
flashing recovery from /sdcard/recovery-RA-heroc-v1.6.2-pink.img
mtd: erase failure at 0x00380000 (Input/output error)
mtd: erase failure at 0x00380000 (Input/output error)
mtd: skipping write block at 0x00380000
and now it will not boot into recovery.
So, I flashed back to 1.5.2 and it worked...
tried 1.6.2 again and got the same error.
is there a problem with 0x00380000? that is what is wrong with the nandoid backup and now i can't reflash a recovery. Is this fixable?
Any suggestions?
Nope, sorry, that is a little over my head.
The only other suggestion I would have is completely start over. Try to run the RUU again and restore your phone to regular stock 2.1. Then re-download all the root tools all over again....Android SDK, HTC Sync, and the .zip that contains the rest of the files....and start the whole root process over from square one. Maybe you've already tried that with no success, but that's about the only other thing I can think to suggest.
Thanks for all your help so far. Now I hope some else on here might have an idea. My phone works great and this is my wife's phone....she is none too happy at the moment!
The recovery partition isn't writable. Either you are not properly rooted, or you need to mount it as writable. If you adb shell, then su, do you get the # prompt? If not, then you are not rooted. If so, exit the shell, type adb remount, and then try flashing
Sent from my Hero CDMA using XDA App
I have a # sign at the prompt.
I can mount as writable and successfully flash 1.5.2.
But nandroid reports an error at 0x00380000
Therefore, I decided to flash 1.6.2 to see if this fixes my problem. Instead i get an error about 0x00380000 when trying to reflash. When I try to boot recovery afterwards, it just hangs on the "HTC" screen
So, I boot back into regular OS and use adb to mount writable and then reflash the recovery back to 1.5.2. That happens with success. But of course if I try to run nandroid it reports an error again at 0x00380000.
So i think I am rooted and I think I am mounting it correctly. But evidently i can't read or write into memory 0x00380000. But I don't know what that means or how to fix.
Any additional suggestions would be much appreciated. Thanks in advance.
My system partition was erased via fastboot in order to successfully flash a different one, however I'm getting write errors on one I pulled from somebodies' nandroid backup, and a buffer exceeded error when trying to flash the system.img from the leaked stock images thread.
Is there any way to flash the image from my phone (I read that fastboot doesn't handle files over 300mb?) or an alternate image I can use. Everything else is in tact the phone just stalls at the Google screen due to a missing /system
Alex.xTF said:
My system partition was erased via fastboot in order to successfully flash a different one, however I'm getting write errors on one I pulled from somebodies' nandroid backup, and a buffer exceeded error when trying to flash the system.img from the leaked stock images thread.
Is there any way to flash the image from my phone (I read that fastboot doesn't handle files over 300mb?) or an alternate image I can use. Everything else is in tact the phone just stalls at the Google screen due to a missing /system
Click to expand...
Click to collapse
You need a sparse filesystem image. Until the original factory images are made available online (it's in the works, but I don't have an exact date), somebody with a working device could create such an image by running (as root):
# make_ext4fs -l 512m -s /sdcard/system.img /system
This should create a flashable system.img (~145MB) on /sdcard (that you can then grab with adb pull or usb mass storage)
I really appreciate you responding, hopefully I can recover my phone without a return, anybody you can suggest I ask to do this for me?
Anybody with a Nexus S and an adb shell running as root should be able to do this.
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
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).
This guide is for hard bricked Moto G5 Cedric
Hard bricked means a device which can not enter bootloader mode normally
This method has now been confirmed working
Works with XT1672 XT1670 XT1671 XT1675 XT1676 XT1677 (and most likely all others and if you ask if it will work on your version I will just copy & paste this to you!)
Smaller Image
Thanks to Luka Panio, Omega, and nift4 we now have a smaller image size
Goto This github page and under assets download mmcblk0.img.gz
Extract mmcblk0.img from the zip file to PC
Previous Larger Images
Mega
Download mmcblk0.zip image from Mega
Create your own mega account and import the file into your mega account. Log into your account and download it from your own account
Extract mmcblk0.img from mmcblk0.zip to PC
Or for those of you who can't use mega or have unstable Internet I've split the large file size into smaller multiple zip files. You must download each part and then extract using an unzip tool like winrar or 7zip
Android File Host
Download mmcblk0.zip mmcblk0-part1.zip and mmcblk0-part2.zip from Android File Host
Extract mmcblk0.z01 from mmcblk0-part1.zip
Extract mmcblk0.z02 from mmcblk0-part2.zip
Extract mmcblk0.img from mmcblk0.zip (If prompted point to mmcblk0.z01 and mmcblk0.z02 but it shouldn't ask if all files are in the same folder)
Requirements
Freshly formatted microSD card 16gb if using the smaller image or at least 32gb if using the previous larger images (It needs to have at least 31.3gb free after formatting - if it displays as less you will need to buy a 64gb microSD card or use the smaller image)
7zip
Linux mint live usb/dvd
USB card reader
Method
The BEST method to flash the sdcard with mmcbk0.img file is to use LINUX!
Windows users have no need to install Linux on their PC, you can run Linux from a bootable usb-stick that is at least 8gb or a dvd
Do not run Linux as a virtual machine on Windows! Use the live USB/DVD
0) Put the Moto g5 on mains charge until you have finished flashing the sdcard so it's fully charged ready for the boot test!
1) Run Linux, preferably cinnamon or mate versions of Linux Mint
2) Insert the sdcard in pc or card reader and open "Disks" app
3) In "Disks" app select sdcard and you will see the sdcard partitions
4) Press "-" to delete the partition (delete all partitions if there is more than one)
5) Press "+" to create a new one and name it mmcblk0, set FAT(FAT32) file format and press "CREATE"
6) Press "Play" button to mount the sdcard, look to see what path the sdcard has (/dev/sd??) and then close the "Disks" app
7) Go to Desktop, open "Computer" and navigate to the location where the img file is extracted (mmcblk0.img)
8) Open the window where img file is with root (right click on window and select "open as root")
9) In root window open the Terminal (right click on window and select "open terminal")
no need to type "su" in terminal, it has root already (see notes if using Linux live usb/dvd)
10) Type in terminal the command written below and don't forget to eliminate that "1" from the sdcard path,
that "1" can make the difference between the phone booting or not!!!!!
Things to note
Linux Live dvd doesn't have open as root so just open in terminal and add sudo to the start of the commands
I've included this in the commands below
If you get a status error just remove status=progress from the terminal command below
Terminal comands
- if your sdcard is seen like " /dev/sdb1"
in terminal apply this command:
Code:
sudo dd bs=4M if=mmcblk0.img of=/dev/sdb status=progress oflag=sync
-if your sdcard is seen like " /dev/mmcblk0p1"
in terminal apply this command:
Code:
sudo dd bs=4M if=mmcblk0.img of=/dev/mmcblk0 status=progress oflag=sync
and the flashing process should start
When it finishes, test the sdcard in the phone and it should boot!
If you get a size error of the sdcard in terminal you have to change the sdcard and try again!
Thanks to @vaserbanix for the original version of this guide
Re-flash Stock Firmware
Once the phone is in bootloader mode you can flash stock firmware via fastboot
Note that in order to flash gpt the firmware MUST be the same or newer than the version currently on your phone
Firmware can be download from Here
Once you have firmware that is the same or newer than your current version you can remove the sd card and run these commands (assuming you have fastboot all setup on your pc)
If you get a security downgrade error when you try to flash gpt.bin or bootloader.img then the firmware you are trying to flash is too old!
Code:
fastboot oem fb_mode_set
fastboot flash partition gpt.bin
fastboot flash bootloader bootloader.img
fastboot flash logo logo.bin
fastboot flash boot boot.img
fastboot flash recovery recovery.img
fastboot flash dsp adspso.bin
fastboot flash oem oem.img
fastboot flash system system.img_sparsechunk.0
fastboot flash system system.img_sparsechunk.1
fastboot flash system system.img_sparsechunk.2
fastboot flash system system.img_sparsechunk.3
fastboot flash system system.img_sparsechunk.4
fastboot flash system system.img_sparsechunk.5
fastboot flash system system.img_sparsechunk.6
fastboot flash system system.img_sparsechunk.7
fastboot flash system system.img_sparsechunk.8
fastboot flash modem NON-HLOS.bin
fastboot erase modemst1
fastboot erase modemst2
fastboot flash fsg fsg.mbn
fastboot erase cache
fastboot erase userdata
fastboot oem fb_mode_clear
fastboot reboot
I might consider doing this if you explained what this loader.img is?
Is it something one would flash to recover their G5?
Exanneon said:
I might consider doing this if you explained what this loader.img is?
Is it something one would flash to recover their G5?
Click to expand...
Click to collapse
Potentially - its used to boot off the sd card so those with a bricked phone can access the bootloader through booting it off their sd card & then flash the firmware via fastboot
See
https://www.aryk.tech/2017/02/how-to-unbrick-debrick-qualcomm-android.html?m=1
I hope the solution is achieved soon
Here you go:
https://cloud.wdata.de/index.php/s/JK2by8YBQCSrsof
Device Info:
Cedric XT1676 Retail
LineageOS 14.1
TWRP 3.2.1 (32bit)
staffe said:
Here you go:
https://cloud.wdata.de/index.php/s/JK2by8YBQCSrsof
Device Info:
Cedric XT1676 Retail
LineageOS 14.1
TWRP 3.2.1 (32bit)
Click to expand...
Click to collapse
Thanks for uploading it
Hello, I followed all the steps of the link, using a 16gb card and the file here hung and nothing, the phone does not start.
In my case it is an xt1676 which only turns on the led and blinks when I connect it to the pc by usb or the wall charger.
takoa said:
Hello, I followed all the steps of the link, using a 16gb card and the file here hung and nothing, the phone does not start.
In my case it is an xt1676 which only turns on the led and blinks when I connect it to the pc by usb or the wall charger.
Click to expand...
Click to collapse
I take it the programme wrote the loader image successfully to sdcard
So either the person who uploaded the Loader.img interrupted the extract & so its corrupted or this phone can't boot off the sd card with this method
It does say it may take a while to boot but who knows
If anyone else can upload a Loader.img using the methods in the first post so there's a comparison please do
Yeah right.
What is strange to me, although maybe it is, is the size of the file hung here, 165 mb.
the 16gb card is formatted in fat32, is it correct?
Does the DiskImageRev2 program automatically create the card to be bootable?
Why install the qualcomm drivers if the phone does not have to be connected to the PC? It is assumed that the phone will boot in bootloader mode and there only need the adb / fastboot controllers.
I do not mind to keep trying since the phone I give for lost at the moment.
Can someone return to the first post with an xt1676?
Thank you.
TheFixItMan said:
I'm trying to work on a solution for guys with a hard bricked moto g5 but as I no longer own this device anymore I need someone to provide the following
Requirements
Rooted moto g5
Busybox installed
Terminal emulator installed
What I need
In terminal emulator type su and grant superuser access
Then type
Code:
dd if=/dev/block/mmcblk0 of=/sdcard/Loader.img bs=1024 count=168960
Wait for the command prompt to return (it may take a few mins)
Post the Loader.img file created on the root of sdcard here
Click to expand...
Click to collapse
https://drive.google.com/file/d/1H2Qkc1XKbr7Is46n5xdCFlgiuIH1m-vE/view
Device : XT1677
takoa said:
Yeah right.
What is strange to me, although maybe it is, is the size of the file hung here, 165 mb.
the 16gb card is formatted in fat32, is it correct?
Does the DiskImageRev2 program automatically create the card to be bootable?
Why install the qualcomm drivers if the phone does not have to be connected to the PC? It is assumed that the phone will boot in bootloader mode and there only need the adb / fastboot controllers.
I do not mind to keep trying since the phone I give for lost at the moment.
Can someone return to the first post with an xt1676?
Thank you.
Click to expand...
Click to collapse
I presume it's needed for some devices who use different methods of flashing stock firmware
Someone else has uploaded an image file so you can try that one from a xt1677
Yes formatted fat32 - you should just have to select the drive the sdcard card is assigned to on your pc in the program eg f: and then select image file & then write - and accept the warning
It should make it bootable
Iv no idea if this method will work with this device
then it does not work in this model or the file posted here is wrong. Because I have done it as here is exposed and nothing.
I'm going to try the one from xt1677
TheFixItMan said:
So either the person who uploaded the Loader.img interrupted the extract & so its corrupted or this phone can't boot off the sd card with this method
It does say it may take a while to boot but who knows
Click to expand...
Click to collapse
Hmm, there haven't been any error messages on my side. I pulled the image again with above dd-command. I also tried with adb shell instead of terminal emulator but it's always the same file with the exact same file size.
staffe said:
Hmm, there haven't been any error messages on my side. I pulled the image again with above dd-command. I also tried with adb shell instead of terminal emulator but it's always the same file with the exact same file size.
Click to expand...
Click to collapse
I assume the file is correct - it's probably more the case of this phone doesn't support this method
If I get my hands on this device again in the future I can properly test things but at the moment all I can do is throw out ideas for people to try
Think I'll leave it now as without the device there's not a lot I can do
nothing, it does not work. it does not start :crying:
As I said, only the LED flashes when connected by USB or charger.
I recommend using rufus for flashing it to the sd card, it has never failed me yet, and supports up to 16gb.
Edit: I have the XT1675, if anyone would find it useful for me to post this variant's bootloader then I'd be happy to do so.
Edit again: Isn't dd used for writing an image to flash storage for later booting rather than extracting it?
takoa said:
nothing, it does not work. it does not start :crying:
As I said, only the LED flashes when connected by USB or charger.
Click to expand...
Click to collapse
It seems, some qualcomm devices need a full mmcblk0 dump to be able to boot from sdcard (e.g. LG G5)¹. I don't know if thats the case for our device but you can give it a try:
Loader_XT1676.zip Uncompressed filesize: ~4GB
¹ "The Loader method requires a full ROM Dump also known as a full blk0 backup of a working LG G5 H850 correctly flashed or written on a pretty good and fast class 10 SD Card."
Source: https://www.aryk.tech/2018/03/lg-g5-h850-unbrick-solutions.html
Exanneon said:
Edit again: Isn't dd used for writing an image to flash storage for later booting rather than extracting it?
Click to expand...
Click to collapse
dd basically clones/copies the source-data block by block to another disk, partition or (img-)file.
staffe said:
It seems, some qualcomm devices need a full mmcblk0 dump to be able to boot from sdcard (e.g. LG G5)¹. I don't know if thats the case for our device but you can give it a try:
Loader_XT1676.zip Uncompressed filesize: ~4GB
¹ "The Loader method requires a full ROM Dump also known as a full blk0 backup of a working LG G5 H850 correctly flashed or written on a pretty good and fast class 10 SD Card."
Source: https://www.aryk.tech/2018/03/lg-g5-h850-unbrick-solutions.html
dd basically clones/copies the source-data block by block to another disk, partition or (img-)file.
Click to expand...
Click to collapse
Thanks for the info - if someone can try this full Loader.img & let me know if it works I'll write up a guide
Iv added the guide to the first post if people want to test
Like Iv said before I no longer own this device - I have not tested this & it may not work
Feel free to add potential solutions to help those with bricked devices