Related
Remember to fully backup your system first
do 1 -4 after streakmod 0.3.2.8
do 5 with newest mke2fs、e2fsck、busybox （or from the Attach Files ）
1.mount data、sdcard
mkdir /datas
mount -t ext3 /dev/block/innersd0p6 /datas
mount -t vfat /dev/block/mmcblk1p1 /sdcard
2.backup
mkdir /sdcard/LOST.DIR/
tar -cpf /sdcard/LOST.DIR/data.tar /datas
3.del old partition ,add new partitions
umount /cache
umount /datas
fdisk /dev/block/innersd0
d
6
n
l
+1G
n
l
t
7
b
w
4.format new partitions
mke2fs -F -j -b4096 -m0 /dev/block/innersd0p6
e2fsck -yf /dev/block/innersd0p6
busybox mkfs.vfat /dev/block/innersd0p7
5.restore
mount -t ext3 /dev/block/innersd0p6 /datas
rm -r datas
tar -xpf /sdcard/LOST.DIR/data.tar
6.use new added partition
mkdir /sdcard/usbdisk
mount -t vfat /dev/block/innersd0p7 /sdcard/usbdisk
Remember to fully backup your system first
video
http://player.youku.com/player.php/sid/XMzQ4NjY2Mzg0/v.swf
the Attach Files can change partitions automaticly
View attachment 2to3.zip could add new partition
View attachment 3to2.zip could change it back to 2 partitions
View attachment 3to3.zip is used to change the partition size
（change “+1G” in part.sh of the zip packages ）
View attachment AutoMount.zip could mount the new partition after boot
in DSC 0.71， it will be mounted to /mnt/usbdisk ,the real u-disk will be mounted to /sdcard/usbdisk
in other systems,it will be mounted to /sdcard/usbdisk ,then you cann't umount your sdcard before umount /sdcard/usbdisk
After added new partition , you must not do Factory Restart or fastboot userdata.img , otherwise it will change the partitions back
so when you have flashed a new ROM or if you want to do factory restart ,you may need to fastboot my View attachment userdata.zip the other way is to do "wipe data /factory reset" and "selective restore View attachment firstboot.zip" by StreakMod 0.3.2.8
full restore by SreakMod is safe，it won't change partitions
Remember to fully backup your system first
What is the advantage of this? Also, there appears to be some formatting problem with your post, with some lines of single letters. Makes it really confusing looking.
lordmorphous said:
What is the advantage of this? Also, there appears to be some formatting problem with your post, with some lines of single letters. Makes it really confusing looking.
Click to expand...
Click to collapse
Those are likely the commands to use fdisk itself. It's basically "what to press" so you could literally do it blind.
The innerSD is sometimes large enough to forgo using the outerSD completely, esp if you have a larger innerSD.
Given it's age, the S5 has an absolutely huge /data partition, it's nearly 2gb when comparable devices are 1gb tops (such as the venue)
Have you considered making your new partition and naming it /sdcard instead?
The correct way on HC and newer is to make /data/media a symlink to /sdcard and use MTP to mount it. The actual sdcard becomes /sdcard2
The S5 kernels do not support mtp so you cant do this.
But what if you took that new partition you made? innersd0p7 becomes /sdcard and the actual sdcard becomes /sdcard2. Then you could also use your partition for apps that refuse to work without an sdcard present (like titanium backup) Still you wouldnt be able to mount it.
The GNote does /sdcard/sdcard2 or something as a hack to support both without MTP, but it's hack and ultimately different from the standardized sdcard/sdcard2 in newer android.
ALso if you're repartitioning the innerSD, not only is a backup a good idea, but it's recommeneded to have access to the card itself. If for some reason the repartition goes wrong you might end up not being able to boot. Reformatting the sdcard externally will fix it.
OK, at first glance this line
fdisk /dev/block/innersd0
d
6
n
l
looked like it should have been fdisk /dev/block/innersd0p6
Like I said, first glance. Guess that is what I get for replying to posts this late at night....time for bed.
K, time to give this a proper OP, if anyone wants any of the info that was here before you can look here
_________________________________________________________________________________________________
So, the whole idea here started with me reading an article on how part of the whole I/O problem with the transformer is partially caused by the hardware used as internal storage. I wanted to find out if this had any merit and I figured the best way to do it would be to "replace" the internal storage. I did this by mounting the /data partition to the exteral SD (which according to my research, my specific SD Card is better at writing speeds - allegedly the main problem with the transformer's internal storage hardware wise). Then I ran a bunch of benchmarks and have been running it that way for about 24 hours and so far it feels great. Anyone is welcome to give it a try, and hopefully with help, suggestions and feedback from the community, we can all take as much advantage of this idea as possible.
Before I go any further I want to give credit to those who helped me so far, because without them I would still be completely clueless, and not only have they helped be accomplishing what I got so far, but thanks to them I've also learned a bunch of things I didn't know before. So here it goes:
Rayman - For suggesting the method for mounting /data to the external SD.
lilstevie - For helping me get the new kernel flashed right.
Turge - For showing me how to properly repack the kernel.
Parastie - For suggesting doing the same thing to /cache (working on that now).
dagrim1 - For SQL patch and for suggesting a temporary remount (even though it didn't work it was a good thing to try).
_motley - For all his work on his awesome kernel.
_________________________________________________________________________________________________
Updates:
Update 1 (08-01-2012 File boot-data+cache+internal-AOKP6.1base.zip) :
Now both /data and /cache are moved to the external SD card. This means you need a third partition mmcblk1p3 in order to use this modification.
It will also mount the internal storage (previously inaccessible) to /mnt/sdcard_internal
It also attempts to (fail at this point) to mount the internal sd partition (what used to be /sdcard) to /sdcard/Internal_SD (which is why you will always see that folder get created but stay empty). If anybody knows how to make it work please advise.
Modified Lines:
init.cardhu.rc
Code:
# TweakerL MOD > original mount = mmcblk0p8 /data | mmcblk0p3 /cache
mount ext4 /dev/block/mmcblk1p2 /data wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
mount ext4 /dev/block/mmcblk1p3 /cache wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
# TweakerL MOD > added mounts for internal storage
mkdir /mnt/sdcard_internal 0000 system system
mount ext4 /dev/block/mmcblk0p8 /mnt/sdcard_internal wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
# TweakerL MOD > give access to internal SD from /sdcard
mkdir /data/media/Internal_SD 0755 media_rw media_rw
mount /mnt/sdcard_internal/media /data/media/Internal_SD wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
Update 2 (08-01-2012 About backing up/restoring in recovery) : - READ UPDATE 5
One thing that worried me was that by using this mod people wouldn't be able to backup their data partition properly, but now I know that it's possible to do it. It will only work on TWRP though since it has basic terminal access and keyboard. To do it, go into Advanced > Terminal and in there type:
umount /dev/block/mmcblk0p8
mount /dev/block/mmcblk1p2 /data
And until you reboot, any backup/restore should use the external SD data partition instead of the internal. The same should be doable with the cache partition in case you want to backup/restore that.
Update 3 (08-02-2012 File flashme-kernel-motley305-aokp-data+cache2SD.zip) :
Put together a flashable zip that will install motley's 3.0.5 aokp kernel using this mod. Works like a charm so far though I only tried flashing on TWRP. Also, internal storage can be accessed in /data2 and internal sd can be accessed in /sdcardi . Current changes are as follow:
Code:
# TweakerL MOD > move /data and /cache to external SD card || original mount = mmcblk0p8 /data | mmcblk0p3 /cache
mount ext4 /dev/block/mmcblk1p2 /data wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
mount ext4 /dev/block/mmcblk1p3 /cache wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
# TweakerL MOD > create mount for internal storage
mkdir /data2 0000 system system
mount ext4 /dev/block/mmcblk0p8 /data2 wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
# TweakerL MOD > symlink internal sd to a couple of easily accessible locations
symlink /data2/media /mnt/sdcard_internal
symlink /data2/media /sdcardi
Update 4 (08-03-2012 File boot-cm10-unofficial-data+internal.zip) :
Running the unofficial CM10 (no cherrypicks one) using this mod and so far it's pretty amazing. The rom itself is pretty stable and even snappier with /data mounted to external SD. Benchmarks are at the bottom. Current modifications:
fstab.cardhu:
Code:
#TweakerL MOD > Move /data to external SD and internal /data to /data2
/dev/block/mmcblk1p2 /data ext4 rw,nosuid,nodev,noatime,user_xattr,acl,barrier=1,journal_async_commit,nodelalloc,data=writeback wait
/dev/block/mmcblk0p8 /data2 ext4 rw,nosuid,nodev,noatime,user_xattr,acl,barrier=1,journal_async_commit,nodelalloc,data=writeback wait
init.cardhu.rc:
Code:
# TweakerL MOD > create mount for internal storage
mkdir /data2 0000 system system
mount_all /fstab.cardhu
# TweakerL MOD > symlink internal sd to a couple of easily accessible locations
symlink /data2/media /mnt/sdcard_internal
symlink /data2/media /sdcardi
Update 5 (08-03-2012 About backing up/restoring in recovery) :
So after doing some tests, and paying more attention to TWRP, I noticed something rather useful:
When you have this mod enabled, or whenever you have a mmcblk1p2 partiion, TWRP will have the sd-ext menu enabled. This means that to backup your data you can simply backup the sd-ext partition and to restore your data you can simply restore your sd-ext partition. No need to worry about manually switching the mount point for /data in recovery. I guess it was a whole lot easier than I thought.
Also congratulations and thanks to everyone who has contributed with this so far.
WE MADE IT TO FRONT PAGE ON XDA (08-03-2012)
_________________________________________________________________________________________________
Requirements:
There are a few things you will need to do in order for this to work right for you, and a couple of things you'll have to research before you even try it.
#1. Obviously, you have to be rooted/unlocked because you're not gonna be able to change much around otherwise.
#2. You MUST repartition your external SD. The kernel I've put together so far WILL ONLY mount /data to mmcblk1p2, which basically says "mount /data to the second partition in the external SD." also, the ramdisk expects that partition to be ext4, so essentially:
Make sure you have an external SD with at least two partitions and that the second partition is formatted to ext4. I personally use Gparted to repartition my stuff, but feel free to use whatever rocks your boat. Even if you're on windows you can still use gparted by using virtualbox, so I'm not gonna go look for a different windows solution.
#3. This is the research part... This will be beneficial or detrimental to each user depending on the SD card used. If you have a slow SD card this probably will do you no good. However, just because you have a class 10 SD card, that doesn't mean it will benefit you either. On my own research I have found that some class 6-10 SD Cards have extremely slow random write speeds, so if you happen to have one of those, even if it's a class 10, this might not be for you. This means that you're gonna have to do some research to find out if your SD Card will benefit you or not. You can always just give it a try, as far as I know this is entirely reversible, how easy or hard being just a matter of how bad you mess up on meeting the requirements and following the instructions.
#4. At this point (07-30-2012) I'm doing all this stuff using the AOKP milestone 6.1 kernel as base for my modified kernel, so if you're not using AOKP milestone 6.1, flashing my kernel might borke your system. You've been warned, feel free to proceed otherwise at your own peril.
_____________________________________________________________________________________________________________
Installation:
#1. Download attached file (boot-data2SD-AOKP6.1base.zip) and extract it to the root of your internal storage (/sdcard).
#2. Open a terminal.
#3. Type the following:
Code:
su
dd if=/sdcard/boot.blob of=dev/block/mmcblk0p4 bs=1
#4. Wait for it to complete.
#5. Reboot.
Upon rebooting you will know that it worked because it will look just as if you just flashed a new rom, that is, you'll get the device setup screen (assuming that the tablet booted at all lol). If you're planning to use TB to restore your apps, you'll probably want to copy the TB folder to your external SD's first partition so that you can copy it back once you're done with the device setup (at this point you will have no access - unless you manually mount it - to your internal storage).
_______________________________________________________________________________________
Reverting:
Follow the same exact steps for installation but use boot-default-AOKP6.1.zip instead.
_______________________________________________________________________________________
Optional:
#1. If you want to have access to everything you had on your data partition in the new data partition, you'll have to clone everything from one to the other. To do this, make sure that your new data partition (the one in your external SD) has enough storage space to fit everything you currently have in your data partition (the one in your internal storage). Then run the following command in your terminal.
Code:
dd if=dev/block/mmcblk0p8 of=dev/block/mmcblk1p2 bs=4096 conv=notrunc,noerror
BEWARE that if you have a lot of stuff this can take quite a while and even though I've read a way of getting the progress for this in Linux I'm not sure that you can check the progress on Android.
_______________________________________________________________________________________
Next steps in development:
#1. Move /cache as well.
#2. Find out what happens with recovery backups when the partitions are changed.
#3. Attempt to apply mod to motley's kernel.
#4. Create a script that is run on boot to eliminate need for replacing the kernel.
#5. With help from the community, find the best SD Card for this.
#6. Run the modified system for a while to have a good feel for performance benefits
#7. Come up with other interesting uses for this other than getting better I/O (maybe an easy - kinda easy - way to dual boot with ubuntu, maybe other stuff, dunno).
_______________________________________________________________________________________
How can I set my kernel to do this?
I didn't do a whole lot, and it's not like I want it to be a secret, so as I modify things I'll try to keep the steps listed here so that anyone modifying their own kernel who would like to try this modification can go ahead and do it.
You'll need to know how to unpack/repack a kernel. Turge has a SUPER EASY explanation here on how to do it on windows (I'll pack together the necessary binaries for linux later, maybe).
Mount /data to the second partition in your external SD (formatted as ext4 filesystem):
After unpacking the kernel navigate to the folder that has the ramdisk and open it
(DON'T USE ANY ASCII BASED TEXT EDITOR BECAUSE IT WILL PROBABLY MESS THINGS UP I USE NOTEPAD++)
Around line 26 change:
Code:
mount ext4 /dev/block/mmcblk0p8 /data wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
to
Code:
mount ext4 /dev/block/mmcblk1p2 /data wait noatime nodiratime nosuid nodev nodelalloc,errors=panic
_______________________________________________________________________________________________________
SD Cards tested:
Samsung 32GB Class 10 MicroSDHC High Speed Memory Card - Very Good Results
SanDisk® microSDHCTM 8GB Memory Card - Very Good Results
"Either way, with this mod, the tablet feels like it should have right from the start. It's speedy and responsive, and apps being installed don't stall the system." - Turge - Post #59
_______________________________________________________________________________________________________
Benchmarks:
/data mounted to mmcblk0p8 (Internal Storage):
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
/data mounted to mmcblk1p2 (External SD):
RL Benchmark WITHOUT dagrim1's sql patch as per request:
/data mounted to mmcblk0p8 (Internal Storage):
/data mounted to mmcblk1p2 (External SD):
*Important thing to note: When running the benchmark with data in the internal SD it was about 220 seconds in the first run, then about 180, then about 130 and finally 118; whereas running it from the external SD was consistenly between 63 and 65 seconds every time. I think this more than proves that A) Asus used a cheap I/O storage, B) No matter what software changes are made, more than likely running the rw partitions from a better I/O storage, i.e. an external SD is a good idea.
As promised here are benchmarks on a JB rom (Unofficial CM10). Also sorry it took me a while to get these, I was going to use eos3 but I started getting random reboots. Then I decided to try cm10, and I messed up a flash and had to redo a bunch of things. Anyway, the only change here is the mod itself (no custom kernel or anything). Though one thing to note is that I moved /cache back to the internal partition after some thought that this allows /data and /cache to be written at the same time to different locations thus lowering the bottleneck.
/data mounted to mmcblk0p8 (internal storage):
/data mounted to mmcblk1p2 (external storage):
Now, as you can see, JB did bring a major improvement to I/O, bringing the benchmark down from about 115sec to 68 (almost reaching the modded ICS at 60 seconds). But as I expected, better software works better on better hardware and now the modded JB is running at 50 seconds instead of 60. Next I'm going to put dagrim1's sql patch and see how low the benchmark goes. Also will be posting the modded blob in just a little bit for anyone who wants to use it on CM10.
We don't have sd-ext it's an old trick when phones had very little /data partitions, you have the possibility to create a sd-ext partition on an external sdcard and mounting it as a secondary data. (like opt partition on Linux).
To see what block device is data just run 'mount' command in terminal emulator. I don't have my device here.
sdcard cache is already set to 2048 if I'm correct.
Your script would mean creating a sd-ext partition on an external sdcard, modify fstab to have it correctly mounted then applying the script.
Not really easy for common users.
I would rather look at kernel drivers (not I/O schedulers but drivers handling with file system format) but it's quite a hard work.
Hmmm...
Was talking to Rayman and it doesn't actually seem that hard to do... Just gotta change the init.cardhu.rc in the ramdisk to mount /data to /dev/block/mmcblk1p2 instead of /dev/block/mmcblk0p8
The thing is, that while I know every step that I have to take to get it done, I haven't used linux in forever and quite honestly I couldn't even compile blobtools right now if I wanted to to extract the ramdisk from the boot blob to make the necessary change... so yea anyone who knows how to edit a kernel should be able to do it, and then just repack it as a blob... I'll probably look into it later, but if anyone wants to type the terminal commands for to to get/compile blobtools I'll appreciate it...
As in just a mount of data to mmcblk1p2?
Would a temp solution (just to check if it works) be to remount data manually? (Tried it, to mmcblk1p1 btw since 1p2 didn't seem to exist for me, but it still mounts to mmcblk0p8.
Using:
mount -o remount,rw -t ext4 /dev/block/mmcblk1p1 /data
(as su in terminal)
dagrim1 said:
As in just a mount of data to mmcblk1p2?
Would a temp solution (just to check if it works) be to remount data manually? (Tried it, to mmcblk1p1 btw since 1p2 didn't seem to exist for me, but it still mounts to mmcblk0p8.
Using:
mount -o remount,rw -t ext4 /dev/block/mmcblk1p1 /data
(as su in terminal)
Click to expand...
Click to collapse
Reason why mmcblk1p2 didn't work is because you have to repartition the sd card to have an ext4 partition... personally what I did was take my 32gb sd card and have the first partition as a fat32 partition for storage and set the rest to an ext4 partition... also, you have to do that because the /data partition is already expected to be an ext4 partition on most of the current ROMs... Trying to set it without doing that most likely won't work.
Also, another thing that's important is that for this to be beneficial you have to have an SD Card with higher random write speed than your internal storage speed... my internal storage speed is about .25 mb/s and my sdcard is about 1.5mb/s so there should be a big difference... Oh and if you happen to have a class 10 sdcard that doesn't necessary mean that it has high random write speed... you actually have to go look up the specs or run benchmarks on it.
TweakerL said:
Reason why mmcblk1p2 didn't work is because you have to repartition the sd card to have an ext4 partition... personally what I did was take my 32gb sd card and have the first partition as a fat32 partition for storage and set the rest to an ext4 partition... also, you have to do that because the /data partition is already expected to be an ext4 partition on most of the current ROMs... Trying to set it without doing that most likely won't work.
Also, another thing that's important is that for this to be beneficial you have to have an SD Card with higher random write speed than your internal storage speed... my internal storage speed is about .25 mb/s and my sdcard is about 1.5mb/s so there should be a big difference... Oh and if you happen to have a class 10 sdcard that doesn't necessary mean that it has high random write speed... you actually have to go look up the specs or run benchmarks on it.
Click to expand...
Click to collapse
Thanks, makes sense yeah... will have to check if it's worth the hassle for now. Not at this moment anyway, but interesting concept...
Stuck... again...
So I figured how to unpack the boot.blob, then unpack the boot.blob.LNX, then decompress the ramdisk... made the necessary change to init.cardhu.rc... compressed the ramdisk to the same format it was before, repacked the boot.blob.LNX, repacked the boot.blob... dd if=blob of=dev/block/mmcblk0p4 seek=28 bs=1 ... and ... nothing... reboot and where you're supposed to get the quick progress bar nothing seems to happen... I'm assuming I messed up on the recompressing ramdisk/packing the boot.blob... but I'm not sure how...
Anyway... I'll post exactly how I did it tomorrow so maybe someone with more experience can help me figure out where I messed up...
But so far, I wanna say thanks to rayman and lilstevie for all the help they've given me so far with this idea.
TweakerL said:
... compressed the ramdisk to the same format it was before, repacked the boot.blob.LNX, repacked the boot.blob... dd if=blob of=dev/block/mmcblk0p4 seek=28 bs=1 ...
Click to expand...
Click to collapse
Just wondering, why did you choose to use seek=28?
I believe the TFP will need the first 28 header signature to be there in order to flash through the staging paritition (p4).
Your other option would be to flash using fastboot:
1. If you've installed the AndroidRoot.mobi bootloader (if you have nvflash), then you can directly flash the boot.blob.LNX file, as this is a raw image.
fastboot -i 0x0b05 flash boot boot.blob.LNX
2. If you don't have AndroidRoot.mobi bootloader, then I suggest you get NVFlash working first and get a backup... if not, you can use the following to flash the blob:
fastboot -i 0x0b05 flash boot blobfileyou'vecreated
3. Use fastboot to flash to the staging partition:
fastboot -i 0x0b05 flash staging blobfileyou'vecreated
TweakerL said:
So I figured how to unpack the boot.blob, then unpack the boot.blob.LNX, then decompress the ramdisk... made the necessary change to init.cardhu.rc... compressed the ramdisk to the same format it was before, repacked the boot.blob.LNX, repacked the boot.blob... dd if=blob of=dev/block/mmcblk0p4 seek=28 bs=1 ... and ... nothing... reboot and where you're supposed to get the quick progress bar nothing seems to happen... I'm assuming I messed up on the recompressing ramdisk/packing the boot.blob... but I'm not sure how...
Anyway... I'll post exactly how I did it tomorrow so maybe someone with more experience can help me figure out where I messed up...
But so far, I wanna say thanks to rayman and lilstevie for all the help they've given me so far with this idea.
Click to expand...
Click to collapse
I've repacked the boot.img for the Prime before to add init.d support so I'll post my method and the files needed in a few minutes once I get to work. It'll involve getting cygwin installed (with Perl support I believe) if you're on Windows.
Would it be better to move cache and maybe dalvik cache (assuming the SD random read/write is faster then internal memory) ? Since you're only moving data and leaving cache on internal, that'll still hit the issues of having bad IO. Moving cache (which I believe would have more random access) I think would be better.
Thoughts?
dagrim1 said:
As in just a mount of data to mmcblk1p2?
Would a temp solution (just to check if it works) be to remount data manually? (Tried it, to mmcblk1p1 btw since 1p2 didn't seem to exist for me, but it still mounts to mmcblk0p8.
Using:
mount -o remount,rw -t ext4 /dev/block/mmcblk1p1 /data
(as su in terminal)
Click to expand...
Click to collapse
Thanks for the idea, I tried to do that but nothing seemed to happen (checking on file manager /data partition is still taking the same amount of space as it did before). It would've been a really good way of testing this whole thing though
kokopuphz said:
Just wondering, why did you choose to use seek=28?
I believe the TFP will need the first 28 header signature to be there in order to flash through the staging paritition (p4).
Your other option would be to flash using fastboot:
1. If you've installed the AndroidRoot.mobi bootloader (if you have nvflash), then you can directly flash the boot.blob.LNX file, as this is a raw image.
fastboot -i 0x0b05 flash boot boot.blob.LNX
2. If you don't have AndroidRoot.mobi bootloader, then I suggest you get NVFlash working first and get a backup... if not, you can use the following to flash the blob:
fastboot -i 0x0b05 flash boot blobfileyou'vecreated
3. Use fastboot to flash to the staging partition:
fastboot -i 0x0b05 flash staging blobfileyou'vecreated
Click to expand...
Click to collapse
I used seek=28 out of despair and by lilstevie's suggestions... dd with or without seek had the same exact result, the staging just ignoring the whole thing lol...
Sounds like a plan (flashing with fastboot)... I've got one dumb question though before I do that (and yea i've got nvflash setup and all the backups and stuff). How do I actually go about restoring the system with NVFLASH if I go and borke the system ? XD
Turge said:
I've repacked the boot.img for the Prime before to add init.d support so I'll post my method and the files needed in a few minutes once I get to work. It'll involve getting cygwin installed (with Perl support I believe) if you're on Windows.
Click to expand...
Click to collapse
That would be much appreciated, I don't mind steps for windows or linux, I'll go either way
Parastie said:
Would it be better to move cache and maybe dalvik cache (assuming the SD random read/write is faster then internal memory) ? Since you're only moving data and leaving cache on internal, that'll still hit the issues of having bad IO. Moving cache (which I believe would have more random access) I think would be better.
Thoughts?
Click to expand...
Click to collapse
I agree that moving the cache is a good idea, one of the main reasons why I'm testing with /data though is that it will be much easier to have solid evidence of whether this works or not that way since all the benchmark apps seem to benchmark on the /data partition. I know benchmarks aren't real world results, but if I can run benchmarks on the same partition and it's 5 times faster on the SD card than on the internal memory, I think it should mean something. After that, if there are positive results, I'm thinking of moving both /data and /cache partitions and run that way for a while to see how well it performs, and then to run with just the /cache moved and see how that performs.
Turge said:
I've repacked the boot.img for the Prime before to add init.d support so I'll post my method and the files needed in a few minutes once I get to work. It'll involve getting cygwin installed (with Perl support I believe) if you're on Windows.
Click to expand...
Click to collapse
Here are the steps for repacking the boot.img. Some involve running the commands via cygwin, others involve running them via the Windows Command Prompt.
The instructions for installing cygwin, extracting and repacking the boot.img were found here: http://www.freeyourandroid.com/guide/extract-edit-repack-boot-img-windows
Once you have setup cygwin, extract the attached files in a folder under your "home" folder in cygwin.
copy boot.blob to the same folder and run the following via the Windows Command Prompt to extract the boot.img from the boot.blob:
Code:
BlobUnpack.exe boot.blob
ren boot.blob.LNX boot.img
From the cygwin bash terminal window, switch to the same folder and run the following to extract the ramdisk from the boot.img:
Code:
./extractboot boot.img
You now have an out/ramdisk folder that contains the files you want to edit.
Once done, repack the ramdisk and kernel into boot_new.img with the following command (via cygwin once again):
Code:
./packboot
then from the Command Prompt repack boot_new.img into boot2.blob using the following:
Code:
blobpack -s boot2.blob LNX boot_new.img
You can now flash the boot.blob to the staging partition via a command in updater-script:
Code:
package_extract_file("/boot.blob", "/dev/block/mmcblk0p4");
or by using adb while in recovery/android:
Code:
dd if=/sdcard/boot2.blob of=/dev/block/mmcblk0p4
Did anyone think of running iotop? If we know what part of /data is contributing to the stalls, maybe an interesting idea would be to just mount that part of the tree on SD?
tyvm will get on it now, will report back any results
Sent from my Transformer Prime TF201 using Xparent SkyBlue Tapatalk 2
what's iotop?
Though regardless, the problem I'm trying to deal with is the fact that apparently, the storage hardware in the Prime has limited I/O capabilities, namely random write speeds, regardless of software. Because of this the stalls are at least partially caused by the "where" the /data is rather than the "content" in the /data.
Sent from my Transformer Prime TF201 using Xparent SkyBlue Tapatalk 2
TweakerL said:
what's iotop?
Click to expand...
Click to collapse
ffs. Why do I bother?
tshoulihane said:
ffs. Why do I bother?
Click to expand...
Click to collapse
You know, I can just google it, but the fact that you care enough to post your opinion but not enough to explain it is the kind of mentality that keeps people who could potentially contribute to the community from doing so because they have to go research all over the internet, possibly going through bad information, for something that might be very simple. Read a few posts up and you'll see the right kind of mindset. Turge could've just*given some halfassed response and sent me on a wild goose chase but instead he took the time to explain in a way that anyone with any amount of knowledge could understand...
And I hope that since you can't bother to give an useful response, that you can't bother wasting you "precious time" justifying and complaining about how people ask questions that they could just look for elsewhere...
So after a failed attempt to upgrade from CyanogenMod 10.1.3 to 10.2, I was unable to access /data or /sdcard because both systems were encrypted. I ended up having to factory reset my phone because it refused to co-operate or let me access my files. However, before I did that, I was able to run
Code:
adb shell "dd if=/dev/block/mmcblk0p2" > data.img
and
Code:
adb shell "dd if=/dev/block/mmcblk0p3" > sdcard.img
, which appears to have copied the raw partition images from the phone (at least, they're the right sizes).
According to my reading, Android (and, I'm inferring, CyanogenMod) encrypts filesystems using dm-crypt, with a AES-CBC ESSIV:SHA256 cipher, with the key being derived from the password using PBKDF2. Knowing the precious little I do about encrypted file systems, my guess is that if I configure the image in cryptsetup to create a drive mapping, I can mount the mapped drive and recover the data from the images.
According to /fstab.herring on my ahem, fresh, install of Android, the /data partition is in ext4 format whereas the /sdcard partition is vFAT. So, once I've gotten through the encryption on the partition images, they should mount normally, right?
I know that dm-crypt accepts plain, LUKS, LoopAES and TrueCrypt device formats. I'm inferring from the PBKDF2 extension that Android goes the LUKS route for encrypting. Is this conclusion correct?
Could someone explain whether it's possible to decrypt a dumped android image? I'm really hoping that the cypher information is stored on the file system and not on some key file that I nuked in the factory reset. If it can, in theory, be decrypted, am I using the right tools to approach the matter? If so, I'll continue fiddling with cryptsetup and mount, but no sense in wasting time if it's an impossible task.
Never did get a response to this question, so I'll try it again, but start with a simpler question:
If someone dds an Android (specifically Cyanogenmod 10.x) partition to an img file, is there any way to read that image from, say a Linux laptop? I dumped the contents of the /system partition using
Code:
adb shell "dd if=/dev/block/mmcblk0p1" > system.img
I expected system.img to be a normal ext4 partition. However, attempting to loopback mount it with
Code:
sudo mount -t ext4 -o loop,ro system.img ~/android/system
Gave me errors about corrupt group descriptors, bad magic numbers and other maladies indicative of a thoroughly corrupted file system. I'm assuming that:
/data has the same ext4 partition structure as /system; and
The process to mount /storage would be no different to mounting /system with the exception that the former uses vFAT as its file system
However, as my Android is currently working normally (well, as well as one can hope for Android to work), I know I don't have a corrupted file system.
So what's going on? Does Android use a special version of ext4 that other Linuxes don't recognise? Am I not dd-ing correctly? Is there a block-size issue I ignored to my peril?
Borden Rhodes said:
So after a failed attempt to upgrade from CyanogenMod 10.1.3 to 10.2, I was unable to access /data or /sdcard because both systems were encrypted. I ended up having to factory reset my phone because it refused to co-operate or let me access my files. However, before I did that, I was able to run
Code:
adb shell "dd if=/dev/block/mmcblk0p2" > data.img
and
Code:
adb shell "dd if=/dev/block/mmcblk0p3" > sdcard.img
, which appears to have copied the raw partition images from the phone (at least, they're the right sizes).
According to my reading, Android (and, I'm inferring, CyanogenMod) encrypts filesystems using dm-crypt, with a AES-CBC ESSIV:SHA256 cipher, with the key being derived from the password using PBKDF2. Knowing the precious little I do about encrypted file systems, my guess is that if I configure the image in cryptsetup to create a drive mapping, I can mount the mapped drive and recover the data from the images.
According to /fstab.herring on my ahem, fresh, install of Android, the /data partition is in ext4 format whereas the /sdcard partition is vFAT. So, once I've gotten through the encryption on the partition images, they should mount normally, right?
I know that dm-crypt accepts plain, LUKS, LoopAES and TrueCrypt device formats. I'm inferring from the PBKDF2 extension that Android goes the LUKS route for encrypting. Is this conclusion correct?
Could someone explain whether it's possible to decrypt a dumped android image? I'm really hoping that the cypher information is stored on the file system and not on some key file that I nuked in the factory reset. If it can, in theory, be decrypted, am I using the right tools to approach the matter? If so, I'll continue fiddling with cryptsetup and mount, but no sense in wasting time if it's an impossible task.
Click to expand...
Click to collapse
Can you give the result of the "file sdcard.img" and "file data.img" commands?
You are quite right. With regular LUKS container/partition, you would do (being root) the following. With the following commands, you can create a container named "safe", setup it, then format its content in ext3 and mount the partition:
Code:
dd if=/dev/zero bs=1M count=50 of=safe
losetup /dev/loop0 safe
cryptsetup luksFormat -c aes -h sha256 /dev/loop0
cryptsetup luksOpen /dev/loop0 safe
mkfs.ext3 /dev/mapper/safe
(losetup /dev/loop0 safe)
(cryptsetup luksOpen /dev/loop0 safe)
mkdir mnt
mount -t ext3 /dev/mapper/safe mnt
//HERE: do whatever you want in your mounted encrypted filesystem
umount mnt
cryptsetup luksClose safe
losetup -d /dev/loop0
For details, you can go there: http://blog.theglu.org/index.php/20...-couteau-suisse-du-chiffrement-de-partitions/
Sorry, the article is in French but you can translate it if you need to.
Here, using "hexdump", you can see the "safe" file has a LUKS magic at the beginning. And doing a "file safe" command, you can check it detects it as a "LUKS encrypted file".
If doing "file" on your .img files does not give you the same result, you may not be able to directly use the "cryptsetup" command and need to adapt it.
Finally: usually in Android the header containing the key is stored on another partition so you may have lost it when wiping your phone, sorry.
---------- Post added at 02:44 PM ---------- Previous post was at 02:41 PM ----------
Borden Rhodes said:
Never did get a response to this question, so I'll try it again, but start with a simpler question:
If someone dds an Android (specifically Cyanogenmod 10.x) partition to an img file, is there any way to read that image from, say a Linux laptop? I dumped the contents of the /system partition using
Code:
adb shell "dd if=/dev/block/mmcblk0p1" > system.img
I expected system.img to be a normal ext4 partition. However, attempting to loopback mount it with
Code:
sudo mount -t ext4 -o loop,ro system.img ~/android/system
Gave me errors about corrupt group descriptors, bad magic numbers and other maladies indicative of a thoroughly corrupted file system. I'm assuming that:
/data has the same ext4 partition structure as /system; and
The process to mount /storage would be no different to mounting /system with the exception that the former uses vFAT as its file system
However, as my Android is currently working normally (well, as well as one can hope for Android to work), I know I don't have a corrupted file system.
So what's going on? Does Android use a special version of ext4 that other Linuxes don't recognise? Am I not dd-ing correctly? Is there a block-size issue I ignored to my peril?
Click to expand...
Click to collapse
Can you give the result of the "file system.img" command?
Thanks, saidlike, for your reply:
saidelike said:
Can you give the result of the "file sdcard.img"...
Click to expand...
Click to collapse
sdcardPartitionDump.img: data
saidelike said:
... and "file data.img" commands?
Click to expand...
Click to collapse
data.img: data
saidelike said:
Can you give the result of the "file system.img" command?
Click to expand...
Click to collapse
system.img: Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b (needs journal recovery) (extents) (large files)
Again, attempting to run
Code:
mount -t ext4 -o loop systemimg mountpoint/
yields
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Click to expand...
Click to collapse
Ignoring the results of data.img and sdcard.img for the time being, the fresh dump of the system partition shows that it's an EXT4 filesystem, but that it's heavily corrupted. fsck.ext4 on that partition basically asks me to fix every single inode, so it's not a simple unclean journal issue. Therefore, is it fair to conclude that CyanogenMod (and maybe AOSP too) have modified the ext4 partiiton type?
@Borden Rhodes
Maybe, my reply is too late, but you could try to make the same experiment with backup of your current data.
If you get the same results as with the old pre-wipe backup, then you still have a hope.
4 this kind of guys x)
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Code:
Warning:
Your device will never boot :D
Does this enough?
Ok jk but consider its possible
So don't blame me,
not responsible for anything
Trick:
Read 2nd Post First
(if u think necessary)(i would)
Why ?? :
Cuz u want to increase/decrease size on internal storage/internal sd card/nand/emmc.
So u can save Avengers 1080p in dual audio
I.e. default internal storage will increase from 24.x GB to 26.x GB
Sounds cool ?
Go ahead
Tools required:
0. Nandorid Backup ,
back up everything every way you can/know
1. Rooted Phone
2. Custom Recovery with ADB Sideload
3. Minimal ADB and Fastboot Tools(for Computer)
4 parted utilities.zip (download from below)
5. Computer should recognise device for that install necessary drive
6. brain, commen sense, patients,calm etc.
---> PROCEDURE/STEPS
(will add screen shot, Rewrite again )
1.
Extract 'parted' from zip copy to "/system/bin"
(if can't Open Es File explorer app>find & tape Root explorer option>mount r/w option> mount system to r/w (read/write allow)
2.
Put phone in TWRP Recovery
3.
Connect to computer
On command line interface
(Windows>Run>CMD>enter)
#commands:
adb shell
su
parted /dev/block/mmcblk0
you will see the following screen
4.
Now to see the partitions and their partition numer use the following command
print
It will output a screen like follows
From the list above we can see partition number, the start position, the end position and the type of partition
Now from the List we need to figure out what partitions we need to remove and remake, and since we are majorly concerned about the Userdata and system partition, we will be playing around with those partitions only. But from the screenshot above you can see that Between the system and the userdata partition there is the cache partition.
To avoid any problems further. i would suggest you take a screenshot of this list .
5
Now Enlisting the partitions that we would have to remove inorder to resize them, they are:-
partition no. 27 i.e. system
partition no. 28 i.e cache
partition no. 29 i.e. userdata
In case you are using a device that has 2 system partitions (For eg. MI3) and you wanna reduce system2 and increase system1 you will need to delete only those 2 partitions
So now going further we will now remove the partitions using the following commands
rm 27
The above command will remove the partition no. 27 i.e the system partition
rm 28
This will remove the partition no. 28 i.e cache
rm 29
This will remove the partition no. 29 i.e. userdata
At this point of time you have lost all the data on your internal storage, system and cache partition. that means your device wont boot anymore except in recovery (which we are already in )
6.
Now that we have removed the partitions, we have raw space with us, which we would allocate to the three partitions that we removed, as per our choice.
To do that, we use the following commands
mkpartfs primary ext2 336 1250
mkpartfs primary ext2 1250 1653
mkpartfs primary ext2 1653 7818
336 is the start position of the partition and 1250 is the end position of the paritition.
since the partitions we removed started at 336 and ended at 7818, for my device, we would be able to play around only between these two numbers. i.e 336 and 7818
The first parition we made here is numbered 27 by default and will be of the size (1250-336 = 914) MBs
The second partition we made is numbered 28 and will be of the size 403 MB. (This is the cache partition and since I did not want to change the size i kept it the same)
The third partition we made is numbered 29 and will be of the size (7818-1653 = 6165) MB
The Important thing we need to note here is that the partition Number should not change as this could cause problems later on. i.e., considering my case the system parition should be 27, cache should be 28 and userdata should be 29.
7.
Now we will name these partitions using the following commands
name 27 system
name 28 cache
name 29 userdata
8.
Now punch the following command
quit
This will make you come out of parted utility. so that we can perform the next set of commands
Now we need to convert the partitions from ext2 to ext4 using the following commands
**// For System Partition //**
tune2fs -j /dev/block/mmcblk0p27
e2fsck -fDp /dev/block/mmcblk0p27
tune2fs -O extents,uninit_bg,dir_index /dev/block/mmcblk0p27
e2fsck -fDp /dev/block/mmcblk0p27
**// **
**// For cache Partition //**
tune2fs -j /dev/block/mmcblk0p28
e2fsck -fDp /dev/block/mmcblk0p28
tune2fs -O extents,uninit_bg,dir_index /dev/block/mmcblk0p28
e2fsck -fDp /dev/block/mmcblk0p28
**// **
**// For userdata Partition //**
tune2fs -j /dev/block/mmcblk0p29
e2fsck -fDp /dev/block/mmcblk0p29
tune2fs -O extents,uninit_bg,dir_index /dev/block/mmcblk0p29
e2fsck -fDp /dev/block/mmcblk0p29
**// **
9.
Now we have changed the type of the 3 partitions that we created from ext2 to ext4 and we are ready to go
Now we will enter the parted utility again and check to see if the partitions are made properly or not.
parted /dev/block/mmcblk0
print
As we can see in the screenshot. The system partition is now 914 MB and the userdata partition is no 6165 MB
Now punch the command
quit
exit
exit
Yes you need to exit two times.. first to come out of super user and second to come out of ADB shell
10.
Now Once the repartitioning is done
you need to flash your ROM
(MIUI /Lineage/RR/Viper/Mokee etc)
Now exit sideload in the TWRP and goto Install and select the Rom package and flash it.
Reboot and you should be done!
CREDITS, Thanks :
https://iwf1.com/how-to-re-partition-your-android-tablet-or-smartphone-all-options-included-change-size-fs-type-etc
https://forum.xda-developers.com/crossdevice-dev/android-one-general/guide-repartition-internal-storage-to-t3292159
http://en.miui.com/thread-183258-1-1.html
Reserved
sry for being so direct
here explanation for things that might didn't understood
->
Note: as much as I’d like to, I do not currently possess the resources to grant readers technical support. The guide itself, in the vast majority of cases should be sufficient help. For any individual issue please refer to online forums which are meant for that purpose.
Why Re-Partition?
If you’re here out of curiosity or any other reason than necessity, you may wonder: “why would anyone want to repartition a smartphone / tablet?”.
To answer, each person probably has their own reason, a couple of such I can think of are:
In the case of an upgrade, when there’s not enough space on one partition but others has aplenty.
When you don’t have enough space to install more apps – since your data partition is full – so you want to resize that partition.
Of course, some cases can be resolved via a more simple solution, however, if you want to deal with the problem directly and not just bypassing it – repartition is perhaps the best way to go.
In order to re-partition your device, basically, these are the steps you’ll need to make:
1. Connect your device to your PC.
2. Open up a command shell, on Windows you’d probably use CMD / PowerShell, on Mac / Linux – Terminal.
2-a. Reboot into recovery mode. (Optional, depends on the partition you plan to modify)
3. Use ADB to connect to your device.
4. Launch a partitioning software.
5. Start partitioning.
6. Reinstall any required system file in case you’ve deleted those and afterwards you may exit the shell and reboot your device.
Explaining The Steps
1. We use another machine, in this case our PC, in order to re-partition Android, because we want to have access to our Android system just in case something goes wrong during the partitioning, and also, since Android system cannot be run and resized at the same time.
2. This step is rather self explanatory. We must use a flexible tool that will assist us re-partitioning.
2-a. If you wish to modify any partition other than the recovery partition, I recommend booting into recovery mode in order to do so.
Being inside recovery mode wouldn’t interfere with the process as you may delete the system partition and its files. Furthermore, it might become handy in case you’ll need to reinstall Android system.
3. ADB is an official Android developers tool and it also happens to be the most suitable tool for the job at the moment.
5.
Since this step depends on what you’re actually intending to do with your device – it doesn’t say much, it is an open step, open for your decisions that is.
By typing the help command of your partitioning tool you’ll get a list of the options available to you. For example, these are a few of the options you’ll see in parted:
rm NUMBER – will delete a partition
mkpart – will create a partition
unit UNIT – will set unit type, for example “unit b” will set parted to use bytes, “unit gb” for Giga bytes, etc… (Tip: use bytes for maximum accuracy).
name NUMBER NAME – lets you name the partition (upon making any changes, don’t forget to name the partitions properly).
q – quit parted.
Important Things To Note:
fdisk executes your commands only when changes are saved whereas Parted executes them instantly.
fdisk may not fully support GPT partition table, thus in case yours is GPT, it’s recommended to use Parted instead.
6.
* Tip: If you’re unsure about your device partition names, you can use a command that shows them: cat /proc/partitions.
As you can see, there’s mmcblk0 – which is the main block where all the partitions are stored.
And there are 12 partitions in total which uses the name format “mmcblk0” plus “p” and a number that represent them, such as: mmcblk0p1, mmcblk0p2, etc…
Blocks lie inside /dev directory in Linux (yes, Android is a variation of Linux). We will use the block we’ve found in order to re-partition the device.
A short explanation regarding the relevant partitions:
Partition number 9 labeled FACTORYFS – is the “system” partition where all the operating system files are stored in.
Number 10 – DATAFS – is the “data” partition where all applications usually save their data.
Number 11 – UMS (USB Mass Storage) – is the internal storage partition where all the stuff such as: pictures, videos, etc, are stored in.
To resize those, you’ll have to delete them all and then assign different sizes – this is where a backup might become handy (I recommend copying all the files to your computer prior to erasing any partition).
After erasing and re-partitioning the available space, you should re-label the partitions with the same names (for compatibility sake) and create file systems (I prefer using ext4, however, if your device came with other specific file systems, it might be a good idea to stick to those).
So, how do we do it?
Here’s the sequence of commands with a following explanation:
(parted) rm 9
(parted) rm 10
(parted) rm 11
Will delete FACTORYFS, DATAFS and UMS respectively.
************
From another thread different info
By default, Parted uses MB as the storage unit. To prevent possible unused space after repartitioning, we’ll use sectors as a unit instead.
Type
unit s
This’ll change to sectors.
Type
print
It’ll give a warning, just type
i
Then:
print free
At the top, you’ll see that the sector size is written. Write this number down somewhere. For my Android One 4GB, the sector size is 512 bytes.
Now, you need to understand what the list means. Each horizontal row shows the details of a partition.
The 1st column shows the partition number.
The 2nd column shows the start offset of that partition. That means that the partition starts at the location mentioned.
The 3rd column shows where the partition ends. Notice that each partition starts exactly 1 sector after the previous one ends.
The 4th column is obviously the size of the partition.
The 5th column is the file system used by the partition. If nothing is written in this column, that means that it’s a binary partition.
The 6th column is the partition name.
You’ll see that the sizes in that list are weird. They’re not in any standard unit you might know. That’s because we used sectors instead of megabytes. The ‘s’ after each number indicates that it’s in sectors. (You can use the default MB unit (1MB=1000 KB. 1KB=1000bytes), or the MiB unit (1MiB=1024 KiB), but that just might leave 1 or 2 MB of space unused. So, I’m using sectors).
Remember that 1 sector = 512 bytes for my phone.
There’s some free space at the top and bottom of the list. Leave that free space there. Do not make partitions using those.
To convert sectors to MiB or KiB:
1s = 512bytes (Use the sector size you wrote down previously for this step, it might not be 512 bytes for you)
1024 bytes = 1 KiB
1024 KiB = 1 MiB
1024 MiB = 1GiB
So, 4833280s = (4833280 x 512) B = 2474639360 B
= (2474639360 / 1024) KiB = 2416640 KiB
= (2416640 /1024) MiB = 2360 MiB
= (2360 / 1024) GiB = 2.30 GiB
We’ll use another terminal window with sizes in MiB now. So open another Parted prompt in a new terminal / command prompt window, but instead of
unit s,
this time, write
unit MiB
Type “print”, “i”, and “print free” again
Look at my 11th partition. Its size is 8MiB. I know that this logo partition doesn’t need more than 2 MiB. So, I’ll make it smaller.
When you make partitions smaller, all the data inside will be lost. So, we need to back up the partitions first.
Open a 3rd terminal window. Type
adb shell dd if=/dev/block/mmcblk0p11 of=/microSD/p11
The “dd” command copies bytes from the “if=” location, to the “of=” location. The internal storage is /dev/block/mmcblk0. The “p11” after that refers to the partition we are backing up. Notice that in the Parted list, “logo” has a partition number of “11”. So the general command to back up partitions is
adb shell dd if=/dev/block/mmcblk0p<partition_number> of=/microSD/p<partition_number>
From recovery, unmount all partitions except microSD and oem. Then back up partitions 11, and 13 from PC. We will copy the files from OEM instead of using dd. So type
adb shell mkdir /microSD/oem
adb shell cp –a /oem/ /microSD/oem
Go to /microSD/oem/oem/app with TWRP’s file manager, and delete everything there.
Open the 1st terminal with sizes in sectors.
Type
rm 11
This will delete the oem partition. Type
print free
.
Abhijeet Rajgor said:
sry for being so direct
here explanation for things that might didn't understood
->
Note: as much as I’d like to, I do not currently possess the resources to grant readers technical support. The guide itself, in the vast majority of cases should be sufficient help. For any individual issue please refer to online forums which are meant for that purpose.
Why Re-Partition?
If you’re here out of curiosity or any other reason than necessity, you may wonder: “why would anyone want to repartition a smartphone / tablet?”.
To answer, each person probably has their own reason, a couple of such I can think of are:
In the case of an upgrade, when there’s not enough space on one partition but others has aplenty.
When you don’t have enough space to install more apps – since your data partition is full – so you want to resize that partition.
Of course, some cases can be resolved via a more simple solution, however, if you want to deal with the problem directly and not just bypassing it – repartition is perhaps the best way to go.
Click to expand...
Click to collapse
Hey, Can you tell me the partition sizes for different partitions i.e. system, data, cache.... for the attached zip file.
incomplete guide
Bro go to link in the post guide is yet incomplete , I'll rewrite again with more specific n Direct to point
Thanks
Abhijeet Rajgor said:
Bro go to link in the post guide is yet incomplete , I'll rewrite again with more specific n Direct to point
Thanks
Click to expand...
Click to collapse
Do you know how we can delete the /cust partition and include it into the system?
I don't know
bekcicandrej said:
Do you know how we can delete the /cust partition and include it into the system?
Click to expand...
Click to collapse
Am yet working on my device itself yet didn't tried on Redmi 3s,
Cwm recovery for my Alcatel
I'm a mechanical engineer, not an IT guy. I can fix machines, perhaps, but not bricked phones. So try anything at your own extreme risk. This is NOT a step by step guide.
DEVICE:
QMobile Z8, same as Wikio Ridge 4G, (MSM8916).
Running Android 5.0.2, SuperSU rooted.
Kernel v 3.10.49
Thanks to @ASAZING for TWRP 3.0.2-0
PROBLEM:
So the screen started blinking and locking / unlocking automatically like UI resetting. And there was no SIM. At first I thought it's launcher or SuperSU causing problem. But it got worse over days. So I decided a factory flash since I didn't have untouched flashable zip.
Flashed firmware using QFIL but no success. Rebooted to recovery and TWRP was still there.
/data partition was locked and TWRP doesn't support decryption. So I did a factory reset and the message came: /data not mounted. Invalid Argument
Formatted /data from "Repair or Change Filesystem" option in TWRP and as a result /data and /cache both couldn't be mounted.
Formatted /cache, and /system too not mounted.
Manually formatted using 'make_ext4' and tried 'fastboot format:ext4 userdata' as well. Both succeeded apparently but mount still failed.
Run 'e2fsck' and that showed: "Bad magic number in super block" and "The superblock could not be read."
Run 'mke2fs -n' for alternate super blocks, run again 'e2fsck' but no success. Images are attached.
'sgdisk --verify' gives this error log:
Code:
sgdisk --verify mmcblk0p1
[COLOR="Red"]***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format in memory.
***************************************************************
Exact type match not found for type code 7200; assigning type code for 'Linux filesystem'
Exact type match not found for type code 6500; assigning type code for 'Linux filesystem'
Exact type match not found for type code 7900; assigning type code for 'Linux filesystem'
Exact type match not found for type code 0D00; assigning type code for 'Linux filesystem'
Warning! Main partition table overlaps the first partition by 34 blocks!
You will need to delete this partition or resize it in another utility.
Warning! Secondary partition table overlaps the last partition by 3805778618 blocks!
You will need to delete this partition or resize it in another utility.
Problem: partitions 2 and 1 overlap:
Partition 2: 168689522 to 2104717761
Partition 1: 778135908 to 1919645538
Problem: partitions 3 and 1 overlap:
Partition 3: 1869881465 to 3805909656
Partition 1: 778135908 to 1919645538
Problem: partitions 3 and 2 overlap:
Partition 3: 1869881465 to 3805909656
Partition 2: 168689522 to 2104717761
Problem: partition 1 is too big for the disk.
Problem: partition 2 is too big for the disk.
Problem: partition 3 is too big for the disk.
Problem: partition 4 is too big for the disk.
Warning! Main partition table overlaps the first partition by 34 blocks!
You will need to delete this partition or resize it in another utility.
Warning! Secondary partition table overlaps the last partition by 3805778618 blocks!
You will need to delete this partition or resize it in another utility.
Identified 9 problems![/COLOR]
==========================
sgdisk --verify mmcblk0p16
[COLOR="red"]Creating new GPT entries.
Problem: GPT claims the disk is larger than it is! (Claimed last usable sector is 18446744073709551584, but backup header is at 1 and disk size is 2 sectors.
The 'e' option on the experts' menu will probably fix this problem
Identified 1 problems!
[/COLOR]
==========================
sgdisk --verify mmcblk0p17
[COLOR="red"]Creating new GPT entries.
Problem: GPT claims the disk is larger than it is! (Claimed last usable sector is 18446744073709551598, but backup header is at 15 and disk size is 16 sectors.
The 'e' option on the experts' menu will probably fix this problem
Identified 1 problems![/COLOR]
==========================
sgdisk --verify mmcblk0p22
[COLOR="red"]Creating new GPT entries.
Problem: GPT claims the disk is larger than it is! (Claimed last usable sector is 18446744073709551614, but backup header is at 31 and disk size is 32 sectors.
The 'e' option on the experts' menu will probably fix this problem
Identified 1 problems![/COLOR]
'parted rm' and 'fastboot erase' didn't work either. Partition was still there.
Then I tried to flash stock recovery through TWRP. And recovery too gone.
Now, device boots directly to bootloader (fastboot mode) and is halted there. Have to 'fastboot boot recovery.img' or 'fastboot boot boot.img' each time.
Download Mode (QDLoader 9008) is also accessible.
FLASHING FACTORY FIRMWARE:
Now left only with fastboot and EDL, tried once again QFIL flasher, Wiko official flasher, QDownloader. Log says: "Read back verify failed at sector ...." for partitions misc, system, cache, persist, recovery, userdata (6 partitions) and 2 partition table *.bins
Hence proved, eMMC is malfunctioning and device now can't boot on its own due to no partition table.
Tried 'sgdisk --backup' and 'sgdisk --load-backup' options for partition table. It gives error: "Warning! Current disk size doesn't match that of backup." and "Problem: Partition 28 ends before it begins." etc.
'fastboot flash partition *.bin' also failed with error: "remote: failed to write partition".
'dd if=gpt_main0.bin of=/dev/block/mmcblk0' apparently succeeded but comparing octal dump ('od') files of 34 sectors at start shows no difference, means file is not written to eMMC.
SOLUTION SUMMARY:
Partition SD card according to already existing partition table on internal eMMC.
Flash partition images from factory firmware to newly created partitions.
Modify kernel (boot.img) and recovery to boot from sd card instead of internal memory.
Boot kernel or recovery through fastboot.
SECTION 1
PARTITION SD CARD:
Here comes Google. Following the footsteps of @lexelby at this, I created gpt (parted command) on 16GB C-10 sd card using Ubuntu virtual machine.
Created first partition for external_sd card and 6 more of same size as original ones (size checked by parted and from rawprogram_unsparse.xml). Filesystems: system, userdata, cache & persist of ext4 while misc, recovery of linux-swap (though 'dd' will overwrite them).
Then I unsparsed userdata, system and cache images from factory firmware (on Windows used packsparseimg.exe binary). Sparsed images can only be flashed through fastboot?
Copied 5 prtitions images: userdata, system, cache, persist and misc using dd command to /dev/block/mmcblk1p*.
MODIFYING BOOT & RECOVERY:
Now coming to the changes in mount paths of boot and recovery (fstab and init.*.rc).
Extracted boot.img and then ramdisk using "Image Studio for Android". 'unpackbootimg' and 'abootimg' don't extract all files on Ubuntu. 'mkbootimg' makes smaller boot.img file without boot.img-dtb. Perhaps I'm doing it wrong.
Anyway, then did 'grep dev/block' on all extracted files. Results are attached for reference.
Made changes in "fstab.qcom" and "init.target.rc". For details on changes made, please read on RE-MODIFYING BOOT & RECOVERY.
Repacked boot.img
Similarly extracted recovery.img, did 'grep dev/block' on all extracted files. And made changes in "recovery.fstab".
Repacked recovery.img
COPYING IMAGES TO PARTITIONS AND BOOTING:
'fastboot flash boot boot.img' and 'dd if=recovery.img of=dev/block/mmcblk1p*' (though useless, have to boot from fastboot)
Rebooted to recovery by 'fastboot boot recovery.img'
userdata, persist and cache couldn't be mounted in TWRP. Tried 'mount -t ext4 -o loop *.img' on Ubuntu but there too not mounted. Googled and using commands 'file', 'fdisk', 'sfdisk', 'e2fsck' and finally 'resize2fs -f /*.img' resolved the problem "bad geometry: block count xxx exceeds size of device...".
Also unsparsed userdata too large to handle and only a few MBs data inside, that too useless. Therefore, did 'make_ext4fs' on cache & userdata.
Now booted kernel by 'fastboot boot boot.img'
And.......... it boots. But very very slow (due to slow write speed of sd card obviously). Took almost half an hour at first boot.
UNRESOLVED PROBLEMS:
There is no sound. Because of /persist not mounted? And still no SIM, means radio firmware isn't readable from eMMC or this too due to /persist absent? After all that contains drivers. And also Wi-Fi and bluetooth not working.
SECTION 2
RE-PARTITION SD CARD:
So re-created gpt on sd card (using parted and fdisk) and in a hope to utilize all necessary partitions, 100% replicated all partitions (except larger userdata) including space required at start and end of eMMC for partition table. Partition tables of both mmcblk0 and mmvblk1 are attached.
RE-MODIFYING BOOT & RECOVERY:
Made following changes in boot.img:
DEVICE BOOTS ALSO WITHOUT MAKING ANY CHANGES TO BOOT.IMG.
I don't know why but 'bootdevice' is automagiacally changed from 7824900.sdhci (eMMC) to 7864900.sdhci (external SD card). It seems there is some auto-detection mechanism.
Code:
########## ./ramdisk/fstab.qcom ##########
#/dev/block/bootdevice/by-name/system /system ext4 ro,barrier=1,discard wait
#/dev/block/bootdevice/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard wait,check,encryptable=footer
#CHANGED TO
/dev/block/[B]mmcblk1p24[/B] /system ext4 ro,barrier=1,discard wait
/dev/block/[B]mmcblk1p32[/B] /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard wait,check,encryptable=footer
#/devices/soc.0/7864900.sdhci/mmc_host /storage/sdcard1 vfat nosuid,nodev wait,voldmanaged=sdcard1:auto,noemulatedsd
#[B]disabled[/B]
Code:
########## ./ramdisk/init.target.rc ##########
on fs
mount_all fstab.qcom
#wait /dev/block/bootdevice/by-name/cache
#mount ext4 /dev/block/bootdevice/by-name/cache /cache nosuid nodev barrier=1
#CHANGED TO
wait /dev/block/[B]mmcblk1p26[/B]
mount ext4 /dev/block/[B]mmcblk1p26[/B] /cache nosuid nodev barrier=1
#wait /dev/block/bootdevice/by-name/persist
#mount ext4 /dev/block/bootdevice/by-name/persist /persist nosuid nodev barrier=1
#CHANGED TO
wait /dev/block/[B]mmcblk1p25[/B]
mount ext4 /dev/block/[B]mmcblk1p25[/B] /persist nosuid nodev barrier=1
#wait /dev/block/bootdevice/by-name/modem
#mount vfat /dev/block/bootdevice/by-name/modem /firmware ro context=u:object_r:firmware_file:s0,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337
#CHANGED TO
wait /dev/block/[B]mmcblk1p1[/B]
mount vfat /dev/block/[B]mmcblk1p1[/B] /firmware ro context=u:object_r:firmware_file:s0,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337
on charger
#wait /dev/block/bootdevice/by-name/system
#mount ext4 /dev/block/bootdevice/by-name/system /system ro barrier=1
#CHANGED TO
wait /dev/block/[B]mmcblk1p24[/B]
mount ext4 /dev/block/[B]mmcblk1p24[/B] /system ro barrier=1
Code:
########## ./split_img/boot.img-cmdline ##########
#console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=30 msm_rtb.filter=0x3F ehci-hcd.park=3 androidboot.bootdevice=7824900.sdhci lpm_levels.sleep_disabled=1
#CHANGED TO
console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=30 msm_rtb.filter=0x3F ehci-hcd.park=3 [B]androidboot.bootdevice=7864900.sdhci[/B] lpm_levels.sleep_disabled=1
And following changes in recovery.img:
Code:
########## ./ramdisk/etc/recovery.fstab ##########
#/cache ext4 /dev/block/bootdevice/by-name/cache flags=display=Cache
#/system ext4 /dev/block/bootdevice/by-name/system flags=display=System
#/data ext4 /dev/block/bootdevice/by-name/userdata flags=encryptable=footer;length=-16384
#/persist ext4 /dev/block/mmcblk0p25 flags=backup=1;display=Persist
#/boot emmc /dev/block/bootdevice/by-name/boot flags=display=Boot
#/recovery emmc /dev/block/bootdevice/by-name/recovery flags=backup=1;display=Recovery
#/misc emmc /dev/block/bootdevice/by-name/misc /misc flags=backup=1;display=Misc
#/firmware vfat /dev/block/mmcblk0p1 flags=backup=1;display=Modem
#/splash emmc /dev/block/mmcblk0p18 flags=backup=1;display=Splash
#/fsg emmc /dev/block/mmcblk0p20 flags=backup=1;subpartitionof=/oem
#/aboot emmc /dev/block/mmcblk0p4 flags=backup=1;display=Aboot
#/abootbak emmc /dev/block/mmcblk0p5 flags=subpartitionof=/aboot;backup=1
#/hyp emmc /dev/block/mmcblk0p10 flags=backup=1;display=Firmware-update
#/sbl1 emmc /dev/block/mmcblk0p2 flags=backup=1;subpartitionof=/hyp
#/rpm emmc /dev/block/mmcblk0p6 flags=backup=1;subpartitionof=/hyp
#/tz emmc /dev/block/mmcblk0p8 flags=backup=1;subpartitionof=/hyp
#/hypbak emmc /dev/block/mmcblk0p11 flags=backup=1;subpartitionof=/hyp
#/sbl1bak emmc /dev/block/mmcblk0p3 flags=backup=1;subpartitionof=/hyp
#/rpmbak emmc /dev/block/mmcblk0p7 flags=backup=1;subpartitionof=/hyp
#/tzbak emmc /dev/block/mmcblk0p9 flags=backup=1;subpartitionof=/hyp
#/modemst1 emmc /dev/block/mmcblk0p13 flags=backup=1;display=EFS
#/modemst2 emmc /dev/block/mmcblk0p14 flags=backup=1;subpartitionof=/modemst1
#/oem emmc /dev/block/mmcblk0p30 flags=backup=1;display=OEM
#/DDR emmc /dev/block/mmcblk0p20 flags=backup=1;subpartitionof=/oem
#/fsc emmc /dev/block/mmcblk0p16 flags=backup=1;subpartitionof=/oem
#/ssd emmc /dev/block/mmcblk0p17 flags=backup=1;subpartitionof=/oem
#/pad emmc /dev/block/mmcblk0p12 flags=backup=1;subpartitionof=/oem
#CHANGED TO
/cache ext4 /dev/block/[B]mmcblk1p26[/B] flags=display=Cache
/system ext4 /dev/block/[B]mmcblk1p24[/B] flags=display=System
/data ext4 /dev/block/[B]mmcblk1p32[/B] flags=encryptable=footer;length=-16384
/persist ext4 /dev/block/[B]mmcblk1p25[/B] flags=backup=1;display=Persist
/boot emmc /dev/block/[B]mmcblk1p23[/B] flags=display=Boot
/recovery emmc /dev/block/[B]mmcblk1p27[/B] flags=backup=1;display=Recovery
/misc emmc /dev/block/[B]mmcblk1p15[/B] flags=backup=1;display=Misc
/firmware vfat /dev/block/[B]mmcblk1p1[/B] flags=backup=1;display=Modem
/splash emmc /dev/block/[B]mmcblk1p18[/B] flags=backup=1;display=Splash
/fsg emmc /dev/block/[B]mmcblk1p21[/B] flags=backup=1;subpartitionof=/oem
/aboot emmc /dev/block/[B]mmcblk1p4[/B] flags=backup=1;display=Aboot
/abootbak emmc /dev/block/[B]mmcblk1p5[/B] flags=subpartitionof=/aboot;backup=1
/hyp emmc /dev/block/[B]mmcblk1p10[/B] flags=backup=1;display=Firmware-update
/sbl1 emmc /dev/block/[B]mmcblk1p2[/B] flags=backup=1;subpartitionof=/hyp
/rpm emmc /dev/block/[B]mmcblk1p6[/B] flags=backup=1;subpartitionof=/hyp
/tz emmc /dev/block/[B]mmcblk1p8[/B] flags=backup=1;subpartitionof=/hyp
/hypbak emmc /dev/block/[B]mmcblk1p11[/B] flags=backup=1;subpartitionof=/hyp
/sbl1bak emmc /dev/block/[B]mmcblk1p3[/B] flags=backup=1;subpartitionof=/hyp
/rpmbak emmc /dev/block/[B]mmcblk1p7[/B] flags=backup=1;subpartitionof=/hyp
/tzbak emmc /dev/block/[B]mmcblk1p9[/B] flags=backup=1;subpartitionof=/hyp
/modemst1 emmc /dev/block/[B]mmcblk1p13[/B] flags=backup=1;display=EFS
/modemst2 emmc /dev/block/[B]mmcblk1p14[/B] flags=backup=1;subpartitionof=/modemst1
/oem emmc /dev/block/[B]mmcblk1p30[/B] flags=backup=1;display=OEM
/DDR emmc /dev/block/[B]mmcblk1p20[/B] flags=backup=1;subpartitionof=/oem
/fsc emmc /dev/block/[B]mmcblk1p16[/B] flags=backup=1;subpartitionof=/oem
/ssd emmc /dev/block/[B]mmcblk1p17[/B] flags=backup=1;subpartitionof=/oem
/pad emmc /dev/block/[B]mmcblk1p12[/B] flags=backup=1;subpartitionof=/oem
#/external_sd auto /dev/block/mmcblk1p1 /dev/block/mmcblk1 flags=display="MicroSD Card";storage;wipeingui;removable
#CHANGED TO
# None. [B]External sd disabled[/B].
Code:
########## ./ramdisk/uneventd.rc ##########
#/dev/block/bootdevice/by-name/config 0660 system system
#CHANGED TO
/dev/block/[B]mmcblk1p29[/B] 0660 system system
Code:
########## ./split_img/recovery.img-cmdline ##########
#console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=30 msm_rtb.filter=0x3F ehci-hcd.park=3 androidboot.bootdevice=7824900.sdhci lpm_levels.sleep_disabled=1 androidboot.selinux=permissive
#CHANGED TO
console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=30 msm_rtb.filter=0x3F ehci-hcd.park=3 [B]androidboot.bootdevice=7864900.sdhci[/B] lpm_levels.sleep_disabled=1 androidboot.selinux=permissive
Repacked boot.img and recovery.img.
RE-COPYING IMAGES TO PARTITIONS AND BOOTING:
Copied (dd) all available (15) images to (20) partitions on sd card.
Copied (dd) the 10 images not found in factory firmware from mmcblk0 to mmcblk1. (Not sure if successful).
2 partitions (/data and /cache) already formatted in ext4.
'fastboot boot recovery.img'. All partitions are mounted now. No horrible error lines.
'fastboot boot boot.img'
ROM booted successfully WITH sounds, SIM, Wi-Fi and Bluetooth. All seems working well so far.
SECTION 3
Continued on post 3...
hello hi
i have xiaomi redmi 2 chinesse version with same problem with your device. stuck logo, only still can access recovery TWRP via fastboot boot trwp.img.
twrp cant wipe, cant format, internal storage 0mb, "failed argument ".cant flash stock rom with flash tools "failed write partition", . try terminal parted rm not solve. try to many google same issue not solve. i think emmc or hardware issue
i never using linux and linux command so
please help me.make step by step guide , boot from sdcard .
- make partition sd card to be like emmc partition block
- can i using windows os or using small linux distro
- how to modif image stock rom ,kernel ,and flashing to sdcard
- how to boot from sdcard
many thank you
Continued from OP...
SECTION 3
QUERIES:
UNCERTAIN PARTITIONS
But there are no images available for these 10 partitions in factory firmware:
pad, modemst1, modemst2, fsc, ssd, DDR, keystore, config, oem & devinfo.
These seem to be very essential for OS, also containing IMEI if I'm not mistaken? I'm not sure of their contents. How system working without them? All are useless?
HOW TO COMPLETELY BOOT FROM SD CARD
In boot.img, "fstab.qcom" contains mount paths for system & userdata. While "init.target.rc" contains only mount paths for cache, persist and modem. In total 5 partitions which are mounted (checked by 'mount').
Code:
[email protected]:/ $ mount | grep mmcblk1
/dev/block/mmcblk1p24 /system ext4 rw,seclabel,relatime,discard,data=ordered 0 0
/dev/block/mmcblk1p32 /data ext4 rw,seclabel,nosuid,nodev,relatime,discard,noauto_da_alloc 0 0
/dev/block/mmcblk1p26 /cache ext4 rw,seclabel,nosuid,nodev,relatime 0 0
/dev/block/mmcblk1p25 /persist ext4 rw,seclabel,nosuid,nodev,relatime,data=ordered 0 0
/dev/block/mmcblk1p1 /firmware vfat ro,context=u:object_r:firmware_file:s0,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=437,iocharset=iso8859-1,shortname=lower,errors=remount-ro 0 0
[email protected]:/ $
So the primary question is:
How to change mount source of other partitions from mmcblk0 to mmcblk1? Or how to force OS to read the essentially required partitions from mmcblk1 instead of mmcblk0?
Need to modify any other files in ramdisk or kernel-zimage or in /system or to modify init.d scripts or create new scripts? Any help?
Other than 10 partitions mentioned above, these "not mounted" partitions also include modem, sbl1, aboot, rpm, tz and hyp and fsg. Modem contains bootable code of MBR and following 5 are also executable binaries. I think these are all part of bootloader i.e. loading in initial booting process and not required by OS. But what about the fsg and ten others? Where are those used? Here is a partition detail.
Another primary issue is:
I think it's almost impossible to make Boot ROM (CPU embedded) hand over charge to bootloader at "mmcblk1". "mmcblk0" must be hardcoded in Boot ROM.
So, how to make bootloader load "kernel" and "rootfs" from mmcblk1p* instead of mmcblk0p*? Like there are switches in testing devices to optionally boot from different memories. Can we modify "aboot" (the little kernel) or "emmc_appsboot.mbn" ELF binary for this purpose? It must be complicated as bootloaders are signed by vendor (Qualcomm) and involve low-level programming as discussed here. Right?
Or in other words, how to force bootloader to read partition table from dev/mmcblk1 instead of dev/mmcblk0?
If we can't do this, system doesn't know how to boot in the absence of eMMC. That would have to be done through fastboot everytime we need to. Because boot chain will be stuck at bootloader.
Multi-booting solutions are also dependent on a fully working /boot partition on eMMC because they (one way or the other) re-flash/replace modified boot image every time a ROM is to be switched. EFIDroid is a secondary bootloader but that too replaces /boot and/or /recovery.
I have gone through this, this, this and this. But they only address partial booting from sd card e.g. dual booting in which only /system, /data and /cache are involved. None has discussed complete boot from sd. Is it really impossible? This link gives a little hope but it points to a ready made solution (bootloader) which boots kernel from SD card. But it gives no explanation how.
I have also come across a few threads discussing Samsung (and HTC too) booting from SD Card as a fix to QHSUSB_DLOAD mode or bricked-bootloaader state. They extracted "debrick" file from a working phone and flashed that to the start of SD Card. Debrick file seems to be a single bootloader file containing all bootloaders in it as explained here and here. So after flashing the bootloader(s) with its accompanying partitions to SD Card, when device was powered on, it automatically booted from SD Card. If it's that simple for all devices with Qualcomm SoC, the only thing I have to do is :laugh:
Code:
[COLOR="Red"]dd if=/dev/zero of=/dev/block/mmcblk0 bs=1m count=200[/COLOR]
Any suggestions? I believe this must be possible as they are discussing here.
Edit: Related quote from [GUIDE][9008][EDL|QDL][QUALCOMM ONLY] Unbrick via external sdcard (no QFIL!):
On eMMC devices, the boot path is /dev/block/mmcblk0. If you have a 9008 brick, the SD card is seen as /dev/block/mmcblk0 so the phone will boot from it on an eMMC device.
Click to expand...
Click to collapse
Some secondary questions:
HOW ARE PARTITIONS IDENTIFIED BY BOOT-ROM WITHOUT PARTITION TABLE ON eMMC
If there is no readable partition table on a bricked eMMC, how Boot ROM (primary bootloader on SoC) switches control to secondary bootloader or bootable modem partition or other partitions used by processors? Means how SoC / Processors locate modem, sbl, rpm, tz or aboot (the little kernel's offspring) on eMMC? Also, why 'parted /dev/block/mmcblk0 p' and 'sgdisk --print /dev/block/mmcblk0'show partitions if there is no table?
Though parted-2.2 shows warning:
Code:
[COLOR="Red"]Error: Both the primary and backup GPT tables are corrupt. Try making a fresh
table, and using Parted's rescue feature to recover partitions.[/COLOR]
Or I'm thinking in wrong direction? This link discusses the issues but I'm not clear how it works.
Once the a device is powered on it starts code from a know location (ROM) and looks for the first stage bootloader in a specific block.
Click to expand...
Click to collapse
How is this "specific block" located by cpu ROM?
It's talking about some "low-level" and "high-level" partition tables. How they differ? How can we manipulate the former?
And finally...
HOW TO SPEED UP SD CARD
Other than using a UHS-III or the most recent and expensive App Performance Class (A1) sd card, what changes we can make to kernel to boost read/write speed? Otherwise, it's almost useless with too slow speed, frequent ANRs, hangs and laggings.
Default I/O scheduler being used on QMobile Z8 is cfq with default tune-able settings. I think it's one of best schedulers for higher throughput. Na? Try other? Details here:
Code:
[email protected]:/ # cat /sys/block/mmcblk0/queue/scheduler
noop deadline row [cfq]
[email protected]:/ # for fyle in $(find /sys/block/mmcblk0/queue/iosched/ -type f); do echo $fyle; cat $fyle; done;
/sys/block/mmcblk0/queue/iosched/fifo_expire_async
50
/sys/block/mmcblk0/queue/iosched/group_idle
0
/sys/block/mmcblk0/queue/iosched/quantum
20
/sys/block/mmcblk0/queue/iosched/slice_async
40
/sys/block/mmcblk0/queue/iosched/slice_idle
10
/sys/block/mmcblk0/queue/iosched/slice_sync
100
/sys/block/mmcblk0/queue/iosched/low_latency
0
/sys/block/mmcblk0/queue/iosched/fifo_expire_sync
50
/sys/block/mmcblk0/queue/iosched/back_seek_max
16384
/sys/block/mmcblk0/queue/iosched/target_latency
300
/sys/block/mmcblk0/queue/iosched/back_seek_penalty
2
/sys/block/mmcblk0/queue/iosched/slice_async_rq
2
[email protected]:/ # cat /sys/block/mmcblk1/queue/scheduler
noop deadline row [cfq]
[email protected]:/ # for fyle in $(find /sys/block/mmcblk1/queue/iosched/ -type f); do echo $fyle; cat $fyle; done;
/sys/block/mmcblk1/queue/iosched/fifo_expire_async
50
/sys/block/mmcblk1/queue/iosched/group_idle
0
/sys/block/mmcblk1/queue/iosched/quantum
20
/sys/block/mmcblk1/queue/iosched/slice_async
40
/sys/block/mmcblk1/queue/iosched/slice_idle
10
/sys/block/mmcblk1/queue/iosched/slice_sync
100
/sys/block/mmcblk1/queue/iosched/low_latency
0
/sys/block/mmcblk1/queue/iosched/fifo_expire_sync
50
/sys/block/mmcblk1/queue/iosched/back_seek_max
16384
/sys/block/mmcblk1/queue/iosched/target_latency
300
/sys/block/mmcblk1/queue/iosched/back_seek_penalty
2
/sys/block/mmcblk1/queue/iosched/slice_async_rq
2
[email protected]:/ #
Tried different cache values (read_ahead_kb) from 64 to 4048. Makes no difference apparently.
Also disabled jounalling using 'tune2fs -O ^has_journal' and e2fsck checks using 'tune2fs -c -1'.
Changed mount options to for /data and /cache:
Code:
[email protected]:/ # mount | grep -E "/cache|/data"
/dev/block/mmcblk1p32 /data ext4 rw,seclabel,[B]noatime,discard,nobarrier,noauto_da_alloc,commit=60[/B] 0 0
/dev/block/mmcblk1p26 /cache ext4 rw,seclabel,noatime,discard,nobarrier,noauto_da_alloc,commit=60 0 0
[email protected]:/ #
Seems useless so far. Any ideas? Or it's a hardware limitation of device?
Is there a way to get rid of FUSE and use ext4 in true sense for whole /data (only possible if someone is willing to quit using MTP), though it doesn't matter much for Android's internal operations? But it's a real pain for I/O operations on external media.
Edit: Speed much improved by using a more certain branded SD Card; Sandisk C-10.
@yoAeroA00 Sir need your special attention for kernel part. You have a good history with kernel tweaking and multibooting.
I try to manual flash commands, one by one read from flash_all.bat. everything is okay finish, except file "gpt_both0.bin" and "sec.dat"
jeksparo said:
I try to manual flash commands, one by one read from flash_all.bat. everything is okay finish, except file "gpt_both0.bin" and "sec.dat"
Click to expand...
Click to collapse
If flasher is unable to flash partitions, then flashing manually won't make any difference. "gpt_both0.bin" contains partition tables; main and backup. First sector is protective mbr for legacy partitioning tools and next 33 sectors contain gpt partition table. A backup of partition table is stores on last 33 sectors of disk or emmc in our case. Total 67 sectors make 33.5 KiB size which is same as that of gpt_both0.bin. Let me have a look at partition table for further clarity. Run these from twrp to save your partition table.
Code:
sgdisk -p /dev/block/mmcblk0 > pt1
parted /dev/block/mmcblk0 p free > pt2
cant compile sgdisk -p /dev/block/mmcblk0 > pt1 invalid option --p
and parted /dev/block/mmcblk0 > pt2 blank line after entering
my device shell dont have parted command, so i run parted from sd card.
how to created gpt on sdcard using parted and fdisk, if my parted command in sdcard too, it is possible?
jeksparo said:
cant compile sgdisk -p /dev/block/mmcblk0 > pt1 invalid option --p
and parted /dev/block/mmcblk0 > pt2 blank line after entering
my device shell dont have parted command, so i run parted from sd card.
how to created gpt on sdcard using parted and fdisk, if my parted command in sdcard too, it is possible?
Click to expand...
Click to collapse
For sgdisk use --print as help shown in your screenshot.
Code:
sgdisk --print /dev/block/mmcblk0 > /part_table
"> /partition_table" is to save the output in root directory so that you can copy paste it. Otherwise you can also take screenshots in TWRP with PWR + VOL- combination.
'parted' doesn't come bundled with TWRP. You can use the binary from your SD card but you need to copy it somewhere else like '/sbin' if you want to partition you SD card. 'fdisk' can't create GPT, it's legacy tool for MBR partition scheme. You need to use 'parted', 'gdisk' or 'sgdisk' etc. to create partitions. Binaries for Android are with limited functionality. That's why Linux is preferred, but not necessary. Also the copying of partition images will be easy on Linux, though very slow if you connect card reader in virtual machine.
These partitions on your device contain filesystem and will be mounted in ROM
modem vfat
system ext4
cache ext4
persist ext4
userdata ext4
Click to expand...
Click to collapse
Boot and recovery partitions can also be used if your partition table isn't too corrupt to recognize them. Otherwise you'll have to use fastboot on every boot like me.
Simple is to duplicate the whole internal partition table on SD card because rest of the partitions don't occupy much space. It makes partition numbering easy.
But before creating partitions, you need to know exact boundaries in bytes:
Code:
parted /dev/block/mmcblk0
(parted) u b
(parted) p free
(parted) q
please hellp me
Hiii . i have wiko ridge 4g and i have the same problem as you it stuck on wiko logo and when i try to flash it with stock rom from wiko site nothing hapend and i tried to flash it using Qfil in the log i see "Read back verify failed at sector" the same problem as you sooooo please make step by step guid
i can boot to download mode . when i try to boot to recovery it boot to fastboot mode automaticly .....plz help me..... -sorry for my english-
_6ix._.9ine said:
Hiii . i have wiko ridge 4g and i have the same problem as you it stuck on wiko logo and when i try to flash it with stock rom from wiko site nothing hapend and i tried to flash it using Qfil in the log i see "Read back verify failed at sector" the same problem as you sooooo please make step by step guid
i can boot to download mode . when i try to boot to recovery it boot to fastboot mode automaticly .....plz help me..... -sorry for my english-
Click to expand...
Click to collapse
On what part you need help? It's all about partitioning an sd card and copying data to it. Then unpack, modify and re-pack boot.img
plllllz help me
mirfatif said:
On what part you need help? It's all about partitioning an sd card and copying data to it. Then unpack, modify and re-pack boot.img
Click to expand...
Click to collapse
i've been trying to understand what u wrote for the last 7 days and i couldn't understand shiiiit :crying:
i don't know anything about this shiiiit :crying: i'm so sad plz make video and upload it on youtube and show me step by step how did u boot from sd card plllllllllllllllllz _sorry for my english_
MODIFYING BOOT & RECOVERY:
Now coming to the changes in mount paths of boot and recovery (fstab and init.*.rc).
Extracted boot.img and then ramdisk using "Image Studio for Android". 'unpackbootimg' and 'abootimg' don't extract all files on Ubuntu. 'mkbootimg' makes smaller boot.img file without boot.img-dtb. Perhaps I'm doing it wrong.
Anyway, then did 'grep dev/block' on all extracted files. Results are attached for reference.
Made changes in "fstab.qcom" and "init.target.rc". For details on changes made, please read on RE-MODIFYING BOOT & RECOVERY.
Click to expand...
Click to collapse
In that part I used the "ABOOTIMG". To work, do the following:
Code:
$ sudo abootimg -x boot.img ramdisk ramdisk kernel kernel
or
Code:
#abootimg -x boot.img ramdisk ramdisk kernel kernel
You will find 3 files. The "RAMDISK" comes packaged in "GZIP". Unzip it and enter the folder that will be created. Inside this folder you will have the files to edit as the post follows.
By the way, congratulations for the initiative!
Turkish
Nothing is understood when it is translated. Can a British English translate this to me?
Thanks you very much for your great story and for a lot of informations!
Peace & Respect
mirfatif,
thanks for this interesting and promising information!
I'd like, though, get an additional explanation: you use "fastboot" to handle your smartphone. Does it mean,
that it was bootable when you've started all this stuff with booting from SD-card?
I'm asking because I'm trying to boot my samsung galaxy GT-N7100 from sd-card with completely dead emmc.
igorbounov said:
you use "fastboot" to handle your smartphone. Does it mean,
that it was bootable when you've started all this stuff with booting from SD-card?
Click to expand...
Click to collapse
My phone doesn't have "completely" dead eMMC. Booting process works up to bootloader (aboot) and it's related partitions. So fastboot works (as it's managed by bootloader). But after that, bootloader can't load boot image (kernel) from boot partition. Neither recovery partition is readable. Thus I have to do it manually using fastboot. And the remaining OS related partitions are read from SD card.
mirfatif said:
My phone doesn't have "completely" dead eMMC..
Click to expand...
Click to collapse
Now I get the idea... Nevertheless it looks like now I should stop attempts recovering smartphone because while trying I've turned
(somehow) my available 64Gb Samsung SD-card to a write-protected state (while partitioning). So my further experiments seem
not worth it - now it looks like buying a new Galaxy Note with a new SD-card is more cost-effective.
igorbounov said:
I've turned
(somehow) my available 64Gb Samsung SD-card to a write-protected state (while partitioning).
Click to expand...
Click to collapse
Are you unable to create a new partition table using parted/fdisk/gdisk?
mirfatif said:
Are you unable to create a new partition table using parted/fdisk/gdisk?
Click to expand...
Click to collapse
No, I've used everything - even Windows-oriented utilities for low level formatting. All of them complain that
this SD card is write-protected. It has stuck in a strange state - a gpt table created, but no partitions.
And some programs (sfdisk or sgdisk, and even diskpart from Windows) find there some inconsistences.
Perhaps the inner electronics thinks that this errors correspond to a worn state - and sets this read-only attribute.
When I partitioned this sd-card, I've first created the new gpt table, then for a long time speculated about which
partition of what type and size should be created. In this process I've opened two or maybe more parted and
gparted sessions, and then I've saved partitions from one session, then maybe from other... and now this
memory card is in read-only state. Perhaps it has decided that this is the most safe way.
igorbounov said:
No, I've used everything - even Windows-oriented utilities for low level formatting....
Click to expand...
Click to collapse
How did you connect SD card to PC? I mean USB card reader, SD card slot etc. Sometimes card reader drivers are causing the problems. Are you using Linux / Windows natively or on a VM? Did you try creating partition table on Android phone? Usually phones can handle SD cards better. Try card slot or OTG, in TWRP or from ROM, using arm or aarch64 binaries of parted, fdisk and gdisk. Command line tools are preferable for troubleshooting than GUI tools.
mirfatif said:
How did you connect SD card to PC? I mean USB card reader, ...
Click to expand...
Click to collapse
I've used a chip USB card reader. Linux and Windows natively and Windows in a VM (QEMU/KVM). I haven't yet found some other volunteer with Android phone to put my SD card there. My old faithfull Nokia 6131 just don't see this card (and shouldn't, there are no partitions and Nokia 6131 cannot handle sd cards of such size). Yesterday I've used an old card reader, that is built in my daughter's PC, I've used for that purpose a special SD casing for microSD - Windows disk management confirmed that this SD card is read-only.
May be some embedded device could help in this situation - some AVR- or STM32-based device via SPI (than it doesn't matter wether there is some protection or no).