No way to unlock device. Is it bricked? - Nexus 7 Q&A, Help & Troubleshooting

My Nexus 7 wifi tablet was working flawlessly for a few months since buying.
It was rooted, unlocked with stock android 4.2.1 and Team Win Recovery 2.3.2.1
Yesterday morning after charging all the night I saw that it was completely turned off. It didn't bother me, because it happened a couple of times before.
But this time, after I'd switched it on it hung on google color logo.
I waited half an hour but to no avail.
So at first I booted to recovery and wiped cache and the like. But the problem remained. Factory reset didn't help either.
So as a last resort I formated everything (including system).
Then I saw surprisingly in fastboot mode that lock state is: LOCKED.
I've tried to unlock it but it ended with an error:
C:\Users\Warp\AppData\Local\Android\android-sdk\platform-tools>fastboot oem unlock
...
(bootloader) erasing userdata...
(bootloader) erasing userdata done
(bootloader) erasing cache...
FAILED (remote: (Unknown error code))
finished. total time: 7.241s
After I'd pressed "yes" to the question "unlock bootloader" on tablet it was displaying text "Neither USP nor CAC patition found" in a loop.
Because there is still TWR installed and I can't wipe it out i think I've lost the guarantee.
I can see my device in fastboot mode:
C:\Users\Warp\AppData\Local\Android\android-sdk\platform-tools>fastboot getvar all
(bootloader) version-bootloader: 4.13
(bootloader) version-baseband: N/A
(bootloader) version-hardware: ER3
(bootloader) version-cdma: N/A
(bootloader) variant: grouper
(bootloader) serialno: XXXXXXXXXXXXXXXXXXXXXX
(bootloader) product: grouper
(bootloader) secure: yes
(bootloader) unlocked: no
(bootloader) uart-on: no
(bootloader) partition-size:bootloader: 0x0000000000600000
(bootloader) partition-type:bootloader: emmc
(bootloader) partition-size:recovery: 0x0000000000c00000
(bootloader) partition-type:recovery: emmc
(bootloader) partition-size:boot: 0x0000000000800000
(bootloader) partition-type:boot: emmc
(bootloader) partition-size:system: 0x0000000028a00000
(bootloader) partition-type:system: ext4
(bootloader) partition-size:cache: 0x000000001bb00000
(bootloader) partition-type:cache: ext4
(bootloader) partition-size:userdata: 0x0000000364700000
(bootloader) partition-type:userdata: ext4
all:
finished. total time: 0.193s
Is there anything left I can try?

AW: No way to unlock device. Is it bricked?
Have you tried reflashing stock rom? Maybe this rewrites recovery, too
Sent from my SK17i running Android 4.1.2

mihahn said:
Have you tried reflashing stock rom? Maybe this rewrites recovery, too
Click to expand...
Click to collapse
Yes, but it can't be done because the device is locked.

Before you do anything drastic, realize that you still have (in TWRP) a privileged execution environment (a root shell).
That means at a minimum you have a root-privileged shell available and some tools for fooling with partitions known to the TWRP kernel.
By drastic, I mean specifically: don't overflash the recovery partition at the command line from the root shell using /sbin/flash_image. Keep "root" until you are sure that nothing else can be done.
Back in a couple minutes - booting my N7 into TWRP right now to have a look at some things.
[ Edit ] From your post I see you have fastboot drivers set up - can you connect to TWRP via ADB?

Thank you for your reply.
Yes, I can see my device using: adb devices
adb shell also works.
[Edit] One more odd thing, when TWRP starts it asks me to enter my password. I think it's related to data encrypted partition but I've never done it for sure.

