I've been browsing device and found g3mod.log in root which said:
Checking mmcblk0p2
/dev/block/mmcblk0p2: clean, 1390/62592 files, 57046/250000 blocks
Checking stl6
/dev/block/stl6: clean, 1255/13600 files, 51067/54400 blocks
Checking stl7
/dev/block/stl7 contains a file system with errors, check forced.
/dev/block/stl7: Inode 6257 has imagic flag set.
/dev/block/stl7: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
Checking stl8
/dev/block/stl8: clean, 12/2176 files, 143/8704 blocks
Click to expand...
Click to collapse
And when I run fsck (fsck /dev/block/stl7) there are tons of errors.
Command:
Code:
# fsck -t ext2 /dev/block/stl7
fsck -t ext2 /dev/block/stl7
fsck (busybox 1.18.2, 2011-01-22 14:38:24 CET)
e2fsck 1.41.12 (17-May-2010)
/dev/block/stl7 contains a file system with errors, check forced.
Output (stripped off from unnecessary stuff. if needed i can attach full dummy output (fsck -n -v /dev/block/stl7):
Code:
• Inode has magic flag set,
• has extra sizes,
• has compression flag set on filesystem without compression support,
• has INDEX_FL flag set but is not a directory,
• i_blocks is 4294967295, should be 0,
• is in use, but has dtime set,
• has a extra size (65535) which is invalid,
• has compression flag set on filesystem without compression support
• Extended attribute block for inode 6316 (...) is invalid (4294967295)
...
The system operates normally and I haven't noticed any problems, but this still worries me, i guess it shouldn't have errors.
FS type of /system is ext2 converted by using g3mod app (data is ext4, cache ext2), data2sd and app2sd are enabled, init.d scripts are: app2sd_v2, swap, zipalign, kickasskernel, v6supercharger (testing beta 8), sdcard speed fix (set to 4KB).
Kernel is g3mod v. 1.8 extreme and rom is Kyrillos 7.1.
stl7 is my data partition. could it be that it is due to data2sd?
Edit: mount or mount | grep stl7 does not even display /data or /stl7. is this normal?
Edit: the above data filesystem is incorrent. g3mod app displays rfs (although it was ext4, probably messed up between flashing) but the g3mod app will not convert it, i have just tryed and still displays rfs.
Hope you can help. Any help and information is appreciated.
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.
Not so long ago I started experiencing severe freezes and lockups on my I9300. The symptoms were well known as pre-SDS lockups. Before SDS workarounds have been released such symptoms would mean a death sentence for the device. While this is not the case any more the freezes still make the phone virtually unusable.
So far the only way to bring the phone back to usability was a full wipe of the device combined with filling the partitions with some data in order to ensure that every sector has been written to. Some have also succeeded to get rid of such behaviour after flashing stock firmware (after having been running AOSP).
Some technical background
The reason for the freezes (at least on my device) were block read errors. This is roughly equivalent to a situation where you HDD starts having bad sectors, however flash memory is a bit different to a magnetic disk drive. The read errors encountered most likely due to data corruption resulting in CRC errors during read. In my case the dmesg (kernel log) showed the following errors:
Code:
[ 5896.313473] c0 mmc0: it occurs a critical error on eMMC it'll try to recover eMMC to normal state
[ 5896.482283] c0 mif: set_hsic_lpa_states: 304: called(exynos4_check_usb_op+0x84/0x100):
[ 5896.482469] c0 mif: set hsic lpa enter: active state (0), pda active (0)
[ 5896.665712] c0 mmc0: Fixing MoviNAND SDS bug.
[ 5896.708336] c0 mmc0: Verifying SDS patch.
[ 5896.794283] c0 mmc0: recovering eMMC has been done
[ 5896.794412] c0 brq->sbc.opcode=23,brq->cmd.opcode=18.
[ 5896.794539] c0 brq->sbc.error=-131,brq->cmd.error=0, brq->stop.error=0,brq->data.error=0.
[ 5896.794789] c0 mmcblk0: unknown error -131 sending read/write command, card status 0x900
[ 5896.795869] c0 end_request: I/O error, dev mmcblk0, sector 21590248
[ 5896.796034] c0 end_request: I/O error, dev mmcblk0, sector 21590256
[ 5896.796182] c0 end_request: I/O error, dev mmcblk0, sector 21590264
[ 5896.796379] c0 CMD aborting case in MMC's block layer ret 0.
[ 5896.796512] c0 mmcblk0: CMD18, ARG=0x14970e8.
[ 5896.796613] c0 packed CMD type = 0.
[ 5896.796700] c0 mmc0, request returns 4.
Instead of doing a full wipe of the device's internal flash memory partitions I've tried out another method. I was looking for a program that would rewrite all the data without actually wiping it. Such operation would cause the data to be written again and additionally the wear levelling algorithm inside the eMMC controller would have the chance to relocate the data to another physical block on the flash memory chip.
It turned out that the program I was looking for is already there - just not fully thought of being the right one to use in such case.
When bad blocks encounter on a HDD on your PC you normally need to scan the whole media and mark all the bad blocks found on the filesystem so that they can no longer be allocated for file storage. On Linux this task is performed by the e2fsck system utility which uses another utility called badblocks to do the scan and report the unusable blocks. It is the latter that is interesting.
Among several options found in the badblocks utility there are three methods for discovering such broken blocks:
- read-only where the program will attempt to read all blocks one-by-one.
- non-destructive read-write in which case the program will for each block: read it, fill it with a pattern and write back the original content.
- destructive write where all blocks will be filled by pattern(s) destroying any existing content.
The two last modes are interesting for the purpose of rewriting your device's memory partitions to get rid of bad blocks.
The non-destructive read-write mode can be used to attempt to recover without wiping the contents of the partition. This is mostly relevant to the /data partition (and possibly /efs) as all other ones can be easily restored. Note however that when a read error occurs the data in that sector is already lost. When you attempt to recover such partition it will appear to be working again, but some apps may be crashing randomly as some of their data is corrupted. The non-destructive read-write mode can also be used to prevent freezes from happening. All you need is to treat the /data partition this way once a while (not too often - every 6 months without a factory reset).
The destructive write mode can be used in case you don't care for the data. This is equivalent to the methods used so far (wiping the partition and filling it with random junk). This mode can also be used to securely* wipe your phone before selling it or giving it away.
* Due to wear levelling this is actually not a secure wipe as some of the data will still persist on the Flash memory chip. However it is secure from a user point of view as the data is no longer visible and recovering it will most likely require advanced and expensive procedures.
Fix and prevent
Rewriting your flash partition data will fix freezes due to bad blocks. However when freezes start to happen this usually means that some data is already unreadable and therefore - lost. In order to refresh the data the non-destructive write test in badblocks can be used periodically to rewrite the data. This will result in a small speedup of your phone.
Important: You must be careful not to rewrite your partition too often as each flash memory block has a limited number of erase cycles (around 100,000 for SLC and 10,000 for MLC chips). Doing this too often will actually damage your chip in the long term making your phone unusable. I believe that rewriting your /data partition every 6 months without a factory reset should prevent any issues. You do not need to do this if you periodically factory-reset your phone as in such case the data is rewritten anyway.
Step-by-step instructions
DISCLAIMER: This may be a dangerous operation if not executed properly. I do not accept any responsibility for damage that it may cause. Please do this on your own risk.
Prerequisites
Before you begin there are some requirements that need to be fulfilled:
A recent backup of your phone. Remember - there are three kinds of people in this world - those who make backups, those who have not yet lost their data and those morons who still refuse to make backups despite loosing data.
SDS-proof recovery. This is true for all recent recoveries these days, but better make sure. The recovery must also allow ADB connections. While this is true for all recoveries, some have problems with it. In my case I couldn't connect to CWM 6.0.4.4 as ADB kept complaining that the connection is unauthorized. Flashing latest Philz Touch (6.00.8 in my case) solved the problem.
ADB installed on your PC. Please search forum or internet to find instructions.
badblocks binary for Android recovery. Since this utility is not included in the recovery by default you need to obtain it elsewhere. The one I've built is attached to this post.
Instructions
These assume we're working on the /data partition. For other partitions please check their corresponding device node and modify the instructions accordingly.
Reboot to recovery.
Do a nandroid backup if not done before.
Connect to your phone using the USB cable.
Run adb push badblocks sbin/badblocks. In case you have just downloaded the attached ZIP file unzip it first to extract the badblocks binary.
Run adb shell to enter a shell on your phone.
Run chmod 0755 sbin/badblocks to make the badblocks binary executable.
Make sure your /data is not mounted. The quick way is to run mount. It will list all mounted filesystems. If /data on /dev/block/mmcblk0p12 is among them you'll need to unmount it by running: umount /data. If it complains about the filesystem being busy you'll need to reboot the phone and enter recovery again. After that repeat all the steps.
Once you are sure that /data is not mounted run: badblocks -b 4096 -n -t 0xFF -s /dev/block/mmcblk0p12. This command is where the main magic happens. What it does is it reads every sector, fills it with 0xFF bytes and then writes back the original data. This way the data is unchanged, but every block gets rewritten. After running badblocks you should see some percentage indicator about the progress. The operation on /data should take around an hour. Observe any errors that may occur. In my case there were none, but if the flash is heavily worn out there may be some unrecoverable sectors.
In case there are no errors everything should be done. Optionally you may want to trim the /data filesystem as all blocks have been rewritten and the eMMC conroller will think that there are no unused blocks on the device. You can do this by mounting the /data filesystem (mount /data) and running fstrim (fstrim -v /data).
You're good to go. Type exit in the ADB shell and reboot your phone into the system.
In case you do not care for the data on the partition you may run badblocks in destructive mode. In such case in step 7 replace "-n" with "-w" in badblocks command line: badblocks -b 4096 -w -t 0xFF -s /dev/block/mmcblk0p12
The same procedure can be repeated for other filesystems (/system, /cache). I would not recommend doing this on the partitions containing the kernel, recovery, efs or bootloader unless you're asking for trouble.
Reserved for future use.
This should seriously be stickied. Works better than using the dummy file generator that everyone recommends.
Actually, if you're getting SDS freeze on patched firmware with V2 fix (XXEMB2+) it is SDS fix recovering bad block. It's even stated in your kernel message.
This method is good if you want to get rid of misc freezes and fix all blocks at once. Because badblocks forces kernel to rewrite all blocks instead of only one/affected block (during normal freeze).
May be useful, but it's not a magic trick. If somebody gets freezes and kernel can't fix it itself then magic badblocks binary won't help him, unfortunately.
I wonder if you could use e2fsck to mark some permanently broken blocks as bad blocks on the filesystem so that they won't be used for filesystem data. A similar thing used to be done on HDDs. The problem that I see here is that the FTL may relocate that block somewhere and it may end up being reused somewhere else and keep doing damage.
I'm really curious how does the eMMC controller on the I9300 handle permanently broken blocks. Does it have some reservoir of usable blocks (like in modern SSD disks) that can be used as a replacement?
KrissN said:
I wonder if you could use e2fsck to mark some permanently broken blocks as bad blocks on the filesystem so that they won't be used for filesystem data. A similar thing used to be done on HDDs. The problem that I see here is that the FTL may relocate that block somewhere and it may end up being reused somewhere else and keep doing damage.
I'm really curious how does the eMMC controller on the I9300 handle permanently broken blocks. Does it have some reservoir of usable blocks (like in modern SSD disks) that can be used as a replacement?
Click to expand...
Click to collapse
This is actually a very good question, I'm wondering as well. If you're clever enough then you may download my latest ArchiDroid 2.X Experimental ROM with built-in debian and try to discover that with native linux gnu utilities.
JustArchi said:
This is actually a very good question, I'm wondering as well. If you're clever enough then you may download my latest ArchiDroid 2.X Experimental ROM with built-in debian and try to discover that with native linux gnu utilities.
Click to expand...
Click to collapse
Desctructive mode? Will that be equivalent to a lets say factory reset? ie losing all user made data.
Wow, this really helped. I am using SM-G355H (not really made with exynos but with sc8830 from spreadtrum but still by samsung) and was afraid that the phone has failed for good. Though the partition failing was the /system/ not the /data/, OP's badblocks build and instructions definitely fixed it, like magic.
Additional note: To identify which partition is failing
Take note of the failing sector, in my case it's at 1879872
Code:
mmcblk0: error -110 transferring data, sector [B]1879872[/B], nr 256, cmd response 0x900, card status 0xb00
and find the partition using the output of this command where /dev/block/mmcblk0 is the block device
Code:
sgdisk --print [B]/dev/block/mmcblk0[/B]
It will print something like:
Code:
Logical sector size: 512 bytes
Disk identifier (GUID): 52444E41-494F-2044-4D4D-43204449534B
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 7618526
Partitions will be aligned on 512-sector boundaries
Total free space is 21949 sectors (10.7 MiB)
Number Start (sector) End (sector) Size Code Name
1 8192 15871 3.8 MiB 0700 FIXNV1
2 15872 23551 3.8 MiB 0700 FIXNV2
3 23552 27647 2.0 MiB 0700 SBL1
4 27648 31743 2.0 MiB 0700 SBL2
5 31744 41983 5.0 MiB 0700 WDSP
6 41984 52223 5.0 MiB 0700 WDSP_BACKUP
7 52224 72703 10.0 MiB 0700 MODEM
8 72704 93183 10.0 MiB 0700 MODEM_BACKUP
9 93184 93695 256.0 KiB 0700 FOTA_SIG
10 93696 110079 8.0 MiB 0700 OTA
11 110080 117759 3.8 MiB 0700 RUNTIMENV1
12 117760 125439 3.8 MiB 0700 RUNTIMENV2
13 125440 131071 2.8 MiB 0700 PARAM
14 135680 176639 20.0 MiB 0700 efs
15 176640 186879 5.0 MiB 0700 prodnv
16 186880 187391 256.0 KiB 0700 Odin_reserved
17 187392 218111 15.0 MiB 0700 KERNEL
18 218112 248831 15.0 MiB 0700 RECOVERY
19 248832 494591 120.0 MiB 0700 CSC
20 494592 2829311 1.1 GiB 0700 system
21 2829312 2890751 30.0 MiB 0700 HIDDEN
22 2890752 7609343 2.3 GiB 0700 userdata
Find the partition whose start and end sectors contain that failing sector. In my case it's the system since
1879872 in within 494592 to 2829311
Code:
20 [B]494592 2829311[/B] 1.1 GiB 0700 system