Restore a deleted partition - General Questions and Answers

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.

Related

[Q] How to find out what partitions correspond to which files in /dev/blocks?

This is a question from a noob I searched for the answer first, but nothing remotely close showed up.
There are files in /dev/block/ that correspond to certain physical partitions on the phone. For instance, mmcblk0p17 corresponds to modem partition. Some others correspond to recovery, system, data partitions, etc. Is there any command that would display which partitions those blocks in /dev/block correspond to? Knowing this, I can write images with "dd" from terminal emulator without going to CWM or Odin/ADB.
Your help would be greatly appreciated.
E107946 said:
This is a question from a noob I searched for the answer first, but nothing remotely close showed up.
There are files in /dev/block/ that correspond to certain physical partitions on the phone. For instance, mmcblk0p17 corresponds to modem partition. Some others correspond to recovery, system, data partitions, etc. Is there any command that would display which partitions those blocks in /dev/block correspond to? Knowing this, I can write images with "dd" from terminal emulator without going to CWM or Odin/ADB.
Your help would be greatly appreciated.
Click to expand...
Click to collapse
seems i have faced the same problem now, it is really confusing fdisk command could not show the label of partitions on android device

[Q] XPS10, clean drive (somebody removed all partititions) - [repaired]

Hi,
At first - if this is wrong category, please move it into correct one.
I have Dell XPS10 - RT based device. It was used by some company - then they wiped all data. All, including partitions. Device is booting into recovery from USB pendrive, but cannot recover it because "required partition is missing".
After digging in recovery command prompt, I found that there's no partitions on internal drive. Created some, upacked wim image - everything's was copying and creating ok, so there's no problem with flash memory.
But I'm still looking how to recreate original partition table, and UEFI bootloader - as I have no experience with uefi at all. On one of youtube vids I found this partition table (it's print from diskpart)
Partition, Type, Size, Offfset
Partition 1 Recovery 500MB 1024KB
Partition 2 System 100MB 501MB
Partition 3 Reserved 128MB 601MB
Partition 4 Primary 53GB 729MB
Partition 5 Recovery 4100MB 53GB
So from what I'm guessing - first 1MB is GPT, then there's not needed partition. 2nd is 100MB system, so it's efi bootloader one? 3rd seems to be usual "System reserved" for Win bootloader and 4 is main one. 5th is not needed again.
After unpacking wim into partition 4, device is still not booting, so I assume that I need somehow install bootloader into partitions 2 and 3. Any clues how to achieve that?
Found this script: http://technet.microsoft.com/en-us/library/hh825686.aspx, will try to apply it tomorrow.
[e]
So, this link helped me - device has usual EFI/GPT partition table - recreated it with help of this technet link, unpacked wim and repaired boot record. Now I'm happy owner of XPS10 64GB

[Completed] Swipe Monster Tab XL916 messup up with internal Storage paritions

Hi,
I wanted to just Overclocked the CPU of my Swipe Monster tab XL916,and as a consequence my device got hanged .I rebooted it and it was still working but it had no User apps in it.It was a strange when I checked out in Setting>Storage that now i had two internal storage partition(Strange)....One partition was just 16 mb and other was The Other was the actual paritition which was 5GB in size.
Maybe it could have changed some system files which led to changes in overall system. I am seriously not able to understand what has went wrong with my device.
#EDIT :Finally got ADB working..Please tell me if you need any information ,i can now run ADB shell commands.i have researched a lot and added parted binaries to the sbin folder,so now I can use parted tool also.I have found out that when i push any app to system via adb the Internal Storage which was earlier as Apps (16 MB) now becomes Apps (19.95 MB) . That means is my System Memory or some part of it is being assumed as Internal Memory.Earlier i was not able to install apks as user apps (as it said not enough memory). But now i am able to do that.
One thing more i have noticied which is quite strange :
a)When sd card is mounted before the boot : The mount command has 2 entries for /dev/block/vold/93:72(for /mnt/sdcard and for /mnt/secure/asec) and one entry for external sdcard by /dev/block/vold/179:1. I have 4 tmpfs (for /dev,/mnt/asec,/mnt/obb,/mnt/sdcard.android_secure)
b)after removing sdcard : vold entry 179:1 is oviously removed but also entry for vold 93:72 for mnt/secure/asec is removed.No change observed in tempfs.
c)reinserting sd card vold entry 179:1 comes back to play while entry for vold 93:72 for mnt/secure/asec is still not appearing.No change observed in tempfs
COMMAND : ls -al /dev/block : has entries for loop 0-7 (strange),platform,vold,nand a-j(nandd is system),ram 0-1,mmcblk0 and mmcblk0p1 for external sdcard
COMMAND: df shows =>/dev ,/mnt/asec,/mnt/obb,/system,/mnt/sdcard,/mnt/extsd
Hi!
Glad you got it sorted! In the future, you can post here for questions or help...
http://forum.xda-developers.com/android/help
Thanks!

