Hi,
At first - if this is wrong category, please move it into correct one.
I have Dell XPS10 - RT based device. It was used by some company - then they wiped all data. All, including partitions. Device is booting into recovery from USB pendrive, but cannot recover it because "required partition is missing".
After digging in recovery command prompt, I found that there's no partitions on internal drive. Created some, upacked wim image - everything's was copying and creating ok, so there's no problem with flash memory.
But I'm still looking how to recreate original partition table, and UEFI bootloader - as I have no experience with uefi at all. On one of youtube vids I found this partition table (it's print from diskpart)
Partition, Type, Size, Offfset
Partition 1 Recovery 500MB 1024KB
Partition 2 System 100MB 501MB
Partition 3 Reserved 128MB 601MB
Partition 4 Primary 53GB 729MB
Partition 5 Recovery 4100MB 53GB
So from what I'm guessing - first 1MB is GPT, then there's not needed partition. 2nd is 100MB system, so it's efi bootloader one? 3rd seems to be usual "System reserved" for Win bootloader and 4 is main one. 5th is not needed again.
After unpacking wim into partition 4, device is still not booting, so I assume that I need somehow install bootloader into partitions 2 and 3. Any clues how to achieve that?
Found this script: http://technet.microsoft.com/en-us/library/hh825686.aspx, will try to apply it tomorrow.
[e]
So, this link helped me - device has usual EFI/GPT partition table - recreated it with help of this technet link, unpacked wim and repaired boot record. Now I'm happy owner of XPS10 64GB
Hello guys, for the previous year I would say, I have read about repartitioning MTK phones, starting with my old Cubot MTK6572 (Rest In Peace) to my current Doogee MTK6582.
I have tried countless times to repartition using the EBRTweak utility, or changing the EBR1 & EBR2 files myself but it never, ever works.. I always manage to get in the first initial boot and have a false victory where I see that I have re partitioned successfully, but after I reboot after, I always get a boot loop after that initial boot.
For editing the EBR files, I have tried:
-Using EBRTweak
-Editing myself by changing the values from scratch by making calculations with sectors, bytes and addresses
-Editing myself by
First adding a value in the /data partition length, adding that value
Second adding that same value to the start address of the FAT partition
Third removing that same value to the length of the FAT partition
For flashing the EBR files, I have tried:
-Flashing all the patitions with SP flash tools with the new EBR files (without changing the Scatter file)
-Flashing all the patitions with SP flash tools with the new EBR files (changing the Scatter file)
-Flashing only the EBR partitionsa on a working ROM
-Flashing the EBR files using an updater-script via a custom recovery
With each of these methods, all my calculations were exact when I verified everything (to the byte), including using "disktype" command in Linux.
So after one year of failure, I finally decided to post on XDA to ask for help... please, please, does anyone know why the first boot works but the second boot always ends up in a boot loop? :silly:
I emailed Doogee engineers and they told me that u cant re-partition it
NaturalBornCamper said:
Hello guys, for the previous year I would say, I have read about repartitioning MTK phones, starting with my old Cubot MTK6572 (Rest In Peace) to my current Doogee MTK6582.
I have tried countless times to repartition using the EBRTweak utility, or changing the EBR1 & EBR2 files myself but it never, ever works.. I always manage to get in the first initial boot and have a false victory where I see that I have re partitioned successfully, but after I reboot after, I always get a boot loop after that initial boot.
For editing the EBR files, I have tried:
-Using EBRTweak
-Editing myself by changing the values from scratch by making calculations with sectors, bytes and addresses
-Editing myself by
First adding a value in the /data partition length, adding that value
Second adding that same value to the start address of the FAT partition
Third removing that same value to the length of the FAT partition
For flashing the EBR files, I have tried:
-Flashing all the patitions with SP flash tools with the new EBR files (without changing the Scatter file)
-Flashing all the patitions with SP flash tools with the new EBR files (changing the Scatter file)
-Flashing only the EBR partitionsa on a working ROM
-Flashing the EBR files using an updater-script via a custom recovery
With each of these methods, all my calculations were exact when I verified everything (to the byte), including using "disktype" command in Linux.
So after one year of failure, I finally decided to post on XDA to ask for help... please, please, does anyone know why the first boot works but the second boot always ends up in a boot loop? :silly:
Click to expand...
Click to collapse
I dont know whats the purpose of the repartition...
bestmedever said:
I dont know whats the purpose of the repartition...
Click to expand...
Click to collapse
Some phones (Notably the Mediatek "MTK" phones) are known to have a very small internal storage for your applications.
This is because the storage usually attributed to applications 6GB on the MTK6582 is split in two parts:
1- 1.3gb for applications
2- 4.7gb for an internal sd-card to put music and movies
But nobody uses internal sd-card much, because we all have external sd cards of 32gb or more. This means that you have a 4.7GB that is completely unused and an internal storage for applications of 1.3gb that gets full as soon as you install a few applications like Facebook, Youtube (that use a LOT of space nowadays), or update your system apps.
All this is completely ridiculous so a few people and I are trying to make repartition and have more space for application, while getting rid of that useless "internal sd-card"
exactly
NaturalBornCamper said:
Some phones (Notably the Mediatek "MTK" phones) are known to have a very small internal storage for your applications.
This is because the storage usually attributed to applications 6GB on the MTK6582 is split in two parts:
1- 1.3gb for applications
2- 4.7gb for an internal sd-card to put music and movies
But nobody uses internal sd-card much, because we all have external sd cards of 32gb or more. This means that you have a 4.7GB that is completely unused and an internal storage for applications of 1.3gb that gets full as soon as you install a few applications like Facebook, Youtube (that use a LOT of space nowadays), or update your system apps.
All this is completely ridiculous so a few people and I are trying to make repartition and have more space for application, while getting rid of that useless "internal sd-card"
Click to expand...
Click to collapse
yeah that's what I'm saying, I talked with MTK engineers but they just replay with "if you re-partition your phone, it will brick" over and over, I told them to just give me a solution, like changing EBR files or something, and I know how to unbrick MTK phones, but they didn't care at all, the problem is: why they just put all the storage as an internal storage instead of phone storage and internal storage, it's pathetic to put phone storage and SD card storage at same time...
WOW! You actually managed to talk to them? That is awesome, we could have a lead here, don't let that go, friend!
I'm happy that you agree with me however and all the thousands of people with the same problem. Maybe if you tell them that you don't care about bricking your phone and the warranty, that you just like to play around and you have a backup phone anyways (to convince them to answer).
You could tell them that the repartitioning works on the first initial boot, but ends up in a boot loop after you reboot a second time. If they don't want to tell us how to fix it, they could at least tell us why this is happening so we could research on the subject.
Thanks for your help, I'll hit "thanks" on your post!
Ok, I have two Devices a t959 and a t959v. I have brought them both up to android 4.x.x with the appropriate files for the device. Somehow the T959 repartitioned the amount of system RAM from 500Mb to 1.5Gb while the t959v is still at 500mb. On the t959 I flashed to stock, using the Samsung Vibrant Root tools. (T959UVJFD)
then the update.zip recovery from 03.11.2102. then to cm-7.2.0-vibrantmtd and then to Xperia Vibrantmtd 4.2.2. I didn't notice the repartition until I ran out of space installing the same apps that were on the t959 and then compared the two phones under settings/apps. the t959v says 410Mb used and 117Mb free. the t959 says 373mb used and a whopping 1.1Gb free.
I looked at the log for the Xperia update and came across this: "Creating file system with parameters: Size: 1589624832 This would indicate that the partitioning happened during that update.
My upgrade path on the t959v was Oneclick Stock restore, then bhundven-blastoff-v2.5. then CM 11-20140908-UNOFFICIAL-galaxys4gmtd.
I didn't see anything similar during the update in the t959v.
So my dumb question is: Is there a way to have a similar memory partition on the t959v?
It seems to be that having the larger system partition goes a long way to making the phone really useable since after about 9 apps the normal system partition fills up. Is there a downside to having the larger system partition?
thewizardofahhs said:
Ok, I have two Devices a t959 and a t959v. I have brought them both up to android 4.x.x with the appropriate files for the device. Somehow the T959 repartitioned the amount of system RAM from 500Mb to 1.5Gb while the t959v is still at 500mb. On the t959 I flashed to stock, using the Samsung Vibrant Root tools. (T959UVJFD)
then the update.zip recovery from 03.11.2102. then to cm-7.2.0-vibrantmtd and then to Xperia Vibrantmtd 4.2.2. I didn't notice the repartition until I ran out of space installing the same apps that were on the t959 and then compared the two phones under settings/apps. the t959v says 410Mb used and 117Mb free. the t959 says 373mb used and a whopping 1.1Gb free.
I looked at the log for the Xperia update and came across this: "Creating file system with parameters: Size: 1589624832 This would indicate that the partitioning happened during that update.
My upgrade path on the t959v was Oneclick Stock restore, then bhundven-blastoff-v2.5. then CM 11-20140908-UNOFFICIAL-galaxys4gmtd.
I didn't see anything similar during the update in the t959v.
So my dumb question is: Is there a way to have a similar memory partition on the t959v?
It seems to be that having the larger system partition goes a long way to making the phone really useable since after about 9 apps the normal system partition fills up. Is there a downside to having the larger system partition?
Click to expand...
Click to collapse
First off, welcome to the forums!
By "system RAM", I'm assuming that you mean data storage for apps. There are typically three main partition to worry about: the system partition which contains all the preinstalled apps and the OS (Android), the data partition which stores all user installed apps and data, and the sdcard partition (optional) which stores music, videos, pictures etc. The RAM is used by the phone as a place to hold the data that is currently being used.
The TL,DR version is this: The T959 has 16gb of storage, the T959V has only 1GB. Read on for more info...
One of the key differences (to the end user) of the T959 and the T959V is that the T959 has an internal SD card while the T959V does not. So for the T959, there is 16GB of space, some of which is used for the data, some for the system, and the rest for the sdcard partition. On the other hand, the T959V just has a larger oneNand partition than the T959. On the T959, it stores the recovery, boot, and efs partitions (which are not really important for the end user, just that they work ) So on the T959V, it has a larger one (about 1GB) that stores the data and system partition in addition to the recovery, boot, etc partitions. The sdcard partition is used when you insert a microSD card into the phone. On the T959, when you insert an microSD card it is used as yet another partition that the T959V doesn't have.
Note that this is a bit of a simplification.
It is possible to have more space on the data partition to install apps, but then you have to move the data partition to the microSD card. This is slower but definitely possible.
Hope this helps.
Hi,
My system partition size is 1.9GB and I am unable to update from current 7.1.6. The latest ROMs filesize are much larger and thus, the phone will bricked whenever I tried to update to newer ROMs.
I tried fastboot ROMs and the same problem persisted except 7.1.6 versions and below. Of course, CM13 worked because the ROM size is a lot smaller but the camera quality is horrible. sMIUI and xiaomi.eu ROMs do not work, resulting in bricking (hard brick- I cannot power up). The only way out is to install 7.1.6 Fastboot ROM via MiFlash.
I tried wiping and even formatting my file partitions to clean away rubbish but do not resolve the fundamental problem that the system partition size is only 1.85GB (1.5GB filled).
Any ways to format/resize my system partition?
PS: The phone is rooted and I have the latest SuperSU (2.74) and TWRP (3.0.2) installed.
Fastboot edl should rewrite all the partition data that is needed, expect the one part that has your imei numbers (take backup before you start)
Here's the guide:
http://en.miui.com/thread-237832-1-1.html
Hiya! I don't believe my problem is device specific. The background of how I ended up in this crappy situation is, but I believe the resulting issue is general. Should I be wrong, tell me and I'll move this to my device's section.
Short question: how can I (and can I?) restore data in a partition that got deleted, if no new filesystem has been created over it?
Long background: I have a Xiaomi Mi2-S 32GB. It used to have a peculiar layout: a double system partition (/system1 and /system2)¹, a small internal storage (/userdata)², and a big emulated SD card (/storage)³.
Let's explain why:
¹ False dual boot: the active system is installed in the first partition. When installing an update with the official app, the newer system gets installed in the second and that one gets booted. So, should this newer system fail to boot, you have an older one correctly working and ready to boot.
² and ³: so that the whole storage partition containing photos, music, videos, downloads, backups, saved games and such can be accessed with MTP, while the userdata containing apps and complementary system things is kept safe. This last decision, however, brings up a new problem: userdata can't be accessed by user to put his files or by apps without root permissions to store data (like photos), while storage can't be used to install apps, or even to move them using Link2SD or such. Some users might find storage is insufficient for their videos and music, while others might find userdata is too little for their games, and they are both stuck in this situation.
I was in the second group, so I altered my layout using stillka's guide on xiaomi.eu (Sorry, I can't post links). I extended my userdata, so that my storage resulted smaller. Plus, I understood altering a partition would mean deleting all the partitions before that one, and recreating them thereafter.
Until this point, all was OK. I installed Ivan's AOSP Lollipop for unmerged partitions, and found out it would experience random reboots with True Dual Boot. So I stuck with False one and forgot about everything. I kept that version without updating for a long time.
Then, several months later, my phone started rebooting randomly anyway. I figured I would come back to MIUI to get Xiaomi's support for an official ROM.
Little did I know they decided to change layout in the meantime. MIUI got so big the size of the two systems was insufficient. So they decided to merge them into an unique partition big enough. So, while flashing with the official tool MiFlash, it practically altered my system layout, having to delete all that was placed before them (cache, userdata and storage), never telling me what it was going to do, advising me to back my storage up somewhere. All I did was back up my userdata into storage, confident flashing their official ROM with their official tool would just write into system, since nobody told me otherwise.
So this is the result: the old, small size of userdata is back, and everything that comes after is left without any filesystem: these are the last line in parted's print output
20 327MB 336MB 8389kB ext4 persist
21 336MB 1409MB 1074MB ext4 system
22 1409MB 1812MB 403MB ext4 cache
23 1812MB 5570MB 3758MB ext4 userdata
24 5570MB 31.3GB 25.7GB storage
Click to expand...
Click to collapse
I've tried parted's rescue command, but it is unable to find a partition lying there. I don't have my old layout, so I'm not able to precisely know where my old storage began, but I remember it to be around 18 GiB in size. I've tried all ranges possible (from the current end of userdata, 18 G from the end and so on) but no dice.
Can someone tell me if there is any hope, and what can I try?
Now I'm trying to dd the whole eMMC, or even just the last partition, to my computer to work on it using, say, testdisk. There is just one problem.
Obviously, I must issue the commands in my PC's environment, as I've nowhere to dump the biggest partition in my phone to, on it. So it goes something like
Code:
adb shell su -c "cat /dev/block/mmcblk0" | pv > mmcblk0.raw
The problem is, even if my phone was rooted by TWRP and in my options menu, the su binary is not found
/sbin/sh: su: not found
Click to expand...
Click to collapse
What should I do? Should I manually push the su binary in /system/bin? Where should I take su? From my PC?
This link should be helpful to you. Though its for MI3, the guy explains exactly how he recreates all the stock partitions one by one using the parted utility.
However, I think even before you try that, I think you should consider using the shortcut suggested in this link. If you can alter the flash_all.bat slightly and add the gpt_both0.bin, it can re-create the stock partitions (at least this is what the poster has done for Mi3/Mi4, since yours is Mi2, I'm not so sure, you may have to find out).
Finally, here is one more link that you may want to read up.
---------- Post added at 06:34 AM ---------- Previous post was at 06:34 AM ----------
This link should be helpful to you. Though its for MI3, the guy explains exactly how he recreates all the stock partitions one by one using the parted utility.
However, I think even before you try that, I think you should consider using the shortcut suggested in this link. If you can alter the flash_all.bat slightly and add the gpt_both0.bin, it can re-create the stock partitions (at least this is what the poster has done for Mi3/Mi4, since yours is Mi2, I'm not so sure, you may have to find out).
Finally, here is one more link that you may want to read up.
The problem is I don't have to restore stock partitions. That was already done against my knowledge, only that the last partition was left without a filesystem. If anything, I should restore my previous, custom layout, I have no trace left about.
I've managed to use testdisk. It is not able to find any partition in my phone eMMC though...
Testdisk's failure might be because of a wrong geometry setting, even if it sounds strange to me.
This is the ouput of parted's print
parted print said:
Error: Both the primary and backup GPT tables are corrupt. Try making a fresh
table, and using Parted's rescue feature to recover partitions.
Model: (file)
Disk /media/Storage/mmcblk0.raw: 31.4GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
Click to expand...
Click to collapse
This is fdisk's p
fdisk p said:
Disk mmcblk0.raw: 29.2 GiB, 31354139648 bytes, 61238554 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
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
mmcblk0.raw1 1 4294967295 4294967295 2T ee GPT
Click to expand...
Click to collapse
2T? Seriously?
Given that parted doesn't give those errors when run directly in adb, maybe something has gone wrong in the process of dumping my memory. I've issued this command:
Code:
adb shell dd if=/dev/block/mmcblk0 | pv | dd of=/media/Storage/mmcblk0.raw
Did I do something wrong?
This is what testdisk tells me in the analyse menu:
testdisk analyse said:
Disk mmcblk0.raw - 31 GB / 29 GiB - CHS 3812 255 63
Current partition structure:
Partition Start End Size in sectors
1 P EFI GPT 0 0 2 267349 89 4 4294967295
Warning: Bad ending head (CHS and LBA don't match)
No partition is bootable
Click to expand...
Click to collapse
It also detects an Intel table, which is rather odd. Selecting Intel or GPT gives the same result anyway, a big, round zero.
Rather than messing with partition tables using parted, I think there is a simple thing you can try:
1. Restore stock partition tables as it is (using the linked guide or some other means).
2. Restore the stock partitions themselves, something like this:
dd if=/sdcard/system.img of=/dev/block/mmcblk0
dd if=/sdcard/boot.img of=/dev/block/mmcblk1
These are just examples, you know which partition number corresponds to system.img, boot.img, etc. If you can do the above successfully, you will have restored the handset back to stock settings (both partitions and data) and it should start working in theory.
I'm not sure whether I'm not describing my problem clearly or I'm not understanding your suggestion.
The fact is my phone works correctly, it is not bricked. Right now I'm booting MIUI 8. My system partition is alright. My problem is my storage partition (the emulated SD card with all my personal data in it) got deleted, and I'm trying to get it back.
And the layout I had when my storage partition was available was not the stock one, but was already altered by me, as in storage was smaller in order to make more room for userdata (more apps). So, restoring stock layout would not give me my storage's previous start and end points.
k, now I understand your issue! If you want to recover data from a damaged (in this case non-existent) storage partition, have you tried any linux recovery programs (those may be your only option) though I'm not sure how many of them are designed to work with an eMMC.
Or is it the case that you don't care anything about recovering your personal data and just want to fix the storage partition, so the Mi2 file-manager recognizes it?
>> 2T? Seriously?
Yes, that's normal. I've observed even on MediaTek based devices that the partition tables leave that much extra space on the /storage partition (which is typically the last) though its actual physical size is just 2-3GB. You either got the starting/ending points of /storage partition in your MBR/GPT tables wrong (CHS/LBA numbers) or it is just a case of formatting this partition so that the Mi2 recognizes it. In that case, you can just try formatting it to FAT32 or something (but remember that you will loose all your personal data in that case).
Indeed my whole concern is trying to recover what was on it. For all I know, there's the possibility everything was wiped the instant MiFlash destroyed my storage partition, but since no new filesystem was written on it I'm not abandoning hope.
What I did was dump my eMMC to work on it using Linux restore programs (testdisk, mainly), but something must have gone wrong when dumping it. I will try to save the correct partition table and feeding it to TestDisk, but somehow I get the idea this won't solve my problem.
Is there anyway to get the eMMC's geometry parameters to input them manually in TestDisk?
The card is described by parted as "MMC SEM32G", and the parameters I can change are cylinder geometry (number of cylinders, default 3812), head geometry (number of heads: 1-255, default 255), sector geometry (numbers of sectors per track: 1-63, default 63) and sector size.
> What should I do? Should I manually push the su binary in /system/bin? Where should I take su? From my PC?
If you were still unable to take the dump for want of the su binary, then here is an easier way to disk dump the partitions without requiring the su binary at all, but you'll need the CWM image of your Mi2 device:
1. Start phone in Fastboot mode by long-pressing DnVolume+Start buttons.
2. Connect to USB Cable (ensure adb drivers and fastboot are installed).
3. Run this command: fastboot boot /path/to/CWM.img
4. Once phone boots into CWM, adb commands will work! Just mount the system partition in RW.
5. Using adb shell take the dump (you won't be needing root now since the partitions are in RW mode):
dd if=/dev/block/mmcWhatEver of=/sdcard/whatEver.img
EDIT
And if for some reason this doesn't work and you absolutely MUST copy the su binary, you can get the latest zip from the ChainFire.eu site, unzip the su binary and SuperSu.apk files and push the former in /system/xbin/su and the latter in /system/app folders using adb.
Of course, you'll have to provide correct permissions to the su binary, enable the setuid bit on it and finally symlink it to /bin/su.
I got the su binary by letting CWM recovery root my device. However, issuing commands with su copies just the first few bytes. In particular:
Code:
adb shell /system/xbin/su -c "dd if=/dev/block/mmcblk0" | pv | dd of=/media/Storage/mmcblk0.raw
Get 38B, while
Code:
adb shell su -c "cat /dev/block/mmcblk0" | pv > /media/Storage/mmcblk0.raw
Gets 25B.
Anyway, I can't use your suggestion: I don't have an /sdcard partition on my phone anymore: it's the one I'm trying to recover (the last 25.7GB without any filesystem in the partition table I posted in the OP). I must dump them on my PC.