I was running Chucktr's CM11 12.16 rom. Went to turn on phone, and got a black screen after the white HTC boot up screen. When I did get it to boot to the bootloader, the recovery did not work either. I got TWRP 2.8.0.1 installed, and can see from there, that there is problems mounting.
E: Primary block device /dev/block/mmcblk0p35 for mount point '/data' is not present!
E: Unable to recreate and-sec folder.
Updating partition details...
e: Unable to mount '/cache'
E: Unable to mount '/data'
E: Unable to mount '/system'
and so on.
Update 2/22/15: Results of parted
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) p
p
p
Error: Invalid partition table on /dev/block/mmcblk0 -- wrong signature 0.
Ignore/Cancel? i
i
i
Model: MMC KYL00M (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 512B 132kB 131kB primary boot
2 132kB 394kB 262kB primary
3 394kB 33.5MB 33.1MB primary
4 33.5MB 15.8GB 15.7GB extended
5 33.5MB 33.6MB 16.4kB logical
6 33.6MB 33.8MB 262kB logical
7 33.8MB 54.8MB 20.9MB logical
8 54.8MB 55.0MB 262kB logical
9 55.0MB 56.1MB 1049kB logical
10 56.1MB 56.3MB 262kB logical
11 56.3MB 58.4MB 2097kB logical
12 58.4MB 59.5MB 1049kB logical
13 59.5MB 59.5MB 32.8kB logical
14 59.5MB 65.8MB 6291kB logical
15 65.8MB 66.8MB 1049kB logical
16 66.8MB 67.1MB 262kB logical
17 67.1MB 109MB 41.9MB logical
18 109MB 151MB 41.9MB logical fat16
19 151MB 159MB 8388kB logical
20 159MB 168MB 8387kB logical
21 168MB 201MB 33.6MB logical fat16
22 201MB 218MB 16.8MB logical
23 218MB 235MB 16.8MB logical
24 235MB 252MB 16.8MB logical
Any ideas on where to start with fixing this?
amgold said:
I was running Chucktr's CM11 12.16 rom. Went to turn on phone, and got a black screen after the white HTC boot up screen. When I did get it to boot to the bootloader, the recovery did not work either. I got TWRP 2.8.0.1 installed, and can see from there, that there is problems mounting.
E: Primary block device /dev/block/mmcblk0p35 for mount point '/data' is not present!
E: Unable to recreate and-sec folder.
Updating partition details...
e: Unable to mount '/cache'
E: Unable to mount '/data'
E: Unable to mount '/system'
and so on.
Update 2/22/15: Results of parted
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) p
p
p
Error: Invalid partition table on /dev/block/mmcblk0 -- wrong signature 0.
Ignore/Cancel? i
i
i
Model: MMC KYL00M (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 512B 132kB 131kB primary boot
2 132kB 394kB 262kB primary
3 394kB 33.5MB 33.1MB primary
4 33.5MB 15.8GB 15.7GB extended
5 33.5MB 33.6MB 16.4kB logical
6 33.6MB 33.8MB 262kB logical
7 33.8MB 54.8MB 20.9MB logical
8 54.8MB 55.0MB 262kB logical
9 55.0MB 56.1MB 1049kB logical
10 56.1MB 56.3MB 262kB logical
11 56.3MB 58.4MB 2097kB logical
12 58.4MB 59.5MB 1049kB logical
13 59.5MB 59.5MB 32.8kB logical
14 59.5MB 65.8MB 6291kB logical
15 65.8MB 66.8MB 1049kB logical
16 66.8MB 67.1MB 262kB logical
17 67.1MB 109MB 41.9MB logical
18 109MB 151MB 41.9MB logical fat16
19 151MB 159MB 8388kB logical
20 159MB 168MB 8387kB logical
21 168MB 201MB 33.6MB logical fat16
22 201MB 218MB 16.8MB logical
23 218MB 235MB 16.8MB logical
24 235MB 252MB 16.8MB logical
Any ideas on where to start with fixing this?
Click to expand...
Click to collapse
Are you S-OFF? If you are, grab an RUU (a real RUU that is the EXE file that runs from Windows, not a flashable ZIP) and run it, reflash back to complete stock, and see if you can recovery that way, it is your best chance (sometimes this needs to be done twice)... If you are S-ON, well, you are probably screwed.
The real underlying issue here is WHY did the partition table get corrupted,the life of the flash memory in this device is less than expected by most people... a lot of Rez's die because of failure of the internal flash memory, I have seen several of them myself.
acejavelin said:
Are you S-OFF? If you are, grab an RUU (a real RUU that is the EXE file that runs from Windows, not a flashable ZIP) and run it, reflash back to complete stock, and see if you can recovery that way, it is your best chance (sometimes this needs to be done twice)... If you are S-ON, well, you are probably screwed.
The real underlying issue here is WHY did the partition table get corrupted,the life of the flash memory in this device is less than expected by most people... a lot of Rez's die because of failure of the internal flash memory, I have seen several of them myself.
Click to expand...
Click to collapse
Thanks for your reply. Unfortunately I am S-ON. I've looked unsuccessfully for a way to S-OFF without running software but have not found anything. Starting to feel like I now own a paperweight.
amgold said:
Thanks for your reply. Unfortunately I am S-ON. I've looked unsuccessfully for a way to S-OFF without running software but have not found anything. Starting to feel like I now own a paperweight.
Click to expand...
Click to collapse
Your chances of recovery at this point are very slim then... S-off is not possible on a non-bootable device, you can try multiple recoveries (CWM, TWRP, Amon Ra) and multiple format/wipes and flashing different ZIP packages, once in a while it recovers itself, but without access to the partition table via S-Off the chances are extremely low.
As I said before, the flash RAM in this device seems to be reaching its life span limits for lots of people... Nothing you did, it's just reaching its limits of writes and starting to fail.
acejavelin said:
Your chances of recovery at this point are very slim then... S-off is not possible on a non-bootable device, you can try multiple recoveries (CWM, TWRP, Amon Ra) and multiple format/wipes and flashing different ZIP packages, once in a while it recovers itself, but without access to the partition table via S-Off the chances are extremely low.
As I said before, the flash RAM in this device seems to be reaching its life span limits for lots of people... Nothing you did, it's just reaching its limits of writes and starting to fail.
Click to expand...
Click to collapse
This has to do with normal phone operation, right? Not how many times you've flashed ROMs? Curious because I rarely flash ROMs so wondering if that would mean my phone might have a longer life. I would be fine with it for another couple years.
feralicious said:
This has to do with normal phone operation, right? Not how many times you've flashed ROMs? Curious because I rarely flash ROMs so wondering if that would mean my phone might have a longer life. I would be fine with it for another couple years.
Click to expand...
Click to collapse
Emmc (your phones flash RAM) has a finite number of writes, when it reaches that point there is nothing you can do. It has nothing to do with flashing ROMs, it happens to completely stock devices as well... Like any other product, there are good ones and bad ones, some last longer than others, just the way it is. You didn't cause it to happen, normal use did, it was just it's time.
Related
Unfortunately, I don't have a backup of mmcblk0p5, but even if I try (out of desperation) to flash someone else's mmcblk0p5, ID doesn't change from zeros. I managed to run CM7 from external sdcard, but installing CM onto mmc doesn't seem to work.
Ubuntu Total Reflash from this forum flashed al successfully, but failed on recovering stage and since then it just bootloops to that point (boot -> factory reset fails -> reboot).
Now trying to flash stock ROM 1.4.0, but don't think it'll work. Any advice?
P.S. Now found something strange: mmcblkp7 (seventh partition is gone, and that seem to repeat after every recovery option I try).
Code:
Number Start (sector) End (sector) Size Code Name
1 256 511 128.0 KiB 8300 xloader
2 512 1023 256.0 KiB 8300 bootloader
3 1024 31743 15.0 MiB 8300 recovery
4 32768 65535 16.0 MiB 8300 boot
5 65536 163839 48.0 MiB 8300 rom
6 163840 262143 48.0 MiB 8300 bootdata
8 1019904 2273279 612.0 MiB 8300 system
9 2273280 3145727 426.0 MiB 8300 cache
10 3145728 5242879 1024.0 MiB 8300 media
11 5242880 30535639 12.1 GiB 8300 userdata
UPD.: Paste from parted's print after I create partition 7 (factory):
Code:
(parted) print
print
Model: MMC SEM16G (sd/mmc)
Disk /dev/block/mmcblk0: 15.9GB
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 16.3MB 15.7MB recovery
4 16.8MB 33.6MB 16.8MB boot
5 33.6MB 83.9MB 50.3MB rom
6 83.9MB 134MB 50.3MB fat32 bootdata
7 134MB 522MB 388MB ext4 factory
8 522MB 1164MB 642MB ext4 system
9 1164MB 1611MB 447MB ext4 cache
10 1611MB 2684MB 1074MB fat32 media
11 2684MB 15.6GB 12.9GB ext4 userdata
Your NT's factory installed device info (ProductID, manufactured data, etc.) and individual device data (serial no., MAC address, security encryption keys, etc.) are stored in p5 and p7, if you reformatted these two partitions all that info was wiped out and the individual device data can't be replaced with data from another NT. See http://forum.xda-developers.com/showpost.php?p=37515697&postcount=31 for more details.
digixmax said:
Your NT's factory installed device info (ProductID, manufactured data, etc.) and individual device data (serial no., MAC address, security encryption keys, etc.) are stored in p5 and p7, if you reformatted these two partitions all that info was wiped out and the individual device data can't be replaced with data from another NT. See http://forum.xda-developers.com/showpost.php?p=37515697&postcount=31 for more details.
Click to expand...
Click to collapse
Oh, that's unfortunate. I didn't wipe it by myself, it just suddenly got stuck after i got ~4% of battery charge the other day. Can I do something for it?
P.S. Or, if nothing can be done, what's the most simplistic/minimalistic yet full-[stock]-feature ROM for sdcard available? Disregarding Android verion.
digixmax said:
Your NT's factory installed device info (ProductID, manufactured data, etc.) and individual device data (serial no., MAC address, security encryption keys, etc.) are stored in p5 and p7, if you reformatted these two partitions all that info was wiped out and the individual device data can't be replaced with data from another NT. See http://forum.xda-developers.com/showpost.php?p=37515697&postcount=31 for more details.
Click to expand...
Click to collapse
Huh, seems like I did it. I even can't recall all the steps I performed, but it included just little more messing up with gdisk/parted, trying to wipe all data and caches through CWM and install CM10.1, but that failed as usually, so I just uploaded Veronica's mmcblk0p5 again, then I thought "wtf, let's give it another try" and applied Ubuntu Total Reflash procedure and it worked! All of a sudden, I have my factory-state Nook (saying nothing about case cracks and fractures ^_^).
So, now I'm going to share link to this post with all the people I think are relevant to this question and ask them: is that normal? Can I try to flash CM 10.1 now without *too much* risk of getting my dear brick again? Thanks in advance.
UPD: Checked ID, MAC and so on - seems to be different from 00...0, but I'm not sure whether it's still unique (i reckon that they are like Veronica's now).
UPD2: Installed CM 10.1 rather successfully. I guess, someone can add to FAQ that even with broken mmcblk0p5 one still could help himself.
I dont know about anyone else but the partition layout on the S3 LTE really bother's me it just wastes so much
has any work been done on seeing if resizing causes any problems
as im tempted to resize cache,system,hidden to pull back 1971mb of space wasted by samsung
then make a custom full odin package with the new partition sizes and flash
clearly i wouldnt be able to use standard samsung packages anymore and would have to make my own
which isnt a problem
All sizes are in true Megabyte/Gigabyte what is called Mib/Gib by people of late
to try and differentiate from the stupid ass rounding hd manufacturers started
TOMBSTONES = 256mb
CACHE = 1024mb
SYSTEM = 1536mb
HIDDEN = 560mb
Leaving 10.8GB for userdata
Im unsure what the tombstones dir is used for so i would be inclined to leave it
but cache can be dropped to 100mb if not using ota updates which i dont
system i could drop to 1024mb and be fine
i dont think hidden is used on the s3 lte
so i could pull back around 1971mb of wasted space
for userdatea with partitions like below
CACHE = 100mb
SYSTEM = 1024mb
HIDDEN = 1mb
Here's the current layout
Note it isnt even 16 fake GB
Model: MMC MAG4FB (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 4194kB 8389kB 4194kB BOTA0
2 8389kB 12.6MB 4194kB BOTA1
3 12.6MB 33.6MB 21.0MB ext4 EFS
4 33.6MB 37.7MB 4194kB m9kefs1
5 37.7MB 41.9MB 4194kB m9kefs2
6 41.9MB 46.1MB 4194kB m9kefs3
7 46.1MB 54.5MB 8389kB PARAM
8 54.5MB 62.9MB 8389kB BOOT
9 62.9MB 71.3MB 8389kB RECOVERY
10 71.3MB 164MB 92.3MB fat16 RADIO
11 164MB 432MB 268MB ext4 TOMBSTONES
12 432MB 1506MB 1074MB ext4 CACHE
13 1506MB 3116MB 1611MB ext4 SYSTEM
14 3116MB 3704MB 587MB ext4 HIDDEN
15 3704MB 3712MB 8389kB OTA
16 3712MB 15.8GB 12.0GB ext4 USERDATA
ShonkUK said:
I dont know about anyone else but the partition layout on the S3 LTE really bother's me it just wastes so much
has any work been done on seeing if resizing causes any problems
as im tempted to resize cache,system,hidden to pull back 1971mb of space wasted by samsung
then make a custom full odin package with the new partition sizes and flash
clearly i wouldnt be able to use standard samsung packages anymore and would have to make my own
which isnt a problem
All sizes are in true Megabyte/Gigabyte what is called Mib/Gib by people of late
to try and differentiate from the stupid ass rounding hd manufacturers started
TOMBSTONES = 256mb
CACHE = 1024mb
SYSTEM = 1536mb
HIDDEN = 560mb
Leaving 10.8GB for userdata
Im unsure what the tombstones dir is used for so i would be inclined to leave it
but cache can be dropped to 100mb if not using ota updates which i dont
system i could drop to 1024mb and be fine
i dont think hidden is used on the s3 lte
so i could pull back around 1971mb of wasted space
for userdatea with partitions like below
CACHE = 100mb
SYSTEM = 1024mb
HIDDEN = 1mb
Click to expand...
Click to collapse
You can do it with PIT Magic i did this before for S2 I'd like to do the same thing with s3 but i don't have the PIT file for the international version (My Phone )
I have a NOOK tablet 16GB that is somehow locked from modifying partitions
I have tried
the repart image , which has worked many times for me in the past
the AdamOutler Ubuntu Disk
formatting / wiping options in various versions of CWM and TWRP
fastboot erases
fastboot formats
dd'ing /zero to various partitions
parted
sgdisk
a zillion scripts
something at a low level is preventing modifications to the partitions
Im wasting far too much time on this , but I hate being beat (-:
I have a backup of rom and factory , and dd images of stock parttions so I am 100% comfortable with something that
will COMPLETELY ZAP the device
if I boot a known good CM10 image from SD card, it fails to boot , I was assuming if I could get a running android from the card, I'd have access to lots of tools... , but it just fails to tun CM10
any help appreciated.
Thanks
To completely zap the device, erase the partition table. That will leave you one, giant, unallocated space.
From there, you need to recreate all partitions from scratch.
You will not be able to boot without a bootable CWM SD, so have that handy.
sagirfahmid3 said:
To completely zap the device, erase the partition table. That will leave you one, giant, unallocated space.
From there, you need to recreate all partitions from scratch.
You will not be able to boot without a bootable CWM SD, so have that handy.
Click to expand...
Click to collapse
Thanks for responding, Yes, I have tried multiple ways to to zap the table and it doesnt stick.
sgdisk -Z, sgdisk -z parted,
no matter what I do the partitions remain untouched.
I reboot and it still boots into an old stock OS that has a FC shortly after startup, and the internal recovery (factory) , which I can not overwrite, gives the please restart and try again message.
hmm,
I WAS able to get a CM7 SD card image to boot and run
appears to work "normally" , but Internal storage shows as "not available" in settings
mikeataol said:
hmm,
I WAS able to get a CM7 SD card image to boot and run
appears to work "normally" , but Internal storage shows as "not available" in settings
Click to expand...
Click to collapse
You're supposed to do:
# gdisk
# o
# w
# q
That will for sure give you an empty partition table. You probably forgot to write the changes before exiting.
sagirfahmid3 said:
You're supposed to do:
# gdisk
# o
# w
# q
That will for sure give you an empty partition table. You probably forgot to write the changes before exiting.
Click to expand...
Click to collapse
Hi, no, I didnt forget to "write" after the "o"
/tmp # ./gdisk /dev/block/mmcblk0
./gdisk /dev/block/mmcblk0
GPT fdisk (gdisk) version 0.8.4
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.
Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
on the recovery & transformation menu to examine the two tables.
Warning! One or more CRCs don't match. You should repair the disk!
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged
****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
Command (? for help): o
o
This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N): y
y
Command (? for help): w
w
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
Do you want to proceed? (Y/N): y
y
OK; writing new GUID partition table (GPT) to /dev/block/mmcblk0.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
/tmp # q
/tmp #
after reboot
Command (? for help): p
p
Disk /dev/block/mmcblk0: 31105024 sectors, 14.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): CE21388C-B927-4A5C-91CE-DBD1DE4AB3BC
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 30535678
Partitions will be aligned on 256-sector boundaries
Total free space is 1285 sectors (642.5 KiB)
Number Start (sector) End (sector) Size Code Name
1 256 511 128.0 KiB 8300 xloader
2 512 1023 256.0 KiB 8300 bootloader
3 1024 31743 15.0 MiB 8300 recovery
4 32768 65535 16.0 MiB 8300 boot
5 65536 163839 48.0 MiB 8300 rom
6 163840 262143 48.0 MiB 8300 bootdata
7 262144 1019903 370.0 MiB 8300 factory
8 1019904 2273279 612.0 MiB 8300 system
9 2273280 3145727 426.0 MiB 8300 cache
10 3145728 5242879 1024.0 MiB 8300 media
11 5242880 30535639 12.1 GiB 8300 userdata
Humm...wow, that's pretty crazy. Try writing zeroes to your emmc and then retrying.
# dd if=/dev/zero of=/dev/block/mmcblk0
Is there any way to re-partition ROM eMMC ? since /cache has 500 MB ,it can be re - partitioned to merge into /data partition . so any body here know how to re-partition ROM ? is it possible ?
Parted dump:
Code:
31 106824kB 117268kB 10445kB boot
32 117268kB 127795kB 10527kB recovery
33 127795kB 603980kB 476185kB ext4 cache
34 603980kB 1543504kB 939524kB ext4 system
35 1543504kB 1551892kB 8389kB kpan
36 1551892kB 3958768kB 2406875kB ext4 userdata
Since the "important" partitions are towards the end, something can well be done (as long as you have full OS installation media in zip or nandroid format, plus some tools which may not even be needed on this phone)... If you can wait a week I'll try to write a guide
After some testing, it appears to be impossible, like there is some S-ON on the partition table area...
full partition table needed please..
Ryccardo said:
Parted dump:
Code:
31 106824kB 117268kB 10445kB boot
32 117268kB 127795kB 10527kB recovery
33 127795kB 603980kB 476185kB ext4 cache
34 603980kB 1543504kB 939524kB ext4 system
35 1543504kB 1551892kB 8389kB kpan
36 1551892kB 3958768kB 2406875kB ext4 userdata
Since the "important" partitions are towards the end, something can well be done (as long as you have full OS installation media in zip or nandroid format, plus some tools which may not even be needed on this phone)... If you can wait a week I'll try to write a guide
Click to expand...
Click to collapse
Hey bro, could you please provide me a full partition table in that same format?
good morning,
I've got 3 galaxy S4 (I-9505) and for some purpose (and testing) I want to clone one into another one (just to test strange different behaviours between two of them, apparently with same android version etc).
I dumped the full internal eeprom, as a 16GB file, with dd throw adb, and now I'm trying to restore this image in another phone.
the destination phone has CWM recovery installed and booted, the image is visible from external sd, but I've tried with netcat as well...
what happens is that after writing to /dev/block/mmcblk0, after average 30MB I receive an input/output error, and adb crashed. on the phone the recovery appears active, but not fully working... if I choose any menu it waits forever. phone is not detected ltil I restart it in recovery again.
I tried moving ahead with "dd seek & skip" to start a bit further and the same happens.
it works only if I start from the efs partition.
this is my layout:
Number Start End Size File system Name Flags
1 8192s 33735s 25544s apnhlos
2 33736s 139263s 105528s mdm
3 139264s 139519s 256s sbl1
4 139520s 140031s 512s sbl2
5 140032s 141055s 1024s sbl3
6 141056s 145151s 4096s aboot
7 145152s 146175s 1024s rpm
8 146176s 147199s 1024s tz
9 147200s 180991s 33792s pad
10 180992s 208895s 27904s ext4 efs
11 208896s 215039s 6144s modemst1
12 215040s 221183s 6144s modemst2
13 221184s 222743s 1560s m9kefs1
14 222744s 224303s 1560s m9kefs2
15 224304s 225863s 1560s m9kefs3
16 225864s 5878343s 5652480s ext4 system
17 5878344s 5894727s 16384s persist
18 5894728s 10134087s 4239360s ext4 cache
19 10134088s 10146375s 12288s param
20 10146376s 10166855s 20480s boot
21 10166856s 10187335s 20480s recovery
22 10187336s 10207815s 20480s fota
23 10207816s 10220103s 12288s backup
24 10220104s 10226247s 6144s fsg
25 10226248s 10226263s 16s ssd
26 10226264s 10244695s 18432s ext4 persdata
27 10244696s 11268695s 1024000s ext4 hidden
28 11268696s 11309655s 40960s carrier
29 11309656s 30765655s 19456000s ext4 userdata
so if I start writing from sector 180992 it goes up to the end and the phone boots.
what could be the cause of not being able to write from the beginning?
david
I suppose it's the bootloader protecting from writing operation in sensible area. but I thought it was not acting while raw writing the block device.
guess it fails when trying to write in the same area where odin refuses non-signed .bin files.
I've two jtag boxes... so the only way to flash the whole mmcblk0 image is through jtag interface (luckily confortable on the S4)?
guess so as well. but as you said I thought it didn't act like that raw writing.
I've got 2 jtag box as well, and will give a try with them. yes S4 is nice with that, with large confortable pads.
david