Related
Let me start with: I know that there have been many posts on this, but before you get mad, I was unable to find an answer to what I specifically want to do.
For reference: I am a software developer and sysadmin with a decent amount of Linux experience, but not a lot of android specific experience.
Now that the introduction is out of the way:
What I would like to do is completely remove the "USERDATA" partition (the "Internal SD card"), grow the "SYSTEM" partition to fill that space, and then mount my SD Card (external) as the SD Card that the system sees.
I'm currently on Cyanogenmod 10.1 but want to upgrade to 11 soon.
The reason I want to do this is because:
I have all if my apps that I can set to install to SD Card
Both "internal" partitions are full (only about 200MB is available for pictures/etc. and I can no longer update apps)
Camera (and pretty much everything else as well) stores to the Internal SD card by default
If the system partition was 1.1+1.4=2.5GB and all of my apps were "installed" to a real SD card, it would be a lot more comfortable.
So, here's what I am thinking *might* work (maybe not in the right order, though?):
Point the fstab entry for the internal SD card to the external SD card
I have the PIT file. I will delete the "USERDATA " and grow "SYSTEM" to fill the space
When I write it out in steps, it seems pretty simple...
My concerns:
Will a ROM update (to CM11) re-partition back to the old way (and, in the process, break a bunch of stuff)?
I don't ever plan to go back to stock android or change to another ROM (other than upgrades).
Thanks for reading this long post and for any insight you may be able to provide.
--mobrien118
It's a wonderful idea if it works.
Sent from my SAMSUNG-SGH-T769 using xda app-developers app
Modifying partitions is a bit dangerous.
But I have to ask you why do you need another GB of /system storage?
There was a line you can put in the build.prop that flips your ext. SD with the internal one on cm10 I believe.
This'd interest me if I could get rid of usbdisk and sdcard0 merged.
It would need the phone to be repartitioned though, causing issues with the backups and ROMs.
You may even have to compile cm from source.
Its a lot of trouble
Sent from my SAMSUNG-SGH-T769 using Tapatalk
I just did so on S4 Mini with cm-11 Android 4.4.
First I was thinking of using symlinks and/or bind mounts to redirect to the the external sdcard, but that's a bit of a hassle because
1) Since 4.2: both emulated and external storage is mounted with a fuse layer on top not supporting symlinks
2) Since 4.4: no more global write access on external storage
So moving data was the simplest solution. Besides providing (much) more space my sdcard is also around 20% faster in sequential writes: 8.5 MB/s internal vs 10.5 MB/s external. Is it really 2014?
I haven't yet decided what to do with the original data partition, so for the moment I left it unused. Hence I haven't touched the internal partition table.
Quick summary
partition sdcard (gdisk)
I recommend using GPT, this lets you work with partition names rather than numbers. For the sake of still having an "official" external sdcard I made two partitions. Keep in mind that it's usually the first partition which gets automatically mounted as external sdcard. So I made the 2nd partition the new home for data. This partition however has to be manually specified in the ramdisks fstab which involves flashing the boot partition.
format the new partitions (mkfs.ext4)
copy the original /data directory tree to the new data partition
extract initrd from boot.img (abootimg)
extract files from initrd (gunzip & cpio)
replace the /data entry in fstab pointing at your new data partition
re-pack initrd and boot.img (gzip, cpio & abootimg)
flash boot.img onto the boot partition (dd)
If you use recovery, you also have to edit it's fstab (analog to boot.img mentioned above)
done
Alternatively has anyone tried an init.d script? I see those scripts get executed before the mounting of data & sdcard
Meanwhile the original userdata partition got replaced by 3 new partitions: system2, cache2 & userdata2 which are now used for a dual boot ROM.
I've only changed GPT, not PIT. ROMs and Recovery don't use PIT, so as long as Heimdall/Odin isn't involved it should not cause any issues.
Hey guys,
So after read all that, I am also vry interested in what the OP has suggested. I get that the pit doesn't need to be affected, but as the OP asked, when flashing a new rom or updating an existing, would the partition be reformatted back to the way android handles it, ie; back to the system and data seperate and the sdcard not being used as the internal partition?
I am no developer and only have minimal knowledge in linux and android programing, but I am a quick study and any guide to help me sort this would be greatly appreciated.
Also I am about to get a second S4 mini specifcally for doing things like this so if I brick I don't care?
My next question is could it be possible to code the PIT file to do this for you so that you can just flash that through odin, but again would flashing roms affect this.
Cheers,
Sora.
aguaz said:
I just did so on S4 Mini with cm-11 Android 4.4.
First I was thinking of using symlinks and/or bind mounts to redirect to the the external sdcard, but that's a bit of a hassle because
1) Since 4.2: both emulated and external storage is mounted with a fuse layer on top not supporting symlinks
2) Since 4.4: no more global write access on external storage
So moving data was the simplest solution. Besides providing (much) more space my sdcard is also around 20% faster in sequential writes: 8.5 MB/s internal vs 10.5 MB/s external. Is it really 2014?
I haven't yet decided what to do with the original data partition, so for the moment I left it unused. Hence I haven't touched the internal partition table.
Quick summary
partition sdcard (gdisk)
I recommend using GPT, this lets you work with partition names rather than numbers. For the sake of still having an "official" external sdcard I made two partitions. Keep in mind that it's usually the first partition which gets automatically mounted as external sdcard. So I made the 2nd partition the new home for data. This partition however has to be manually specified in the ramdisks fstab which involves flashing the boot partition.
format the new partitions (mkfs.ext4)
copy the original /data directory tree to the new data partition
extract initrd from boot.img (abootimg)
extract files from initrd (gunzip & cpio)
replace the /data entry in fstab pointing at your new data partition
re-pack initrd and boot.img (gzip, cpio & abootimg)
flash boot.img onto the boot partition (dd)
If you use recovery, you also have to edit it's fstab (analog to boot.img mentioned above)
done
Alternatively has anyone tried an init.d script? I see those scripts get executed before the mounting of data & sdcard
Click to expand...
Click to collapse
I just managed to replace my internal sd with the external sd following your ruff guide. thank you very much! At first I struggled a bit getting it to work, because I had encrypted my data partition before -.- this seems to change something in the fstab / mounting / boot-up process, I couldn't get my S4 mini to boot with just changing the fstab.qcom in boot.img. With my recovery (TWRP) it worked from the start editing recovery.img's fstab.twrp /data mount point.
After decrypting(formatting) /data and re-editing fstab.qcom in boot.img it finally works I'm so happy! Enjoying a lot of space on my sdcard now!
usefull threads / information I learnt from:
Partition structure of S4 Mini
Encryption of ExtSD & some fstab information
Editing initrd
abootimg ReadMe
(Links last tried 28.05.2015)
Hello,
I'm having some issues with partitions and recovery image creation after Windows 8.1 clean installation ( from USB pen drive). Disk situation is in the attachments. First thing I noticed is that there is a new partition between C: and Recovery Partition. The problem is that windows doesn't recognize recovery partition and when I try to
backup it on usb drive the option "Copy the recovery pertition from PC to recovey unit" is gray (unclickable). I tried to copy it with EaseUs Partition Manager but the unit doesn't boot. What can I do in order to rescue Recovery Image?
Tnx a lot
>What can I do in order to rescue Recovery Image?
The rec partition is non-functional once you did the clean install. You can delete all partitions and reclaim the space, and have the partition tool recreate the ESP (EFI Service Partition, required for EFI toys). If using GPT format, also recreate the MSR (Microsoft Reserved Partition, required for GPT disks). Alternatively, you can switch to MBR and skip the MSR.
Then, ESP (100MB space) is the first partition, MSR (128MB) is second, and the rest can be allotted to the main partition. Make sure partition tool is current, else it may not handle EFI stuff. I use freebie Partition Wizard.
More info here http://msdn.microsoft.com/en-us/library/windows/hardware/dn640535(v=vs.85).aspx
For recovery, simply use an image backup tool to back up the main partition once you're done installing and setting up 8.1. There are lots of tools to do this, and you can save the image into a dedicated partition like the MS rec partition, or offline it to USB and save the space for regular use. There is no need to stick with the convoluted MS method.
Abstracts foreyro
e.mote said:
>What can I do in order to rescue Recovery Image?
The rec partition is non-functional once you did the clean install. You can delete all partitions and reclaim the space, and have the partition tool recreate the ESP (EFI Service Partition, required for EFI toys). If using GPT format, also recreate the MSR (Microsoft Reserved Partition, required for GPT disks). Alternatively, you can switch to MBR and skip the MSR.
Then, ESP (100MB space) is the first partition, MSR (128MB) is second, and the rest can be allotted to the main partition. Make sure partition tool is current, else it may not handle EFI stuff. I use freebie Partition Wizard.
Click to expand...
Click to collapse
Thank you for reply,
I suspected there were no chance. I virtually undestand what you suggest but I'm not sure how to do exactly. Should I create a bootable partition
tool? Isn't possible to delete and join partitions during win8.1 installation( when it ask to select the partition for installation)?
>Should I create a bootable partition tool?
Yes. Many partitioning tools come in ISO form. To image the ISO onto a bootable USB stick, the simplest tool to use is Rufus http://rufus.akeo.ie . Rufus can also image the Windows ISO to boot USB, so no need for the dedicated MS tool. More complicated, but also more capable, are multiboot tools that allow booting from multiple ISOs, eg Easy2Boot http://easy2boot.com .
>Isn't possible to delete and join partitions during win8.1 installation
I doubt it is capable as a regular partitioning tool, eg create specific partitions like ESP/MSR, or move them. You do want to delete everything, then recreate the ones you need, to avoid non-contiguous space. If you want to stick with MS stuff, the tool to use is fdisk, but that harks back to the stone age in terms of user-friendliness.
thank you again. I tried first the easier way and deleted partitions during Win installation. The result is in the attachment. Please, tell me your opinion.
Attachments:
Looks like Win install is self-sufficient and can create the needed partitions. As a rule, I do my own partitioning, since Win install will create the Win RE (Recovery Environment) partition, which is useless when I'm handling my own backup/recovery. I also disable UEFI on my boxes and use MBR, which then obviates the need for ESP & MSR, so everything can be allocated to data. GPT is irrelevant for small drives, and EFI is basically a headache. But if you're happy, then it's all good.
Edit for my above post: I meant diskpart, not fdisk.
The other day, I attempted to make a Windows 8 Recovery USB using my external hard drive and the Media Creation tool. I specifically made a new partition for this process, as I had two other partitions on it with data. Making sure that the partition that was empty was selected, I successfully created the media. I couldn't get it to boot, however, and when I looked on the hard drive, its erased and merged my other two partitions, turning them into unallocated space, and the G: partition was the recovery drive.
I don't want to touch the recovery partition, because I don't want to screw anything else up.
Please help, I had a lot of important files on there and I'm not sure what to do.
Hiya! I don't believe my problem is device specific. The background of how I ended up in this crappy situation is, but I believe the resulting issue is general. Should I be wrong, tell me and I'll move this to my device's section.
Short question: how can I (and can I?) restore data in a partition that got deleted, if no new filesystem has been created over it?
Long background: I have a Xiaomi Mi2-S 32GB. It used to have a peculiar layout: a double system partition (/system1 and /system2)¹, a small internal storage (/userdata)², and a big emulated SD card (/storage)³.
Let's explain why:
¹ False dual boot: the active system is installed in the first partition. When installing an update with the official app, the newer system gets installed in the second and that one gets booted. So, should this newer system fail to boot, you have an older one correctly working and ready to boot.
² and ³: so that the whole storage partition containing photos, music, videos, downloads, backups, saved games and such can be accessed with MTP, while the userdata containing apps and complementary system things is kept safe. This last decision, however, brings up a new problem: userdata can't be accessed by user to put his files or by apps without root permissions to store data (like photos), while storage can't be used to install apps, or even to move them using Link2SD or such. Some users might find storage is insufficient for their videos and music, while others might find userdata is too little for their games, and they are both stuck in this situation.
I was in the second group, so I altered my layout using stillka's guide on xiaomi.eu (Sorry, I can't post links). I extended my userdata, so that my storage resulted smaller. Plus, I understood altering a partition would mean deleting all the partitions before that one, and recreating them thereafter.
Until this point, all was OK. I installed Ivan's AOSP Lollipop for unmerged partitions, and found out it would experience random reboots with True Dual Boot. So I stuck with False one and forgot about everything. I kept that version without updating for a long time.
Then, several months later, my phone started rebooting randomly anyway. I figured I would come back to MIUI to get Xiaomi's support for an official ROM.
Little did I know they decided to change layout in the meantime. MIUI got so big the size of the two systems was insufficient. So they decided to merge them into an unique partition big enough. So, while flashing with the official tool MiFlash, it practically altered my system layout, having to delete all that was placed before them (cache, userdata and storage), never telling me what it was going to do, advising me to back my storage up somewhere. All I did was back up my userdata into storage, confident flashing their official ROM with their official tool would just write into system, since nobody told me otherwise.
So this is the result: the old, small size of userdata is back, and everything that comes after is left without any filesystem: these are the last line in parted's print output
20 327MB 336MB 8389kB ext4 persist
21 336MB 1409MB 1074MB ext4 system
22 1409MB 1812MB 403MB ext4 cache
23 1812MB 5570MB 3758MB ext4 userdata
24 5570MB 31.3GB 25.7GB storage
Click to expand...
Click to collapse
I've tried parted's rescue command, but it is unable to find a partition lying there. I don't have my old layout, so I'm not able to precisely know where my old storage began, but I remember it to be around 18 GiB in size. I've tried all ranges possible (from the current end of userdata, 18 G from the end and so on) but no dice.
Can someone tell me if there is any hope, and what can I try?
Now I'm trying to dd the whole eMMC, or even just the last partition, to my computer to work on it using, say, testdisk. There is just one problem.
Obviously, I must issue the commands in my PC's environment, as I've nowhere to dump the biggest partition in my phone to, on it. So it goes something like
Code:
adb shell su -c "cat /dev/block/mmcblk0" | pv > mmcblk0.raw
The problem is, even if my phone was rooted by TWRP and in my options menu, the su binary is not found
/sbin/sh: su: not found
Click to expand...
Click to collapse
What should I do? Should I manually push the su binary in /system/bin? Where should I take su? From my PC?
This link should be helpful to you. Though its for MI3, the guy explains exactly how he recreates all the stock partitions one by one using the parted utility.
However, I think even before you try that, I think you should consider using the shortcut suggested in this link. If you can alter the flash_all.bat slightly and add the gpt_both0.bin, it can re-create the stock partitions (at least this is what the poster has done for Mi3/Mi4, since yours is Mi2, I'm not so sure, you may have to find out).
Finally, here is one more link that you may want to read up.
---------- Post added at 06:34 AM ---------- Previous post was at 06:34 AM ----------
This link should be helpful to you. Though its for MI3, the guy explains exactly how he recreates all the stock partitions one by one using the parted utility.
However, I think even before you try that, I think you should consider using the shortcut suggested in this link. If you can alter the flash_all.bat slightly and add the gpt_both0.bin, it can re-create the stock partitions (at least this is what the poster has done for Mi3/Mi4, since yours is Mi2, I'm not so sure, you may have to find out).
Finally, here is one more link that you may want to read up.
The problem is I don't have to restore stock partitions. That was already done against my knowledge, only that the last partition was left without a filesystem. If anything, I should restore my previous, custom layout, I have no trace left about.
I've managed to use testdisk. It is not able to find any partition in my phone eMMC though...
Testdisk's failure might be because of a wrong geometry setting, even if it sounds strange to me.
This is the ouput of parted's print
parted print said:
Error: Both the primary and backup GPT tables are corrupt. Try making a fresh
table, and using Parted's rescue feature to recover partitions.
Model: (file)
Disk /media/Storage/mmcblk0.raw: 31.4GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
Click to expand...
Click to collapse
This is fdisk's p
fdisk p said:
Disk mmcblk0.raw: 29.2 GiB, 31354139648 bytes, 61238554 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
mmcblk0.raw1 1 4294967295 4294967295 2T ee GPT
Click to expand...
Click to collapse
2T? Seriously?
Given that parted doesn't give those errors when run directly in adb, maybe something has gone wrong in the process of dumping my memory. I've issued this command:
Code:
adb shell dd if=/dev/block/mmcblk0 | pv | dd of=/media/Storage/mmcblk0.raw
Did I do something wrong?
This is what testdisk tells me in the analyse menu:
testdisk analyse said:
Disk mmcblk0.raw - 31 GB / 29 GiB - CHS 3812 255 63
Current partition structure:
Partition Start End Size in sectors
1 P EFI GPT 0 0 2 267349 89 4 4294967295
Warning: Bad ending head (CHS and LBA don't match)
No partition is bootable
Click to expand...
Click to collapse
It also detects an Intel table, which is rather odd. Selecting Intel or GPT gives the same result anyway, a big, round zero.
Rather than messing with partition tables using parted, I think there is a simple thing you can try:
1. Restore stock partition tables as it is (using the linked guide or some other means).
2. Restore the stock partitions themselves, something like this:
dd if=/sdcard/system.img of=/dev/block/mmcblk0
dd if=/sdcard/boot.img of=/dev/block/mmcblk1
These are just examples, you know which partition number corresponds to system.img, boot.img, etc. If you can do the above successfully, you will have restored the handset back to stock settings (both partitions and data) and it should start working in theory.
I'm not sure whether I'm not describing my problem clearly or I'm not understanding your suggestion.
The fact is my phone works correctly, it is not bricked. Right now I'm booting MIUI 8. My system partition is alright. My problem is my storage partition (the emulated SD card with all my personal data in it) got deleted, and I'm trying to get it back.
And the layout I had when my storage partition was available was not the stock one, but was already altered by me, as in storage was smaller in order to make more room for userdata (more apps). So, restoring stock layout would not give me my storage's previous start and end points.
k, now I understand your issue! If you want to recover data from a damaged (in this case non-existent) storage partition, have you tried any linux recovery programs (those may be your only option) though I'm not sure how many of them are designed to work with an eMMC.
Or is it the case that you don't care anything about recovering your personal data and just want to fix the storage partition, so the Mi2 file-manager recognizes it?
>> 2T? Seriously?
Yes, that's normal. I've observed even on MediaTek based devices that the partition tables leave that much extra space on the /storage partition (which is typically the last) though its actual physical size is just 2-3GB. You either got the starting/ending points of /storage partition in your MBR/GPT tables wrong (CHS/LBA numbers) or it is just a case of formatting this partition so that the Mi2 recognizes it. In that case, you can just try formatting it to FAT32 or something (but remember that you will loose all your personal data in that case).
Indeed my whole concern is trying to recover what was on it. For all I know, there's the possibility everything was wiped the instant MiFlash destroyed my storage partition, but since no new filesystem was written on it I'm not abandoning hope.
What I did was dump my eMMC to work on it using Linux restore programs (testdisk, mainly), but something must have gone wrong when dumping it. I will try to save the correct partition table and feeding it to TestDisk, but somehow I get the idea this won't solve my problem.
Is there anyway to get the eMMC's geometry parameters to input them manually in TestDisk?
The card is described by parted as "MMC SEM32G", and the parameters I can change are cylinder geometry (number of cylinders, default 3812), head geometry (number of heads: 1-255, default 255), sector geometry (numbers of sectors per track: 1-63, default 63) and sector size.
> What should I do? Should I manually push the su binary in /system/bin? Where should I take su? From my PC?
If you were still unable to take the dump for want of the su binary, then here is an easier way to disk dump the partitions without requiring the su binary at all, but you'll need the CWM image of your Mi2 device:
1. Start phone in Fastboot mode by long-pressing DnVolume+Start buttons.
2. Connect to USB Cable (ensure adb drivers and fastboot are installed).
3. Run this command: fastboot boot /path/to/CWM.img
4. Once phone boots into CWM, adb commands will work! Just mount the system partition in RW.
5. Using adb shell take the dump (you won't be needing root now since the partitions are in RW mode):
dd if=/dev/block/mmcWhatEver of=/sdcard/whatEver.img
EDIT
And if for some reason this doesn't work and you absolutely MUST copy the su binary, you can get the latest zip from the ChainFire.eu site, unzip the su binary and SuperSu.apk files and push the former in /system/xbin/su and the latter in /system/app folders using adb.
Of course, you'll have to provide correct permissions to the su binary, enable the setuid bit on it and finally symlink it to /bin/su.
I got the su binary by letting CWM recovery root my device. However, issuing commands with su copies just the first few bytes. In particular:
Code:
adb shell /system/xbin/su -c "dd if=/dev/block/mmcblk0" | pv | dd of=/media/Storage/mmcblk0.raw
Get 38B, while
Code:
adb shell su -c "cat /dev/block/mmcblk0" | pv > /media/Storage/mmcblk0.raw
Gets 25B.
Anyway, I can't use your suggestion: I don't have an /sdcard partition on my phone anymore: it's the one I'm trying to recover (the last 25.7GB without any filesystem in the partition table I posted in the OP). I must dump them on my PC.
This is just an idea. I tried it on my Nokia 6.1 (2018) (PL2) running Android 10, and it worked; so I thought it might work on other devices too. My device:
Android 10 Q
System-as-root
A/B slots
Released with Project Treble support (and hence has the fstab in the vendor partition)
DM-verity, force-encryption and disk quota disabled with this mod by Zackptg5.
It basically uses a single partition to store the contents of what I call two different userdata "profiles". Normally, you have one userdata partition on a device, and that stores one profile. Here, however, I used a subdirectory on the root of the userdata partition to store the contents of the second profile, and modified the fstab to correctly bind-mount it on /data. Bind-mounting made things simple in my opinion--I didn't have to go about actually repartitioning my storage. The reason this works is that any changes you make to your phone on the lines of installing and updating apps, downloading files, changing settings, etc. are all reflected only on the userdata partition. No other partition on an android phone is ever touched unless the system is updated. Hence, the userdata partition is the only partition you need to mess around with in order to have two profiles.
===================================DISCLAIMER:
I am NOT sharing a solution. I am only sharing an idea for you to try and/or improvise on. It may work, it may not. I will not hold your hand; you will have to use your own knowledge and common sense. I am not responsible for anything that goes wrong on your device.
If you do not understand what is going on in this post, please do not try this.
There is a reason I'm not explaining all the terms I'm using here. I assume that if you, the reader, want to try this out, you a) have some knowledge and experience, and b) have the fire in your belly to research to learn more about what you don't understand.
===================================
Now for the fun:
The first thing I did was to create a new mountpoint the userdata partition. This I made on what is the root filesystem of the device; on a system-as-root device, it would be on the root of the system partition, and on a non-system-as-root device, it would be on the root of the boot ramdisk. I named it userdata/. Accordingly, I edited my fstab.qcom (at etc/fstab.qcom on the vendor partition for my device) to mount the userdata partition on /userdata/ instead of /data/:
Code:
#<device> <mountpoint> <type> <options>
/dev/block/bootdevice/by-name/userdata /userdata <whatever whatever whatever> <you'd probably have to disable options like fileencryption, quota, check (verification), etc.>
and to mount the second profile's directory. Note that it is bind-mounted:
Code:
/userdata/userdata/ /data none bind
Now to switch between the two profiles, you'd switch between the original fstab and the one you just modified.
That is (most of) it. Some things I noticed:
The device would refuse to boot initially. What worked was to backup and wipe my data, boot, create the second profile's directory and copy the contents of the just-created userdata profile into the second profile's directory. In other words, I couldn't run a "first boot" on the second data profile--I had to copy an existing profile into the second profile. I really don't know why this happens.
I suspect that disk quota, filesystem encryption and verification will mess with this (or rather, the other way around). I can't be sure, because I have all three disabled.
Having a shared Internal Storage (/data/media/0/) is convenient. For this, I just bind-mounted that too:
Code:
/userdata/media/0/ /data/media/0/ none bind
This can also be used to easily achieve dual booting on an A/B device, as long as you don't use seamless updates. One ROM per slot can be installed, and the fstab.qcom on one of the vendor partitions can be configured to use the second profile. This way, there would be no need for an external SD card or additional partitions.
I'm pretty sure there will be other hurdles with other devices and other android versions. As I said, I'm just here to share an IDEA, and NOT a foolproof, one-size-fits-all solution. I hope this helps other people make their lives simpler. Please do share your notes on this thread if you manage to get it working on your device!
Its easy to have two roms on one device and its simple,just take a nandroid aof your current rum,now flash another rom an set it up,when u need the other rom just restore your nandroid and so on,i have 4 roms,all fine,lol.
But that's kinda inefficient, don't you think? If you just swap a single file instead of the whole data partition, it's much faster--it takes as long as rebooting + a few milliseconds.
But well, whatever suits you
Hey bro can u pls explain the second code line u mentioned???
varunrocks17 said:
Hey bro can u pls explain the second code line u mentioned???
Click to expand...
Click to collapse
/userdata/userdata/ /data none bind: (this is the line right?)
This bind-mounts the directory /userdata/userdata on /data. /userdata/userdata (directory /userdata under the userdata partition that we previously mounted) is the directory under which the contents of the alternative userdata partition are stored.
Bind-mounting is a means by which a folder can be treated as a device to mount (as opposed to a normal block device or partition). As the mount(8) documentation states, it is a way to "Remount part of the file hierarchy somewhere else."
By this mechanism, the /userdata/userdata folder is made to look like the entire userdata partition. In other words, when you access anything under /data/, you're in fact accessing /userdata/userdata/.
I did something similar to a Jellybean. That is, quite long time ago. Stock fw didn't support encryption. So I made a hack that used cryptsetup and vold.decrypt triggers. That way only framework had to restart. It probably is not that simple anymore...
Anyways, what I learned that it wasn't worth it, so I didn't release it back then. Back then there was a real space shortage and it wasn't wasted like nowadays....
Thanks for that userdata idea that's what I was messing around and. Creating multiple partitions for each rom ...
Btw one question :
Kernel intially mounts vendor then from vendor/etc/fstab.qcom all others are mounted ..?
Or kernel have the predefined vendor system and userdata partition locations ..??
I am really confused here ..
That's why my multi boot was bit messy..
aryankaran said:
Thanks for that userdata idea that's what I was messing around and. Creating multiple partitions for each rom ...
Click to expand...
Click to collapse
Glad I could help
aryankaran said:
Kernel intially mounts vendor then from vendor/etc/fstab.qcom all others are mounted ..?
Or kernel have the predefined vendor system and userdata partition locations ..??
Click to expand...
Click to collapse
On my system-as-root device treble-enabled device, the vendor partition is mounted by the kernel. There is a node in the kernel's device tree blob (dtb) that specifies the vendor mount. When the kernel is fully initialized, it has its own /dev filesystem, using which it mounts the vendor partition. I hope that part is clear.... not sure if I explained it nicely...
Once the vendor is mounted, /vendor/etc/fstab.qcom is read and all the other partitions are mounted from there.
Ok it means it's just the same scenario as it was till Android 7.1.2 that boot image mounts all partitions..
Just difference that kernel now mounts vendor and further processed by fstab ..