Well, I have a couple of hypotheses.
I guess I should ask one more question - is it correct that in TWRP you see none of your backups in /sdcard (TWRP mounts /sdcard on when it starts up) ?
If you have anything left on the SD card you want saved, get it backed up to your PC with "adb pull" before proceeding any further. (All suggestions below assume you have nothing left to save anywhere in /data.)
Also, I note that my N7 discharges slowly when plugged into my computer but sitting at the TWRP screen - so get your nexus fully charged before going any further.
The fact that you can boot TWRP means that the bootloader can find your recovery image, so at a minimum that means the bootloader can still understand some of the partitioning information it has available.
It is possible that the initial problem you had was something as simple as a corruption of a ext4 file system involving /cache, /system, or /data - as they need to be mounted after the early boot (ramdisk) initialization has more or less finished up. If they can not be mounted, the late boot processes never occur. Looking at your subsequent problems with unlocking the bootloader indicate a problem with the /cache partition - maybe?
[ The re-locking of the bootloader is odd, though. It suggests something got erased or mangled in a partition of the flash RAM that normally does not get mounted or touched by any of the usual kernel boots (whether we are talking about a recovery boot or any other android kernel boot). That means something other than /system, /cache, or /data - probably misc1, misc2, mfg, or possibly somewhere else (like slack space at the ends of either the boot or recovery partitions, or even in hard-coded location. ]
What happens if you try to rebuild the ext4 filesystems on /cache, /system, and /data?
[ note the partitions below are for the grouper N7 device; do a "adb shell cat /etc/fstab" to see if there are differences if you are on tilapia (3G version of the Nexus 7) ]
C:\foo> adb shell
# umount /data
# umount /cache
# umount /sdcard
# /sbin/mke2fs -t ext4 -m 0 /dev/block/mmcblk0p4
# /sbin/mke2fs -t ext4 -m 0 /dev/block/mmcblk0p3
# /sbin/mke2fs -t ext4 -m 0 /dev/block/mmcblk0p9
Does this succeed or fail? If it fails, what about first trying
# /sbin/erase_image /dev/block/mmcblk0p??? ( substitute correct # for ???)
prior to the mke2fs operation?
If you can get them to succeed, you might try restoring a backup (adb push to your "SD card"), and then doing a restore from TWRP and see if you can get it to boot.
You may also want to get your misc1 and misc2 partitions backed up - they contain the partitioning information (and usually the android "boot communication block), and they are generally identical (down to the last byte):
C:\foo> adb shell
# mount /sdcard (if this fails then you can't do this obviously)
# dd if=/dev/block/mmcblk0p5 of=/sdcard/part5.img bs=4096
# dd if=/dev/block/mmcblk0p8 of=/sdcard/part8.img bs=4096
# exit
C:\foo> adb pull /sdcard/part5.img
C:\foo> adb pull /sdcard/part8.img
If one of misc1 or misc2 got corrupted - and that is what is confusing the bootloader - it should be possible to flash the bad one with the good spare - but let's leave that alone until we see if /cache, /data, and /system can be re-initialized.
I'll come back to this thread in 8 hours or so - time for bed for me.

bftb0 said:
Well, I have a couple of hypotheses.
is it correct that in TWRP you see none of your backups in /sdcard (TWRP mounts /sdcard on when it starts up) ?
Click to expand...
Click to collapse
Yes it mounts it and it is empty (besides TWRP directory). I don't have backup either but it is no problem for me. I just want to start with stock Android 4.2.1 or if it's not possible - wipe out TWRP and send nexus for repairing.
bftb0 said:
What happens if you try to rebuild the ext4 filesystems on /cache, /system, and /data?
Does this succeed or fail?
Click to expand...
Click to collapse
Everything went smoothly, no errors here.
bftb0 said:
If you can get them to succeed, you might try restoring a backup (adb push to your "SD card"), and then doing a restore from TWRP and see if you can get it to boot.
Click to expand...
Click to collapse
I was trying to install a few roms this way, but the flashing never ends. On nexus I can see all the time: Flashing file 1 of 1 /sdcard/aokp_grouper_jb-mr1_build-1.zip
As I saw in recovery.log the problem is at the moment when filesystem is created:
C:\Users\Warp\AppData\Local\Android\android-sdk\platform-tools>adb shell cat /tmp/recovery.log
[cut]
I:Set page: 'main2'
I:Set page: 'install'
I:Set page: 'flash_confirm'
I:Set page: 'flash_zip'
I:Set page: 'flash_zip'
Installing '/sdcard/aokp_grouper_jb-mr1_build-1.zip'...
Checking for MD5 file...
Skipping MD5 check: no MD5 file found.
Creating filesystem with parameters:
Size: 681574400
Block size: 4096
Blocks per group: 32768
Inodes per group: 6944
Inode size: 256
Journal blocks: 2600
Label:
Blocks: 166400
Block groups: 6
Reserved block group size: 47
Created filesystem with 11/41664 inodes and 5415/166400 blocks
and it stops here.
bftb0 said:
You may also want to get your misc1 and misc2 partitions backed up - they contain the partitioning information (and usually the android "boot communication block), and they are generally identical (down to the last byte):
Click to expand...
Click to collapse
Ok, done. I've checked they are identical.
bftb0 said:
I'll come back to this thread in 8 hours or so - time for bed for me.
Click to expand...
Click to collapse
Great I'm waiting impatiently.
Regards

warpek said:
...I don't have backup either...
Click to expand...
Click to collapse
Arrgh - you never made any backups?. I was hoping you had a TWRP backup - they are just tar files, so you can manually untar them into mounted partitions at the command line... and that way see if any errors occur on an individual partition you are working with. But I'll come back to this in a little bit.
warpek said:
Everything went smoothly, no errors here.
Click to expand...
Click to collapse
OK, got it.
warpek said:
As I saw in recovery.log the problem is at the moment when filesystem is created:
[cut]
Creating filesystem with parameters:
Size: 681574400
...
Created filesystem with 11/41664 inodes and 5415/166400 blocks
and it stops here.
Click to expand...
Click to collapse
Well, 650 MB (=681574400 bytes) is the /system partition, and the "Created filesystem" message probably indicates success with a mke2fs operation. But mke2fs does not wipe all the blocks, so it is still possible that the *restore to /system* operation is hanging on a media failure.
warpek said:
Ok, done. I've checked they are identical.
Click to expand...
Click to collapse
Just out of curiosity, do you get a md5sum of 3039dc3a07a56d0392d48787e4a202a1 for your part5.img and part8.img files? In principle, yours should not be identical to mine - especially if there is something unusual in the BCB (Boot Control Block), but there is a chance they are the same as these partitions seem to contain multiple backups of partitioning information. (My N7 appears to have been made in December)
OK, lets try something innocuous - raw read tests on all of your partitions. Let's see if you have a bunch of bad pages in one partition.
With TWRP running
C:\foo> adb shell
# dd of=/dev/null bs=4096 if=/dev/block/mmcblk0boot0
# dd of=/dev/null bs=4096 if=/dev/block/mmcblk0boot1
# dd of=/dev/null bs=4096 if=/dev/block/mmcblk0p1
# dd of=/dev/null bs=4096 if=/dev/block/mmcblk0p2
# dd of=/dev/null bs=4096 if=/dev/block/mmcblk0p3
# dd of=/dev/null bs=4096 if=/dev/block/mmcblk0p4
# dd of=/dev/null bs=4096 if=/dev/block/mmcblk0p5
# dd of=/dev/null bs=4096 if=/dev/block/mmcblk0p6
# dd of=/dev/null bs=4096 if=/dev/block/mmcblk0p7
# dd of=/dev/null bs=4096 if=/dev/block/mmcblk0p8
These should all go through pretty quickly - I omitted the /data partition (p9) because it is huge. The next largest (system/p3) should take about 20 seconds for a successful raw read. If you get a read failure, repeat the command on the offending partition with the "conv=noerror" option, as in
dd of=/dev/null bs=4096 conv=noerror if=/dev/block/mmcblk0p8
Basically I'm just looking for you to narrow down the search to a problem partition. The next step is to try to manually unpack files into /system, /cache, and /data to see if there is a flash media problem in one of those partitions. Unfortunately, this is where TWRP backup files would have been useful: ROM files are not useful for this, and the google factory images e.g. nakasi-jop40d-factory-6ac58a1a.tgz contain image files which are not archives - they are "sparse ext4 images".
Even though you observed no failures with the mke2fs operations, you might want to also try to repeat that process (only for p3, p4, and p9 !) , but this time using the partition erase command first.
# /sbin/erase_image /dev/block/mmcblk0pN
prior to the mke2fs operation.
OK, standing by.

bftb0 said:
Arrgh - you never made any backups?
Click to expand...
Click to collapse
I always do, but I though that because there are no important files for me on the nexus and everything else can be downloaded (system image, twrp) there is no need. Obviously I was mistaken.
bftb0 said:
Just out of curiosity, do you get a md5sum of 3039dc3a07a56d0392d48787e4a202a1 for your part5.img and part8.img files?
Click to expand...
Click to collapse
I used md5sum to co compare those files, here is mine:
part5.img 59071590099d21dd439896592338bf95
part8.img 59071590099d21dd439896592338bf95
bftb0 said:
OK, lets try something innocuous - raw read tests on all of your partitions. Let's see if you have a bunch of bad pages in one partition.
Click to expand...
Click to collapse
Everything looks ok here. No errors and no long time reads.
bftb0 said:
Basically I'm just looking for you to narrow down the search to a problem partition. The next step is to try to manually unpack files into /system, /cache, and /data to see if there is a flash media problem in one of those partitions. Unfortunately, this is where TWRP backup files would have been useful:
Click to expand...
Click to collapse
Is there anything I can I do then?
bftb0 said:
Even though you observed no failures with the mke2fs operations, you might want to also try to repeat that process (only for p3, p4, and p9 !) , but this time using the partition erase command first.
# /sbin/erase_image /dev/block/mmcblk0pN
prior to the mke2fs operation.
Click to expand...
Click to collapse
Ok, done, still no errors.
I've also tried writing test using dd if=/dev/zero of=/dev/block/partition bs=4096 (for partition p3 and p4) and again without any errors.

warpek said:
I used md5sum to co compare those files, here is mine:
part5.img 59071590099d21dd439896592338bf95
part8.img 59071590099d21dd439896592338bf95
Click to expand...
Click to collapse
Hmmmm. I did a little more looking at my own misc partition images, and they each contain 64 repeated (and identical!) blocks of information that are 1280 bytes long - a group of 8 (at minor offsets of 0x4000, 0x5000, 0x6000, 0x7000, 0xc000, 0xd000, 0xe000, 0xf000) that repeat 8 times every 64kB (major offset of 0x10000). If you want to attach one of your misc partition images, I can have a look at it for comparison (it is small - 512 kB, and should not contain any private data). Wait, I just realized: I have a 32GB WiFi N7 - is yours a 16GB?
warpek said:
Is there anything I can I do then?
Click to expand...
Click to collapse
I could shove a (near stock) boot.img and system.img backup from TWRP someplace, but the system image is huge. I don't have a convenient place to drop it - got any suggestions? In principle - barring any other errors - that should boot correctly so long as the ext4 filesystems on /data and /cache are intact and operating correctly.
warpek said:
I've also tried writing test using dd if=/dev/zero of=/dev/block/partition bs=4096 (for partition p3 and p4) and again without any errors.
Click to expand...
Click to collapse
Barring a tar or other archive file which we could unpack directly into (mounted) /system, that was going to be my next suggestion. Rats.
Maybe it is time to try the read/write tests with the /data partition?
Actually, before you do that, what were the dump lengths you got for each of your partitions? Here are mine (using bs=4096):
Code:
/dev/block/mmcblk0boot0 512 ( 2097152 bytes - 2.0MB)
/dev/block/mmcblk0boot1 512 ( 2097152 bytes - 2.0MB)
/dev/block/mmcblk0p1 3072 ( 12582912 bytes - 12.0MB) recovery
/dev/block/mmcblk0p2 2048 ( 8388608 bytes - 8.0MB) boot
/dev/block/mmcblk0p3 166400 (681574400 bytes - 650.0MB) system
/dev/block/mmcblk0p4 113408 (464519168 bytes - 443.0MB) cache
/dev/block/mmcblk0p5 128 ( 524288 bytes - 512kB) misc1?
/dev/block/mmcblk0p6 2560 ( 10485760 bytes - 10.0MB) -WTF?- "staging?"
/dev/block/mmcblk0p7 1280 ( 5242880 bytes - 5.0MB) mfg
/dev/block/mmcblk0p8 128 ( 524288 bytes - 512kB) misc2?
/dev/block/mmcblk0p9 ?? ( ?? bytes - ??MB) data
Note I didn't do my /data partition - I have a 32GB N7, so I suppose that means that /data is 30+ GB in size. Lazy and didn't want to wait.
---------- Post added at 01:40 PM ---------- Previous post was at 12:55 PM ----------
FYI,
shoving some TWRP backup images (system, boot) to my dropbox right now. Lightly-rooted stock. (Added su and SuperSu in /system, and altered default.prop in the boot image so that the secure flag is disabled and the adb daemon starts up straight away). Other than those changes, 100% stock, including kernel.
I'll send a PM when I figure out how Dropbox works.

bftb0 said:
Wait, I just realized: I have a 32GB WiFi N7 - is yours a 16GB?
Click to expand...
Click to collapse
Yes, I've got 16GB version.
bftb0 said:
I could shove a (near stock) boot.img and system.img backup from TWRP someplace, but the system image is huge. I don't have a convenient place to drop it - got any suggestions?
Click to expand...
Click to collapse
I can create ftp account on and send you login data in a private message. Will it be convenient for you?
bftb0 said:
Maybe it is time to try the read/write tests with the /data partition?
Click to expand...
Click to collapse
Yea, but ... now something really strange happened.
All partitions have disappeared. _I'm sure_ that I didn't zeroed the whole mmcblk0 device. Just the partition I mentioned before.
Code:
ls /dev/block
loop0 loop2 loop4 loop6 mmcblk0 mmcblk0bo
loop1 loop3 loop5 loop7 mmcblk0boot0 platform
fdisk -l /dev/block/mmcblk0
Disk /dev/block/mmcblk0: 15.7 GB, 15762194432 bytes
4 heads, 16 sectors/track, 481024 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
Disk /dev/block/mmcblk0 doesn't contain a valid partition table
TWRP still starts but it takes more time.
bftb0 said:
Actually, before you do that, what were the dump lengths you got for each of your partitions? Here are mine (using bs=4096):
Click to expand...
Click to collapse
I don't have partition table now so I it is useless. But for the future use, can you tell me please how I can see this kind of dump?
Edit: I'd be grateful if anyone having Nexus 7 16GB paste output of command:
Code:
adb shell /sbin/fdisk -l /dev/block/mmcblk0
I hope I will be able to create proper partitions on my device then.
But I'm afraid of using fdisk to create partitions because this can lead to destroy current recovery which still starts.

warpek said:
Yes, I've got 16GB version.
I can create ftp account on and send you login data in a private message. Will it be convenient for you?
Click to expand...
Click to collapse
or you could just attach it - should be less than the XDA attachment size limit, and as I mentioned there is no private info in there.
Looking at my own dumped images, it looks like this same partitioning information appears in mmcblk0boot0 190 times (!!), and in mmcblk0boot1 256 times (!!). I need to extract them all and compare checksums to see if they are identical.
warpek said:
Yea, but ... now something really strange happened.
All partitions have disappeared. _I'm sure_ that I didn't zeroed the whole mmcblk0 device. Just the partition I mentioned before.
Code:
ls /dev/block
loop0 loop2 loop4 loop6 mmcblk0 mmcblk0bo
loop1 loop3 loop5 loop7 mmcblk0boot0 platform
fdisk -l /dev/block/mmcblk0
Disk /dev/block/mmcblk0: 15.7 GB, 15762194432 bytes
4 heads, 16 sectors/track, 481024 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
Disk /dev/block/mmcblk0 doesn't contain a valid partition table
TWRP still starts but it takes more time.
I don't have partition table now so I it is useless. But for the future use, can you tell me please how I can see this kind of dump?
Click to expand...
Click to collapse
Holy ****.
(My info was just from collected from looking at the output of individual dd read commands on each partition)
Again, holy **** - that's a world of hurt. I suppose recovery might still be possible, but perhaps only with some exhaustive code review of how the mmc driver determines the partitioning. and possibly some very dangerous patching of areas in mmcblk0boot{0,1}. It does appear that partitioning information is stored redundantly in multiple places on the tablet.
I am wondering - if the partitioning information that the TWRP boot was somehow partially corrupted - then running "dd if=/dev/zero" to write without a "count=" size constraint might have caused an over-run past where the actual partition was supposed to live.
At this point, I wouldn't attempt any more writing operations - especially since TWRP doesn't know where anything lives any longer.
---------- Post added at 02:23 PM ---------- Previous post was at 02:16 PM ----------
For the purposes of rescue you might want to capture some dumps of mmcblk0boot0 and mmcblk0boot1
Since you can not mount the /sdcard to store the dumps temporarily, you should be able to stuff them into ramdisk temporarily and then pull them to your PC via adb in the same TWRP session:
C:\foo> adb shell
# mkdir /tmp/dumps
# dd if=/dev/block/mmcblk0boot0 bs=4096 of=/tmp/dumps/mmcblk0boot0.img
# dd if=/dev/block/mmcblk0boot1 bs=4096 of=/tmp/dumps/mmcblk0boot1.img
# exit
C:\foo> adb pull /tmp/dumps/
The worst that can happen here (if the partitioning for mmcblk0boot{0,1} is wrong - and huge - you'll wedge the TWRP session by filling memory.
Without committing to a lot of effort it looks like you are looking at RMA time.

bftb0 said:
I am wondering - if the partitioning information that the TWRP boot was somehow partially corrupted - then running "dd if=/dev/zero" to write without a "count=" size constraint might have caused an over-run past where the actual partition was supposed to live.
Click to expand...
Click to collapse
Yes, I suppose it could be the case.
bftb0 said:
For the purposes of rescue you might want to capture some dumps of mmcblk0boot0 and mmcblk0boot1
Click to expand...
Click to collapse
Done without problems.
bftb0 said:
Without committing to a lot of effort it looks like you are looking at RMA time.
Click to expand...
Click to collapse
[/QUOTE]
I don't want to bother you with too much digging, so maybe it's time to send my device back do the seller.
But before that ... I think I should wipe out TWRP.
Should I use dd on the whole mmcblk0 device to do that?
Nevertheless I'm really greateful for your time and efforts. Thank you very much.

warpek said:
Should I use dd on the whole mmcblk0 device to do that?
Click to expand...
Click to collapse
Hmmm. Dunno. At this point you might end up borking the bootloader trying something like that.
There have been other threads where folks reported returning devices without bothering to do any clean up - and without repercussions.
Seems believable; the folks that are tasked with repairing units under RMA are not approaching each one as if it were a forensic evaluation. From a pure business standpoint that would be a huge waste of time and money. If they ever get rewarded for anything they do, it's probably a throughput metric (devices repaired or scrapped per work shift). Your unit will be one of many.
Your thanks are welcome, but I have an interest in this anyway. I noticed in digging around that (rather bizarrely) there is a partition that TWRP identifies as "staging" (/dev/block/mmcblk0p6). The bizarre part of this is that a hexdump revealed a few strings that were unicode URLs for XDA's ad networks. !! ?? !!
That rather freaks me out - what the frick is user data (I suppose from web browsing?) doing in a partition that never gets mounted and is (apparently) not in any identify-able file system format?
Back when Amon_RA was packaging his recovery for various devices, he would use a STOCK KERNEL in the boot image for his recovery boot. That pretty much is a guarantee that the kernel drivers (e.g. for MTD/MMC) would behave no differently from the way the device manufacturer does things - including for important things like interpreting partition tables.
With TWRP and CWM we currently have no such assurances that subtle bugs have not crept in to important places unless we repackage their boot images to use stock kernels.
Anyway, I am trying to review what I *think* is partitioning information to see what I can figure out - but you probably shouldn't wait for me.
Good luck with your return.

I don't want to bother you with too much digging, so maybe it's time to send my device back do the seller.
But before that ... I think I should wipe out TWRP.
Should I use dd on the whole mmcblk0 device to do that?
Click to expand...
Click to collapse
Hi warpek, I don't mean to butt in to this thread but I encountered a similar issue to yours this past weekend that's gotten to the point where I can no longer turn on nor get into the bootloader anymore. My question is since our devices have been modified, do you know if there is there any chance that Asus could deny and void the warranty upon finding that out?
There have been other threads where folks reported returning devices without bothering to do any clean up - and without repercussions.
Click to expand...
Click to collapse
Alright guess I'll go give it a shot.

Hi fungosaurus,
For the benefit of the rest of the N7 community - could you say a few words about what ROM/kernel was on your tablet, and (if you know) about what the charge state of the battery was like when the first hint of problem occurred?
A few reports don't mean anything conclusive, but it sure is starting to look like something is going on with "low battery" / "can't turn on" syndromes ... which then unfold into full-blown disasters.

bftb0 said:
Hi fungosaurus,
For the benefit of the rest of the N7 community - could you say a few words about what ROM/kernel was on your tablet, and (if you know) about what the charge state of the battery was like when the first hint of problem occurred?
A few reports don't mean anything conclusive, but it sure is starting to look like something is going on with "low battery" / "can't turn on" syndromes ... which then unfold into full-blown disasters.
Click to expand...
Click to collapse
Oh yes of course. CM10.1 Jan 10 nightly with whichever kernel it came with. As far as I could tell the battery was fully charged when I could no longer power it back on or access the bootloader.
My issue was actually a bit complicated and I might've actually been the one to worsen it through my ignorance. I made a post on Reddit that describes in detail what happened. Does this help?

fungosaurus said:
Does this help?
Click to expand...
Click to collapse
Only time will tell - for instance if lots of folks start reporting troubles with the same kernel.
Sounds more like a hardware problem though. Thanks for the info.
I think I saw a recent news article stating that Asus is shipping about 1 million N7's per month now. If they have shipped 5 million cumulatively, and they have a defect rate of only 0.1% in the first year of service, that would be 5000 owners who might end up on message boards looking for help. Although - since rooters are presumably a small fraction of owners - I guess we should see a much smaller number of folks who are rooted AND experience hardware troubles.
@warpek - the data stored in the misc1/misc2 partitions does in fact appear to be partitioning data. But I don't think you can use "fdisk" for the mmcblk0 device in any event.

bftb0 said:
Hmmm. Dunno. At this point you might end up borking the bootloader trying something like that.
There have been other threads where folks reported returning devices without bothering to do any clean up - and without repercussions.
Click to expand...
Click to collapse
Yes, but to be sure that I won't have any problems while returning my device I zeroed the whole block device.
bftb0 said:
Your thanks are welcome, but I have an interest in this anyway. I noticed in digging around that (rather bizarrely) there is a partition that TWRP identifies as "staging" (/dev/block/mmcblk0p6). The bizarre part of this is that a hexdump revealed a few strings that were unicode URLs for XDA's ad networks. !! ?? !!
Click to expand...
Click to collapse
That is really astounding. Please let us now if you have any conclusions.
Meanwhile I'm sending my nexus to Asus.
Thanks again.

fungosaurus said:
My question is since our devices have been modified, do you know if there is there any chance that Asus could deny and void the warranty upon finding that out?
Click to expand...
Click to collapse
As bftb0 said it shouldn't be any problems but to be sure I zeroed the whole block device area before returning it back.

Related

[RAM] S2 Partitioning of RAM

I run a pure ICS ROM, with all the Samsung apps and addons removed.
But I still have a 500Mb partition mounted under "/preload". Samsung stuff.
This renders 500Mb of RAM useless since the "pure" ICS does not store anything there. This could be used for /data instead.
Now, can anyone point me to a .pit file I can use that does not have that partition included, or better still, how do I edit or create my own .pit file. I tried fdisk but with no luck.
[email protected]:/ # df -kh
Filesystem Size Used Available Use% Mounted on
tmpfs 415.3M 32.0K 415.3M 0% /dev
tmpfs 415.3M 0 415.3M 0% /mnt/asec
tmpfs 415.3M 0 415.3M 0% /mnt/obb
/dev/block/mmcblk0p9 503.9M 282.1M 221.8M 56% /system
/dev/block/mmcblk0p7 98.4M 4.1M 94.4M 4% /cache
/dev/block/mmcblk0p1 19.7M 8.2M 11.5M 42% /efs
/dev/block/mmcblk0p10 2.0G 368.6M 1.6G 18% /data
/dev/block/mmcblk0p12 503.9M 8.4M 495.6M 2% /preload
You shouldn't be trying to mess with PIT. Believe me.
Also, you misspelled Storage. That's not RAM.
Sent from my GT-I9100 using XDA App
Sorry, storage ofcourse.
My basic plan was to just backup /data, remove the /preload & /data partition and recreate /data with a size of 2.5Gb. But nooo... fdisk does not want me to do this.
Been using Linux for 15 years so I thought that would work.
Are there no recoveries with partitioning tools out there? Like CWM but not only with sdcard-partitioning.
This kind of worries me too, it seldom is good... fdisk output:
The number of cylinders for this disk is set to 1923584.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): p
Disk /dev/block/mmcblk0: 15.7 GB, 15758000128 bytes
1 heads, 16 sectors/track, 1923584 cylinders
Units = cylinders of 16 * 512 = 8192 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 1 1923456 15387647+ ee EFI GPT
Partition 1 does not end on cylinder boundary
Command (m for help): v
Partition 1 does not end on cylinder boundary
Partition 1: sector 0 greater than maximum 16
2048 unallocated sectors
Command (m for help):
Let me explain it straight : Bootloader and PIT are tightly linked together. PIT is set by samsung and mapped directly to the bootloader initialization. If you bork the PIT, the bootloader is borked too, leading to device not booting at all (even in download mode).
Just leave that partition alone and enjoy your phone. You certainly won't even use those 500MB.
And by the way, a phone's storage partitionning is not a hard drive. You don't just fdisk like on a computer.
bodhisattva99 said:
Sorry, storage ofcourse.
My basic plan was to just backup /data, remove the /preload & /data partition and recreate /data with a size of 2.5Gb. But nooo... fdisk does not want me to do this.
Been using Linux for 15 years so I thought that would work.
Are there no recoveries with partitioning tools out there? Like CWM but not only with sdcard-partitioning.
This kind of worries me too, it seldom is good... fdisk output:
The number of cylinders for this disk is set to 1923584.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): p
Disk /dev/block/mmcblk0: 15.7 GB, 15758000128 bytes
1 heads, 16 sectors/track, 1923584 cylinders
Units = cylinders of 16 * 512 = 8192 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 1 1923456 15387647+ ee EFI GPT
Partition 1 does not end on cylinder boundary
Command (m for help): v
Partition 1 does not end on cylinder boundary
Partition 1: sector 0 greater than maximum 16
2048 unallocated sectors
Command (m for help):
Click to expand...
Click to collapse
If it were that easy, someone would have done it already. I suggest just symlinking the partition to a folder if you really want to use the extra space... If you're adventurous, find a way of using it for Dalvik.
XpLoDWilD said:
Let me explain it straight : Bootloader and PIT are tightly linked together. PIT is set by samsung and mapped directly to the bootloader initialization. If you bork the PIT, the bootloader is borked too, leading to device not booting at all (even in download mode).
Just leave that partition alone and enjoy your phone. You certainly won't even use those 500MB.
And by the way, a phone's storage partitionning is not a hard drive. You don't just fdisk like on a computer.
Click to expand...
Click to collapse
Thanks for a great answer. Case closed I guess.
I moved dalvik there by soft linking it and so far everything seems to work fine.
After a reboot the filesystem is mountrd RO. Not quite sure where to change that. Something like /etc/fstab.... Anyone?
EDIT: Found it, init.rc....
OK, next dumb question, as the init.rc gets overwritten on reboot, where is the original?
bodhisattva99 said:
OK, next dumb question, as the init.rc gets overwritten on reboot, where is the original?
Click to expand...
Click to collapse
I believe it's in initramfs packed with the kernel.
oinkylicious said:
I believe it's in initramfs packed with the kernel.
Click to expand...
Click to collapse
OK, that sucks since I cannot recompile it.
I solved it by a script in /system/etc/init.d/ , its an ugly 5-minuter but it does the job.
Works on every reboot, if the dalvik is already moved nothing happens, I just get some stderr. Takes a few seconds the first time.
Will extend tomorrow if a "wipe dalvik-cache" is done from recovery. It wont handle that right now.
----- script -----
mount /preload -o remount,rw,nosuid,nodev,noatime,noauto_da_alloc
chmod 0771 /preload
mv /data/dalvik-cache /preload/
ln -s /preload/dalvik-cache /data/dalvik-cache
----- script -----
Ahh, no more wasted space!
bodhisattva99 said:
OK, that sucks since I cannot recompile it.
Click to expand...
Click to collapse
Sure you can, it's pretty straightforward. [GUIDE]Unpack/Repack initramfs in zImage (i9100)
XpLoDWilD said:
You shouldn't be trying to mess with PIT. Believe me.
Also, you misspelled Storage. That's not RAM.
Sent from my GT-I9100 using XDA App
Click to expand...
Click to collapse
You can tell people this multiple times mate but they tend not to listen until one day you see a post: "Halp, ma fone.. it b0rk"
oinkylicious said:
Sure you can, it's pretty straightforward. [GUIDE]Unpack/Repack initramfs in zImage (i9100)
Click to expand...
Click to collapse
Many thanks! Some play for to tomorrow then.
Intratech said:
You can tell people this multiple times mate but they tend not to listen until one day you see a post: "Halp, ma fone.. it b0rk"
Click to expand...
Click to collapse
OK, OK, I got the message...
Sorry wasn't directed at you... was just a general statement.
Intratech said:
Sorry wasn't directed at you... was just a general statement.
Click to expand...
Click to collapse
No prob, better than I learn it the hard way...
You boy have a heart of a Jedi. Full respect. Hopefully no one will cry like an Ewok soon
Sent from my GT-I9100 using xda premium
Sorry for all the stupid questions but I only had the S2 for three days.
OK, here goes... nothing...
Seems to repack fine. Lets just hope I did the scripting OK.
Will upload once I've tried it out myself...
[email protected] ~/work/android/initramfs-tools $ ./repack boot.img initramfs-bodhisattva99_v1.0.cpio
---------------------------kernel repacker for i9100---------------------------
Extracting gzip'd kernel from boot.img (start = 17972)
CPIO compression type detected = gzip | offset = 193180
CPIO image MAX size:1921884
Head count:2115064
Making head.img ( from 0 ~ 193180 )
Making a tail.img ( from 2115064 ~ 10031364 )
Current ramdsize using cat : 3272192 with required size : 1921884 bytes
Current ramdsize using gzip -f9 : 1916756 with required size : 1921884 bytes
gzip -f9 accepted!
Merging [head+ramdisk] + padding + tail
Now we are rebuilding the zImage
Image ---> piggy.gzip
piggy.gzip ---> piggy.gzip.o
Compiling head.o
Compiling misc.o
Compiling decompress.o
Compiling lib1funcs.o
Create vmlinux.lds
head.o + misc.o + piggy.gzip.o + decompress.o + lib1funcs.o---> vmlinux
vmlinux ---> zImage
New zImage size:5740672
Padding new zImage to 8388608 bytes
Padding sufiles to new_zImage
new_zImage has been created
Cleaning up...
finished...
Haha... lets try it!
Well,all this is nice and you have my respect for being fearless with these matters,but some months ago there was another interesting idea for the proper use of the hidden partition.A hidden porn stash.Works like a charm.
I don't remember who proposed that,but kudos to him.
OK, can someone explain to me how to build a CWM flashable .zip with the new zImage?
Been searching forum for 2 hours and I can only find how to build application zips, not kernel...
It should also prefferably have a script in it that runs the following after updating the kernel/boot.img
rm -rf /data/dalvik-cache
ln -s /preload/dalvik-cache /data/dalvik-cache
bodhisattva99 said:
OK, can someone explain to me how to build a CWM flashable .zip with the new zImage?
Been searching forum for 2 hours and I can only find how to build application zips, not kernel...
It should also prefferably have a script in it that runs the following after updating the kernel/boot.img
rm -rf /data/dalvik-cache
ln -s /preload/dalvik-cache /data/dalvik-cache
Click to expand...
Click to collapse
Flash with mobile odin
Sent from my GT-I9100 on CM9 using Tapatalk

[Q] Semi-soft hard non-brick - just looking for ideas

Anyway, I was using Miui V3 2.4.20 [2.6.35], and Google maps wasn't very happy with it. So I decided it was time to move on to the .32 kernal version, since the developer was going that way too. Downloaded a stock rom with .32 kernal, went to the pink screen and flashed, and then boot loop.
Luckily, I'm awesome, so my phone won't die on me. Tried flashing some roms through clockwork, no bootloop, just stuck at huawei logo. Tried flashing some stock roms, and at about 98% done flashing it goes error. Some parts get flashed causing my recovery reverts to stock, but I'm still stuck at the huawei logo.
Also, in clockworkmod I get errors mounting data and emmc, so that might be a problem. Other partitions mount fine.
I'm sure I'll find a solution eventually, so there's no rush. I've been in similar situations before. Just wanted to see what other people had used for similar situations. So if you know of something that would help, please let me know.
Found these through search (I'll do a better search again later), i will try them tomorrow:
http://forum.xda-developers.com/showpost.php?p=18944228&postcount=4
http://forum.xda-developers.com/showthread.php?t=1683249
http://forum.xda-developers.com/showthread.php?t=1689469
http://forum.xda-developers.com/showthread.php?t=1682501
http://forum.xda-developers.com/showthread.php?t=1011527
After reading a lot of threads, attempting to flash a lot of roms (stock and others), replacing all kinds of images, and offering a sacrifice to the cellphone gods, still at the same problem:
To reiterate problem:
1) Stuck/reboots at Huawei logo
2) Flashing stock roms via pink screen never finish installing, get error message at ~95% finished (During install, unpacks fine)
3) Flashing roms via recovery say they installed, but still boot problem
4) This problem occurred while trying to downgrade from .35 to .32
My next step is to try using Linux to put the Dload folder on the internal SD card and try installing from there. I have a feeling it is related to the partitions having problems. I used both the "get back pink screen" and "data partition resize," maybe something went wrong with them that only appeared when I tried to go back to stock. I'll find out more when I install linux and can see if the partitions are OK or not.
I've always wanted to try linux, and now that my phone is broke I have found the motivation to do so. So a word of advice for people for people wanting to try linux but are too lazy to download the linux file: Soft-brick your phone, it gives you motivation.
UPDATE: I'm pretty sure my partition table is broke pretty bad. In adb shell, df gives me:
Filesystem Size Used Free
/dev 173M 64K 172M
/system 203M 200M 2M
/cache 127M 4M 123M
and that's it. No /HWUserData, /.cust_backup, /mnt/asec, /mnt/obb, or /data.
Would someone be as kind as to tell me how to fix the partition table? I've got a soldering iron, duct tape and super glue. Also, I'm not afraid to buy a "box" to do some Jtag stuff.
Anybody know what Blefish uses to format the phone memory? I read on his tumbler page and his github that he has altered the partition table (he split the /hwuserdata into three sections, which means he has the ability to create partitions) If I can get that tool, then I have a plan:
0) If my understanding is correct, the updates don't install because the needed partitions are missing, which causes an error. I guess the updates won't create partitions, just alter them.
1) Use the tool blefish used to setup the partition table as described in this thread: http://forum.xda-developers.com/showthread.php?t=1504488
2) Once the partitions are back, i should at least be able to get the blue screen, if I'm good, then I can put all right files in /dev/sdb1, which will get me the pink screen.
3) Using the blue/pink screen, I can install stock firmware, which should correct any problems that the partition table has. Maybe even install android.
4) Do the happy dance
5) ???
6) Profit
I've done my homework, searched the forums, made a plan, and cleaned my room. Someone please give me some feedback and at least let me know if I'm heading in the right direction.
typci said:
Anybody know what Blefish uses to format the phone memory?
Click to expand...
Click to collapse
I am using fdisk, the main partitioning tool for MBR table. You can check the table by doing fdisk /dev/block/mmcblk0 and then "p" which should print the current partition table. From there, you can also modify the partitions.
Sent from my U8800 using Tapatalk 2
Blefish said:
I am using fdisk, the main partitioning tool for MBR table. You can check the table by doing fdisk /dev/block/mmcblk0 and then "p" which should print the current partition table. From there, you can also modify the partitions.
Sent from my U8800 using Tapatalk 2
Click to expand...
Click to collapse
Awesome. I used to use fdisk back in the dos days, so I just need to brush up on my skills and learn the adb specifics. I really need to take the time to go learn all the commands associated with adb.
INTERESTING UPDATE: If I flash a rom with locked boot loader, I still get the pink screen but it doesn't work, i.e. I can't access the image folder via windows. If I flash a rom without a locked boot loader, pink screen works. Granted none of these roms actually fully flash, I still get the error near the end.
Fdisk = Permission denied, su = permission denied. Rooted boot image prevents me from getting into recovery, which means adb won't work. Any other way to get root? I'll try flashing a custom rom when I can get clockworkmod working again. For some reason I can't get recovery to load via vol+ & power.
Also something weird is going on. When it boots, it reboots once, then goes to stock recovery, tries to do a factory reset, gets errors on formating. Also in windows two removable disks appear, but I can access them. I take it that they represent the internal SD card and maybe the pink screen image folder partition. Tomorrow I'll try linux and see what happens.
UPDATE:
1) I can't use FDISK because SU won't work. I'm not sure how SU/root works on a software/partition bricked phone.
2) Rooted boot.img won't boot into recovery. SuperOneClick won't work because it can't find the data partition (probably because I don't have one).
3) I was going to try flashing a custom rom but for some reason I can't get clockworkmod working again. The phone will boot into stock recovery on it's own, after a couple of reboots. However, if I change the boot.img or recovery.img to anything else, it gets stuck at huawei logo or boot loop.
4) Unbuntu LiveCD won't work (says it can't find the kernal) even though I used the installer from the website and tried it both via cd and flash drive. Working on installing a dual-boot system now.
I'm really striking out here. Couple of questions if anyone would care to answer.
1) Besides recovery, how else can I establish an adb connection? Pink screen and huawei logo give me device not found.
2) Is there a root exploit available that doesn't require a data partition or is there a root exploit I can modify so it doesn't require a data partition? It's OK if it's a manual exploit, while I'm new with android/adb, I got plenty of experience with command prompt input from back in the dos days.
Also learned there is a HuaWei office in my town. Don't know what they do there, but if I don't make any progress after I couple more days, I'll go find out.
typci said:
UPDATE:
1) I can't use FDISK because SU won't work. I'm not sure how SU/root works on a software/partition bricked phone.
2) Rooted boot.img won't boot into recovery. SuperOneClick won't work because it can't find the data partition (probably because I don't have one).
3) I was going to try flashing a custom rom but for some reason I can't get clockworkmod working again. The phone will boot into stock recovery on it's own, after a couple of reboots. However, if I change the boot.img or recovery.img to anything else, it gets stuck at huawei logo or boot loop.
4) Unbuntu LiveCD won't work (says it can't find the kernal) even though I used the installer from the website and tried it both via cd and flash drive. Working on installing a dual-boot system now.
I'm really striking out here. Couple of questions if anyone would care to answer.
1) Besides recovery, how else can I establish an adb connection? Pink screen and huawei logo give me device not found.
2) Is there a root exploit available that doesn't require a data partition or is there a root exploit I can modify so it doesn't require a data partition? It's OK if it's a manual exploit, while I'm new with android/adb, I got plenty of experience with command prompt input from back in the dos days.
Also learned there is a HuaWei office in my town. Don't know what they do there, but if I don't make any progress after I couple more days, I'll go find out.
Click to expand...
Click to collapse
On pink screen, your device is just like any other mass storage device. So you can still use fdisk on ubuntu with the correct /dev/sdX path. You can also format the data/system/cache using other tools if you need to.
Sent from my U8800 using Tapatalk 2
Sweet, so I just need to get Unbuntu working. I still can't figure out why the live CD/flash drive didn't work. Oh, well. When I get off of work I'll get to installing the dual-boot system. Thanks for your help.
typci said:
Sweet, so I just need to get Unbuntu working. I still can't figure out why the live CD/flash drive didn't work. Oh, well. When I get off of work I'll get to installing the dual-boot system. Thanks for your help.
Click to expand...
Click to collapse
i actually understood nothing from your posts but i would like to congratulate you for being a user who does research before asking ppl something
and I gladly give you a bump
JaymzBond said:
i actually understood nothing from your posts but i would like to congratulate you for being a user who does research before asking ppl something
and I gladly give you a bump
Click to expand...
Click to collapse
Thanks. Unfortunately the project is on hold for a couple of days. My electric motorcycle has been having some problems and I've been repairing it. Also, I think I found out why linux wasn't working. Apparently the "alternative" downloads aren't useable as a live CD, which is why the kernal wasn't there. Anyway, it's been a great learning experience. Maybe after I "break" my phone enough times I'll learn enough to become a developer.
Doing some research before getting back to working on the phone.
Looks like Blefish is talking about using linux's fdisk, when I was trying to use adb's fdisk. That would certainly allow me to bypass the su problem with adb. I think I got all the correct files for my linux livecd, so that shouldn't be a problem. After I'm done with my workout, I'll try it out and see how it goes. It's time to learn how to use linux.
Update: Got unbuntu working. Storage devices are all /media instead of /dev like I was expecting. But I think I'm not looking in the right place.
Plugged in phone via pink screen and 3 drives came up:
System - has system stupp (app, bin, etc, fonts, ...) - sdb12
256 MB File system - image folder with all the .img and .mbn files - sdb1
136 MB File system - has fotapkg, lost+found, recovery folders- filesystem type ext3/ext4 - I'm not sure what this is, maybe sdb6? If it was data (sdb13) then I wouldn't get the error in recovery, If it was the internal SD card the filesystem should be vfat. If someone knows better, please let me know.
For some reason I don't have permission to access the lost+found folder, or so Unbuntu tells me.
Tried to used fdisk with system, got error: I don't know how to handle files with mode 40755
Also found some recovery log files in the fotapkg and recovery folders. I'll post it here incase someone can get some more useful information out of it. Does anyone know what all these (null) mean?
Tomorrow I'll get to work on learning how to use unbuntu and fdisk.
Starting recovery on Sun Jan 6 00:03:50 1980
can't open /dev/tty0: No such file or directory
framebuffer: fd 3 (480 x 800)
recovery filesystem table
=========================
0 /tmp ramdisk (null) (null)
1 /boot vfat /dev/block/mmcblk0p1 (null)
2 /fat vfat /dev/block/mmcblk0p1 (null)
3 /cache ext4 /dev/block/mmcblk0p6 (null)
4 /data_pseudo ext4 /dev/block/mmcblk0p13 (null)
5 /misc emmc /dev/block/mmcblk0p7 (null)
6 /recovery vfat /dev/block/mmcblk0p1 (null)
7 /HWUserData vfat /dev/block/mmcblk0p14 (null)
8 /system ext4 /dev/block/mmcblk0p12 (null)
9 /sdcard vfat /dev/block/mmcblk1p1 /dev/block/mmcblk1
I:cmdline: console=ttyDCC0 androidboot.hardware=huawei androidboot.localproppath=hw/default androidboot.emmc=true androidboot.image=recovery androidboot.mode=user androidboot.baseband=msm
Ita_move_command_file
I:Got arguments from boot message
Command: "recovery" "--wipe_data" "--wipe_cache"
Formatting /cache...
Creating filesystem with parameters:
Size: 136314880
Block size: 4096
Blocks per group: 32768
Inodes per group: 4160
Inode size: 256
Journal blocks: 1024
Label:
Blocks: 33280
Block groups: 2
Reserved block group size: 15
Created filesystem with 11/8320 inodes and 1585/33280 blocks
E:failed to mount /data_pseudo (No such file or directory)
E:failed to mount /data_pseudo (No such file or directory)
Formatting /data...
Need size of filesystem
E:format_volume: make_extf4fs failed on /dev/block/mmcblk0p13
E:failed to mount /data_pseudo (No such file or directory)
E:failed to mount /data_pseudo (No such file or directory)
Formatting /cache...
Creating filesystem with parameters:
Size: 136314880
Block size: 4096
Blocks per group: 32768
Inodes per group: 4160
Inode size: 256
Journal blocks: 1024
Label:
Blocks: 33280
Block groups: 2
Reserved block group size: 15
Created filesystem with 11/8320 inodes and 1585/33280 blocks
Data wipe failed.
wipe internal sdcard fail.
It could be that the data partition (originally mmcblk0p13) got wiped out and now mmcblk0p13 is internal sd card. Here's the original partition table:
Code:
Disk /dev/block/mmcblk0: 3959 MB, 3959422976 bytes
1 heads, 16 sectors/track, 483328 cylinders
Units = cylinders of 16 * 512 = 8192 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 1 30721 245760 b Win95 FAT32 CUST
Partition 1 does not end on cylinder boundary
/dev/block/mmcblk0p2 * 30721 30783 500 4d Unknown SBL1
Partition 2 does not end on cylinder boundary
/dev/block/mmcblk0p3 30783 31158 3000 46 Unknown TZ
Partition 3 does not end on cylinder boundary
/dev/block/mmcblk0p4 31158 483328 3617363+ 5 Extended EBR
Partition 4 does not end on cylinder boundary
/dev/block/mmcblk0p5 32769 34304 12288 59 Unknown OEMINFO/BOOTLOADER IMAGES
/dev/block/mmcblk0p6 40961 57600 133120 4c Unknown CACHE
/dev/block/mmcblk0p7 65537 65599 500 5a Unknown MISC
/dev/block/mmcblk0p8 73729 74112 3072 58 Unknown FSG?
/dev/block/mmcblk0p9 81921 82795 7000 50 Unknown ADSP
/dev/block/mmcblk0p10 90113 90496 3072 4a Unknown MODEM_ST1
/dev/block/mmcblk0p11 98305 98688 3072 4b Unknown MODEM_ST2
/dev/block/mmcblk0p12 106497 134656 225280 83 Linux SYSTEM
/dev/block/mmcblk0p13 139265 216064 614400 83 Linux USERDATA
/dev/block/mmcblk0p14 221185 483328 2097152 69 Unknown INTERNAL_SD
The sdb6 is indeed cache, and it is used for recovery communication between Android.
If everything would be ok, it would mount sdb1, sdb6, sdb12, sdb13 and sdb14 inside Ubuntu, so it seems that something is wrong at the end.
If you have 14 partitions, use disk utility from Ubuntu and try manually formatting the 13 for ext4 and 14 for vfat. Taking ownership is not needed, it should work either way.
Blefish, thanks for the help. Got unbuntu up and working along with fdisk and identified the phone.
I have 13 partitions (including one empty one) , not 14. Here's the print out:
[email protected]:~$ sudo fdisk /dev/sde
omitting empty partition (13)
Command (m for help): p
Disk /dev/sde: 3959 MB, 3959422976 bytes
1 heads, 62 sectors/track, 124729 cylinders, total 7733248 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sde1 1 491520 245760 b W95 FAT32
/dev/sde2 * 491521 492520 500 4d QNX4.x
/dev/sde3 492521 498520 3000 46 Unknown
/dev/sde4 498521 7733247 3617363+ 5 Extended
/dev/sde5 524288 548863 12288 59 Unknown
/dev/sde6 655360 921599 133120 4c Unknown
/dev/sde7 1048576 1049575 500 5a Unknown
/dev/sde8 1179648 1185791 3072 58 Unknown
/dev/sde9 1310720 1324719 7000 50 OnTrack DM
/dev/sde10 1441792 1447935 3072 4a Unknown
/dev/sde11 1572864 1579007 3072 4b Unknown
/dev/sde12 1703936 2154495 225280 83 Linux
Comparing with your partition table I see two differences:
1) the ending block of sde1 is 491520 on mine and on the original it is 30721, however the blocks are the same, so that is probably not a problem
2) sde13 is empty, and sde14 is missing.
This actually makes sense. When I was using MIUI, I reduced the size of the internal sd to near zero, since MIUI could only either the internal or external sd, not both. After trying to downgrade, I had a problem, so I tried to restore the internal sd card back to stock size, just to bring my phone back to stock. Something must have gone when I did that.
So if I understand the problem correctly, to fix this I need to:
1) Split sde13 into 2 partitions
2) Format sde13 to ext4 and sde14 to vfat
3) Try installing adroid again
Do I need to name the partitions a certain name or do anything else?
In the mean time I'll be looking into how to use disk utility and fdisk to deal with sde13 and sde14.
Had an idea that I only need sde13 (data) to get things working again, the system shouldn't need sde14 (internal sd) to work.
So I went to disk utility, found Qualcomm MMC storage and tried to format the free 2.9GB at the end. Got an error:
Error creating partition: helper exited with exit code 1: In part_add_partition: device_file=/dev/sde, start=1103101952, size=2856000000, type=0x83
Entering MS-DOS parser (offset=0, size=3959422976)
MSDOS_MAGIC found
looking at part 0 (offset 512, size 251658240, type 0x0b)
new part entry
looking at part 1 (offset 251658752, size 512000, type 0x4d)
new part entry
looking at part 2 (offset 252170752, size 3072000, type 0x46)
new part entry
looking at part 3 (offset 255242752, size 3704180224, type 0x05)
Entering MS-DOS extended parser (offset=255242752, size=3704180224)
readfrom = 255242752
MSDOS_MAGIC found
readfrom = 255243264
MSDOS_MAGIC found
readfrom = 255243776
MSDOS_MAGIC found
readfrom = 255244288
MSDOS_MAGIC found
readfrom = 255244800
MSDOS_MAGIC found
readfrom = 255245312
MSDOS_MAGIC found
readfrom = 255245824
MSDOS_MAGIC found
readfrom = 255246336
MSDOS_MAGIC found
readfrom = 1140842496
No MSDOS_MAGIC found
Exiting MS-DOS extended parser
Exiting MS-DOS parser
MSDOS partition table detected
containing partition table scheme = 1
got it
Error: Invalid partition table on /dev/sde -- wrong signature 0.
ped_disk_new() failed
So, my partition table is corrupt? I'll need to figure out how to fix this.
Here's some options I've found:
http://forum.xda-developers.com/showpost.php?p=21572216&postcount=12
ksatta mentions a couple of ideas:
1) If someone backed up their phone using dd, I could use that to restore my phone.
Here's a link on how to do it: http://linuxpoison.blogspot.com/2009/04/creating-backuprestore-images-using-dd.html
dd if=/dev/sdX | gzip > /home/sdX.bin.gz
where sdX is the U8800
2) I could clone someone's partition table. If someone could give me a copy of their MBR that should work.
Here's a link on how to do it: http://embraceubuntu.com/2005/10/20/backing-up-the-mbr/
Create a backup of your MBR by doing a:
dd if=/dev/sdX of=MBR-backup bs=512 count=1
That should read “create a disk dump of the input file, which is /dev/sdx (change to hda, or hdb or sda, depending on where the MBR is on your computer), and save it in the output-file MBR-backup in the directory from where the command is issued. Backup the first sector only, while you are at it”.
3) gparted - it's some kind of partition tool. Might be able to use it to fix the error. Not sure how to use it though.
For now I'm going to look into gparted for Ubuntu. If someone can help me out with a dd backup or cloning the partition table that would be awesome.
UPDATE: For people following this thread, and to keep me more organized, I'll start adding more of the important resources I find. They may one day help you fix your phone.
https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/434463
Seems a guy fixed his the same error with gparted. However it wasn't on a phone. Also I'm seem a lot of people refer to sfdisk. I'll need to learn more about it.
https://answers.launchpad.net/ubuntu/+question/113539
"I got an answer in a forum, which looks easy.
Do a
sudo fdisk /dev/sda
then type
w
to write partition table, without any modification of it.
The signature should be fixed."
Is this safe to do to my phone? I know I'll have to write the MBR eventually, but I have to get it right the first time. If I screw up, I may not be able to connect to ubuntu anymore. Anyway, the guy said it fixed the error with his harddrive, so it's worth a try.
http://www.thegeekstuff.com/2010/09/linux-fdisk/
How to use fdisk, in case anyone needs to know
So my new plan is to:
1) dd Backup and MBR backup - in case I break it worse than it is
2) try to fix with fdisk w or gparted
I think the change in start and end is caused by Ubuntu using cylinders/sectors/blocks. Should not too much difference though.
Using MBR restore would not work here, as it restores the main 4 partitions list. MBR uses EBR aswell, which is located at the beginning of every extended partition. So we would have to copy the EBR of every partition.
I'd suggest deleting sde13, adding sde13 and sde14.
When adding sde13, note that starting block should be at the end of sde12, so simply insert last block of sde12 there. If it gives error, simply press enter as it automatically finds free block after the last one. End block could be for example +500M so fdisk automatically finds the correct end block. Do the same for sde14, but note the start block again. sde14 end block should be the last block there is on the card.
After you've done that, do w to write and if it tells you to restart or something, unplug the phone, take out the battery and restart to pink screen again. Then try to use disk utility again or gparted (have not tested this) to reformat sde13 and sde14 to ext4 and vfat.
You should be safe until you don't mess with the primary partitions, especially the mmcblk0p2 and mmcblk0p3.
Thanks again for the reply, Blefish. I may have just fixed it. I'll know soon enough.
I did two things:
1) sudo fdisk /dev/sde12 followed by w
2) sudo fdisk /dev/sde followed by w
After that it enabled me to add the 13 and 14 partition. I used disk utility so I didn't have to worry about the blocks. Afterwards they mounted in ubuntu like they should.
UPDATE: Not quite fixed, but the rom installed without error. So I think the partition problem is fixed.
Now I just have a boot loop. I'll go back to ubuntu, clear the cache, and try installing from the internal sdcard
2nd UPDATE: Stock recovery gives and error about mounting the cache partition. However CWM mounts it fine. My partition problems may not be over.
3rd UPDATE: genokolar's "Custom you partition" file to return to stock file deletes my partition 13 and 14. Had 13 and 14 back working, used the file as per instructions, afterwards ubuntu drive utililty shows 13 and 14 as "free." So that is where part of my problem comes from.
4th UPDATE: Fixed the problem with stock recovery. Turns out froyo doesn't like ext4 partitions. Changed cache partition to ext3, no more error.
Here are some exerts from the CMW log when I tried to flash cyanongen. Can anyone tell me if any of these errors are problems, and if they are what they mean?
W:Unable to get recovery.fstab info for /datadata during fstab generation!
W:Unable to get recovery.fstab info for /sd-ext during fstab generation!
I:Checking for extendedcommand...
I:Skipping execution of extendedcommand, file not found...
failed to open /sys/class/android_usb/android0/state: No such file or directory
-- Installing: /sdcard/CM7-070512.zip
Finding update package...
I:Update location: /sdcard/CM7-070512.zip
Opening update package...
Installing update...
unmount of /system failed; no such volume
package_extract_file: no backup_initd.sh in package
set_perm: chown of /tmp/backup_initd.sh to 0 0 failed: No such file or directory
set_perm: chmod of /tmp/backup_initd.sh to 777 failed: No such file or directory
about to run program [/tmp/backup_initd.sh] with 2 args
run_program: execv failed: No such file or directory
run_program: child exited with status 1
Pass 5: Checking group summary information
/dev/block/mmcblk0p12: 11/56448 files (0.0% non-contiguous), 7142/225280 blocks
mount: failed to mount /dev/block/mmcblk0p12 at /system: Invalid argument
set_perm: chown of 0750 to 0 2000 failed: No such file or directory
set_perm: chmod of 0750 to 755 failed: No such file or directory
set_perm: chown of /system/etc/init.qcom.post_boot.sh to 0 2000 failed: No such file or directory
set_perm: chmod of /system/etc/init.qcom.post_boot.sh to 555 failed: No such file or directory
set_perm: chown of /system/xbin/apply_firewall to 0 0 failed: No such file or directory
set_perm: chmod of /system/xbin/apply_firewall to 6755 failed: No such file or directory
set_perm: chown of /system/xbin/apply_theme to 0 0 failed: No such file or directory
set_perm: chmod of /system/xbin/apply_theme to 6755 failed: No such file or directory
set_perm: chown of /system/xbin/dumplog to 0 0 failed: No such file or directory
set_perm: chmod of /system/xbin/dumplog to 6755 failed: No such file or directory
set_perm: chown of /system/xbin/mv2sd to 0 0 failed: No such file or directory
set_perm: chmod of /system/xbin/mv2sd to 6755 failed: No such file or directory
set_perm: chown of /system/xbin/ota to 0 0 failed: No such file or directory
set_perm: chmod of /system/xbin/ota to 6755 failed: No such file or directory
Updating BOOT Image...
about to run program [/tmp/backup_initd.sh] with 2 args
run_program: execv failed: No such file or directory
run_program: child exited with status 1
Installation complete!script result was [Installation complete!]
Install from sdcard complete.
failed to open /sys/class/android_usb/android0/state: No such file or directory
My phone is fixed. I have no idea how it became fixed, but it is fixed.
I placed b518 on the internal sd card, and installed it. Then bootloop. So I held both volume keys+power to try another rom. It installed again. Went to recovery, it did a factory reset. Bootloop. Went back to recovery to see if I could wipe the sd card. No option for it, so I did another factory reset and rebooted my phone. I left my phone bootlooping for a minute while I looked online for a Huawei service center, and then my phone booted. I gues it got scared and didn't want to go to a service center.
This been a great learning experience, although at times a major headaches. I want to thank blefish for all his help. Thanks to this, i've bee reading his blog and other stuff, and now will follow some of his other projects.
Now to downgrade back to 2.2!!!!
UPDATE: All official roms are working correctly (b136, b138, b518, b528), recovery (5.0.2.6) works. However I haven't been able to get a single custom rom to work. Tried a couple .32 MIUI and CM, but they all stick at the huawei logo. Did factory reset and dalvik wipe, get error can't mount /sd-ext during dalvik wipe, and still doesn't boot.
Maybe I need to try a newer verison of CWM? I tried the newer versions before, and I didn't like them. Buggy and often wouldn't find my sd card.
This thread must be made sticky because it consists of pure information about dealing with soft-bricks. Thanks a lot for your curiosity, you're my hero.

