Related
I'm a noob. I have 1 phone that can't go down. I have searched XDA, Google, Bing, and YouTube but can't find an answer.
What happens to all the files, folders, and data on a phone when you flash it?
I know there are files on the phone that ID it to the provider. I think it's in the EFS folder, but in all the guides I've read and YouTubes I've watch, not one of them mentions copying anything first nor does it say anything about putting a file back.
Some of the guides I've read make it sound like you wipe everything down to basic hardware before flashing a ROM and kernel back onto the phone.
Does anybody know of a really, really basic guide to what happens?
Most of the time I learn by trial and error. I take it apart and see how it works. I have 4 laptops in varies stages of repair to prove it. But like I said, I only have one phone and I can't spend another $300 just to have another phone to tear down.
On another note...is there a way to set up a sig on this forum?
Firstly, know your hardware as most phones now are using NAND chips for (as it would be) your HDD (Hard Disc Drive) writing files/data/folders/etc is not done the same as a standard HDD.
The NAND chip when being written to copies out (in a size dictated by the chip manufacturer) the Original data, erases the data once copied then writes in your data, verifies it's written correctly, erases the Copied data, moves onto next block/page/sector/etc of data and repeats the process.
If verification fails, the original block/etc of data is written back from the copied location.
Bashing away at my HTC Desire C
---------- Post added at 11:33 PM ---------- Previous post was at 11:26 PM ----------
I don't think there is a 'basic' guide that could cover all the intricacies of how different manufacturers work around the hardware and software also allowing for the proprietary software Dev's are trying to figure out how it works just to make (sometimes) the simplest things work.
Bashing away at my HTC Desire C
RackMonkey said:
What happens to all the files, folders, and data on a phone when you flash it?
Click to expand...
Click to collapse
If you wanna see what would happen when you flash CM11 you can read our upgrader.sh script that tells the phone the steps needed to back up or wipe certain partitions.
https://github.com/teamacid/android_device_samsung_galaxys4gmtd/blob/cm-11.0/updater.sh
If you're flashing from Gingerbread (BML), your EFS partition gets backed up to the SD card, the kernel/bootimage gets overwritten, then the phone reboots.
After it reboots it will copy the modem file into the /radio partition, then the system partition gets wiped, then it will flash the bootimage again with using a new method.
After this the cache and data partitions get wiped, and your EFS backup that was restored to the sd card gets put on the newly created /efs partition.
After all this is done, the script ends and the recovery will continue instlaling the CM11 files to the /system partition
Any other data doesn't get wiped/erased, only what I mentioned.
Thanks FB. That's the first explanation that I could really understand.
I'm asking friends if they have an old phone I can destroy. Then the fun really begins.
FBis251 said:
If you wanna see what would happen when you flash CM11 you can read our upgrader.sh script that tells the phone the steps needed to back up or wipe certain partitions.
https://github.com/teamacid/android_device_samsung_galaxys4gmtd/blob/cm-11.0/updater.sh
If you're flashing from Gingerbread (BML), your EFS partition gets backed up to the SD card, the kernel/bootimage gets overwritten, then the phone reboots....
Click to expand...
Click to collapse
Thanks for posting that file, it was interesting to see. I would also like to know, how the 1 GB ROM of the phone is partitioned.
llinkll said:
Thanks for posting that file, it was interesting to see. I would also like to know, how the 1 GB ROM of the phone is partitioned.
Click to expand...
Click to collapse
Here's the file that defines the partition layout for CM11:
https://github.com/teamacid/niltmt_kernel/blob/cm-11.0/drivers/mtd/onenand/samsung_galaxys4g.h
It starts at around line 31, as an example:
Code:
.name = "boot",
.offset = (72*SZ_256K),
.size = (40*SZ_256K), //101
The offset will tell you how many bytes into the flash chip the particular partition is, this one is at 72 * 256kB blocks which is at 18432kB.
The size of it is 40 256kB blocks. 40 * 256kB = 10,240kB. So the boot partition is starts around 18mB after the first block, and is a size of 10mB.
Once you scroll to the bottom we find the reservoir partition, you can read the description in the comment on that file (line 67).
It ends at (4012 + 84) * 256kB = 1,048,576 kB
FBis251 said:
Here's the file that defines the partition layout for CM11:
https://github.com/teamacid/niltmt_kernel/blob/cm-11.0/drivers/mtd/onenand/samsung_galaxys4g.h
It starts at around line 31, ....
Click to expand...
Click to collapse
Thanks a lot for the help, it's really appreciated.
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.
I'm new to rooting and installing new roms on android systems, but i work making custom linux and windows systems and optimizing for over a decade.
So, my optimizing spirit is tingling to try everything, but this particular thing is just a question, i'm not intending to actually do it.
When using the terminal on TWRP, i've noted that i could fdisk the internal storage (/dev/mmcblk0) and that i could see all the partitions it had, like system, data, cache and so on.
TWRP and other tools only re-format those partitions with ext4 in order to wipe, so i used 'dd' in terminal to zerofill the ones i knew i could wipe and then formatted then in ext4 (with 'dd if=/dev/zero of=partition').
But i had a bigger question and i couldn't find answer nowhere: What would happen if i actually used dd to zero fill EVERYTHING, the entire /dev/mmcblk0, including the very partition table, every byte on it?
Would the device still enter fastboot mode? Would i still be able to connect it on the fastboot utility and flash a new recovery or do something?
Or, if after zero filling, still on the terminal, if i used fdisk to re-create the proper partitions and then formatted them, could i reboot, re-flash the recovery (once there would be the partition for it) and do an very-deep-clean install?
Not that i think that this has any utility, i just wonder if this would end up rendering the device totally useless, or if the fastboot mode is stored in an ROM chip, like a computer bios is.
Guilherme Franco said:
I'm new to rooting and installing new roms on android systems, but i work making custom linux and windows systems and optimizing for over a decade.
So, my optimizing spirit is tingling to try everything, but this particular thing is just a question, i'm not intending to actually do it.
When using the terminal on TWRP, i've noted that i could fdisk the internal storage (/dev/mmcblk0) and that i could see all the partitions it had, like system, data, cache and so on.
TWRP and other tools only re-format those partitions with ext4 in order to wipe, so i used 'dd' in terminal to zerofill the ones i knew i could wipe and then formatted then in ext4 (with 'dd if=/dev/zero of=partition').
But i had a bigger question and i couldn't find answer nowhere: What would happen if i actually used dd to zero fill EVERYTHING, the entire /dev/mmcblk0, including the very partition table, every byte on it?
Would the device still enter fastboot mode? Would i still be able to connect it on the fastboot utility and flash a new recovery or do something?
Or, if after zero filling, still on the terminal, if i used fdisk to re-create the proper partitions and then formatted them, could i reboot, re-flash the recovery (once there would be the partition for it) and do an very-deep-clean install?
Not that i think that this has any utility, i just wonder if this would end up rendering the device totally useless, or if the fastboot mode is stored in an ROM chip, like a computer bios is.
Click to expand...
Click to collapse
The hardware side of fastboot is typically stored on mmcblk0 somewhere in bootloader, meaning it is in the boot partition which is one of the things you would wipe. This would hardbrick your device, rendering it virtually unrecoverable, with a very slim chance of recovering, if its even possible at all, typically, it isn't possible.
Just stick with the tools already designed to handle any wiping that you need.
Sent from my SCH-I535 using Tapatalk
Droidriven said:
The hardware side of fastboot is typically stored on mmcblk0 somewhere in bootloader, meaning it is in the boot partition which is one of the things you would wipe. This would hardbrick your device, rendering it virtually unrecoverable, with a very slim chance of recovering, if its even possible at all, typically, it isn't possible.
Just stick with the tools already designed to handle any wiping that you need.
Sent from my SCH-I535 using Tapatalk
Click to expand...
Click to collapse
That's interesting, i thought my fear was irrational, but it seems to be the case.
But, why is it like that? Why leave everything you need in an RW memory, while you could use a piece of ROM memory to grant the basic functions and the capability of manipulating the RW one (like a PC BIOS)?
In computers you usually don't need to mind wiping everything you can, your device will still work or will be at least recoverable.
Even screwing BIOS and firmwares in computers and some other devices is something that usually won't render the device unrecoverable. Although they sure can cause a hell lot of headache and may need physical intervention like soldering chips and such, i myself strove to find the correct bios images for certain motherboards and to flash the chips because i didn't have an proper flashing equipment, so i had to build an arduino circuit for that (but i luckily worked with detachable chips).
The only other device i know to be rendered unrecoverable are hard drives if you wipe the firmware stored in platter, as it has the service area, which keeps a big part of all information needed to properly address and read the disk and even the other system tracks spread through the disk, that are also needed to control the head, to read and to correct data errors.
Some of these are written at factory, but others must be writable so the hard drive can take care of itself.
But you'd only be able to mess with these data with proprietary low-level software using specific microcode, zero fill and low-level formatting software can't write on any of these tracks, they can only access LBA addressed tracks.
Guilherme Franco said:
That's interesting, i thought my fear was irrational, but it seems to be the case.
But, why is it like that? Why leave everything you need in an RW memory, while you could use a piece of ROM memory to grant the basic functions and the capability of manipulating the RW one (like a PC BIOS)?
In computers you usually don't need to mind wiping everything you can, your device will still work or will be at least recoverable.
Even screwing BIOS and firmwares in computers and some other devices is something that usually won't render the device unrecoverable. Although they sure can cause a hell lot of headache and may need physical intervention like soldering chips and such, i myself strove to find the correct bios images for certain motherboards and to flash the chips because i didn't have an proper flashing equipment, so i had to build an arduino circuit for that (but i luckily worked with detachable chips).
The only other device i know to be rendered unrecoverable are hard drives if you wipe the firmware stored in platter, as it has the service area, which keeps a big part of all information needed to properly address and read the disk and even the other system tracks spread through the disk, that are also needed to control the head, to read and to correct data errors.
Some of these are written at factory, but others must be writable so the hard drive can take care of itself.
But you'd only be able to mess with these data with proprietary low-level software using specific microcode, zero fill and low-level formatting software can't write on any of these tracks, they can only access LBA addressed tracks.
Click to expand...
Click to collapse
The simple answer would be that the manufacturers don't want you messing with the device to begin with so they don't do anything to make flashing or recovering easier for us.
Sent from my SCH-I535 using Tapatalk
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 ..
Ok guys. I use custom ROM for a while know and I did some mistake that sometime I can fix sometime I can't.
Today I messed with backups and I need help.
I did a full backup using adb directly on my laptop (TWRP recovery).
I tried to restore it using adb restore backup comand line. It didn't worked, why memory got filed up, the phone wouldn't boot, neither on recovery or normal.
I succesfully managed to flash back TWRP using odin, and from there I flashed lineageOS and get my phone to boot.
Evrything was fine but... my external SD isn't regognize anymore, neither by lineage nor TWRP. It just didn't show anywhere, and when I try to mount it in TWRP, the box isn't checkable.
The card is fine, I've tested it on my laptop and on another phone.
So it's either a hardware issue and my phone is broken and it's OK I guess.
Or it's a software issue, and my restoring messed up something, a partition that I'm not aware of, that handles the sd card.
So my question is : what can I try to fix my problem ? And on a larger issue, what are exactly the different partitions on a S7 hardrive, what are their purpose, How can I restore them to their initial state ? How do I identify partition in TWRP ? In Odin ? In Heimdall (I'm a linux user) ? I know that there's something called MoDem, or EFS ? Can someone explain those or point me to a class that explain this ?
No harddrive. The EFS partition is especially important, it contains your phone's unique radio information such as your IMEI. Backup it as soon as possible, if you were to have a rainy day you will thank the stars you made that backup. You could try printing the partition table on ADB shell with gdisk and investigating it.
Wattsensi said:
No harddrive. The EFS partition is especially important, it contains your phone's unique radio information such as your IMEI. Backup it as soon as possible, if you were to have a rainy day you will thank the stars you made that backup. You could try printing the partition table on ADB shell with gdisk and investigating it.
Click to expand...
Click to collapse
df comand line and cat /proc/partition returns this. Can't say if it's right
Using gdisk on /dev/block/mmcblk0 you can print the exact GPT table in a human readable form :^)