corrupted SD-card - adoptable storage

My adoptable SD-card took a crap.
I'd like to think that I can recover the password/key (with a rooted phone), use ddrescue to make an image of the card, use the password/key to decrypt the image of the card, use fsck to fix the file-system (it's ext4, right?) then copy the repaired image back to the card and have a nice day.
Or maybe there's way to fsck the card in the phone? (after making a backup image)
Is this possible? Is there another way to un-screw a corrupted SD-card that's used as adoptable storage?
go vegan said:
My adoptable SD-card took a crap.
I'd like to think that I can recover the password/key (with a rooted phone), use ddrescue to make an image of the card, use the password/key to decrypt the image of the card, use fsck to fix the file-system (it's ext4, right?) then copy the repaired image back to the card and have a nice day.
Or maybe there's way to fsck the card in the phone? (after making a backup image)
Is this possible? Is there another way to un-screw a corrupted SD-card that's used as adoptable storage?
Click to expand...
Click to collapse
If you're trying to fix it so that it works "as-is" again, I wouldn't put too much faith in that.
You can recover the data on the sdcard by various methods, there are many methods and tools, such as these:
http://www.rescuedigitalmedia.com/retrieve-files-from-sd-card-formatted-as-internal-storage
There are more in depth and technical methods/tools also.
Once you have your data safely recovered, format the card and try replacing your data and setting up adoptable storage again the way you did originally.
Sent from my LGL84VL using Tapatalk
Using this as a guide for key recovery and data decryption - https://nelenkov.blogspot.com/2015/06/decrypting-android-m-adopted-storage.html
1- Make a backup of the card
Code:
ddrescue -n /dev/sdc bad-card.img bad-card.log
ddrescue completed in one pass with zero errors. Nice. From here, I'm working with a BACKUP of the card, NOT the card itself.
2- See what's on the card
Code:
fdisk -l bad-card.img
Output:
Code:
Disk bad-card.img: 120.3 GiB, 129116405760 bytes, 252180480 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: gpt
Disk identifier: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Device Start End Sectors Size Type
bad-card.img1 2048 34815 32768 16M unknown
bad-card.img2 34816 252180446 252145631 120.2G unknown
3- Copy the 2nd partition to a file
Code:
dd bs=512 skip=34816 if=bad-card.img of=bad-card-p2.img
* Your numbers may be different
4- Using the encryption key I found using the link, above, mount (read-only) this (2nd) copy of the card
Code:
losetup -r -f --show bad-card-fs-p2.img
cryptsetup luksOpen /dev/loop0 bad-card-fs-p2.img
dmsetup create crypt1 --table "0 252145631 crypt aes-cbc-essiv:sha256 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0 /dev/loop0 0"
mkdir /tmp/mount1
mount -o ro -t ext4 /dev/dm-4 /tmp/mount1
* Your numbers may be different
nb, the "4" in "/dev/dm-4" can be identified by the minor device-number here:
Code:
dmsetup info crypt1
Name: crypt1
State: ACTIVE
Read Ahead: 256
Tables present: LIVE
Open count: 1
Event number: 0
Major, minor: 252, 4
Number of targets: 1
Boom! My files are there!
From here, I used dd to make an unencrypted copy (as a disk-image file) and ran fsck on it. It fixed a few things, apparently nothing catastrophic.
Yeah, recovering pictures and music and that stuff wasn't too bad (since the device is rooted and I was able to recover the encryption key) but getting back the apps and getting the phone back to the state it was in a few hours earlier is not so straightforward.
Lesson learned: Keep a backup copy of the encryption key (in a safe place) so that data can be recovered from an "adopted" SD-card even if the phone gets smashed by a rock.
Too bad there isn't a way to do a "bare metal" backup of an android.
go vegan said:
Using this as a guide for key recovery and data decryption - https://nelenkov.blogspot.com/2015/06/decrypting-android-m-adopted-storage.html
1- Make a backup of the card
Code:
ddrescue -n /dev/sdc bad-card.img bad-card.log
ddrescue completed in one pass with zero errors. Nice. From here, I'm working with a BACKUP of the card, NOT the card itself.
2- See what's on the card
Code:
fdisk -l bad-card.img
Output:
Code:
Disk bad-card.img: 120.3 GiB, 129116405760 bytes, 252180480 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: gpt
Disk identifier: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Device Start End Sectors Size Type
bad-card.img1 2048 34815 32768 16M unknown
bad-card.img2 34816 252180446 252145631 120.2G unknown
3- Copy the 2nd partition to a file
Code:
dd bs=512 skip=34816 if=bad-card.img of=bad-card-p2.img
* Your numbers may be different
4- Using the encryption key I found using the link, above, mount (read-only) this (2nd) copy of the card
Code:
losetup -r -f --show bad-card-fs-p2.img
cryptsetup luksOpen /dev/loop0 bad-card-fs-p2.img
dmsetup create crypt1 --table "0 252145631 crypt aes-cbc-essiv:sha256 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0 /dev/loop0 0"
mkdir /tmp/mount1
mount -o ro -t ext4 /dev/dm-4 /tmp/mount1
* Your numbers may be different
nb, the "4" in "/dev/dm-4" can be identified by the minor device-number here:
Code:
dmsetup info crypt1
Name: crypt1
State: ACTIVE
Read Ahead: 256
Tables present: LIVE
Open count: 1
Event number: 0
Major, minor: 252, 4
Number of targets: 1
Boom! My files are there!
From here, I used dd to make an unencrypted copy (as a disk-image file) and ran fsck on it. It fixed a few things, apparently nothing catastrophic.
Yeah, recovering pictures and music and that stuff wasn't too bad (since the device is rooted and I was able to recover the encryption key) but getting back the apps and getting the phone back to the state it was in a few hours earlier is not so straightforward.
Lesson learned: Keep a backup copy of the encryption key (in a safe place) so that data can be recovered from an "adopted" SD-card even if the phone gets smashed by a rock.
Too bad there isn't a way to do a "bare metal" backup of an android.
Click to expand...
Click to collapse
Very nice.
Sent from my LGL84VL using Tapatalk
Same thing happened again. I knew I'd left a how-to here, so using this as a guide I fixed it much quicker, this time.
1- Power-down and remove the "corrupt" SD-card.
2- Use ddrescue to make a backup copy of the card
Code:
ddrescue -n /dev/sdg bad-card.img bad-card.log
That ran with no errors.
3- While that was backing up, I booted into TWRP and copied expand_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.key to a flash drive via OTG. That's "/data/misc/vold/expand_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.key", as per - https://nelenkov.blogspot.com/2015/06/decrypting-android-m-adopted-storage.html
4- After ddrescue was finished, I decrypted the SD-card.
Code:
blockdev --getsize /dev/sdg2
249702367
od -t x1 expand_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.key
0000000 yy yy yy yy yy yy yy yy yy yy yy yy yy yy yy yy
0000020
dmsetup create crypt1 --table "0 249702367 crypt aes-cbc-essiv:sha256 yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy 0 /dev/sdg2 0"
5- Find out what "crypt1" links to, and what it is.
Code:
file -s /dev/mapper/crypt1
/dev/mapper/crypt1: symbolic link to ../dm-5
file -s /dev/dm-5
/dev/dm-5: Linux rev 1.0 ext2 filesystem data, UUID=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa (extents) (large files)
6- fsck /dev/dm-5.
Code:
fsck /dev/dm-5
fsck from util-linux 2.27.1
e2fsck 1.42.13 (17-May-2015)
/dev/mapper/crypt1: clean, 14314/7806976 files, 21089519/31212795 blocks (check after next mount)
7 - "Remove" the SD-card.
Code:
dmsetup remove crypt1
8- Put the card back in the Android, and it's all good.
nb - Turned out that I didn't need a copy of the card, but it's still good practice to make a backup.
go vegan said:
My adoptable SD-card took a crap.
I'd like to think that I can recover the password/key (with a rooted phone), use ddrescue to make an image of the card, use the password/key to decrypt the image of the card, use fsck to fix the file-system (it's ext4, right?) then copy the repaired image back to the card and have a nice day.
Or maybe there's way to fsck the card in the phone? (after making a backup image)
Is this possible? Is there another way to un-screw a corrupted SD-card that's used as adoptable storage?
Click to expand...
Click to collapse
You are going to big trouble if the card is not recovered.
nyckwilliams said:
You are going to big trouble if the card is not recovered.
Click to expand...
Click to collapse
Did you even read the thread? This member not only posted how they solved the issue but has had to do it twice and posted about it a second time just above the post you made.
Learn to read more than just the first few posts or first few pages of a thread.
Sent from my LGL84VL using Tapatalk
Note to self (and everyone else who finds this) to make it easier to work with image-files from SD-cards. Make use of losetup's "-P" flag to automatically create partitions.
Code:
losetup -r -f --show [B]-P[/B] bad-card.img
/dev/loop0
ls -lh /dev/loop*
brw-rw---- 1 root disk 7, 0 Aug 30 09:31 /dev/loop0
brw-rw---- 1 root disk 259, 0 Aug 30 09:31 /dev/loop0p1
brw-rw---- 1 root disk 259, 1 Aug 30 09:31 /dev/loop0p2
...
Now, the partition of interest is set up as "/dev/loop0p2" with minimum fuss.
Easy, sure and fast solution!
Hello everyone!
I'm going to give you a wonderful news!
You do not need to follow these complicated instructions that are still useful to know in case of need and thanks for this.
The solution is much easy and that's it:
Without turning off the smartphone, remove the micro SD card and reinsert it again.
That's all!
This solves your problem!
Good Android to everyone.
Android 8.1 with Lineage OS on Samsung Galaxy S5 klte and micro SD 128 GB extreme SanDisk A2 U3 V30
Future Technation said:
Without turning off the smartphone, remove the micro SD card and reinsert it again.
Click to expand...
Click to collapse
1- First, make a backup.
2- Good luck.
3- Does that work if the SD card was not unmounted/ejected properly, and the file-system is marked dirty?
go vegan said:
1- First, make a backup.
2- Good luck.
3- Does that work if the SD card was not unmounted/ejected properly, and the file-system is marked dirty?
Click to expand...
Click to collapse
Hello Vegan,
the problem mentioned is created precisely because the system has failed to mount the micro SD and identifies it as corrupt, but it is not really so.
Simply the system has not mounted it and is therefore inaccessible! (Of course, at this stage everyone takes the panic for their data :crying: ).
In my specific case the micro SD is the main memory and obviously also has all the data.
Since it is not yet mounted in the system (due to a reading error), you can not back up your data on the micro SD card.
Furthermore, since it has not yet been mounted (due to a reading error), it can be safely removed and reinserted without restarting the smartphone.
Once this is done, everything is fine.
I hope I was clear in the explanation.
Future Technation said:
Hello everyone!
I'm going to give you a wonderful news!
You do not need to follow these complicated instructions that are still useful to know in case of need and thanks for this.
The solution is much easy and that's it:
Without turning off the smartphone, remove the micro SD card and reinsert it again.
That's all!
This solves your problem!
Good Android to everyone.
Android 8.1 with Lineage OS on Samsung Galaxy S5 klte and micro SD 128 GB extreme SanDisk A2 U3 V30
Click to expand...
Click to collapse
I'm not sure this applies to the specific situation that the OP posted about.
Sent from my LGL84VL using Tapatalk
In my case, the file-system was marked "dirty" and thus could not be mounted by the OS until after it was fsck'd.
Droidriven said:
I'm not sure this applies to the specific situation that the OP posted about.
Sent from my LGL84VL using Tapatalk
Click to expand...
Click to collapse
Hi Droidriven,
it's exactly the same situation, I confirm it.
---------- Post added at 12:02 PM ---------- Previous post was at 11:06 AM ----------
go vegan said:
In my case, the file-system was marked "dirty" and thus could not be mounted by the OS until after it was fsck'd.
Click to expand...
Click to collapse
Hi Vegan,
I had exactly the same problem, the filesystem was corrupt, I explained it well on my post. The micro SD works only after removal and re-insertion. There is no need for check disk. What you did was your option and choice, but in this specific case it is not necessary. You probably did not do as I described but you immediately removed the SD card for a check disk. This post can help many people. Why complicate things when the solution is so easy? Less experienced people can panic. Our job is to help and simplify the work, not to complicate it. However, I'm sure you did your best to solve your problem, but this solution has to admit that it's much easier for everyone.
Have a nice day.
Future Technation said:
Hi Droidriven,
it's exactly the same situation, I confirm it.
---------- Post added at 12:02 PM ---------- Previous post was at 11:06 AM ----------
Hi Vegan,
I had exactly the same problem, the filesystem was corrupt, I explained it well on my post. The micro SD works only after removal and re-insertion. There is no need for check disk. What you did was your option and choice, but in this specific case it is not necessary. You probably did not do as I described but you immediately removed the SD card for a check disk. This post can help many people. Why complicate things when the solution is so easy? Less experienced people can panic. Our job is to help and simplify the work, not to complicate it. However, I'm sure you did your best to solve your problem, but this solution has to admit that it's much easier for everyone.
Have a nice day.
Click to expand...
Click to collapse
Well...
You see...
I'm willing to bet that they tried that first, since it IS the first and simplest troubleshooting step for the scenario, even a noob would know to try that and they seem to be a bit more advanced than a noob. You post as if they did not try that kindergarten level troubleshooting step first, which I'm sure they probably did. But I could be wrong.
Sent from my LGL84VL using Tapatalk
Droidriven said:
Well...
You see...
I'm willing to bet that they tried that first, since it IS the first and simplest troubleshooting step for the scenario, even a noob would know to try that and they seem to be a bit more advanced than a noob. You post as if they did not try that kindergarten level troubleshooting step first, which I'm sure they probably did. But I could be wrong.
Click to expand...
Click to collapse
Hi Droidriven,
This proves that he did not do it.
go vegan said:
In my case, the file-system was marked "dirty" and thus could not be mounted by the OS until after it was fsck'd.
Click to expand...
Click to collapse
The fear factor can always affect one's choices.
Please, review my posts well, I gave a technical and exhaustive explanation of what happened and why I did it that way.
In any case my solution is valid and working. Those who present the same problem can take advantage of this information.
Have a nice day!
Future Technation said:
Hi Droidriven,
This proves that he did not do it.
The fear factor can always affect one's choices.
Please, review my posts well, I gave a technical and exhaustive explanation of what happened and why I did it that way.
In any case my solution is valid and working. Those who present the same problem can take advantage of this information.
Have a nice day!
Click to expand...
Click to collapse
That doesn't prove that they didn't remove and reinsert the sdcard, though. That just proves that their sdcard wasn't working. Nothing in what they posted says that they didn't remove and re-insert the sdcard, you're assuming they didn't because removing and reinserting worked for you. This assumes that their sdcard was "corrupted" for the same reason that yours was and in the same way.
I'm not disagreeing that your method worked for you, I'm just saying that your scenario and their scenario are not necessarily the same.
Sent from my LGL84VL using Tapatalk
Droidriven said:
That doesn't prove that they didn't remove and reinsert the sdcard, though. That just proves that their sdcard wasn't working. Nothing in what they posted says that they didn't remove and re-insert the sdcard, you're assuming they didn't because removing and reinserting worked for you. This assumes that their sdcard was "corrupted" for the same reason that yours was and in the same way.
I'm not disagreeing that your method worked for you, I'm just saying that your scenario and their scenario are not necessarily the same.
Click to expand...
Click to collapse
Excuse me but how old are you? You are a child? This would explain all these controversies. You always want to have the reason anyway. Even if you were an adult, you behave like a child! I have no time to waste with you, but willingly with those who really need to solve the same problem! Those who are truly experts will appreciate this solution. You are spamming here. I will not answer you again. Goodbye!
--------------------------------------------------------------------------------
Hi Go Vegan,
I want to apologize with you for this little discussion, because I started quoting you. My intent is always to share something useful for others. Thank you for your intervention, because obviously if my first approach to this problem does not work for someone, yours becomes indispensable, as obviously it has already been certainly for many others.
This words are for everyone: "We must learn to really listen to others before answering".
Have a nice day!
Might also depend on the phone, the ROM, the version, etc. Might also depend on whether the card is "internal" or "external" storage.
Future Technation said:
Excuse me but how old are you? You are a child? This would explain all these controversies. You always want to have the reason anyway. Even if you were an adult, you behave like a child! I have no time to waste with you, but willingly with those who really need to solve the same problem! Those who are truly experts will appreciate this solution. You are spamming here. I will not answer you again. Goodbye!
--------------------------------------------------------------------------------
Hi Go Vegan,
I want to apologize with you for this little discussion, because I started quoting you. My intent is always to share something useful for others. Thank you for your intervention, because obviously if my first approach to this problem does not work for someone, yours becomes indispensable, as obviously it has already been certainly for many others.
This words are for everyone: "We must learn to really listen to others before answering".
Have a nice day!
Click to expand...
Click to collapse
Actually, with the way you are defending yourself when I'm just telling you the truth, that makes you appear as the child.
You have only 5 posts here and just joined a few days ago. This tells me that you probably haven't dealt with android devices enough to know there can be many different causes for the exact same issue, even on two identical devices that show the same symptoms and that what works in "this" situation on "that" device, doesn't always work the same for another device with the exact same issues.
I was just saying that there are many different details that make all the difference in the world. It's obvious, from everything that you have posted here, that you are unaware of those facts. I was just trying to tell you that you can't be so certain that what you posted is the fix for every user and every device that has this issue. Dont take it so personal.
Sent from my LGL84VL using Tapatalk

A Simple Way to (kind of) Dual Boot an Android

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 ..

Categories

Resources