Corrupt Cache Partition - help needed

Hello,
my setup:
- CM 11 unofficial Build3 by vertigo running with ART and the whatsapp fix ( http://forum.xda-developers.com/showthread.php?t=2498084 )
- latest banks gapps
- latest TWRP (2.6.3.2)
What I wanted to do
I simply wanted to install the new official CM11 nightly, booted into TWRP, installed the rom and the gapps without wiping, which shouldnt be a problem - i didn't revert to dalvik for this, if that makes any difference.
I suspect there was an error while downloading the new nightly rom, it gave me an error msg while updating. (ill use MD5 from now on...)
So i just reflashed the build3 from vertigo with the gapps - but now i have the problem that the phone doesnt boot.
It shows the LG Logo unusually long and then shows the CM Boot Logo forever.
Whats the situation now:
i can mount every partition, except cache - wiping also fails obviously
i can enter TWRP and flash stuff
i have made a backup before my update attempt
i also have every file needed for a clean flash on my sdcard
What I tried already:
Wiping everything but the internal sdcard - clean install - still wont boot
restoring the backup works aswell, but still doesnt boot
help gladly appreciated, i think i only need to fix my cache partition and then restore everything and it should work again...
nfin1te said:
Hello,
my setup:
- CM 11 unofficial Build3 by vertigo running with ART and the whatsapp fix ( http://forum.xda-developers.com/showthread.php?t=2498084 )
- latest banks gapps
- latest TWRP (2.6.3.2)
What I wanted to do
I simply wanted to install the new official CM11 nightly, booted into TWRP, installed the rom and the gapps without wiping, which shouldnt be a problem - i didn't revert to dalvik for this, if that makes any difference.
I suspect there was an error while downloading the new nightly rom, it gave me an error msg while updating. (ill use MD5 from now on...)
So i just reflashed the build3 from vertigo with the gapps - but now i have the problem that the phone doesnt boot.
It shows the LG Logo unusually long and then shows the CM Boot Logo forever.
Whats the situation now:
i can mount every partition, except cache - wiping also fails obviously
i can enter TWRP and flash stuff
i have made a backup before my update attempt
i also have every file needed for a clean flash on my sdcard
What I tried already:
Wiping everything but the internal sdcard - clean install - still wont boot
restoring the backup works aswell, but still doesnt boot
help gladly appreciated, i think i only need to fix my cache partition and then restore everything and it should work again...
Click to expand...
Click to collapse
Can you clear it the slow way? Untick -rm rf option in settings, then clear cache. The partition itself shouldn't have been changed by installing a ROM, it must be some kind of problematic content.
Incep said:
Can you clear it the slow way? Untick -rm rf option in settings, then clear cache. The partition itself shouldn't have been changed by installing a ROM, it must be some kind of problematic content.
Click to expand...
Click to collapse
Nope, as I can't mount it, none of those 2 ways is possible.
Just says
At the beginning:
updating partition details
then:
E:unable to mount /cache
several times,
and somwhere inbetween
Running boot script...
and
Finished running boot script
nfin1te said:
Nope, as I can't mount it, none of those 2 ways is possible.
Just says
At the beginning:
updating partition details
then:
E:unable to mount /cache
several times,
and somwhere inbetween
Running boot script...
and
Finished running boot script
Click to expand...
Click to collapse
I didn't think it needed to be mounted in order to be cleared the normal way.
It sounds like it must be repartitioned, or fixed with some kind of disk scan before it can be normally mounted. Maybe there is a way to ssh into the phone and run fsck on the disk?
(ssh is a remote shell for unix, fsck is the linux "scan disk" tool for recovering errors, you can connect to your phone if it has an ssh server running by downloading Putty for windows or through the terminal on mac)
I'm not an expert on android partitions, so maybe someone else want to chime in on this.
Incep said:
It sounds like it must be repartitioned, or fixed with some kind of disk scan before it can be normally mounted. Maybe there is a way to ssh into the phone and run fsck on the disk?
(ssh is a remote shell for unix, fsck is the linux "scan disk" tool for recovering errors, you can connect to your phone if it has an ssh server running by downloading Putty for windows or through the terminal on mac)
Click to expand...
Click to collapse
I'm more than willing to try, but i'd need some sort of instructions, i have no experience with this.
thanks!
What i want to avoid, if somehow possible, is to reflash a stock rom, reroot and reinstall TWRP and go thru the whole procedure again.
nfin1te said:
I'm more than willing to try, but i'd need some sort of instructions, i have no experience with this.
thanks!
What i want to avoid, if somehow possible, is to reflash a stock rom, reroot and reinstall TWRP and go thru the whole procedure again.
Click to expand...
Click to collapse
I'm not sure if my method works, but atleast you have a running adb server on your phone when in TWRP, which is the android debugging protocol. It has a lot of tools, some which might be useful. You should google a bit around on the subject.
Incep said:
I'm not sure if my method works, but atleast you have a running adb server on your phone when in TWRP, which is the android debugging protocol. It has a lot of tools, some which might be useful. You should google a bit around on the subject.
Click to expand...
Click to collapse
Yeah, thats what im doing atm... but i didn't have success finding someone with a similar problem so far.
All i ever have done in ADB is enable/disable fastboot on my old nexus and sideload some images.
nfin1te said:
Yeah, thats what im doing atm... but i didn't have success finding someone with a similar problem so far.
All i ever have done in ADB is enable/disable fastboot on my old nexus and sideload some images.
Click to expand...
Click to collapse
Me too, I'm not really an android developer, just worked a lot with Linux earlier, and it's conceptually the same thing! Hopefully I pointed you in the right direction.
ok i entered adb shell alrdy, but when i try to use the parted command, it says
~ # parted /dev/block/mmcblk0
/sbin/sh: parted: not found
~ #
Edit:
Apparently, i need to push parted first.
Im currently trying this: http://www.droidforums.net/forum/htc-droid-eris/78650-internal-storage-partitions-screwed-up.html
nfin1te said:
ok i entered adb shell alrdy, but when i try to use the parted command, it says
~ # parted /dev/block/mmcblk0
/sbin/sh: parted: not found
~ #
Click to expand...
Click to collapse
Maybe you don't have parted installed on your phone. Each command is actually it's own program, which lies in a folder which is either /bin for normal apps, and /sbin for system-changing apps. So probably check /sbin if there is a binary file called 'parted' there. But be careful of this program… It can be very destructive.
Incep said:
Maybe you don't have parted installed on your phone. Each command is actually it's own program, which lies in a folder which is either /bin for normal apps, and /sbin for system-changing apps. So probably check /sbin if there is a binary file called 'parted' there. But be careful of this program… It can be very destructive.
Click to expand...
Click to collapse
Yeah thx, i just managed to push the necessary files.
Ok, now im looking at this partition table:
(parted) print
print
Model: MMC 032G96 (sd/mmc)
Disk /dev/block/mmcblk0: 31.3GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 16.8MB 83.9MB 67.1MB fat16 modem
2 83.9MB 84.9MB 1049kB sbl1
3 84.9MB 85.5MB 524kB dbi
4 101MB 101MB 524kB DDR
5 117MB 118MB 1049kB aboot
6 118MB 120MB 1049kB rpm
7 134MB 151MB 16.8MB boot
8 151MB 152MB 1049kB tz
9 152MB 152MB 1024B pad
10 168MB 171MB 3146kB modemst1
11 171MB 174MB 3146kB modemst2
12 174MB 174MB 1024B pad1
13 185MB 201MB 16.8MB misc
14 201MB 235MB 33.6MB ext4 persist
15 235MB 252MB 16.8MB recovery
16 252MB 255MB 3146kB fsg
17 268MB 269MB 524kB fsc
18 269MB 269MB 524kB ssd
19 269MB 269MB 1024B pad2
20 269MB 270MB 524kB encrypt
21 285MB 294MB 8389kB ext4 drm
22 294MB 302MB 8389kB ext4 sns
23 302MB 336MB 33.6MB laf
24 336MB 369MB 33.6MB fota
25 369MB 403MB 33.6MB ext4 mpt
26 403MB 403MB 524kB dbibak
27 403MB 404MB 1049kB rpmbak
28 404MB 405MB 1049kB tzbak
29 405MB 405MB 8192B rct
30 419MB 3322MB 2902MB ext4 system
31 3322MB 3959MB 638MB cache
32 3959MB 4043MB 83.9MB tombstones
33 4043MB 4060MB 16.8MB spare
34 4060MB 4110MB 50.3MB ext4 cust
35 4110MB 31.2GB 27.1GB ext4 userdata
36 31.2GB 31.3GB 62.9MB grow
(parted)
I assume, the problem is, that cache seems screwed as it doesn't show any filesystem right?
So if i make this partition ext4, it should work again?
If i check pt31/cache, it says:
(parted) check 31
check 31
Error: Could not detect file system.
(parted)
So, im assuming, im right.
lol, man this is frustrating
(parted) mkfs ext4
mkfs ext4
Warning: The existing file system will be destroyed and all data on the
partition will be lost. Do you want to continue?
parted: invalid token: ext4
Yes/No? yes
yes
Partition number? 31
31
File system type? [ext2]? ext4
ext4
No Implementation: Support for creating ext4 file systems is not implemented
yet.
(parted)
It's alive again!
ext2 worked aswell, as i/we thought - the problem was the cache partition got f'ed up. Making a new FS using parted solved the problem.
THANKS bro for pointing me in the right direction.
Edit: restored backup and everythings fine again
I have the same issue , i am running on ubuntu i but i dont quite get the instrations ?
emrexcem said:
I have the same issue , i am running on ubuntu i but i dont quite get the instrations ?
Click to expand...
Click to collapse
Hi mate i had the same problem and after a long struggling i got this working again.
-Use a Windows computer and install the SDK tools
-Check OP's link to find the "parted" file
-Connect phone in recovery
-Open cmd in windows and type adb shell, you'll get a new console with a #
-Push your parted file to /sbin using adb push command:
In my case i had the parted file in E: drive so i used adb push E:\parted /sbin/parted
-If you try to execute parted you'll get a "permission denied" error, so after pushing the file you need to fix the permissions so type "chmod 777 /sbin/parted"
-Execute parted and just follow OP's steps and you'll be fine.
Hope it helps
Don't use parted to create a filesystem
nfin1te said:
It's alive again!
ext2 worked aswell, as i/we thought - the problem was the cache partition got f'ed up. Making a new FS using parted solved the problem.
THANKS bro for pointing me in the right direction.
Edit: restored backup and everythings fine again
Click to expand...
Click to collapse
You saved my but but as far as I know it is not recomended to use parted to create a filesystem.
Use
mke2fs -T ext4 [partition]
instead
nfin1te said:
It's alive again!
ext2 worked aswell, as i/we thought - the problem was the cache partition got f'ed up. Making a new FS using parted solved the problem.
THANKS bro for pointing me in the right direction.
Edit: restored backup and everythings fine again
Click to expand...
Click to collapse
Can you please provide more detailed instruction please, i have apparently the same problem, i not familiar with adb, i have now pushed all necessary parts to phone what should i do now.
I am stuck please please help.
pingwinpower said:
You saved my but but as far as I know it is not recomended to use parted to create a filesystem.
Use
mke2fs -T ext4 [partition]
instead
Click to expand...
Click to collapse
Can you please provide more detailed instruction please, i have apparently the same problem, i not familiar with adb, i have now pushed all necessary parts to phone what should i do now.
I am stuck please please help.
redkib said:
Can you please provide more detailed instruction please, i have apparently the same problem, i not familiar with adb, i have now pushed all necessary parts to phone what should i do now.
I am stuck please please help.
Click to expand...
Click to collapse
I cant really provide any more information than this, please be more specific with your problem.
Since apparently you have pushed all the files via adb already, you just need to use the "mkfs" command to create a news filesystem, just be sure to select the right partition number (the corrupted one). You can find the correct command via google or take a look at my post
(parted) mkfs ext2
Warning: The existing file system will be destroyed and all data on the
partition will be lost. Do you want to continue?
Yes/No? yes
yes
Partition number? 31
31
File system type? [ext2]?
ext2
(parted)
Click to expand...
Click to collapse

Corrupt partition /data

Okay so I recently updated my s4(att) from cyanogen 12 to cyanogen 13 (latest nightly). I went to settings/security and chose encrypt phone. After about 30 minutes of encrypting it reboot and got stuck in a bootloop. I thought no problem Ill just reflash. I go to reflash my backup and it says error mounting /data. I try formating data, factory reset, and installing the rom from scratch. It seems my data partition corrupt. So I figure fastboot. Yet upon loading fastboot I cant get adb to see my device. I think I got the right drivers installed. But nothing. Any help would be greatly appreciated.
Edit: fixed.
Solution:
I found this and was able to shell in via adb and format the partition.
f you wish to wipe the /data partition completely (including media like photos), follow the below instructions:
Boot into recovery.
Run adb shell in a terminal (Linux) or Command Prompt ("CMD", Windows). After a few seconds, you should see a line containing ~ #.
WARNING. Triple-check the command that you are entering here. White space and capitalization are important. Make any mistake here and you may accidentally wipe your whole flash memory including recovery images.
NOTE: if you want to encrypt your partition later, you have to leave 16KiB unallocated space on the end of the partition.
In the adb shell, run the command mke2fs -t ext4 /dev/block/mmcblk0p12. Substitute /dev/block/mmcblk0p12 and ext4 according to the recovery filesystem table (for /data). Output when running the command:
~ # mke2fs -t ext4 /dev/block/mmcblk0p12
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
755904 inodes, 3022848 blocks
151142 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=3095396352
93 block groups
32768 blocks per group, 32768 fragments per group
8128 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 34 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
(Optional) Install new firmware (E.g. CM 10.1).
Reboot.
(Optional) In order to encrypt the partition while clearing your whole data partition, run vdc cryptfs enablecrypto wipe PIN_OR_PASSWORD (before Android 5.0) or vdc cryptfs enablecrypto wipe password PASSWORD_IN_HEX (since Android 5.0, see this post for details).
Reconfigure device, choose language, enter name, install apps, etc.
source: android .stackexchange. com/questions/33398/cannot-factory-reset-after-encrypting
(sorry cant post links yet)
of course always check your formatting the correct partition first

[TUTORIAL] How to resize system partition on Galaxy S3 for larger GAPPS

On newer Android versions, the system occupies more of the system partition and with GAPPS upgrades, larger GAPPS packages (such as stock and mini) cannot fit on the system partition of the 2012 Galaxy S3. You can just use pico or nano, but sometimes you want the full GAPPS, the real deal. This is also necessary for upcoming ROMs that come with GAPPS preinstalled, such as Pixel Experience. To do this, you must resize the system partition. You can do this by taking some of the space from the cache partition and giving it to the system partition.
PLEASE NOTE: This process is not risk-free! If you do not know what you are doing, I strongly advise against this procedure. I am not responsible for any bricked devices or issues you may face. You have been warned.
Requirements:
A Samsung Galaxy S3. I have the i9300 model, where I have tested it.
parted, downloadable from here. If it downloads as a txt file, delete the extension by renaming it without the txt.
TWRP installed on your device (available for i9300 from here.)
A computer with ADB installed and relevant drivers.
First of all, you must boot TWRP. Once booted, wipe all partitions in TWRP, including system. Reboot back into recovery. Then go into mount and deselect all devices, and uncheck the box saying "Mount system partition as read-only"
Secondly, connect your S3 and send parted to the device with the following command:
Code:
adb push <path_to_parted> /
Thirdly, enter the ADB shell with the following command:
Code:
adb shell
Now, give executable permission to the parted file with the following command:
Code:
chmod +x parted
Now run:
Code:
./parted /dev/block/mmcblk0
Run the print command and you will get a list of partitions. It should look something like:
Code:
Model: MMC VTU00M (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 4194kB 8389kB 4194kB BOTA0
2 8389kB 12.6MB 4194kB BOTA1
3 12.6MB 33.6MB 21.0MB ext4 EFS
4 33.6MB 41.9MB 8389kB PARAM
5 41.9MB 50.3MB 8389kB BOOT
6 50.3MB 58.7MB 8389kB RECOVERY
7 58.7MB 92.3MB 33.6MB RADIO
8 92.3MB 1166MB 1074MB ext4 CACHE
9 1166MB 2777MB 1611MB ext4 SYSTEM
10 2777MB 3364MB 587MB ext4 HIDDEN
11 3364MB 3372MB 8389kB OTA
12 3372MB 15.8GB 12.4GB ext4 USERDATA
Make a note of the Start and End points for partitions 8 and 9 (CACHE and SYSTEM). In my case, the start and end points for partition 8 are 92.3 and 1166 and the start and end points for partition 9 are 1166 and 2777.
What we're going to do is delete these two partitions, then recreate them, but make the new partition 8 (Cache) smaller and allocate the space left to partition 9 (System).
Remove them with the following commands in parted:
Code:
./parted /dev/block/mmcblk0 rm 8
./parted /dev/block/mmcblk0 rm 9
Now recreate them with the following commands:
Code:
./parted /dev/block/mmcblk0 mkpart primary <cache_start> <cache_start+200>
./parted /dev/block/mmcblk0 mkpart primary <cache_end> <system_end>
Replace <cache_start> with the start of the former cache petition. In my case, it would be:
Code:
./parted /dev/block/mmcblk0 mkpart primary 92.3 292
./parted /dev/block/mmcblk0 mkpart primary 292 2777
Now name the partitions.
Code:
./parted /dev/block/mmcblk0 name 8 CACHE
./parted /dev/block/mmcblk0 name 9 SYSTEM
Then format them as ext4:
Code:
mke2fs -T ext4 /dev/block/mmcblk0p8
mke2fs -T ext4 /dev/block/mmcblk0p9
Run ./parted, followed by print, to check if the changes have been applied. If so, well done! You have successfully enlarged the system partition. Exit parted with the quit command.
Now configure and exit:
Code:
mount -a
exit
Reboot back into recovery and install any ROM of your choice. Once you've installed the ROM, reboot into recovery once again, and navigate to wipe --> advanced wipe, select system, tap repair or change filesystem, then resize.
You can now install any GAPPS of your choice. I've gotten LineageOS 16.0 working with mini gapps (Google Play Store + some Google apps) and it is working fine. You could make the system partition bigger by borrowing some more MB from the cache partition, or experimenting further by taking some from the HIDDEN partition. Remember, I am NOT responsible for any damage done when doing this. You assume full responsibility for any problems with the device. I hope this tutorial did help you, feel free to post here if it did or ask for help if you need it.
Did you experiment this process for a long time ? With so small a cache what could be the consequences ?
A finally do you know what is the use of HIDDEN partition ?
Great tutorial anyway.
barbe31 said:
Did you experiment this process for a long time ? With so small a cache what could be the consequences ?
Click to expand...
Click to collapse
Newer Android versions don't use up as much in the cache partition. If you're on say stock ICS or JB you may encounter some issues but if you're using LOS 15 or 16 it should work fine. I've used LOS 16 with GAPPS using this method for a while on my S3 and it's been fine.
ChasTechProjects said:
parted, downloadable from here.
Click to expand...
Click to collapse
Link says file doesn't exist.
petera703 said:
Link says file doesn't exist.
Click to expand...
Click to collapse
parted
drive.google.com
Cheers for that. I've been trying for some time to do the same thing on a Galaxy S4 Mini, working from a few variations of this process that I've found here and there, but never with any success. All appears to go well, with no errors, but it doesn't stick--the device just reverts to the previous partition sizes on reboot..
I've been using parted 3.2. I wondered if it would work with the parted you were using, but the one from your new link is 1.8 and doesn't even get as far for me (tried that one previously and it gets errors on my device).
If anyone know how to overcome the issue of resized partitions not surviving a reboot on Android, please help! I've been unable to solve it.
If it was plain Linux, it would be something to do with fstab, but fstab is never mentioned in the posts where people succeed in resizing Android partitions, so I think it must be something else, and perhaps something that varies from one device to another. Looking forward to any suggestions--thanks!
Can this idea/technique be applied to other *droid based devices
like Nook HD ?
[ Having same 'not enough space for the gaps' issue]

Categories

Resources