Develop Bugs

113MB of bad blocks on /data...can i be helped???

Edit: summary of what ive tried and failed with.
Wipe all userdata from cwm and amon recovery ... no effect.
erase_image from cwm ... no effect.
fastboot erase ... no effect.
fastboot erase -w ... no effect.
RUU ... no effect.
cat zero to mtd ... no effect.
dd zero to mtd ... no effect.
flash_image (image edited with hex editor to contain only zero's) ... no effect.
fastboot oem task 28 ... no effect.
fastboot oem task 29 ... no effect.
fastboot flash hboot (different partition tables) ... no effect.
I'm out of ideas.
Original post:
Even after clearing all userdata from recovery and erasing userdata from fastboot i am missing over 100mb from /data, but there are no files there taking up the space.
How can i reclaim this space, is it corrupted??? How do i check for (and fix) a corrupt filesystem on android?
I'm thinking of flashing a new HBOOT, oxygen table, but if it's corrupt will it screw it up or fix it?
Below was done from recovery and fastboot and shows the problem, look at how much space is in use on data after wipe.
Code:
[email protected]:~$ sudo su
[email protected]:/home/mercianary# adb shell
/ # mount -a
mount: mounting /dev/block/mmcblk0p2 on /sd-ext failed: No such file or directory
/ # df -hm
Filesystem Size Used Available Use% Mounted on
tmpfs 203.2M 0 203.2M 0% /dev
/dev/block/mtdblock4 95.0M 1.1M 93.9M 1% /cache
/dev/block/mtdblock3 145.0M 132.6M 12.4M 91% /system
/dev/block/mtdblock5 197.6M 187.5M 10.2M 95% /data
/dev/block/mmcblk0p1 3.7G 3.4G 302.9M 92% /sdcard
[B]/ # #wipe all userdata from recovery (amonra 2.0.0)[/B]
/ # mount -a
mount: mounting /dev/block/mmcblk0p2 on /sd-ext failed: No such file or directory
/ # df -hm
Filesystem Size Used Available Use% Mounted on
tmpfs 203.2M 0 203.2M 0% /dev
/dev/block/mtdblock3 145.0M 132.6M 12.4M 91% /system
/dev/block/mtdblock4 95.0M 1.2M 93.8M 1% /cache
[B]/dev/block/mtdblock5 197.6M 113.3M 84.4M 57% /data[/B]
/dev/block/mmcblk0p1 3.7G 3.3G 378.5M 90% /sdcard
/ # reboot bootloader
[B][email protected]:/home/mercianary# fastboot erase userdata
erasing 'userdata'... OKAY[/B]
[email protected]:/home/mercianary# #into recovery again
[email protected]:/home/mercianary# adb shell
/ # mount -a
mount: mounting /dev/block/mmcblk0p2 on /sd-ext failed: No such file or directory
/ # df -hm
Filesystem Size Used Available Use% Mounted on
tmpfs 203.2M 0 203.2M 0% /dev
/dev/block/mtdblock4 95.0M 1.2M 93.8M 1% /cache
/dev/block/mtdblock3 145.0M 132.6M 12.4M 91% /system
[B]/dev/block/mtdblock5 197.6M 113.3M 84.4M 57% /data[/B]
/dev/block/mmcblk0p1 3.7G 3.3G 378.5M 90% /sdcard
/ # ls /data
lost+found
/ # du /data
2 /data/lost+found
4 /data
I'm using
CM7
amonra recovery 2.0.0
N1 Boot table
Any help troubleshooting this would be great, thanks.

did you wipe the /data/ partition in mounts & storage in recovery? try that if not, also try flashing a stock ruu, it will revert and changes made to the MTD Partitions

that was the first thing i tried, no luck. it erased fine but space was still missing
I dont particularly want to flash a RUU or another HBOOT untill i know what's wrong because if there's 100mb of bad nand on my phone i can imagine flashing a RUU or HBOOT going very wrong and leaving me with a very pretty paperweight.

I tried flashing some different hboots, problem still there, it just moves round a bit....
on the original boot table the space is missing on system and data..about 10mb or 20mb on system, the rest on data.
on oxygen and n1 boot table its just missing on data.
I cant seem to reclaim this space
anyone know how to check the disk for errors?

thats bad news, sounds like you may have some corrupt blocks

AndroHero said:
thats bad news, sounds like you may have some corrupt blocks
Click to expand...
Click to collapse
just a few, only 897 of them the phone is still working, so i suppose i'm kinda lucky.
I think i may have screwed it up a few weeks ago when i was messing around with cat, dd, fastboot and flash_image. I remember when i finished messing around i tried to restore my nand backup back on it but it failed, looking back it must have been because it didnt fit anymore due to the bad blocks. This must have been when the corruption occured.
Is it normal to have this many bad blocks? i've never seen more than a few, i'm hoping they aren't actually bad and it just thinks they are because of something stupid i did, is there anything i can do to remove the bad block flag (if there is one???) and then try again?
Code:
/sdcard/badblock # flash_image userdata mtd5.img
mtd: MEMGETBADBLOCK returned 1 at 0x00000000 (errno=0)
mtd: MEMGETBADBLOCK returned 1 at 0x00020000 (errno=0)
mtd: MEMGETBADBLOCK returned 1 at 0x00040000 (errno=0)
mtd: MEMGETBADBLOCK returned 1 at 0x00060000 (errno=0)
mtd: MEMGETBADBLOCK returned 1 at 0x00080000 (errno=0)
mtd: not writing bad block at 0x00000000
mtd: not writing bad block at 0x00020000
mtd: not writing bad block at 0x00040000
...
edited because it put the post over the 30,000 character limit!
...
mtd: not writing bad block at 0x0c520000
mtd: not writing bad block at 0x0c540000
mtd: not writing bad block at 0x0c560000
mtd: not writing bad block at 0x0c580000
error writing userdata: No space left on device
/sdcard/badblock #

That's way too high. NAND blocks usually fail at once and in the same area but not that many at once unless it be software error or a major stressor placed on them. It may be faulty bad block management defuncting those cells. If you could somehow find a way to Secure Erase the NAND, it could help. NAND cells sometimes work fine after this and cell state becomes reset so all those marked bad will be recycled back in use to test. The reason why they can sometimes spring back to perfect retention after a SE is academically quite known.
------------------------------
- Sent via HTC Desire -

I guess that you should use an RUU as it should format nand. If it does not the update wikl fail which mesns that your bad block could never be recoverd. Keep in mind to use RUU and not a PB.img i believe it is safer as long as it comed to bricking the phone. I know that some pvt 1 boards had some bad blocks on nands but never so muny( if it is a pvt1) . Regards
Sent from my LeeDroided Desire HD

I decided to flash a ruu, that was scary, it failed the first time writing /system but successfully recovered itself and worked on the second attempt.
Available space on /data after RUU, 58.44MB not good
looks loke it didnt work, time to re root and get apps2sd, data2sd and the n1 boot table, lets see how i get on with 110MB missing from data, at least it will be fun

mate now that you used the RUU, why don't you return it to HTC for repairs? tell them that it happened whileattempting to update.
mercianary said:
I decided to flash a ruu, that was scary, it failed the first time writing /system but successfully recovered itself and worked on the second attempt.
Available space on /data after RUU, 58.44MB not good
looks loke it didnt work, time to re root and get apps2sd, data2sd and the n1 boot table, lets see how i get on with 110MB missing from data, at least it will be fun
Click to expand...
Click to collapse

mariosraptor said:
mate now that you used the RUU, why don't you return it to HTC for repairs? tell them that it happened whileattempting to update.
Click to expand...
Click to collapse
That's what I was planning to do but I decided against it for several reasons.
I'm not feeling lucky, I dont think I will get away with it this time.
With the nature of the problem I can imagine whoever gets their hands on it at HTC will look into what's happened and discover my warranty's void...paranoid I know.
It doesn't help that there is no RUU for orange UK branded desires, I have to use a dodgy method to unroot (restoring an old backup, removing superuser and su then updating OTA.)
I'm happy with the way it is at the moment, who knows, I might drop it under my car at some point in the near future

anyone know anything about performing a low level format or clearing the bad block map so i can start a fresh???
PS...turns out the stock orange rom doesn't even fit on /system because its missing 10MB of space...damn you orange bloatware...damn you to hell!!!
PPS...Bump.

Get in contact with a dev. I am sure they will help you out to access and do a secure wipe on your memory. Way beyond me for sure

[Q]: repartitioning hiccup [solved]

Ok, I posted this question in 2 other threads that had info on the process (will delete the posts when this one goes live), but no responses after a couple of days. One of them is old though.
I have TWRP 2.1.1 installed. ADB seems to be working normally. Superuser is working fine after booting to android. I'm running a custom ICS ROM (Energy); read that stock ROM can cause issues repartitioning.
I started with this How-to as it looked very straight forward.
I start throwing the commands at ADB and here's what I got for my efforts:
Code:
C:\Program Files (x86)\Android\android-sdk\platform-tools>adb shell
~ # su
su
/sbin/sh: su: not found
~ # cd /data
cd /data
/data # ls
ls
/data #
decided to go ahead and check the mount command:
Code:
~ # mount
mount
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
~ #
and parted just for giggles:
Code:
~ # parted /dev/block/mmcblk0
parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
print
print
Model: MMC MMC08G (sd/mmc)
Disk /dev/block/mmcblk0: 7818MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 131kB 262kB 131kB xloader
2 262kB 524kB 262kB bootloader
3 524kB 11.0MB 10.5MB dkernel
4 11.0MB 212MB 201MB ext4 dfs
5 212MB 229MB 16.8MB recovery
6 229MB 296MB 67.1MB ext4 backup
7 296MB 307MB 10.5MB boot
8 307MB 312MB 5243kB ext4 splash
9 312MB 849MB 537MB ext4 system
10 849MB 2041MB 1192MB ext4 userdata
11 2041MB 2309MB 268MB ext4 cache
12 2309MB 7690MB 5380MB fat32 media
(parted)
Ok, so that much worked. Now I tried to shrink 12 so I could double the size of 9. I want to get Switchme set up for his/her profiles and 500MB just isn't going to cut it.
That's when I hit a brick wall:
Code:
(parted) resize 12 2846 7690
resize 12 2846 7690
resize 12 2846 7690
Error: Unable to satisfy all constraints on the partition.
(parted)

One thing that jumps out at me right away is this:
Code:
adb shell
~ # su
su/sbin/sh: su: not found
It seems you are not actually rooted.
To check, enter:
Code:
adb shell
ls /system/xbin
If you don't see "su" in the list, then you don't have root permissions, which would probably prevent you from doing what you need to accomplish.

That's what I was wondering, but apps are able to ask for and receive root permission from within the ROM. SU does exist, just not where the shell is looking when in recovery.
Code:
C:\Program Files (x86)\Android\android-sdk\platform-tools>adb shell
~ # ls /system/xbin
ls /system/xbin
ls: /system/xbin: No such file or directory
~ #
I did an ls /system/xbin from adb shell and from Terminal Emulator within Android and both returned a long list containing SU.

TWRP provides an unsecured (unsecure? insecure?) boot. Whatever the terminology, it gives you immediate access to root privileges. Apparently CWMR (which was used in the OP of the thread you used) does not and so that author had to use su. For TWRP, it's not necessary and not even available. You already have root privileges as indicated by the hash prompt.
I tried resizing my /sdcard partition and it worked fine with the command you tried. I'm not sure what's going on with your storage device that it wouldn't resize it for you. At first I thought it might be mounted, but your mount command shows otherwise and parted gave me a different error when I had it mounted.
I don't know if this is going to help you, but you might try giving it the "MB" suffix in your numbers....
Code:
resize 12 2846MB 7690MB
Maybe even try changing units to bytes and giving the resize command byte sized boundaries.
Code:
unit B
print
will show you the numbers in bytes and you'd have to use the "B" suffix as in the "MB" example above.
If none of that works, you can always remove and remake the partition. For example...
Code:
rm 12
mkpartfs primary fat32 <start> <end>
name 12 media
You'd obviously need to insert acceptable boundaries for the start and end into that command. It might even be easier to just remove all 9, 10, 11, and 12 and remake/rename them, but remember 9, 10, and 11 are ext4 filesystems so the above mkpartfs command needs to be tweaked accordingly.
One thing I noticed while I was experimenting with the partition table this morning... all of the existing partitions have been allocated in 128MB chunks. I have no idea if this affects performance. I'd imagine you'd only need to stick to the 512B sector sizes, but you might want to stay with those conventions if it's not too inconvenient for you.
If you mess up the partition table, you can always go back to fastboot mode in FFF and use the...
Code:
fastboot oem format
feature to bring your partition table back to stock.
Good luck.

Wow, excellent response. Just the kind of detail I was hoping to get and it confirmed a few suspicions I had while searching the kindle threads. I'll report back on my degree of success when I get some free time to tinker.
I have a nandroid backup (also saved to PC) just in case and saved the partition table as-found. If everything gets hosed and I do an oem format I can just restore that and go or try from square one again, yes?
Sent from my TBolt with the XDA App using 1 opposable thumb

ProfEngr said:
Wow, excellent response. Just the kind of detail I was hoping to get and it confirmed a few suspicions I had while searching the kindle threads. I'll report back on my degree of success when I get some free time to tinker.
I have a nandroid backup (also saved to PC) just in case and saved the partition table as-found. If everything gets hosed and I do an oem format I can just restore that and go or try from square one again, yes?
Sent from my TBolt with the XDA App using 1 opposable thumb
Click to expand...
Click to collapse
I'd say that's a safe bet. Just be very careful about handling partitions 1 and 2 because those two are critical to getting anything to boot on your device. As long as you don't touch the xloader in partition 1 and have FFF installed in partition 2, you can rebuild the rest of it.... in theory. I only say "in theory" because I've never actually had to do it, but I don't see why it wouldn't work.
A couple of additional things I figured out after you put me to work with parted....
It looks like parted doesn't know how to make an ext4 filesystem, so mkpartfs balks if you tell it to make one. You'll have to use mkpart which just makes the partition, but not the filesystem. Then exit out of parted and use mke2fs, which despite its name knows how to make an ext4 filesystem. Like this for the cache partition...
Code:
mke2fs -T ext4 /dev/block/mmcblk0p11
The other thing is that parted sets a "msftres" flag on the fat32 filesystem it makes. The flag apparently is to tell the OS that it's reserved for Windows, or something like that. I didn't have a problem mounting in Linux and MacOS X, but the stuff I've read seems to indicate that older OS's have a problem with it. Unfortunately, the version of busybox on TWRP doesn't have a module to make a fat32 filesystem. I'm looking around to see how to get around that.
In any case, this should get you most of the way there. I'll followup if I find something out.

Ok. I used to run n*x, but use only M$ right now. Haven't touched a 'mac' since Jr High (IIgs)
Sent from my TBolt with the XDA App using 1 opposable thumb

ProfEngr said:
Ok. I used to run n*x, but use only M$ right now. Haven't touched a 'mac' since Jr High (IIgs)
Sent from my TBolt with the XDA App using 1 opposable thumb
Click to expand...
Click to collapse
I have a IIgs sitting in the basement... but it's not a mac, it's an Apple ][.
Found the last piece...
Code:
/system/bin/newfs_msdos /dev/block/mmcblk0p12
will make a fat32 filesystem correctly. I think that's all you'll need.
EDIT: OK, I must have been half asleep when I posted the above. That binary is on the stock system software I had mounted. There's nothing on TWRP to create a fat32 filesystem correctly.

Yeah, ][e was my first computer that didn't crash at the drop of a keystroke. Had an Adam tape drive model, but it froze up constantly.
Sent from my TBolt with the XDA App using 1 opposable thumb

So, I met with success following the repartition thread and tweaking it with your suggestions. I didn't quite move and many MB around as I thought, but it was enough to move me a little farther down the road with SwitchMe. At least it doesn't tell me I don't have enough memory for a 2nd profile now.
I still think it has issues with ICS or EnergyROM itself. When I created a new profile and rebooted to it I was stuck on Nova launcher instead of GO like the main profile. Strange.
I'll consider this thread to have fulfilled its usefulness. Thanks again for the help.

no device found
ProfEngr said:
So, I met with success following the repartition thread and tweaking it with your suggestions. I didn't quite move and many MB around as I thought, but it was enough to move me a little farther down the road with SwitchMe. At least it doesn't tell me I don't have enough memory for a 2nd profile now.
I still think it has issues with ICS or EnergyROM itself. When I created a new profile and rebooted to it I was stuck on Nova launcher instead of GO like the main profile. Strange.
I'll consider this thread to have fulfilled its usefulness. Thanks again for the help.
Click to expand...
Click to collapse
I get
(parted)
Error: No device found
Retry/Cancel

Alcatel 960C/ One Touch Authority

Has anyone created a clockworkmod for this? This phone can be rooted, thru two apps, poot, and ministro(Qt). It still has gingerbread 2.3.6, and I need clockworkmod, or the source code, to use clockworkmod's builder. It is the cdma variant of the alcatel 995(which is gsm). can anyone point me in the right direction?

Source Code
I have it rooted, with adb insecure running, to see everything. My bootloader seems to be locked, and the recovery is unknown, with limited options. I can do most things, except change roms, wipe data, or cache in recovery. I would like to be directed to good repository.

reggjoo said:
I have it rooted, with adb insecure running, to see everything. My bootloader seems to be locked, and the recovery is unknown, with limited options. I can do most things, except change roms, wipe data, or cache in recovery. I would like to be directed to good repository.
Click to expand...
Click to collapse
how did you get it rooted?

rooting alcatel authority (960c)
squidbutt said:
how did you get it rooted?
Click to expand...
Click to collapse
First make sure you have USB Debugging checked and your allowing instalation of unknown sources
DL these from the play store:
Minstro2
Superuser
DL poot.apk: View attachment poot.zip
Run poot, click yes to download the extra librarys, click "click here to poot" you will need to restart the phone when it prompts. You should be rooted now :good:
You can DL ES File Explorer(from play store) and in the settings check: Root Explorer, Up to Root and Mount File System. Now you can manage all the files on your phone but be careful of what you delete, some of the stock apk's are very hard to recover if you delete them.
Hope this helps

Download superuser first
Download superuser first, you won't be able to run it until the phone's rooted. after it's rooted, it will work. This way, seems to stop a problem, when you go thru the steps to root. Some people had a error. If you plan to open the /data, /system, or dalvik cache, on your computer, install chainfire's adb insecure. These folders don't open without this, on a computer.

I have the kernel source here, they have it released on SourceForge I'm guessing you're right saying the bootloader is locked.
Here's some information I've found on the partitions:
mmcblk0 Internal Memory
mmcblk0p1 Mounted using VFAT Contains files pertaining to FOTA (FOTA partition?)
mmcblk0p2 500 blocks ?
mmcblk0p3 1500 blocks ?
mmcblk0p4 1 BLOCK ?
mmcblk0p5 1000 blocks ?
mmcblk0p6 2000 blocks ?
mmcblk0p7 3072 blocks ?
mmcblk0p8 5120 blocks Possible Recovery*
mmcblk0p9 7000 blocks ?
mmcblk0p10 3027 blocks ?
mmcblk0p11 3072 blocks ?
mmcblk0p12 5120 blocks ?
mmcblk0p13 1500 blocks ?
mmcblk0p14 8192 blocks Mounts to /persist
mmcblk0p15 5120 blocks?
mmcblk0p16 1024 blocks?
mmcblk0p17 409600 blocks, Mounts to /system
mmcblk0p18 307200 blocks, Mounts to /cache
mmcblk0p19 892928 blocks, Mounts to /data
mmcblk0p20 122880 blocks, partition appears empty with a sting at the bottom of it reading ANDROID-BOOT!
mmcblk1 SD Card
mmcblk1p1 SD Card Partition
build.prop (Alltel phone):
build.prop
Source Code:
SourceForge Download Link
* In a recent patch I have found, the following code was in the install-recovery.sh file:
Code:
#!/system/bin/sh
if ! applypatch -c EMMC:/dev/block/mmcblk0p15:2048:afbffa74556cd8e77ef7e1a9d0964d9a2bd446b8; then
log -t recovery "Installing new recovery image"
applypatch EMMC:/dev/block/mmcblk0p8:4055040:9411e1fd06dfb3d8da4d1924162caf9e292ea652 EMMC:/dev/block/mmcblk0p15 20270fc8f6c8fca7dae0af5ce0928b589bd6b405 4296704 9411e1fd06dfb3d8da4d1924162caf9e292ea652:/system/recovery-from-boot.p
else
log -t recovery "Recovery image already installed"
fi
Any other information needed?
I'll look into getting a recovery working, but this is by no means a promise.
EDIT:
Something interesting:
The build.prop says the phone has a MSM7630_SURF board, and the Huawei U8800 has the same board, but not quite the same specs:
960C:
480x800
Multitouch
1400 Mhz CPU Sapdragon
512 MB RAM / 2048 MB ROM
Micro SD, 32 GB
3G
U8800:
480x800
Multitouch
800 Mhz CPU Snapdragon
512 MB RAM / 2048 MB ROM
Micro SD, 32 GB
AT&T has a 3g version
I'm betting these two are compatible, and the files I found contain some boot information.
Update:
I found the recovery.fstab for the U8800, doesn't look quite right does it:
Code:
# mount point fstype device [device2]
/boot mtd boot
/cache yaffs2 cache
/data yaffs2 userdata
/misc mtd misc
/recovery mtd recovery
/sdcard vfat /dev/block/mmcblk0p1 /dev/block/mmcblk0
/system yaffs2 system
I'm not sure how exactly to make this resemble the above partition table...
Update:
More information:
U-boot seems to support this board? Maybe this is good?
http://lists.denx.de/pipermail/u-boot/2012-February/118168.html
Also if anyone else wants to take a stab at this, by all means. I'm having trouble getting the tools set up, but if someone with a little more experince wants to that would be great.

Haven't seen this
aldude999 said:
I have the kernel source here, they have it released on SourceForge I'm guessing you're right saying the bootloader is locked.
Here's some information I've found on the partitions:
mmcblk0 Internal Memory
mmcblk0p1 Mounted using VFAT Contains files pertaining to FOTA (FOTA partition?)
mmcblk0p2 500 blocks ?
mmcblk0p3 1500 blocks ?
mmcblk0p4 1 BLOCK ?
mmcblk0p5 1000 blocks ?
mmcblk0p6 2000 blocks ?
mmcblk0p7 3072 blocks ?
mmcblk0p8 5120 blocks Possible Recovery*
mmcblk0p9 7000 blocks ?
mmcblk0p10 3027 blocks ?
mmcblk0p11 3072 blocks ?
mmcblk0p12 5120 blocks ?
mmcblk0p13 1500 blocks ?
mmcblk0p14 8192 blocks Mounts to /persist
mmcblk0p15 5120 blocks?
mmcblk0p16 1024 blocks?
mmcblk0p17 409600 blocks, Mounts to /system
mmcblk0p18 307200 blocks, Mounts to /cache
mmcblk0p19 892928 blocks, Mounts to /data
mmcblk0p20 122880 blocks, partition appears empty with a sting at the bottom of it reading ANDROID-BOOT!
mmcblk1 SD Card
mmcblk1p1 SD Card Partition
build.prop (Alltel phone):
build.prop
Source Code:
SourceForge Download Link
* In a recent patch I have found, the following code was in the install-recovery.sh file:
Code:
#!/system/bin/sh
if ! applypatch -c EMMC:/dev/block/mmcblk0p15:2048:afbffa74556cd8e77ef7e1a9d0964d9a2bd446b8; then
log -t recovery "Installing new recovery image"
applypatch EMMC:/dev/block/mmcblk0p8:4055040:9411e1fd06dfb3d8da4d1924162caf9e292ea652 EMMC:/dev/block/mmcblk0p15 20270fc8f6c8fca7dae0af5ce0928b589bd6b405 4296704 9411e1fd06dfb3d8da4d1924162caf9e292ea652:/system/recovery-from-boot.p
else
log -t recovery "Recovery image already installed"
fi
Any other information needed?
I'll look into getting a recovery working, but this is by no means a promise.
EDIT:
Something interesting:
The build.prop says the phone has a MSM7630_SURF board, and the Huawei U8800 has the same board, but not quite the same specs:
960C:
480x800
Multitouch
1400 Mhz CPU Sapdragon
512 MB RAM / 2048 MB ROM
Micro SD, 32 GB
3G
U8800:
480x800
Multitouch
800 Mhz CPU Snapdragon
512 MB RAM / 2048 MB ROM
Micro SD, 32 GB
AT&T has a 3g version
I'm betting these two are compatible, and the files I found contain some boot information.
Update:
I found the recovery.fstab for the U8800, doesn't look quite right does it:
Code:
# mount point fstype device [device2]
/boot mtd boot
/cache yaffs2 cache
/data yaffs2 userdata
/misc mtd misc
/recovery mtd recovery
/sdcard vfat /dev/block/mmcblk0p1 /dev/block/mmcblk0
/system yaffs2 system
I'm not sure how exactly to make this resemble the above partition table...
Update:
More information:
U-boot seems to support this board? Maybe this is good?
http://lists.denx.de/pipermail/u-boot/2012-February/118168.html
Also if anyone else wants to take a stab at this, by all means. I'm having trouble getting the tools set up, but if someone with a little more experince wants to that would be great.
Click to expand...
Click to collapse
Hello, I haven't looked into this thread for a while. I see that you have some info for these blocks. that I couldn't get. I tried using root explorer, to look into some files, and they couldn't load, and tried to use too much memory, just to attempt to open, which, my phone said it was low on memory. Hate gingerbread, and kwansi choi( maker of this rom), This phone could easily handle a later os.
The usb ID's, are "Device 007: ID 1bbb:9018" .

USB ID's
The usb ID's are 1bbb/9018 . I built a clockworkmod File, and the status is ok, but it still won't flash, because of the bootloader.

reggjoo said:
The usb ID's are 1bbb/9018 . I built a clockworkmod File, and the status is ok, but it still won't flash, because of the bootloader.
Click to expand...
Click to collapse
I noticed that:
mmcblk0p15
mmcblk0p12
mmcblk0p8
all have the same number of blocks.
The FOTA code shows
applypatch EMMC:/dev/block/mmcblk0p8:4055040:9411e1fd06dfb3d8da4d1924162caf9e292ea652 EMMC:/dev/block/mmcblk0p15 20270fc8f6c8fca7dae0af5ce0928b589bd6b405 4296704 9411e1fd06dfb3d8da4d1924162caf9e292ea652:/system/recovery-from-boot.p
Click to expand...
Click to collapse
applypatch useage is as follows:
applypatch [-b <bonus-file>] <src-file> <tgt-file> <tgt-sha1> <tgt-size> [<src-sha1>:<patch> ...]
or applypatch -c <file> [<sha1> ...]
or applypatch -s <bytes>
or applypatch -l
Click to expand...
Click to collapse
Apply patch from blk8 to blk15.
So maybe I was mistaken with what I thought was the partition. Blk8 seems to be where fota grabs it's updated partition from?
This shows that blk15 may actually be the recovery partition. Still useless unless the bootloader can be worked on.

Battery terminals
As we know, if the battery is out, the phone will do nothing( unlike my old huawei, it didn't matter). I wondered if that was the reason why, it's so hard to unlock it. I think the bootloader has been set up to not respond to attempts. The bootloader condition treats the phone as if there's no power to it(?) . I found out that the middle terminals, of the battery contacts, will power the phone, if they're connected, but only for a few seconds.
Maybe there's some code that's unknown, or procedure. The phone doesn't respond to fastboot commands, and I can't enable it(function), on it. In the default.prop file, I see that ro.secure, is 1. Whenever I try to change it to 0( in rewritable mode), it never takes. So this is a little info.

reggjoo said:
The bootloader condition treats the phone as if there's no power to it(?)
Click to expand...
Click to collapse
You know, it's interesting that you mention that. I remember watching a Ben Heck episode, and on an Xbox 360 controller keypad, he had to open it up and connect power to the PIC chip manually. It almost makes me wonder if there's possibly a jumper of some sort on the motherboard somewhere that when connected allows writing? It would be an extremely long shot, I'm even pretty sure that it's the exact board in the Huawei but it's weird that fastboot can't be entered. I've heard that their drivers might be messed up (maybe even on purpose) that could keep you from using fastboot.

aldude999 said:
You know, it's interesting that you mention that. I remember watching a Ben Heck episode, and on an Xbox 360 controller keypad, he had to open it up and connect power to the PIC chip manually. It almost makes me wonder if there's possibly a jumper of some sort on the motherboard somewhere that when connected allows writing? It would be an extremely long shot, I'm even pretty sure that it's the exact board in the Huawei but it's weird that fastboot can't be entered. I've heard that their drivers might be messed up (maybe even on purpose) that could keep you from using fastboot.
Click to expand...
Click to collapse
Yes, I think alcatel's a little shady. I use a dual boot pc, and I found out, using the lsusb command, that the usb id's were different, than what the id's were for the supposedly official usb drivers. Sent them a msg, and they said I was wrong( can't be wrong if everything works!). They take no responsibility for their hardware, and I let people know, every chance I get, whenever I see a review of a phone from them. I found out the id's were wrong, when, before I even rooted it, I installed their onetouchmanager, and it couldn't find my phone( what! out the box!). That's not the way you do things.

Bringing 960C Back To Life!!!
Did anyone ever find a ROM that's compatible with the 960C? I recently found one floating around a storage unit and, naturally, I immediately rooted it only to find out that no one ever bothered developing a custom ROM.
I'm sure if an official ROM was never created specifically for the 960C, it's definitely not gonna happen at this point. I'm thinking that the only hope for the 960C is if it was similar enough to a more popular phone that HAS a custom ROM, maybe someone, somewhere, was successful in modding it just enough to make it compatible with the 960C...
During my research/investigation into a ROM, there was at least one (*HERE*) forum post mentioning someone attempting to mod an existing ROM (for a more popular phone) to make it compatible but it seems that everyone lost interest back in 2013...

thealexday said:
Did anyone ever find a ROM that's compatible with the 960C? I recently found one floating around a storage unit and, naturally, I immediately rooted it only to find out that no one ever bothered developing a custom ROM.
I'm sure if an official ROM was never created specifically for the 960C, it's definitely not gonna happen at this point. I'm thinking that the only hope for the 960C is if it was similar enough to a more popular phone that HAS a custom ROM, maybe someone, somewhere, was successful in modding it just enough to make it compatible with the 960C...
During my research/investigation into a ROM, there was at least one (*HERE*) forum post mentioning someone attempting to mod an existing ROM (for a more popular phone) to make it compatible but it seems that everyone lost interest back in 2013...
Click to expand...
Click to collapse
I still am using my 960c. I wouldn't mind finding the original stock rom or finding out how to upgrade to a newer android version. Currently running version 2.3.6
Too bad I don't know much about modding save for rooting and flashing. I gather there are still some of us here who really like our 960c phones otherwise.

Corrupt data partition, no network, bootloops

I'm posting this in the hope that it will help someone else. The problems I've had are different enough from other threads that this story could provide some clues for someone else. I am also using a mac, so I'm using Heimdall instead of Odin.
I have an sph-l900, galaxy note 2, on Credo Mobile which is on the Sprint network - obviously.
1. My phone started acting strangely and at some point no longer had a carrier. Red X next to the signal meter.
2. Under Status, IMEI and everything else was unknown.
Everything I read said to reset the phone to a stock rom.
Since I had TWRP, I just tried flashing the usual way from the external sdcard. What I noticed is that I was getting an error on wipe,
'can not mount /data' - this is the big clue I didn't see for a while. It's the cause of bootloops after a flash from TWRP and the cause
of the lost network.
This meant that no matter what I did, When I flashed from TWRP I got a bootloop because the Dahlvik cache was not wiped.
I had to resort to putting the phone in odin mode, and use heimdall to flash all the images.
I made a shell command out of this:
heimdall flash --RECOVERY recovery.img --CACHE cache.img --HIDDEN hidden.img --SYSTEM system.img --TOMBSTONES tombstones.img --RADIO modem.bin --BOOT boot.img --PARAM param.bin --TZSW tz.img --BOOTLOADER sboot.bin --no-reboot --verbose
You can use 'heimdall print-pit' to find out what your partition names are. They are probably uppercase like mine.
Finally I'm booting, but still no carrier. I put TWRP back and tried to mount /data. Still no good.
This means that this rom is where I'm stuck until I can get /data mounting again.
Then I added --repartition --pit T0LTE.pit to my heimdall command. This failed every time. Although repartition was clearly what I needed.
Finally, I removed the --repartition, got it working without /data so I could connect using ADB shell to try repairing /data.
1. cd /etc
2. df to see the file systems. /data is clearly missing.
/etc # df
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 916024 136 915888 0% /dev
tmpfs 916024 20 916004 0% /tmp
tmpfs 916024 0 916024 0% /storage
tmpfs 916024 0 916024 0% /mnt/secure
tmpfs 916024 0 916024 0% /mnt/fuse
/dev/block/mmcblk0p12
1290112 40712 1249400 3% /cache
3. cat fstab or vold.fstab on older systems -- shows the mountpoints. So I could determine that /data was /dev/block/mmcblk0p16
/etc # cat fstab
/dev/block/mmcblk0p12 /cache ext4 rw
/dev/block/mmcblk0p16 /data ext4 rw
/dev/block/mmcblk0p13 /system ext4 rw
/dev/block/mmcblk0p14 /preload ext4 rw
4. Try to run file system check.
/etc # /sbin/e2fsck /dev/block/mmcblk0p16
e2fsck 1.41.14 (22-Dec-2010)
/sbin/e2fsck: Superblock invalid, trying backup blocks...
/sbin/e2fsck: Bad magic number in super-block while trying to open /dev/block/mmcblk0p16
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
4. Get info about the file system. with make file system.
/etc # /sbin/mke2fs -n /dev/block/mmcblk0p16
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
5136 inodes, 20480 blocks
1024 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=20971520
3 block groups
8192 blocks per group, 8192 fragments per group
1712 inodes per group
Superblock backups stored on blocks:
8193
5. Try file system check with the superblock backup.
/etc # /sbin/e2fsck -b 8193 /dev/block/mmcblk0p16
e2fsck 1.41.14 (22-Dec-2010)
/sbin/e2fsck: Invalid argument while trying to open /dev/block/mmcblk0p16
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
6. I have no choice but to try to restore the superblocks. mke2fs with -S will try to do that. I added the block size and groups
from the previous report, but I don't think they were necessary.
etc # mke2fs -b 1024 -g 8192 -S /dev/block/mmcblk0p16
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
5136 inodes, 20480 blocks
1024 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=20971520
3 block groups
8192 blocks per group, 8192 fragments per group
1712 inodes per group
Superblock backups stored on blocks:
8193
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 37 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
7. Run file system check again to repair any damage. Answer y to any questions.
/etc # /sbin/e2fsck /dev/block/mmcblk0p16
e2fsck 1.41.14 (22-Dec-2010)
/dev/block/mmcblk0p16 contains a file system with errors, check forced.
Resize inode not valid. Recreate<y>? y
yes
Pass 1: Checking inodes, blocks, and sizes
Root inode is not a directory. Clear<y>? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Root inode not allocated. Allocate<y>? y
yes
/lost+found not found. Create<y>? yes
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: +(1--298) +(8193--8489) +(16385--16600)
Fix<y>? y
yes
Free blocks count wrong for group #0 (7893, counted=7892).
Fix<y>? yes
Free blocks count wrong (19667, counted=19666).
Fix<y>? y
yes
Inode bitmap differences: +1 +(3--10)
Fix<y>? yes
Free inodes count wrong for group #0 (1711, counted=1701).
Fix<y>? y
yes
Directories count wrong for group #0 (1, counted=2).
Fix<y>? yes
Free inodes count wrong (5135, counted=5125).
Fix<y>? y
yes
/dev/block/mmcblk0p16: ***** FILE SYSTEM WAS MODIFIED *****
/dev/block/mmcblk0p16: 11/5136 files (0.0% non-contiguous), 814/20480 blocks
8. Mount data and check to see everything is ok.
/etc # mount /data
/etc # df
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 916024 136 915888 0% /dev
tmpfs 916024 20 916004 0% /tmp
tmpfs 916024 0 916024 0% /storage
tmpfs 916024 0 916024 0% /mnt/secure
tmpfs 916024 0 916024 0% /mnt/fuse
/dev/block/mmcblk0p12
1290112 40712 1249400 3% /cache
/dev/block/mmcblk0p16
19827 161 18642 1% /data
9. Exit, reboot to Odin mode, Reflash the ROM with heimdall/odin just like before. - leave off the --repartition --pit...
10. Reboot.
I now have an almost working phone. It actually has a network connection. It would be safe at this point to call your phone service
tech support and have them walk you through setting up your phone again.
I do not know what it takes for other phones, but with the note 2, I removed the battery while it was booted up to force an network update.
This gave me a new PRL and set my phone number along with everything else. I now had a working phone,
but for some reason no data service.
11. Turn off wifi, update profile. I get session in progress error.
12. Remove battery while booted, wifi off.
13. Reboot. update profile again. data network established.
That's pretty much it. In a nutshell, I had a corrupt filesystem on /data. The initial indicator of this was no carrier signal with an X on it.
This also caused bootloops when reflashing from TWRP/CWM.
Restoring the /data filesystem and flashing a stock rom restored the carrier and allowed a PRL and Profile update to get the phone working again.
Don't turn on wifi right away, let the phone update the PRL and Profile, and get everything working first.

Not enough free space on /system to apply patches

Just want to give everyone a heads up, when attempting to apply OTA updates to my Nexus 7 2013, I was getting the error: "Not enough free space on /system to apply patches". The error was showing up in the recovery log and I was really confused. I tried reflashing various versions, but still all OTA updates would fail with the same error.
TL;DR: Turns out it was the cache, read on for the fix.
I found the following in the OTA update script:
"apply_patch_space(56661556) || abort("Not enough free space on /system to apply patches.");"
So I assumed that I should have at least 56 MB free in "/system"
Doing df would show this:
Code:
f:\AndroidADT\sdk\platform-tools>adb shell df
Filesystem Size Used Free Blksize
/dev 903.4M 56.0K 903.3M 4096
/sys/fs/cgroup 903.4M 12.0K 903.4M 4096
/mnt 903.4M 0.0K 903.4M 4096
/system 827.8M 819.5M [B]8.3M[/B] 4096
/cache 31.5M 4.2M 27.3M 4096
/data 26.4G 7.9G 18.5G 4096
/persist 14.5M 4.2M 10.2M 4096
/storage 903.4M 0.0K 903.4M 4096
/mnt/runtime/default/emulated: Permission denied
/storage/emulated 26.4G 7.9G 18.5G 4096
/mnt/runtime/read/emulated: Permission denied
/mnt/runtime/write/emulated: Permission denied
I didn't, and I couldn't figure out why.
The answer was, after much searching, is that the error message is wrong.
I found this here (ok, so I can't post links, just Google for "edify_generator.py")
Code:
def CacheFreeSpaceCheck(self, amount):
"""Check that there's at least 'amount' space that can be made
available on [B]/cache[/B]."""
self.script.append(('apply_patch_space(%d) || abort("Not enough free space '
'on [B]/system[/B] to apply patches.");') % (amount,))
Notice that the comment talks about /cache, while the error is showing /system.
Turns out my /cache was formatted incorrectly. All I had to do was reboot into the bootloader and then format the cache.
Code:
adb reboot bootloader
...wait for bootloader to start...
fastboot format cache
I just wanted to post this somewhere because I've been Googling for a while now and I've seen others get this error with no solution.
Oh, and the reason why it got into this messed up state is because I did:
Code:
fastboot flash cache cache.img
This was using the official images from Google. So don't ever do that

When you say cache was formatted "incorrectly", had you converted it to f2fs or something?

Thank you very much AlexPi, I can finally receive OTAs and avoid the hassle of flashing a new image, specially now that they are releasing more images with minor bug fixes for the same Android version (there are now 3 images for 6.0.0). I had one OTA of only 2 MB in size and I didn't want to flash a new image just because of this minor change.
I just enter (stock) recovery mode and selected "wipe cache" and it worked just fine after that, so it wasn't even necessary any USB data cable to execute adb and fastboot commands.
By the way, the error message was indeed wrong and it was already fixed.

Thanks. I also flashed the cache partition because I remember that it was effectively the same as wiping the cache. I guess that is not correct.