[Q] partitions at the base of the phone - One (M7) Q&A, Help & Troubleshooting
So just out of curiosity and for the sake of information, I need to ask one thing . Are the partitions present at the base of the phone namely /acct, /cache, /config, /d, /data, dev , / devlog, /etc, /firmware, /mnt, /proc, /ramdump, /root, /sbin, /storage, /sys, /system, /tombstone, and /vendor (present along with /sdcard and these partitions can be viewed using ES File Explorer) read or write protected? i know that /data and /firmware partitions are read protected on unrooted phones and /system is write protected. But what about the various other partitions that i mentioned? are they read or write protected as well? Any help to clear up the confusion will be appreciated.
PS: i know that these partitions are important so i'm not gonna mess with them but i asked this question just for information
muhammad.uzi1994 said:
So just out of curiosity and for the sake of information, I need to ask one thing . Are the partitions present at the base of the phone namely /acct, /cache, /config, /d, /data, dev , / devlog, /etc, /firmware, /mnt, /proc, /ramdump, /root, /sbin, /storage, /sys, /system, /tombstone, and /vendor (present along with /sdcard and these partitions can be viewed using ES File Explorer) read or write protected? i know that /data and /firmware partitions are read protected on unrooted phones and /system is write protected. But what about the various other partitions that i mentioned? are they read or write protected as well? Any help to clear up the confusion will be appreciated.
PS: i know that these partitions are important so i'm not gonna mess with them but i asked this question just for information
Click to expand...
Click to collapse
Well as far has I understand it. On a unrooted phone; you can write to the virtual SD card only. On a rooted phone you can still only write to the virtual SD card but you get root privileges to run apps that non rooted phones can't. . With S-Off you can write, delete from the phones system as well has the virtual SD card, hence the increased danger of permanently hard bricking your phone. Personally I think S-Off is worth the risk providing you THINK BEFORE YOU DO.... S-Off can save many a soft brick and a few almost hard bricks too; but more importantly, if you want to return to a factory shipped phone after rooting and installing a custom recovery/rom. You have to be S-Off.
Sent from my GT-I9505 using XDA Premium 4 mobile app
bored_stupid said:
Well as far has I understand it. On a unrooted phone; you can write to the virtual SD card only. On a rooted phone you can still only write to the virtual SD card but you get root privileges to run apps that non rooted phones can't. . With S-Off you can write, delete from the phones system as well has the virtual SD card, hence the increased danger of permanently hard bricking your phone. Personally I think S-Off is worth the risk providing you THINK BEFORE YOU DO.... S-Off can save many a soft brick and a few almost hard bricks too; but more importantly, if you want to return to a factory shipped phone after rooting and installing a custom recovery/rom. You have to be S-Off.
Sent from my GT-I9505 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I have s off but as far as I know, writing to /system requires root privileges AND a custom non protected kernel , I'm sure about the write protection status of /system , /data and /firmware on an unrooted phone but I'm not sure about the rest.
muhammad.uzi1994 said:
I have s off but as far as I know, writing to /system requires root privileges AND a custom non protected kernel , I'm sure about the write protection status of /system , /data and /firmware on an unrooted phone but I'm not sure about the rest.
Click to expand...
Click to collapse
Sorry should have written; " with S-Off and root you can write or delete from phone system ". That includes the entire system as far has I know. To be honest, I've never tried altering any of the phones system apart from deleting some system apps and altering CID to super CID.
Sent from my GT-I9505 using XDA Premium 4 mobile app
bored_stupid said:
Sorry should have written; " with S-Off and root you can write or delete from phone system ". That includes the entire system as far has I know. To be honest, I've never tried altering any of the phones system apart from deleting some system apps and altering CID to super CID.
Sent from my GT-I9505 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I'm s off and unrooted so basically it means I can write to virtual sd card ONLY, I can't modify any of the partitions mentioned in the OP?
If your S-Off and rooted; you can write to all your partitions, So be careful.
Sent from my GT-I9505 using XDA Premium 4 mobile app
Those you have named [/acct /system etc] are Directories/Folders and only a couple of Partitions [SDCard/User Data] which are part of your Android system.
The base as you said is actually /root directory of the system.
Just to make it a little clearer, S-OFF isn't required to be able to write to the /system directories if you are rooted.
S-OFF does however give you the capability to write to ANY and all Partitions on your phone, making it useful but highly dangerous if used incorrectly.
Bashing away at my HTC Desire C
There are a number of factors that control read and write access to the file system.
/data, /system, /cache are mount points, where partitions are attached to the root file system by the OS.
By default, /system is mounted as read only, but can be remounted as read write if you have root access. /data and /cache are mounted as read write.
Then there's the question of user permissions within the operating system. System processes can write to /data, but root access is needed for users to write to it in a file explorer, etc.
That's where su comes in. It's called 'root' because when you su you are switching roles from the restricted Android standard user to the more privileged root user, allowing you to execute commands like remounting file systems, copying partitions with dd, etc.
S-on and s-off have to do with performing block operations on partitions, such as in recovery.
With s-on you can read all partitions (assuming you have root access) and write to system, data, boot, cache, radio, and recovery partitions only.
With s-off you can write to every partition in recovery.
Hope that helps.
cschmitt said:
There are a number of factors that control read and write access to the file system.
/data, /system, /cache are mount points, where partitions are attached to the root file system by the OS.
By default, /system is mounted as read only, but can be remounted as read write if you have root access. /data and /cache are mounted as read write.
Then there's the question of user permissions within the operating system. System processes can write to /data, but root access is needed for users to write to it in a file explorer, etc.
That's where su comes in. It's called 'root' because when you su you are switching roles from the restricted Android standard user to the more privileged root user, allowing you to execute commands like remounting file systems, copying partitions with dd, etc.
S-on and s-off have to do with performing block operations on partitions, such as in recovery.
With s-on you can read all partitions (assuming you have root access) and write to system, data, boot, cache, radio, and recovery partitions only.
With s-off you can write to every partition in recovery.
Hope that helps.
Click to expand...
Click to collapse
Copy and pasting this for future reference. .
Sent from my GT-I9505 using XDA Premium 4 mobile app
cschmitt said:
There are a number of factors that control read and write access to the file system.
/data, /system, /cache are mount points, where partitions are attached to the root file system by the OS.
By default, /system is mounted as read only, but can be remounted as read write if you have root access. /data and /cache are mounted as read write.
Then there's the question of user permissions within the operating system. System processes can write to /data, but root access is needed for users to write to it in a file explorer, etc.
That's where su comes in. It's called 'root' because when you su you are switching roles from the restricted Android standard user to the more privileged root user, allowing you to execute commands like remounting file systems, copying partitions with dd, etc.
S-on and s-off have to do with performing block operations on partitions, such as in recovery.
With s-on you can read all partitions (assuming you have root access) and write to system, data, boot, cache, radio, and recovery partitions only.
With s-off you can write to every partition in recovery.
Hope that helps.
Click to expand...
Click to collapse
thanks a lot, but what about the folders like /d , and /dev , do they have restricted user permissions or read/write protection as well?
muhammad.uzi1994 said:
thanks a lot, but what about the folders like /d , and /dev , do they have restricted user permissions or read/write protection as well?
Click to expand...
Click to collapse
They all have standard unix file system permissions. There are many good tutorials, like this one.
cschmitt said:
They all have standard unix file system permissions. There are many good tutorials, like this one.
Click to expand...
Click to collapse
i read the link you provided twice but couldnt comprehend, i'm gonna leave it at that, i was just asking for information purposes, Since i dont understand it, i'll leave it at that
cschmitt said:
They all have standard unix file system permissions. There are many good tutorials, like this one.
Click to expand...
Click to collapse
i did some digging/googling and found out that /dev contains system devices info and is write protected as well on unrooted phones http://stackoverflow.com/questions/14277639/android-permission-denied-for-dev-directory thanks a lot for helping out @cschmitt
Related
Can't move Dalvik-cache to cache partition
I've search the forum and find different ways to move dalvik-cache from data partition to cache partition, from creating links or mounting, to a2sd command, but none of them worked for me. In all cases after reboot another dalvik-cache with system access will created along the dalvik-cache the method created in data partition. so I have two dalvik-cache folders (that one of them is link) and system will use the real one that will waste my data partition size. this is how it look like: Code: drwxrwx--x system system 2010-10-23 12:30 dalvik-cache drwxrwxrwx root shell 2010-10-23 11:41 dalvik-cache I am struggling to find a way to free some memory on /data partition, as I rooted without unlocking the boot loader, I couldn't be able to resize the data system and cache partitions, (booted into fastboot mode, used fastboot command to erase system but it couldn't be erased with a access denied error). Anybody can you please help? I am on stock Froyo 2.2.1 and rooted without unlocking bootloader.
bohlool said: I've search the forum and find different ways to move dalvik-cache from data partition to cache partition, from creating links or mounting, to a2sd command, but none of them worked for me. In all cases after reboot another dalvik-cache with system access will created along the dalvik-cache the method created in data partition. so I have two dalvik-cache folders (that one of them is link) and system will use the real one that will waste my data partition size. this is how it look like: Code: drwxrwx--x system system 2010-10-23 12:30 dalvik-cache drwxrwxrwx root shell 2010-10-23 11:41 dalvik-cache I am struggling to find a way to free some memory on /data partition, as I rooted without unlocking the boot loader, I couldn't be able to resize the data system and cache partitions, (booted into fastboot mode, used fastboot command to erase system but it couldn't be erased with a access denied error). Anybody can you please help? I am on stock Froyo 2.2.1 and rooted without unlocking bootloader. Click to expand... Click to collapse I think the stock kernel re-establishes the file system on boot and does not support moving anything. I think you'll need a custom rom and kernel with apps2ext support to do what you're wanting. Try the latest test release of my rom (in my sig), has everything you need.
djmcnz said: I think the stock kernel re-establishes the file system on boot and does not support moving anything. I think you'll need a custom rom and kernel with apps2ext support to do what you're wanting. Try the latest test release of my rom (in my sig), has everything you need. Click to expand... Click to collapse Is there any other way? e.g. Changing something, or Install something to make it no re-establishment? Or any way to change the partition sizes on Stock ROM (rooted but without unlocking boot loader)
bohlool said: Is there any other way? e.g. Changing something, or Install something to make it no re-establishment? Or any way to change the partition sizes on Stock ROM (rooted but without unlocking boot loader) Click to expand... Click to collapse Nope. Root and be done with it, that's why people get the Nexus... Edit: Hang on... I didn't read properly... But the answer's still no... Just load a custom rom/kernel, you're already rooted. Edit 2: Even with a custom rom you can not change partition sizes.
storage problem
Hay. how i can format my nexus one or clear its all earlier data . I also have 8gb sd card waiting for reply. Thanks
Uh... do you mean a factory reset cause that is pretty easy just go to settings -> privacy -> factory reset this will wipe everything from your internal storage except the ROM and updates so you will stay on the same version that you are running now. This will not delete anything on the SD card so if you want to do that just put it in your computer and format it from there.
storage Hay can u more define. is factory rest bracke my root
If by that you mean will it unroot you, then no you will stay rooted even if you factory reset.
There are two different main partitions in the phone (for partitions, think different drives under windows). The first being the /system partition. Everything in the /system partition is readable only. You are not able to modify anything in there (with a standard setup... we will delve a bit into this later). The other partition is the /data partition, which is read/write. This is where every app that you install is located (with a few exceptions which I will note below). When you do a factory reset/data wipe, it will just wipe out that /data partition so all your apps and data are gone (including any system settings. The exception to the rules are for rooting, and certain flashable zips that put apps in the /system partition (like the google apps zip if you are running a custom ROM). So when you rooted, it put everything required for root into the /system partition (by changing it to read/write using root permissions). So if you do the factory reset, it will wipe the /data directory along with the .android_secure folder on the root of the sdcard (which is where all your apps are stored when you store apps on the sdcard). Since the factory reset doesn't include the /system partition (otherwise you would be left without an OS to boot into), your root will remain, and otherwise, it will be just like it was when you first started up the phone. If you want to remove root, you will have to flash a ROM (most likely a stock Android version) that doesn't include root/superuser permissions.
[Q] Fix missing space (23.03GB vs. 64GB), but keep data
I've run in to the problem some other people were having too. A problem, where after fastboot flashing userdata.img (from stock factory image), I'm left with 23.03GB of storage on my device, even though it's a 64GB model. I've Googled the problem, and people suggest running "fastboot format data" to fix it. But of course that will wipe all my settings and so forth. My question is if I can back up the data partition using TWRP onto an OTG device. Then run "fastboot format data" and finally restore data again using TWRP. Would that work? And would it even fix the problem of the missing space. For reference, the issue has previously been discussed here: http://forum.xda-developers.com/nexus-6/help/nexus-6-64gb-23gb-free-space-t2953636
stokholm said: I've run in to the problem some other people were having too. A problem, where after fastboot flashing userdata.img (from stock factory image), I'm left with 23.03GB of storage on my device, even though it's a 64GB model. I've Googled the problem, and people suggest running "fastboot format data" to fix it. But of course that will wipe all my settings and so forth. My question is if I can back up the data partition using TWRP onto an OTG device. Then run "fastboot format data" and finally restore data again using TWRP. Would that work? And would it even fix the problem of the missing space. For reference, the issue has previously been discussed here: http://forum.xda-developers.com/nexus-6/help/nexus-6-64gb-23gb-free-space-t2953636 Click to expand... Click to collapse Just so its clear the fastboot format does the trick. (I also did fastboot and vol scrolled to recovery and did a full wipe before the format)(that was prob overkill) fastboot format userdata fastboot format cache fastboot reboot I've never done that with twrp. I usually just dump my whole SD card to a hard drive then start fresh. Its a reasonable pain to ensure there are no problems. Also wouldn't you have been totally wiped anyway if you were going back to stock? Have you been using it with 23gb for a while?
No, haven't been using it for long like that. Only a few days actually. It's not that I have a lot of files, but I do have a lot of settings and app settings. I know I could probably use Titanium Backup to back that stuff up, but I don't trust that method do get everything and not mess something up. One more question though. Why format cache too? I saw that suggested in the thread I referenced. But isn't it enough to format data? I guess it makes no difference really, but I'm trying to learn in the process too.
stokholm said: I've run in to the problem some other people were having too. A problem, where after fastboot flashing userdata.img (from stock factory image), I'm left with 23.03GB of storage on my device, even though it's a 64GB model. I've Googled the problem, and people suggest running "fastboot format data" to fix it. But of course that will wipe all my settings and so forth. My question is if I can back up the data partition using TWRP onto an OTG device. Then run "fastboot format data" and finally restore data again using TWRP. Would that work? And would it even fix the problem of the missing space. Click to expand... Click to collapse Yes and no. Let me explain; The first problem, which may or may not actually *be* a problem, is whether or not recovery will PERMIT a backup to an OTG. Assuming that it does, it unfortunately will only backup everything on the data partition BESIDES the "media" directory (where the "internal SD card" can be found). To work around this, perform your backup TO the internal storage, then reboot back to Android, copy *everything" from the "internal storage" path to your computer (which will include the "backup" directory, whatever it happens to be called with the recovery you prefer). Then perform the fastboot format on the data partition, boot into Android skipping all the signin junk, copy everything BACK to the internal storage, reboot into recovery again, and restore it. ALTERNATIVELY, and probably much easier (definitely much faster, since it should complete within a few seconds)... I *believe* that most recoveries should include the resize2fs command (though I've never had an actual need for this, so haven't actually tested it), so via ADB into your recovery..... Code: umount /data resize2fs /dev/block/platform/msm_sdcc.1/by-name/userdata should do the trick. NOTE HOWEVER, it is generally recommended to backup any partition where you are resizing a filesystem PRIOR to resizing it. HAVING SAID THAT, I've run resize2fs hundreds of times on hundreds of systems, and never had an issue with a grow operation. Running resize2fs without a "size" parameter will grow the filesystem to the size of the partition. The partition table still holds the correct size, which is why "fastboot format" fixes the issue.
That was a great explanation, @doitright. Thank you for that. I will try resize2fs at some point.
stokholm said: No, haven't been using it for long like that. Only a few days actually. It's not that I have a lot of files, but I do have a lot of settings and app settings. I know I could probably use Titanium Backup to back that stuff up, but I don't trust that method do get everything and not mess something up. One more question though. Why format cache too? I saw that suggested in the thread I referenced. But isn't it enough to format data? I guess it makes no difference really, but I'm trying to learn in the process too. Click to expand... Click to collapse Resizef2s sounds relatively painless, but does again, as doitright says, require caution by backing up before. About the cache thing. I think to do a full format, data and cache are on different blocks, so that might be why. But then again the SD card is mounted in /data/media so maybe only format data is needed and the cache is to help with something else or just to be cautious, I don't know. Now I wonder (and this can be searched here in xda) if TWRP back up data is /data/data or /data minus /data/media? Because fastboot format data I think is all of data i.e. /data. This is worth knowing for the future. Especially since we are flashinging things to our phones and whatever else.
MunkinDrunky said: Now I wonder (and this can be searched here in xda) if TWRP back up data is /data/data or /data minus /data/media? Because fastboot format data I think is all of data i.e. /data. This is worth knowing for the future. Especially since we are flashinging things to our phones and whatever else. Click to expand... Click to collapse ALL recovery backups are /data/* EXCEPT /data/media, being "backed up" to /data/media/something. It simply cannot be implemented any other way for devices without separate storage devices, otherwise the backup would back up previous backups, which would be just plain wasteful. The /cache partition is practically irrelevant. There is quite literally NO REASON to ever worry about it. No reason to wipe it, no reason for format it unless it somehow becomes corrupt.
It doesn't seem like resize2fs is included in TWRP.
stokholm said: It doesn't seem like resize2fs is included in TWRP. Click to expand... Click to collapse The resolution really is as simple as you originally thought. Its a common issue I've seen a hundred times on the nexus 5. Take a full TWRP backup and then copy your entire sdcard to PC. Format data Boot into android and do initial set up. Copy sdcard backup back to device whilst booted into android Restore TWRP backup
You can use the file manager in TWRP to copy your entire sdcard to USB-OTG and copy it back. Personally, I find this easier than copying to PC.
adrman said: You can use the file manager in TWRP to copy your entire sdcard to USB-OTG and copy it back. Personally, I find this easier than copying to PC. Click to expand... Click to collapse The reason I said to copy it to PC via android was that using MTP or adb in recovery will break the sdcard permissions, when it is copied back. If you're confident OTG in TWRP works differently to adb and MTP in TWRP, cool. I just haven't tested it myself so won't suggest it.
rootSU said: The reason I said to copy it to PC via android was that using MTP or adb in recovery will break the sdcard permissions, when it is copied back. If you're confident OTG in TWRP works differently to adb and MTP in TWRP, cool. I just haven't tested it myself so won't suggest it. Click to expand... Click to collapse I used OTG via TWRP's file manager, when I wiped to decrypt and everything came back properly. I would assume that would be the case here as well.
adrman said: I used OTG via TWRP's file manager, when I wiped to decrypt and everything came back properly. I would assume that would be the case here as well. Click to expand... Click to collapse Excellent
rootSU said: Excellent Click to expand... Click to collapse Channeling Mr. Burns? [emoji1]
adrman said: Channeling Mr. Burns? [emoji1] Click to expand... Click to collapse Always, aren't you?
From within TWRP there is an easy way to do this even after you have your phone all setup. This issue always happens on my Nexus 5 and Nexus 6. I did this without doing a backup and after my phone has been used on marshmallow for a week or so. Steps from within TWRP: 1. Wipe > Advanced Wipe 2. Select the Data partition. 3. Select Repair or Change File System (Notice the Partition Size) 4. Select Resize (Wait and shortly after see the partition size be up to full size.)
This doesn't appear to work on 6.0.1 custom Rom with systemless SU 2.61... gave me a bad partition error. Guess I will have to wipe. maamdroid said: From within TWRP there is an easy way to do this even after you have your phone all setup. This issue always happens on my Nexus 5 and Nexus 6. I did this without doing a backup and after my phone has been used on marshmallow for a week or so. Steps from within TWRP: 1. Wipe > Advanced Wipe 2. Select the Data partition. 3. Select Repair or Change File System (Notice the Partition Size) 4. Select Resize (Wait and shortly after see the partition size be up to full size.) Click to expand... Click to collapse
I have come across this thread. Here is what worked for me. (in case somebody needs it in the future) 1. Boot into twrp, type Code: adb shell 2. list the mounted partitions Code: df You should see Code: df Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 1507020 24 1506996 0% /dev tmpfs 1507020 24 1506996 0% /tmp /dev/block/mmcblk0p38 253920 264 248416 0% /cache /dev/block/mmcblk0p42 24143612 23590364 536864 98% /sdcard /dev/block/mmcblk0p42 24143612 23590364 536864 98% /data /dev/block/mmcblk0p41 2015408 1965276 33748 98% /system 3. unmount /data and /sdcard Code: umount /dev/block/mmcblk0p42 umount /dev/block/mmcblk0p41 4. run Code: e2fsck -f /dev/block/platform/msm_sdcc.1/by-name/userdata resize2fs /dev/block/platform/msm_sdcc.1/by-name/userdata now you should see: Code: df Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 1507020 24 1506996 0% /dev tmpfs 1507020 24 1506996 0% /tmp /dev/block/mmcblk0p38 253920 264 248416 0% /cache /dev/block/mmcblk0p42 57306748 23598452 33691912 41% /data /dev/block/mmcblk0p42 57306748 23598452 33691912 41% /sdcard 5. reboot, you are done
/system file system question
Hey there. In twrp I can't change my system partition file system to F2FS. To do it, I enter twrp and do the "normal" steps (wipe, advanced, change to f2fs). TWRP says it changed but if I perform the same steps the file system type remains ext4. Is this supposed to be like this?
You cannot format the system
It's really not practical to change the filesystem of /system since it's distributed as an image and not as files. You theoretically could do it, but it would be a lot of work and you'd have to redo it from scratch every time you updated your ROM. Also, you wouldn't get most of the benefits of f2fs since you'd almost never be writing to it.
Please help me. Tried to change /data file system and wiped all my files...
I'm panicking very much right now. I did a big, big stupid and accidentally wiped my entire /data partition, including /sdcard (!!) in TWRP 3.0.4.1 while attempting to change the filesystem of my /data partition from F2FS to EXT4. I did a full backup of my phone, including /data partition (but excluding /data/media/0/ which is the location for /sdcard of course) on my phone prior to attempting to change the filesystem. I didn't think that this would also wipe /sdcard, and ALL MY FILES INCLUDING MY BACKUP... I'm frantically searching through Google as we speak for guides to clone these formatted sectors over USB (I'd imagine using ADB shell) to a PC and use Windows file or partition recovery tools to try and save every, if not most files. Please lend me your knowledge and links to fixing this issue, Android community. <3 In older Android versions the /sdcard partition was it's own partition, which is why I didn't think of copying all my files over to a PC before making changes to /data.
well, when you wipe data from any partition in twrp it sort of resets all space to be overwritten. The data that is marked for overwrite doesn't remain when you full wipe. Since you changed the file system, the data was removed and overwritten by the wipe with blank space.... i hope you had at least some of it backed up on your pc. I never use those apps personally, i always hard backup all my things with a drag and drop onto my pc. I highly recommend it, saves you a disaster. Im very sorry.... i hope you didnt lose anything really important.
OcazPrime said: well, when you wipe data from any partition in twrp it sort of resets all space to be overwritten. The data that is marked for overwrite doesn't remain when you full wipe. Since you changed the file system, the data was removed and overwritten by the wipe with blank space.... i hope you had at least some of it backed up on your pc. I never use those apps personally, i always hard backup all my things with a drag and drop onto my pc. I highly recommend it, saves you a disaster. Im very sorry.... i hope you didnt lose anything really important. Click to expand... Click to collapse Heh, that's exactly what happened. I'm gonna attempt this guide: https://forum.xda-developers.com/ga...de-internal-memory-data-recovery-yes-t1994705 Basically try to use "dd" to make a RAW copy of "dev/block/dm-0" which according to the mount command I ran in TWRP's terminal shell, is what block /data is used on OnePlus 3T (OOS 4.1.3). Wish me luck.