Related
I have done wonderful things to my device thanks in large part to this community. Thank you.
I see that the system partition has about 1 GB of free space yet there are only 427 MB of files in there. Do I need that much free space? If not, how can I safely resize it?
Using parted. I've tried doing it though, shrinking my data partition to give more to system but it won't stick for some reason. Either I'm doing it wrong, or it doesn't work
The parted binary for android can be found on Cyanogenmod's github in the android_bootable_recovery repo
@CNexus, thanks. I appreciate that. I'll take a peek at that. Strangely enough I'm looking to shrink my system partition. I've seen others are wanting the opposite.
I've partitioned PC drives before but this appears to be much more involved.
Does anyone know of an optimum allotment for system and cache that I should follow?
You should be fine whatever you do.
Worst case if something goes wrong, just flash the PIT file for your internal storage size in Odin and all should be good
But yes, this will be more involved since it will need to be all command-line
I figured this out after a struggle, so I figured I would pass along the info in case it helps anyone else.
I'm running CyanogenMod 11 (Android 4.4.4 Kit Kat AOSP based) on my T-Mobile Galaxy S III. I'm on vacation in Mexico, and I had planned to use my Verizon HTC Rezound (aka HTC Vigor) as a phone with a local Mexican SIM card from Telcel. Once I was in Mexico I discovered that the Rezound does not support the GSM/HSPA bands commonly used in North America. It should work fine in Europe, but I could only get Edge service. I decided to try to unlock my T-Mobile Galaxy S III to see if it worked any better.
The free unlock methods I found seemed to require the stock Service Mode applications - so I needed to install a stock rom. I tried to flash a rooted stock 4.3 ROM but the instructions didn't seem to work. The baseband I was running seemed to be too new for the unlock method, which was noted as working with 4.1.1. I tried to downgrade the baseband. It still did not work. I tried flashing a stock rooted 4.1.1 image, and it still did not work. At some point while trying things I realized that no baseband was getting reported in the about screen and no IMEI number was being reported. The phone wasn't even trying to connect to the network. Googling around made me think I hosed my EFS partition. I didn't have a backup.
I hoped that if the EFS partition was corrupted, it might get rebuilt. I used 'dd if=/dev/block/platform/msm_sdcc.1/by-name/efs of=/storage/extSdCard/efs.img' to make a copy of the current state of the efs, then I deleted all the files. I restarted the phone. So data got written to efs, but still I couldn't connect to the network. I didn't have a windows computer with Odin on my trip, by I tried used heimdall with my Mac to write a stock 4.1.1 rom. Still no luck. Not only was the network not working, but the touch screen and buttons were erratic and it would spontaneously reboot. Also, it would generate no sound at all. I figured I practically had a brick. I tossed it in my suitcase and left it until I got home.
When I got home I used ODIN to write the most recent (Android 4.3) root66 stock rooted image. On reboot I got sound back. That was promising. I used dd again to restore the contents of my EFS partition. I was able to connect to the network again. I installed the latest snapshot build of CyanogenMod 11 and everything seems to be working.
I finally put the pieces together. The EFS partition in older roms is formatted with a FAT filesystem, and in new roms it is formatted with an ext4 filesystem. At some point as the phone is upgraded, the EFS partition gets updated to the newer filesystem. Older basebands can not read the data from the ext4 filesystem. If you do not have a backup of the FAT version of your EFS partition, you can't downgrade to the older baseband.
I don't know the precise transition point, but the baseband that comes with 4.3 can read the ext4 partition fine, but the basebands with 4.1 need the FAT partition.
If you open a terminal shell on your phone or with adb shell, then type 'mount', you'll see a list of mounted volumes. The entry for the EFS partition will look like this...
Code:
/dev/block/platform/msm_sdcc.1/by-name/efs /efs ext4 rw,seclabel,nosuid,nodev,noatime,user_xattr,barrier=1,journal_async_commit,data=ordered,noauto_da_alloc,discard 0 0
The first field is the location of the partition. The second field - in this case '/efs' is the mount point. The third field is the filesystem type. Here you see 'ext4'. On your phone, look for the line where the second entry is '/efs'. If the third entry is 'vfat' you can downgrade to older basebands. If it is 'ext4' you can't go to very old basebands unless you have a backup of the old version of your EFS partition and you know how change the filesystem format. Anyone with decent Unix/Linux experience should be able to do that - it isn't hard - but I don't have the old EFS backup to try it out, so I won't try to give any instructions here.
I hope this saves you some trouble.
I think I understand the theory behind what you are trying to explain here, but I dont think this will make a difference.
First though, how did you come to the conclusion that older builds format that partition differently, or more specifically, as vFAT? And that older modems can only read this format?
The reason I dont believe this will make any difference is because much of the data everyone seems to think is located on the EFS partition is not there on the Qualcomm model S3's. For example, the IMEI. On older devices, and maybe some newer ones (dont know for sure), it was moved. If I remember correctly, some of the NV Data is stored on modemst1, some on modemst2, some on param, and some one hidden boot partitions, (and possibly elsewhere). (Dont quote me on those, its been a while since ive looked at all of this so im going by memory and may be slightly off.) But the EFS partition, as best as I can remember, mostly contains data related to DRM, factory mode, carrier info, s/n, and a few other things. I believe there is some important data there related to the modem and network, but not all of it.
The other reason I dont think this would make a difference is I dont see how the system could read and write to other partitions that are vFAT or ext4, but not EFS. It should be able to do so (and is able to do so for the data that is there) regardless of which format it is using. Both formats have been used on this device since day 1.
I am also not certain about the EFS having been re-formatted to a different filesystem at some point. To my knowledge, Odin does not touch that partition, and I've never seen any indication that it has ever formatted anything unexpected in the past. Besides, wouldnt this change its size on disk and thus require the re-formatting of other partitions to compensate? (Im not saying i am right or you are wrong about this, just there are things that aren't making sense to me here.)
I also dont know how comfortable I would be re-formatting ANY partition to a different filesystem. Let alone one that probably cannot be repaired with Odin. For the $5-6 that you might save, it just doesnt seem to be worth the risk to me. (Risk vs reward)
I do apologize if any of this has come off as too argumentative. If your theory does prove to be correct, thats awesome, but I just want to make sure all points are covered before telling anyone something like this is safe to attempt.
Thanks for the post either way though. I do find it interesting!
DocHoliday77 said:
how did you come to the conclusion that older builds format that partition differently, or more specifically, as vFAT? And that older modems can only read this format?
Click to expand...
Click to collapse
I'm trying to retrace my google searches to find the exact reference. It was not a post focused on the SGH-T999, but another similar device. When I find it I'll update to point there.
DocHoliday77 said:
The other reason I dont think this would make a difference is I dont see how the system could read and write to other partitions that are vFAT or ext4, but not EFS. It should be able to do so (and is able to do so for the data that is there) regardless of which format it is using. Both formats have been used on this device since day 1.
Click to expand...
Click to collapse
It is my impression, and please correct me if I am wrong, that the baseband software does not run inside the linux kernel that primarily operates the phone. The low level radio functions have their own system with their own CPU functions and such. There are several reasons this makes sense.
First, interaction with the mobile radio infrastructure is very timing dependent. The software that operates the radios needs to be "real time" - meaning that every task that the system performs must complete in a predictable, determinable amount of time. General purpose, multitasking operating systems like Linux, virtually all Unix systems, and Windows don't do this well. If a general purpose system has specific subsystems that require real time operation, the common solution is put those operations onto a small purpose built hardware with its own processor and software. Even in your standard PC, the ethernet adapters and disk drives have their own processors and firmware.
Second, if the interaction with the radio network was happening in-kernel, then the GPL would require that the software to run this would be open source. The source code for the baseband is not freely available. That suggests that the baseband is separate. It is possible that the code to run the radios could be in a userland process, not in-kernel, and so sidestep the GPL issue. That is unlikely, however, since it would make the timing issues even more difficult.
So if the baseband is software running on a separate CPU, it doesn't matter that the kernel has the modules to read both vfat and ext4. The baseband would need the modules to read that. If certain baseband revisions did not include the modules to read ext4, then the baseband process could not read that data.
DocHoliday77 said:
I am also not certain about the EFS having been re-formatted to a different filesystem at some point. To my knowledge, Odin does not touch that partition, and I've never seen any indication that it has ever formatted anything unexpected in the past. Besides, wouldnt this change its size on disk and thus require the re-formatting of other partitions to compensate? (Im not saying i am right or you are wrong about this, just there are things that aren't making sense to me here.)
Click to expand...
Click to collapse
Other partitions would need to be changed if the size of the EFS partition was increased, but if the size of the EFS partition was not increases, the format could be changed. That process doesn't have to happen in Odin. It could be done at first boot with a particular software revision. The system would need to backup the data on the EFS partition that needs to be saved, reformat the partition using the equivalent of the mkfs command, adjust the partition table and/or the fstab so that the system could mount it properly, remount it, and write back the EFS data - possibly in a new format. All this could be done by any process that had root privs on the system. The baseband could do this itself, even, before the Linux kernel was loaded.
DocHoliday77 said:
I also dont know how comfortable I would be re-formatting ANY partition to a different filesystem. Let alone one that probably cannot be repaired with Odin. For the $5-6 that you might save, it just doesnt seem to be worth the risk to me. (Risk vs reward) ...t I just want to make sure all points are covered before telling anyone something like this is safe to attempt.
Click to expand...
Click to collapse
I definitely don't suggest that anyone tries this unless they are really really really comfortable with this kind of hacking.
BTW - some additional reading in a different T999 thread mentioned that once you go to the NC2 baseband-firmware it is not possible to go back. Makes me think that NC2 is the dividing line if I'm correct about this.
Afaik, you are correct on how the modem operates independently from the rest of the system. That was a good point I didn't take into account, so I will agree that what you stated about the filesystem format being changed is possible. In helping people around here I do periodically run into folks who have never updated beyond 4.1.1 or 4.1.2, so ill try to remember to ask them to check what format the efs partition uses next time. That would probably be the best way to confirm whether or not it was changed somewhere along the way.
As for the sizing of the partition, I do see what you are saying. I was thinking in terms of keeping the usable space the same, which if I am not mistaken would require more space on disk for vFAT.
One other reason I dont think it was changed btw, is I have compared the partition tables of older vs newer builds in the past. It has been a while though, and I wasn't focusing on the efs at the time so I may have overlooked something, but I didnt notice anything different. I was doing this while helping with our debricking process, so it is possible I just didnt see the change, but I kind of feel like I would have had it been there. But, as I just said, it is possible I overlooked it since I wasnt specifically looking for that kind of change.
The inability to downgrade firmware began with our first 4.3 update (MJC). This was done to help prevent tampering and attempts to break into the Knox secure containers.
Something else that just came to mind, is that while you cannot use an older baseband for that reason (Knox), you can use the 4.3 baseband on pre-knox builds (4.1.2 and earlier). So if you were running 4.1.1, for example, you could use the 4.3 baseband. So if your theory is correct wouldnt it mean the 4.3 baseband is capable of reading both formats? And if that is the case, it would mean its something different blocking the SIM unlock in the menu, right?
We do not have 4.4.2 yet, but I have been very active in AT&T's forums lately and can say it is almost the same. You still cannot use older modems as they just wont function, but you can use the 4.4.2 modem on a 4.1.2 or earlier build. The difference, is that while trying the 4.3 baseband on 4.4.2 firmware just doesnt work, if you put a 4.4.2 modem on 4.3 firmware you get an irrecoverable hard brick. Not even jtag will fix it. (right now the only fix is to replace the motherboard). I know that last bit doesn't have much bearing on the topic at hand, but thought I'd throw it in there since on the subject.
So anyway, if the newer basebands will function on older firmware, and the formatting of the efs had been changed, that means the new modems are capable of reading both formats. If all of that is true, the changing from vFAT to ext4 really wouldn't make a difference.
I hope I explained all of that well enough!
I heard talk of the partitions in these pixel phones being different than the Nexus phones were. Like how the Nexus phones had bootloader, radio, system, recovery, boot, userdata, and cache. What do they mean when they speculate "dual partitions"? And for that matter, how are they going to update older Nexus devices if the partitions are different than the Pixel? A lot of questions I know, but hell, figured why not ask away.
I want to know how much space the 32GB variants have left after the dual partitions are accounted for.
LLStarks said:
I want to know how much space the 32GB variants have left after the dual partitions are accounted for.
Click to expand...
Click to collapse
I think I saw a video that showed 29GB
Edit: formatted to 29 but 24.3 available
H4X0R46 said:
I heard talk of the partitions in these pixel phones being different than the Nexus phones were. Like how the Nexus phones had bootloader, radio, system, recovery, boot, userdata, and cache. What do they mean when they speculate "dual partitions"? And for that matter, how are they going to update older Nexus devices if the partitions are different than the Pixel? A lot of questions I know, but hell, figured why not ask away.
Click to expand...
Click to collapse
Current devices have a single "system" partition, containing the OS and included apps, which gets patched when an OTA update is released. You can't use the phone when the OS is being patched and it's a slow process.
With the new feature, the new phones will have two system partitions (let's call them A and B). The phone can run the OS from one of these partitions (A), while the other partition is upgraded by an OTA update in the background (B). When the upgrade has been downloaded and applied to partition B, the phone can quickly reboot into the OS on partition B, making the upgrade much faster from a user point of view.
The next time the phone installs an update, it can apply it to partition A in the background.
All existing devices will simply continue to use the existing partition structure and patching process.
Daveoc64 said:
Current devices have a single "system" partition, containing the OS and included apps, which gets patched when an OTA update is released. You can't use the phone when the OS is being patched and it's a slow process.
With the new feature, the new phones will have two system partitions (let's call them A and B). The phone can run the OS from one of these partitions (A), while the other partition is upgraded by an OTA update in the background (B). When the upgrade has been downloaded and applied to partition B, the phone can quickly reboot into the OS on partition B, making the upgrade much faster from a user point of view.
The next time the phone installs an update, it can apply it to partition A in the background.
All existing devices will simply continue to use the existing partition structure and patching process.
Click to expand...
Click to collapse
So basically, Android OS would be installed on both partitions? That's too weird. That will take some getting used to!
It's more than just 2 system partitions, as those aren't the only potential partitions affected by an update. llabtoofer posted the exact duplicate partitions a while ago on Twitter.
I want to the size of each partitions.
Please show below via adb shell.
cat /proc/partitions
ls -l /dev/block/platform/soc/7824900.sdhci/by-name
*7824900.sdhci is diffrent name folder.
Milly7 said:
It's more than just 2 system partitions, as those aren't the only potential partitions affected by an update. llabtoofer posted the exact duplicate partitions a while ago on Twitter.
Click to expand...
Click to collapse
Hey I know this post is a little old but do you happen to know where I can find that post ?
aholeinthewor1d said:
Hey I know this post is a little old but do you happen to know where I can find that post ?
Click to expand...
Click to collapse
Very old post lol. You should search XDA for a user named llabtoofer. He knows a lot about HTC phones. I'm quite sure he will answer. You can also search for him on Twitter which is where he originally posted it prior to the phones release date.
hi guys, I am having trouble with my MI Max having 32GB internal memory.
From it's behaviour for last few days I have inferred it's system partition is the culprit.
On stock miui rom, it gives msg that encryption unsuccessful and I need to factory reset it. But even after doing factory reset it shows the same msg.
Its with locked boot loader but referring one thread I could install twrp latest version on it by replacing recovery image in stock rom and flashing with mi flash tool in edl mode.
So with two I tried installing few vision rooms like miui eu ROM, RR and crdroid based on Oreo. All the rooms while flashing fine error E1001, saying system image not updated and flashing failed.
I even tried repairing file system, fixing file system, Channing file system to fat, exfat, ext2, ext3, ext4 and f2fs several times (from advanced wipe menu) but things are not improving. Even tried formatting data partition as it's suggested at few places.
I am out of ideas after spending few days trying to fix it by flashing several times.
So please if some one can assist in resolving the issue, I would really appreciate.
Thank you in advance.
You need to format data not wipe . Go to twrp choose wipe , format data and type yes . Note, by doing this you will lose all of your data if you want to keep it make sure to save it to your PC or USB drive.
Zasnizas said:
You need to format data not wipe . Go to twrp choose wipe , format data and type yes . Note, by doing this you will lose all of your data if you want to keep it make sure to save it to your PC or USB drive.
Click to expand...
Click to collapse
Have already done it several times by now. Didn't make any difference.
harpy.eagle said:
Have already done it several times by now. Didn't make any difference.
Click to expand...
Click to collapse
As discussed yesterday on unofficial LineageOS (nijel8) thread the nand is damaged. You need to delate partition, compact unallocated space & then recreate the exactly the same partition. That way it won't be on the same spot & it will work.
Use a PC with an partition manager.
https://gparted.org/
Zola III said:
As discussed yesterday on unofficial LineageOS (nijel8) thread the nand is damaged. You need to delate partition, compact unallocated space & then recreate the exactly the same partition. That way it won't be on the same spot & it will work.
Use a PC with an partition manager.
https://gparted.org/
Click to expand...
Click to collapse
Tks a lot for the reply. It gave a ray of hope to me. Though I am hearing modifying partition on android device for the first time to fix it. That too for bricked device and to do it on PC. Is there any thread guiding about it? Would read a bit about how to do it in order to not mess things up even more.
harpy.eagle said:
Tks a lot for the reply. It gave a ray of hope to me. Though I am hearing modifying partition on android device for the first time to fix it. That too for bricked device and to do it on PC. Is there any thread guiding about it? Would read a bit about how to do it in order to not mess things up even more.
Click to expand...
Click to collapse
It's still ain't bricked so you can do this relatively easy. When it's bricked EDL programmer for used NAND chip used is needed.
So take a deep breath, see the exact size & type of the partition, delate it, create a new one exactly the same (type, size & name).
https://s10629.pcdn.co/wp-content/pictures/2010/01/captured_Image1.png51.png
https://helpdeskgeek.com/wp-content/pictures/2010/01/captured_Image1.png111.png
The tool I gave you URL is very good documented and with plenty examples & user guides available all which can be found on the site, it uses graphics GUI so it's as easy as it can be. So if you are inexperienced read/watch first how it's done. After you are done flash what you want in TWRP.
Best regards.
What I meant to ask is, how to access partitions of mobile on PC? I have used partitioning app on windows but never for android device. Anyway, as u have clued, I shall try accessing partitions with mobile connected in edl mode.
Hi,
after removing all the bloatware and some apps I will never use there is a little over 1G of free space in my system_root partition. Since both system a/b and userdata partitions are on sda I assume it is the same physical device. So in theory it should be possible to shrink the systems partitions and grow the userdata. Has anybody tried to do this? Does anybody know what type of encryption is used on userdata - it doesn't seem to be luks. I have a linux background and am quite surprised how much android differs from what I am used to...
Cheers
Paul
alpinista82 said:
Hi,
after removing all the bloatware and some apps I will never use there is a little over 1G of free space in my system_root partition. Since both system a/b and userdata partitions are on sda I assume it is the same physical device. So in theory it should be possible to shrink the systems partitions and grow the userdata. Has anybody tried to do this? Does anybody know what type of encryption is used on userdata - it doesn't seem to be luks. I have a linux background and am quite surprised how much android differs from what I am used to...
Cheers
Paul
Click to expand...
Click to collapse
In theory it's possible. But in practice it's extremely difficult, especially with all the partitions on todays devices. Changing a partition effects all partitions after it and they all need to be recreated. It's also extremely dangerous if you don't really know what your doing. I successfully did it on an old skyrocket just for fun. But I wouldn't want to try it on the pixel. I'm not even sure what the dual slots would entail.
Sent from my [device_name] using XDA-Developers Legacy app
alpinista82 said:
Hi,
after removing all the bloatware and some apps I will never use there is a little over 1G of free space in my system_root partition. Since both system a/b and userdata partitions are on sda I assume it is the same physical device. So in theory it should be possible to shrink the systems partitions and grow the userdata. Has anybody tried to do this? Does anybody know what type of encryption is used on userdata - it doesn't seem to be luks. I have a linux background and am quite surprised how much android differs from what I am used to...
Cheers
Paul
Click to expand...
Click to collapse
What bloatware did you remove?
airmaxx23 said:
What bloatware did you remove?
Click to expand...
Click to collapse
Everything that is not related to basic phone functionality or camera. Like two dozen apps. arcore, vrcore, all the carrier and e-sim stuff, play music/video, and a lot of other unnecessary stuff.
This is an answer to jd1609, I hit the wrong button:
Yeah, I thought so. Android has evolved quite a bit since cm14 (Android 7.1). I am just starting to understand whats going on with a/b partitions. I still don't quite understand why they had to go with sparse images instead of just raw images. Most probably to confuse me a bit more ....
But thanks a lot for sharing your experiences.
Cheers
Paul