Just thinking out loud....
I don't know if the ICS leak flashes change the partition table, but the way my phone is set up, there's 11 partitions:
p1: /efs
p2: /system
p3: /cache
p4: The "Internal SD"
p5: A mere 2MB. Mostly blank (long stretches of 00 or FF), except for <1KB of... something. Nothing jumps out at me in the hexdump. Could just be leftover garbage from Gingerbread.
p6: /data
p7: 16MB. Definitely something important here. Strings present suggest it's related to, if not part of, the bootloader, or perhaps download mode.
p8: 5MB: Looks like an Android bootimg. Recovery?
p9: 8MB: Pretty sure this is where the Linux kernel and rootfs for the actual system resides.
p10: 8MB: Completely blank.
p11: 500MB. An ext4 filesystem containing only the Asphalt 6 video and screenshots that you'd find on the "Internal SD" of a freshly Odin'd Glide.
I wonder if p5 actually serves a purpose; if not, we could theoretically merge it, p4, and p6 into one gigantic /data partition. That may be a bit more useful for those running with large microSD cards.
Things we need to look at:
One, bootloader. Does it look for things at static offsets? Does it read the partition table?
Two, recovery. I'm guessing CWMR will read the partition table, but is it expecting certain partitions to contain certain things?
In both cases, it shouldn't be anything we can't work around by filling out partition numbers or stretches of NAND with blank partitions. But we'll need to know what the offsets need to be.
Just putting the thought out there.
PIT & GPT, custom PIT
Actually the last PIT partition contains GPT data, and what we've seen inside the booted system comes out of GPT. But there is unallocated ~11Mb (according to GPT) before the first partition, and the PIT contains info about that!
cross-ref my thread: [Q] mmcblk0 Partiton table type (sgh-i927)
For now I'm looking a way of crafting my custom PIT-file, did you see any info about that?
Using CWM 5.0.2.0, when I try to format /data, I get:
Error formatting /data!
When I try to format /cache, I get:
Error formatting /cache!
This all started because I decided to try Albinoman's AOSP 4.2 ROM. This is what happened:
1. Booted into CWM 5.0.2.0, made a nandroid backup of stock GB ROM.
2. Installed Albinoman's ROM using CWM, wiped /cache and /data.
3. Booted Albinoman's ROM, no problems. Decided I wanted to backup and restore some apps in the old ROM using Titanium Backup.
4. Restored nandroid backup of stock ROM. When it rebooted, all was well.
5. Used Titanium Backup to back up my apps.
6. Installed Albinoman's ROM again.
7. Cleared /data, it was fine. Cleared /cache. Stuck at "formatting" for half an hour.
8. Rebooted back to recovery and tried it again. Couldn't find E:.
9. Tried letting it boot. Stuck on the boot animation for 30-minutes.
10. Wipe everything and re-flash. Tried again. Still stuck on boot animation.
11. Manually unmount and tried to format /data and /cache, and I get the error messages.
I had installed Convert2Ext4_no_data_limit_normal_dalvik.zip to the stock ROM about 4-months ago, not sure if that makes a difference or not.
When I search, it looks like the news is bad... most people that had this error gave up and believed it to be hardware NAND failure. Anything I can do to confirm or rule out NAND failure?
UPDATE: Managed to flash RUU, but results were interesting. It worked and it boots, home screen is blank (no HTC widgets), and apps I'd installed are still there. Clear Storage and Factory Reset does not get rid of them! I can manually uninstall apps, but when I reboot, they come back. I guess the /data must be stuck in some kind of read-only state.
GnatGoSplat said:
Using CWM 5.0.2.0, when I try to format /data, I get:
Error formatting /data!
When I try to format /cache, I get:
Error formatting /cache!
This all started because I decided to try Albinoman's AOSP 4.2 ROM. This is what happened:
1. Booted into CWM 5.0.2.0, made a nandroid backup of stock GB ROM.
2. Installed Albinoman's ROM using CWM, wiped /cache and /data.
3. Booted Albinoman's ROM, no problems. Decided I wanted to backup and restore some apps in the old ROM using Titanium Backup.
4. Restored nandroid backup of stock ROM. When it rebooted, all was well.
5. Used Titanium Backup to back up my apps.
6. Installed Albinoman's ROM again.
7. Cleared /data, it was fine. Cleared /cache. Stuck at "formatting" for half an hour.
8. Rebooted back to recovery and tried it again. Couldn't find E:.
9. Tried letting it boot. Stuck on the boot animation for 30-minutes.
10. Wipe everything and re-flash. Tried again. Still stuck on boot animation.
11. Manually unmount and tried to format /data and /cache, and I get the error messages.
I had installed Convert2Ext4_no_data_limit_normal_dalvik.zip to the stock ROM about 4-months ago, not sure if that makes a difference or not.
When I search, it looks like the news is bad... most people that had this error gave up and believed it to be hardware NAND failure. Anything I can do to confirm or rule out NAND failure?
UPDATE: Managed to flash RUU, but results were interesting. It worked and it boots, home screen is blank (no HTC widgets), and apps I'd installed are still there. Clear Storage and Factory Reset does not get rid of them! I can manually uninstall apps, but when I reboot, they come back. I guess the /data must be stuck in some kind of read-only state.
Click to expand...
Click to collapse
Did you reflash the Convert2Ext4 mod after you flashed the new rom? See this thread and read the top part after 'IMPORTANT:' There is a link in there to the old thread as well with a lot of info.
I did try that, but my /data and /cache are still unable to be written to, wiped, or formatted.
e2fsck won't touch /data, it has a superblock error. It finds errors on /cache and appears to be fixing them, but when I re-run it, the same errors are still there.
GnatGoSplat said:
I did try that, but my /data and /cache are still unable to be written to, wiped, or formatted.
e2fsck won't touch /data, it has a superblock error. It finds errors on /cache and appears to be fixing them, but when I re-run it, the same errors are still there.
Click to expand...
Click to collapse
Since you flashed the RUU, did you install an EXT4 compatible kernel or are you using the stock kernel? Maybe try restoring your working nandroid backup, then run the .zip to revert Convert2Ext4. Or even better, if you have a nandroid from before you installed the EXT4 mod.
DaggerDave said:
Since you flashed the RUU, did you install an EXT4 compatible kernel or are you using the stock kernel? Maybe try restoring your working nandroid backup, then run the .zip to revert Convert2Ext4. Or even better, if you have a nandroid from before you installed the EXT4 mod.
Click to expand...
Click to collapse
Wiping /data and /cache are enough to revert the mod.
Sent from my Galaxy Nexus using Tapatalk 2
Uggh, definitely doesn't sound so good. Since the RUU won't work, I'd say check out this thread:
http://forum.xda-developers.com/showthread.php?t=2123966
Yep, my partitions are no longer EXT4. #1 is EXT3 and #2 is EXT2. I guess that means Convert2Ext4 is no longer in play and the problem is unrelated.
Here is my parted:
Code:
parted /dev/block/mmcblk0 print
Model: MMC SEM08G (sd/mmc)
Disk /dev/block/mmcblk0: 7944MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 8192B 797MB 797MB primary ext3
2 797MB 1007MB 210MB primary ext2
3 1007MB 7944MB 6937MB primary fat32 lba
Yeah, I read that thread and it didn't sound encouraging! I get pretty much the same errors.
Even rm 1 and rm 2 don't remove the partitions. It's like they're read-only. I'm using the parted from CWM 5.0.2.0. Should I use a different one?
Also when I try e2fsck on it:
Code:
~ # e2fsck -pf /dev/block/mmcblk0p1
e2fsck -pf /dev/block/mmcblk0p1
/dev/block/mmcblk0p1: recovering journal
e2fsck: unable to set superblock flags on /dev/block/mmcblk0p1
~ # e2fsck -pf /dev/block/mmcblk0p2
e2fsck -pf /dev/block/mmcblk0p2
/dev/block/mmcblk0p2: Unconnected directory inode 34817 (/???)
/dev/block/mmcblk0p2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
~ # e2fsck -f /dev/block/mmcblk0p2
e2fsck -f /dev/block/mmcblk0p2
e2fsck 1.41.6 (30-May-2009)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Unconnected directory inode 34817 (/???)
Connect to /lost+found<y>? y
yes
Pass 4: Checking reference counts
Inode 2 ref count is 2, should be 3. Fix<y>? yes
Inode 34817 ref count is 3, should be 2. Fix<y>? y
yes
Pass 5: Checking group summary information
Block bitmap differences: +274 +(449--510) +(645--701) -(139524--139541) -(139
85--139800)
Fix<y>? yes
Free blocks count wrong for group #0 (7919, counted=7799).
Fix<y>? y
yes
Free blocks count wrong for group #17 (7934, counted=7929).
Fix<y>? yes
Free blocks count wrong (198324, counted=198199).
Fix<y>? y
yes
Free inodes count wrong for group #17 (2048, counted=2045).
Fix<y>? yes
Directories count wrong for group #17 (0, counted=1).
Fix<y>? y
yes
Free inodes count wrong (51189, counted=51186).
Fix<y>? yes
/dev/block/mmcblk0p2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/block/mmcblk0p2: 14/51200 files (14.3% non-contiguous), 6601/204800 blocks
When I tried it without the -p is when it looks above like it's fixing something, but it really didn't fix anything because it does the same thing when I try e2fsck again (as if it's read-only).
Is MMCBLK0 one physical NAND chip? If so, how come I can read/write/erase the /emmc with no problems? Isn't that just another partition on the same NAND disk?
If /data and /cache are really bad, is there any possible way to do an equivalent of a low-level format on the NAND and repartition?
Is booting CWM 5.0.2.0 and using adb shell supposed to have root privileges?
I can't modify the partition table using either parted or fdisk. I even tried zeroing the partitions using dd if=/dev/zero of=/dev/block/mmcblk0p1, p2, and even the whole of mmcblk0, but nothing actually gets written.
Since it seems like the NAND is probably irreparably borked, can I approach this problem from a different angle?
Can I partition my sdcard with an ext3 and ext2 partition, and tell Android to use those as /data and /cache respectively?
What in Android maps /dev/block/mmcblk0p1 to /data and /dev/block/mmcblk0p2 to /cache, and can I change those to point to partitions on sdcard?
Or is that hard-coded into the kernel?
GnatGoSplat said:
Since it seems like the NAND is probably irreparably borked, can I approach this problem from a different angle?
Can I partition my sdcard with an ext3 and ext2 partition, and tell Android to use those as /data and /cache respectively?
What in Android maps /dev/block/mmcblk0p1 to /data and /dev/block/mmcblk0p2 to /cache, and can I change those to point to partitions on sdcard?
Or is that hard-coded into the kernel?
Click to expand...
Click to collapse
It is hard coded into the kernel. To get root in adbshell try typimg su. This seems to be happening to more and more people as these phones get up there in age.
GnatGoSplat said:
Since it seems like the NAND is probably irreparably borked, can I approach this problem from a different angle?
Can I partition my sdcard with an ext3 and ext2 partition, and tell Android to use those as /data and /cache respectively?
What in Android maps /dev/block/mmcblk0p1 to /data and /dev/block/mmcblk0p2 to /cache, and can I change those to point to partitions on sdcard?
Or is that hard-coded into the kernel?
Click to expand...
Click to collapse
The answer is yes to both actually. Thrle boot.img would need to be customized. The best way is a flashable zip in recovery. Data and cache would need to be wiped manually ad recovery will not pick this up. Expect poorer performance though as SD cards tend to be slower than built in storage.
Sent from my Galaxy Nexus using Tapatalk 2
Thanks! So it sounds like the way to make this work is to compile a custom kernel? I don't know the first thing about it, but I think I could learn.
This is only in the kernel, so I could flash any 3rd party D-Inc ROM and just flash my customized kernel and it will see /data and /cache on the sdcard?
I could probably get one of those fast Class 10 cards if it turns out this is too slow, but I do recall changing vold.fstab once to fool Android into seeing /emmc as /sdcard and the /emmc (as /sdcard) didn't benchmark all that much faster than a real sdcard. I'm assuming /data and /cache are the same speed as /emmc since they're on the same mmcblk0 device, so I'm thinking maybe sdcard performance would be acceptable.
This actually sounds like it could be a better long-term solution than replacing the motherboard because no telling if a new motherboard will fail soon too.
The motherboard should be reliable. Emmc may die. Especially considering how old current dincs are.
I was talking about the boot.img which is not ROM independent and kernels aren't always either. Best idea is a flashable zip to modify the ram disk but I need the partition names if you decide to do it. I recommend keeping cache and data in the same order.
Also there would need to be a flashable wipe script to wipe data and cache.
Sent from my Galaxy Nexus using Tapatalk 2
Sorry, I wasn't very clear. By motherboard failing, I was assuming NAND is soldered to the motherboard, and if that's the case, ruined NAND = ruined motherboard. I had thought maybe I could buy a DInc with smashed LCD and good motherboard and just swap into mine (because mine is MINT condition), but I thought if I do that, I could very well end up in the same place as I'm in now and using sdcard would be more of a guarantee I wouldn't have to worry about this again.
I think I understand, the boot.img and kernel aren't exactly the same thing, but the kernel is part of boot.img? Or is it only the RAMDisk that needs changed, or both? You mentioned partition names, are you offering to make these modifications for me?
By same order, do you mean because mmcblk0p1 is /data, mmcblk0p2 is /cache, and mmcblkp3 is /emmc, I should partition my sdcard the same way with data 1st, cache 2nd, and sdcard 3rd?
Should I partition it with the phone, PC, or does it matter? Should the sizes of the new /data and /cache be the same size as original, or is there any reason I should make them larger?
Could I wipe the new /data and /cache simply by booting into Recovery and using adb shell and format them?
Also, the commands I was issuing in adb shell were from booting into CWM Recovery. Is it possible that mode can't write because I didn't login as root using the su command? I hadn't thought that would be the problem seeing as how the RUU and Android itself can't write to /data and /cache and other people managed to fix partition problems without needing to run su.
GnatGoSplat said:
Sorry, I wasn't very clear. By motherboard failing, I was assuming NAND is soldered to the motherboard, and if that's the case, ruined NAND = ruined motherboard. I had thought maybe I could buy a DInc with smashed LCD and good motherboard and just swap into mine (because mine is MINT condition), but I thought if I do that, I could very well end up in the same place as I'm in now and using sdcard would be more of a guarantee I wouldn't have to worry about this again.
I think I understand, the boot.img and kernel aren't exactly the same thing, but the kernel is part of boot.img? Or is it only the RAMDisk that needs changed, or both? You mentioned partition names, are you offering to make these modifications for me?
By same order, do you mean because mmcblk0p1 is /data, mmcblk0p2 is /cache, and mmcblkp3 is /emmc, I should partition my sdcard the same way with data 1st, cache 2nd, and sdcard 3rd?
Should I partition it with the phone, PC, or does it matter? Should the sizes of the new /data and /cache be the same size as original, or is there any reason I should make them larger?
Could I wipe the new /data and /cache simply by booting into Recovery and using adb shell and format them?
Also, the commands I was issuing in adb shell were from booting into CWM Recovery. Is it possible that mode can't write because I didn't login as root using the su command? I hadn't thought that would be the problem seeing as how the RUU and Android itself can't write to /data and /cache and other people managed to fix partition problems without needing to run su.
Click to expand...
Click to collapse
The NAND is likely soldered to the motherboard, so you're right about that.
To answer your first question, yeah, the kernel is part of the boot.img. The other part is the RAMdisk which is the only thing that needs to be changed.
Partition it in the same order. Probably parted via adb shell. 100MB for cache and at least 750MB for data. Sizes don't matter too much but you want enough.
adb shell has root access automatically in recovery. The issue is hardware most likely so your proposed workaround may be the only option.
First plan of attack is to find the partition names which would be mmcblk1p1 and mmcblk1p1 if you partition the sdcard the same way as the ROM is partitioned. Ideally you need to be able to fix the partitions themselves. I'll try to give more info later.
I copied the partition sizes from mmcblk0, so here's what I have on my 16GB SD card:
Code:
Model: SD SA16G (sd/mmc)
Disk /dev/block/mmcblk1: 16.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 8192B 797MB 797MB primary ext2
2 797MB 1007MB 210MB primary ext2
3 1007MB 16.0GB 15.0GB primary fat32 lba
mmcblk1p1 for /data
mmcblk1p2 for /cache
mmcblk1p3 for /sdcard
Will that work? I couldn't get mmcblk1p1 to show up as ext3. I did use mke2fs -j /dev/block/mmcblk1p1 to format it and I've read ext3 = ext2+journal, so I guess the fact it's not saying "ext3" under filesystem is okay?
GnatGoSplat said:
I copied the partition sizes from mmcblk0, so here's what I have on my 16GB SD card:
Code:
Model: SD SA16G (sd/mmc)
Disk /dev/block/mmcblk1: 16.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 8192B 797MB 797MB primary ext2
2 797MB 1007MB 210MB primary ext2
3 1007MB 16.0GB 15.0GB primary fat32 lba
mmcblk1p1 for /data
mmcblk1p2 for /cache
mmcblk1p3 for /sdcard
Will that work? I couldn't get mmcblk1p1 to show up as ext3. I did use mke2fs -j /dev/block/mmcblk1p1 to format it and I've read ext3 = ext2+journal, so I guess the fact it's not saying "ext3" under filesystem is okay?
Click to expand...
Click to collapse
You would be correct. Yes, that's fine.
Thanks, what should be my next steps?
GnatGoSplat said:
Thanks, what should be my next steps?
Click to expand...
Click to collapse
I'll have to find time to make scripts that will modify the ramdisk, unless you can just extract it and make the changes yourself.
That would be great, I really appreciate all the help so far.
Do you think ramdisk is the only place a change will need to be made?
I was trying to see if I could figure out how to extract ramdisk from boot.img and found a perl script, but I haven't gotten around to playing with it.
My DInc NAND went bad, it became read-only and could not be written to. This is the 8GB NAND that houses /data, /cache, and /emmc partitions.
Tiny came out with a nice little patch for me, to patch custom ROMs in order to use partitions on the physical SD card as /data and /cache. That worked well for awhile, though with an occasional glitch where I'd get random factory resets. Anyway, I don't use the DInc anymore, thinking to fix it with a new motherboard from a cracked screen phone or something and selling it. Probably won't hardly go for anything, but it's not doing me much good sitting around. With that plan in mind, I decided to pull the bad NAND chip just to see how hard that is. Got a new SMD rework station and figured it's something I could goof off with on a boring Saturday morning. It came out without much fuss.
Anyhow, now the phone won't boot CM11 with the NAND chip missing. The phone does try to boot because /boot and /system are on a different NAND chip, but now it's not seeing /data or /cache on the physical SD card, at least that's my guess. I do plan to replace the motherboard, but mainly just curious why it no longer works. Is because of partition order? Because I lost 3 bad read-only partitions, the partition count is now off?
I knew it was possible I'd end up killing my DInc by pulling the bad NAND and I'm not too broken up about it. Mainly just curious why it no longer works, and kind of wondering if it's possible to fix.
Figured out some stuff.
With bad NAND chip removed, MicroSD takes its place as /dev/block/mmcblk0.
In a way, this is kind of good. If I make 3 partitions on MicroSD, I no longer need to use Tiny's patch or a custom recovery to map everything to mmcblk1. I can now use the same TWRP recovery everyone else uses and it recognizes mmcblk0p1 as /data, mmcblk0p2 as /cache, and mmcblk0p3 as /emmc.
Even CM11 and Evervolve 4.4.4 work without any patch and recognizes mmcblk0p1 as /data, mmcblk0p2 as /cache.
However, neither ROM maps mmcblk0p3 to anything. /sdcard, /emmc, /storage/sdcard0, /storage/sdcard1, none of those are mapped to mmcblk0p3.
UPDATE: Figured it out. Had to change /devices/platform/msm_sdcc.3/mmc_host/mmc2 to /devices/platform/msm_sdcc.2/mmc_host/mmc1 in fstab.inc.
just wondering, how are you determining that you have a bad nand chip? are you running any sort of test that can tell you definitely?
I have 3 dincs, 2 that I bought refurbished and used on eBay that seem to have been repaired(the water damage sticker has been tripped). I always assumed that the HTC Dinc was just a weak, limited and terrible phone due to bad 1st generation design. My phones had been prone to rebooting and errors due to the small system app partition. But they have worked reasonably well for me the last 3-4 years.
I upgraded all 3 to the latest evervolv 4.0 version with TWRP 2.6.3 and 2 of the 3 seem to have taken the upgrade well. have the 3rd one constantly reboots when trying to access anything via the play store. The internal 8 gig EMMC card had disappeared from it and also at times, the wifi controller disappears. I down graded it all the way back to Tiny 5-16(which it had run for the last 2 years) and it stabilized for the most part with the EMMC being seen again. Do you think the missing EMMC partition is a sure indicator that the memory on the phone is bad?
Here is the full thread:
http://forum.xda-developers.com/showthread.php?t=2175346
But long story short, I couldn't write to the eMMC chip at all. Not only my /emmc partition was read-only like some people had happen and could fix with fsck_msdos, but my entire eMMC chip, which means /data, /cache, and /emmc were read-only. RUU couldn't fix it, fsck couldn't fix it, and even attempting to remove and rebuild partitions using parted couldn't fix it.
I'm not sure if losing the /emmc partition by itself means the chip is bad. The chip also has the /data and /cache partitions. I'd think if either of those go offline, all your apps will start to FC. Although you did say it constantly reboots, and I think that's possible when /data and /cache go offline. I think mine actually did reboot an awful lot on its own before the eMMC chip went completely bad. You might try running e2fsck -c to check for bad blocks.