This works fine on my phone. If it doesn't work on yours, standard disclaimer applies about bricking, phone exploding, etc... that's all on you.
The problem has been that regardless of patches and regardless of methods to make the stock 8.1 data partition readable from TWRP, my phone won't do it. So as follows is how I've backup up and restored as an alternative. I don't know if this works well on Windows (Probably not) or MacOS (More likely it will), so its only tested on Linux.
Install adb on the computer
On the running phone, enable usb debugging.
Connect to the phone, allow the computer to access it.
Get a shell
Code:
adb shell
Enter as follows to find the block device where data is mounted
Code:
mount | grep /data | grep block
My output was this
Code:
/dev/block/mmcblk0p24 on /data type ext4 (rw,seclabel,nosuid,nodev,noatime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,errors=panic,data=ordered
The first part, "/dev/block/mmcblk0p24" is what I was interested in. You can see it's mounted at /data
You're in fact looking for this specifically at the beginning "/dev/block/mmcblk0p24 on /data"
If you're confused or you have multiple mount-points or what not, or you don't understand, Stop Now, you're about to screw things up.
Copy the first part of what you have here, in my case "/dev/block/mmcblk0p24" (don't use quotes though)
Reboot into TWRP.
Make sure /data is not mounted in the TWRP menu. If it is, then no need to do this as you can back it up directly from TWRP anyway, and you don't nee this.
Backup will make an image of the entire partition, so it will be big. As follows to backup, change the /dev/block/xxxxxxx to what yours is, if it is differant. Replace xxxxxxx with what your output was, mine was mmcblk0p24 (this needs to be input correctly for backup and restore, this here is where you can screw your phone up)
Code:
adb shell 'dd if=/dev/block/xxxxxxx' > DataBackupName.img
(Above, you DO use the single quotes)
DataBackupName.img can be named whatever you want to call it.
This takes a long time, my phone writes 12 gigs or so.
The above command should exit telling you how much data was written. You don't want to have an incomplete backup because the usb cable wasn't great or the process spit the dummy for some reason.
To restore, cross your fingers (works fine on my PC)
Also from TWRP and also making sure data is not mounted:
Code:
adb push DataBackupName.img /dev/block/xxxxxxx
You need to have the correct text to replace the xxxxxx. Screwing this up is very high risk of bricking your phone.
Okay all that said, my assumption is that the initial dump won't work on Windows as it needs to direct the output to a file and I have a hunch that the syntax above for directing the output might be done differently. If someone knows how to do the backup on Windows, or can clarify if it works or not as is (after testing) I imagine that would be helpful for Windows users. Feedback in general is good for others, solutions to problems are great.
Additionally, when I was looking for this solution, the answers were a bit old and had to be mildly adapted, but there was a complaint back then that adb couldn't handle the restore. That hasn't been the case for me. A more recent adb binary might fix this if you happen to have this sort of problem.
A benefit of this method, is that if your system can mount an ext4 volume, you can also mount the image, so if you only want one file from a previous backup, or you want to remove a file from the image, or add one, that's all possible... with Linux (Linux geeks know who they are). Note that the image also contains the contents of what gets mounted at /storage/emulated/0
You can compress the image file when its done to reduce the size.
Related
Seems that a refurbished G1 I received has 3 blocks stuck and marked in eccUnfixed for some time, pulled the info from command:
Code:
cat /proc/yaffs
Issues:
I'm thinking as our G1s are getting older and with ROM flashing abuse we are killing NAND blocks on them fast. Researching at various sites linux-mtd & Yaffs.net, the garbage collector of Yaffs should be marking and removing these if Yaffs was controlling the ECC mode. However since Yaffs G1 android setting relies on NANDecc for marking bad blocks I'm not so sure which is cleaning up and not retiring these blocks, maybe NAND and YAFFS are in disagreements or one has ability to retire these blocks and end this problem. It seems though that while flashing ROMs data is being written on to these areas and after a remount it is evident that something may be wrong.
Experiences:
An app could go missing or a file or folder name with invalid characters may happen or a phones feature may suddenly stop workin such as scanning for wireless networks timing out.
The issue is reproducable on freshly erased partitions via fasboot erase system -w.
If a dev would like to co-ordinate with me I will grant them remote access to a system with said phone connected via usb with adb port redirection/remote adb or desktop access with adb and fastboot and vnc client with vnc server on phone .
Workaround:
Working with xda member Licknuts we tested numerous times with a few ROMs 1.6 and 2.1 and came up with this for a quick work around that basically involves erasing /system via fastboot then in recovery lock /system from being formatted and unmounted after ROM Flashing you then tarball /system partition to /sdcard do a reboot into fastboot and erase system again reboot into recovery and untarball back to /system.
Prerequisite:
A phone that suffers missing apps in /system or odd phone behavior features after fresh ROM flash.
ADB with Fastboot, USB Cable connected to your Phone.
Adapt the procedure bellow for issues stemming from the /data partition.
<Go for it>
Going to have to clear out system as it probably has corruption.
Code:
fasboot erase system
Note:::
Hboot spl dictates reboot & some engineer spls have no menu option and engineer spls do not reboot to recovery with an empty partitions when USB cable is connected so disconnect it and reboot then reconnect when in recovery console or just fastboot flash system system.img using HTC 1.6 system.img extracted from their zip.
FYI:::
Haykura sapphire spls (aka: danger spl / death spl) are able to boot to recovery with only radio/hboot/recovery partitions intact as long as it is instructed to do so other wise you get G1 screen with red[fastboot] with USB cable attached (might be the missing safety mode for bricked G1s but not certain).
Anyhow just Reboot to recovery console from menu option or [send][menu][hang] quickly hold [home]
Using adb shell we can lock system partition from being formatted and unmounted by ROM Flash scripts instructions in scripts.
Code:
adb shell
mount -a
cd /system
flash ROM and any updates from Recovery console on phone as normal...... and then we tarball the /system partition before it remounts on reboot and corruption happens
While still in adb shell and hanging out in /system, issue these commands to mount the sdcard and create a tarball of /system.
Code:
mount /sdcard
tar -cvf /sdcard/system.tar /system
sync
reboot bootloader
in fastboot we erase system again because most likely data will corrupt because the Flashing procedure may have written to bad blocks and when mounted or remounted it will corrupt, this is why we tarballed /system before it happens.
Code:
fastboot erase system
then reboot back to recovery console
using adb shell we un-tarball system.tar back to /system mountpoint with YAFFS that supposedly knows about these bad blocks so writing filles out these should be checked and avoided.
Issue these commands:
Code:
mount /sdcard
mount /system
tar -xvf /sdcard/system.tar -C /
sync
reboot
reboot as normally would and with some luck files wrote out avoiding those marked bad blocks.
Resolutions and notes:
flash_image and ROM flashing scripts may be flashing directly to device level which does not have YAFFS bad block information and once mounted with a file system, corruption happens from file system having bad block information.
Using sapphire spls (danger spl) we have access to fasboot oem task 28 & fastboot oem task 29 will low level format, repair, report and mark blocks bad but doesn't seem to resolve issues maybe YAFFS doesn't sync or care about the blocks marked in NAND mtd.
Possibly we need a compiled kernel and complete compiled tool set to fully work on Nand device mtd and format tools for Yaffs and scripts to automate some tasks. Seems Nandroid and /system/xbin, /sbin, /system/bin and recovery console tool-sets are limited as well.
*I think and type fast so note that typos may exists hopefully not in coding but elsewhere and if you exist solely to point out grammar and spelling of others on internet forums or broken English of members from other countries, then respect my preemptive "go **** yourself".
If my help aided in getting your phone in working order then give a family member or friend a call or donate some $ to the devs that keep our phones fun to use.
Have you got any more in-depth info on this?
The way I see it, you erase with fastboot... What does this accomplish that doesnt happen if one from the recovery console or adb, dd /dev/zero into the MTD device?
Or, better yet, wouldn't tarring the system partition after its written just copy the bad files that existed on the bad erase block(s)?
Or am i seriously not understanding what your instructions are doing.. To me:
Erase in some way once. What this does, i'm unsure.
Flash
Mount /system and tar to sdcard
Erase again (again what this does to assist the process is uncertain to me)
Boot to recovery
Mount everything
Untar from sdcard.
Tell me if I understand this wrong?
as some blocks are reserved to replace bad blocks , most of the time you won't see a problem
However, once these are used up you will effectively see partition 'shrinkage'
we can limit this 'shrinkage by using lbcoder's custom MTD via the kernel command line
I have a relatively simple way of implementing this
http://forum.xda-developers.com/showthread.php?p=7061471#post7061471
Thanks Phonekenstein for such a great input. I never knew this thread was exist until now but I found this and read the title, damn this is exactly what my case is!
Follow your instruction and re-install the rom, every single headached weird behaviors are disappear and the system runs like butter. It seems my phone is finally fixed!
I think this thread should get more attention.
(bump)
This is a great find! I will be trying this on my HD2 as I have some bad blocks also causing Android builds to go wack.
Hey all, This is my first post on the forum, so I thought I'd make it a guide.
I've run into a few roadblocks with installing some development tools like python and stuff, so I figured I'd try and make a filesystem image to hold all of it, what with Android preventing executables on your SD card from actually executing. You should NOT try and use this for freeing up space by moving apps to it. That just breaks things.
Things to know
A mount point is where you access the contents of a filesystem through.
A filesystem is basically a virtual disk.
I'm not responsible for your phone melting into a pool of acid or anything else you want to blame me for. You executed the commands, not me.
If there's been guides for this already, I didn't find them.
Playing with your system files is dangerous. Be careful
Playing with filesystems is even MORE dangerous. Don't do it unless you know what's going on.
Reversing and then combining two words in a sentence, then calling it a bit more dangerous is incredibly dangerous and can kill you. Don't do it.
As I said earlier: This is not intended to free up internal storage on your phone. It is intended to create extra space to put command-line executables.
This was created for those of us who have older phones that don't have a whole lot of internal storage. (Like the Milestone) This should also work on anything that meets the requirements listed below. I use it on a Motorola Milestone A853 running CyanogenMod 7.2.4f UMTS/SHOLES, and it took some tweaking, but it worked. Commands you put into your shell are marked with `bolded text and surrounded by back-ticks. Leave the back-ticks out. (`)`
Requirements! (obtained using `which <command name>` or a specified command)
Free space on your mSD
losetup (configuring loop devices)
mknod (creating loop devices)
mount (mounting filesystems)
mkdir (making directories)
su (root access)
umount (unmounting)
mke2fs (formatting)
Linux filesystem support (`cat /proc/filesystems | grep ext`)
Here we go!
This assumes you are going to use an ext4-formatted filesystem image mounted on /data/development/, with the image located at /mnt/sdcard/development.img. You WILL need to determine your phone's supported ext<num> filesystems using `cat /proc/filesystems | grep ext`. Choose the highest-numbered one.
Create the mountpoint, the image, and then format the image to ext4.
`mkdir /data/development/``dd if=/dev/zero of=/mnt/sdcard/development.img count=409600 bs=1024``mke2fs -l /mnt/sdcard/development.img -b 1024 -t ext4`
Create the block device, set it to point at the image, then mount it.
`mknod /dev/block/loop250 b 7 250``losetup /dev/block/loop250 /mnt/sdcard/development.img``mount -t ext4 /dev/block/loop250 /data/development`
Test it to see if it works.
`touch /data/development/testfile;ls /data/development/`
Use it.
Unmounting (/!\ For connecting to a computer to avoid corruption /!\)
`umount /mnt/sdcard/development.img``losetup -d /dev/block/loop250`
Well, that's all I've got. Suggestions and corrections, as well as good feedback are appreciated.
Some PAQs (Possibly Asked Questions)
Q: I'm getting some errors. Here they are: pastebin.com/some-errors
A: Great, I'll see what I did wrong, and if it's something on your end, I'll try and help you out.
Q: It dun werk
A: Tell me the errors instead of complaining about them. Just saying that does not help me and wastes my time and bandwidth.
Q: "No space left on device"; "Operation not permitted"; "No such file or directory"
A: SD card full; not root (or SD card is full, or something broke); Mount point doesn't exist or (if 'mount' returns that and the point exists) something not cool happened.
Usage guide on Non-Android devices
Some interesting bits of information for use on computers:
There's probably not an easy way to read/write/mount EXT2 filesystems on a Windows machine, so if you have a solution that's stable, go for it.
Linux computers definitely should support this, and I'm not sure about OSX computers, but in theory would work if you had the right things installed. iPhones ... well I have no idea what you'd do with it there.
Linux:
On the device:
THIS PART IS EXTREMELY IMPORTANT, NOT DOING THIS WILL RESULT IN BROKEN FILESYSTEMS!
`umount /mnt/sdcard/development.img`
`losetup -d /dev/block/loop250`Plug your phone into your computer, making sure that the computer mounts it and reads it as removable media, and that the image is present.
On the computer: (Path of your user folder, and the mount point at which your device's SD is mounted can and very likely will vary from distribution to distribution. Check your paths.)
`mkdir /home/user/android-devtools/`
`mount -o loop /media/user/android-sd/development.img /home/user/android-devtools/`Now, you can change things within the image as you normally would a file or folder. Be warned, sometimes doing this can create conflicts in the file permissions, so running the right commands on the phone to change the permissions as root (use `chmod` for the permissions) can save you boatloads of trouble getting things to work, or editing files.
Mac OSX might or might not be the same, but seeing as I haven't picked up an Apple computer since maybe 5 years ago, let alone attempted filesystem management, I just don't know.
Hello,
I am trying to recover from a softbrick issue. I have a BLU Studio C 5+5 LTE and therefore can't use TWRP or CWM (At least that is my assumption, maybe someone knows different). Before getting into the softbrick state I took 3 different types of backups in the hopes that one of them could be used in case it was needed. (like this)
Type 1 - I did an ADB shell backup from a completely stock device (unrooted) I used this command-
adb backup -apk -all -f fullbackup.adb
For this method I followed this guide here-
https://linuxiswonderful.wordpress.com/2015/04/04/full-backup-of-nonrooted-android/
Type 2 - I used Titanium backup and performed a complete system and application backup
Type 3 - I rooted the phone and backed up all partitions using dd after reviewing the partition layout of the device. For example, to backup the system partition I did the following at an ADB shell-
dd if=/dev/block/mmcblk0p21 of=/storage/sdcard1/firmware-img/system.img
I believe the last operation I tried before softbricking was installing the Xposed framework module for my device (running Lollipop 5.1.1).
I am able to still communicate to my device using ADB and I can get an ADB shell. or enter fastboot mode My device presently shows the manufacturer's logo when booting and gets no further.
To recover from this issue I think I have two basic options
#1 restore from backup
#2 locate the problem that is causing the system to hang at startup in the first place
At the end of the day I am trying to find the simplest, quickest method to get back up and running. Both methods are acceptable to me. I am not worried about losing any data.
My challenge/sticking point is how to turn my backups into a usable format to get me back on track or understand the boot process enough to get out of the boot loop.
The first thing I tried was mounting my raw image files created from the dd process. I followed this guide-
https://samindaw.wordpress.com/2012/03/21/mounting-a-file-as-a-file-system-in-linux/
I ran these commands-
#losetup /dev/loop0 /path/to/my/system.img
# mkfs -t ext3 -m 1 -v /dev/loop0
# mount -t ext3 /dev/loop0 /mnt
# cd /mnt
# ls
The various image files I created all seemed to mount "ok" OK meaning that the loopback mount process worked but it appears there is nothing but a lost+found folder in the mounted image. (I'm not sure why that is.)
I am still researching methods to turn my other backups into something usable for recovery purposes.
For using the adb backup file I created, this is what my understanding is-
Adb backup uses a type of compression (don’t remember what kind). I would need to uncompress the file first. After uncompressing and being able to view the file contents I would think I should be able to put together a flashable zip file of some sort.
I think the process for Titanium backup would generally be the same- uncompress/convert file format, create/assemble a flashable zip file
The last thought I had was trying to get the system to boot. To do so, I need to better understand the boot process. I am familiar with how Linux boots as I am a Sys Admin. I know Android is similar but just different enough to make me research this further. I can pull dmesg log for anyone if that will help. I was also seeing where you could use the logcat command. (That is new to me as it seems more Android specific and not used in Linux that I know of)
If there is any other info you need to see, please let me know. I made a lot of notes about the system architecture, partition layout, etc.
Many thanks in advance for your help!
XDA Visitor said:
Hello,
I am trying to recover from a softbrick issue. I have a BLU Studio C 5+5 LTE and therefore can't use TWRP or CWM (At least that is my assumption, maybe someone knows different). Before getting into the softbrick state I took 3 different types of backups in the hopes that one of them could be used in case it was needed. (like this)
Type 1 - I did an ADB shell backup from a completely stock device (unrooted) I used this command-
adb backup -apk -all -f fullbackup.adb
For this method I followed this guide here-
https://linuxiswonderful.wordpress.com/2015/04/04/full-backup-of-nonrooted-android/
Type 2 - I used Titanium backup and performed a complete system and application backup
Type 3 - I rooted the phone and backed up all partitions using dd after reviewing the partition layout of the device. For example, to backup the system partition I did the following at an ADB shell-
dd if=/dev/block/mmcblk0p21 of=/storage/sdcard1/firmware-img/system.img
I believe the last operation I tried before softbricking was installing the Xposed framework module for my device (running Lollipop 5.1.1).
I am able to still communicate to my device using ADB and I can get an ADB shell. or enter fastboot mode My device presently shows the manufacturer's logo when booting and gets no further.
To recover from this issue I think I have two basic options
#1 restore from backup
#2 locate the problem that is causing the system to hang at startup in the first place
At the end of the day I am trying to find the simplest, quickest method to get back up and running. Both methods are acceptable to me. I am not worried about losing any data.
My challenge/sticking point is how to turn my backups into a usable format to get me back on track or understand the boot process enough to get out of the boot loop.
The first thing I tried was mounting my raw image files created from the dd process. I followed this guide-
https://samindaw.wordpress.com/2012/03/21/mounting-a-file-as-a-file-system-in-linux/
I ran these commands-
#losetup /dev/loop0 /path/to/my/system.img
# mkfs -t ext3 -m 1 -v /dev/loop0
# mount -t ext3 /dev/loop0 /mnt
# cd /mnt
# ls
The various image files I created all seemed to mount "ok" OK meaning that the loopback mount process worked but it appears there is nothing but a lost+found folder in the mounted image. (I'm not sure why that is.)
I am still researching methods to turn my other backups into something usable for recovery purposes.
For using the adb backup file I created, this is what my understanding is-
Adb backup uses a type of compression (don’t remember what kind). I would need to uncompress the file first. After uncompressing and being able to view the file contents I would think I should be able to put together a flashable zip file of some sort.
I think the process for Titanium backup would generally be the same- uncompress/convert file format, create/assemble a flashable zip file
The last thought I had was trying to get the system to boot. To do so, I need to better understand the boot process. I am familiar with how Linux boots as I am a Sys Admin. I know Android is similar but just different enough to make me research this further. I can pull dmesg log for anyone if that will help. I was also seeing where you could use the logcat command. (That is new to me as it seems more Android specific and not used in Linux that I know of)
If there is any other info you need to see, please let me know. I made a lot of notes about the system architecture, partition layout, etc.
Many thanks in advance for your help!
Click to expand...
Click to collapse
Greetings,
Thank you for using XDA Assist.
There are no specific forums for your device model on XDA. However, if you create an XDA account, you can ask your questions here:
Android Q&A, Help & Troubleshooting
You will receive expert advice there.
Good luck and welcome to XDA!
Hi. I have to flash a TWRP backup and can't do it thorugh custom recovery due I have a Yotaphone (the phone with a LCD screen by one side and a eInk screen by the other side) and the LCD screen is broken, so I have to use fastboot or adb (as far I know). I cannot even install a ROM because it needs the LCD screen for the first start.
The question if I can do it, cause I know it could be problems with formats.
(I asked this on Yotaphone specific xda forum but no one answered)
Thanks
eReader Fan said:
Hi. I have to flash a TWRP backup and can't do it thorugh custom recovery due I have a Yotaphone (the phone with a LCD screen by one side and a eInk screen by the other side) and the LCD screen is broken, so I have to use fastboot or adb (as far I know). I cannot even install a ROM because it needs the LCD screen for the first start.
The question if I can do it, cause I know it could be problems with formats.
(I asked this on Yotaphone specific xda forum but no one answered)
Thanks
Click to expand...
Click to collapse
You would probably have better luck flashing the stock firmware or have someone with the same device create an adb backup then restore it via adb.
Or if you know which individual .img files you need, have them pull a copy of whichever individual .img files you need(for example: system, boot, etc) then fastboot flash them or use adb shell to dd the .imgs back onto your device in the partitions they belong in.
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE
@Droidriven ,you are right about it would be easy to fash a stock rom, but the LCD screen is necessary for that due the first boot. Maybe I am a little lucky 'cause I live with person who has the same device as me.
I tried the adb backup -all but it seems to just make a backup of the personal data.
Making a dd backup patition would be the better, but for some reason my device isn't recognized as a MTP device and can only connect in PTP. Tried to change the configuration on the phone but still only works with PTP, and I think in PTP mode doesn't have a mounted folder where I can make this stuff.
What I don't know how to do is the dd within the adb shell. It will work connected in PTP mode?
eReader Fan said:
@Droidriven ,you are right about it would be easy to fash a stock rom, but the LCD screen is necessary for that due the first boot. Maybe I am a little lucky 'cause I live with person who has the same device as me.
I tried the adb backup -all but it seems to just make a backup of the personal data.
Making a dd backup patition would be the better, but for some reason my device isn't recognized as a MTP device and can only connect in PTP. Tried to change the configuration on the phone but still only works with PTP, and I think in PTP mode doesn't have a mounted folder where I can make this stuff.
What I don't know how to do is the dd within the adb shell. It will work connected in PTP mode?
Click to expand...
Click to collapse
Is USB debugging enabled?
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE
Yes, debuggind mode is on. In PTP mode, adb sees my device correctly, in MTP mode appears like ???????
I think maybe the answer is where that you mentioned about "adb shell". As long as I can't see the phone mounted in MTP mode it's the only way I see. Now I am searching for the way on pointing the dd output file outside the adb shell. So the process is:
BACKUP:
-adb shell > dd partitions saving them outside the phone
FLASHING:
-fastboot partition by partition
Another problem I have is to know which partion is each, 'cause with "mount" I don't get so much information and with "cat /proc/partitions" only have 13 partitions with their size and no more info. I am looking what to "adb push" that can help me. Maybe install busybox.
Trying to backup&restore without MTP, without access to the recovery nor SDcard... Harder is impossible!!!
eReader Fan said:
I think maybe the answer is where that you mentioned about "adb shell". As long as I can't see the phone mounted in MTP mode it's the only way I see. Now I am searching for the way on pointing the dd output file outside the adb shell. So the process is:
BACKUP:
-adb shell > dd partitions saving them outside the phone
FLASHING:
-fastboot partition by partition
Another problem I have is to know which partion is each, 'cause with "mount" I don't get so much information and with "cat /proc/partitions" only have 13 partitions with their size and no more info. I am looking what to "adb push" that can help me. Maybe install busybox.
Trying to backup&restore without MTP, without access to the recovery nor SDcard... Harder is impossible!!!
Click to expand...
Click to collapse
This command in adb shell or Terminal Emulator should give you your partitions and names(obviously you'd type "su" then press enter then run this command)
ls -l /dev/block/platform/msm_sdcc.1/by-name/
The part with "msm.sdcc.1" might be different for your device. If that command doesn't work I'll help you find what needs to go in that part of the command for your device.
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE
su is not found inside the adb shell, and I found this is cause is not rooted. I have to do it through TWRP in android 6.
As I said, I have two devices of my model so I hope I find time tomorrow for doing it. I also hope to can flashing it to the other device in fastboot mode or some way it doesn't need the main screen (remember I have a LCD screen and a eInk)
I will say something when I do the root. Thanks
Finally did it!
It appears each partitions clearly with the "ls" command you give to me. The question now is how to dd outside the phone. Have I to mount the pc inside the shell or what?
eReader Fan said:
Finally did it!
It appears each partitions clearly with the "ls" command you give to me. The question now is how to dd outside the phone. Have I to mount the pc inside the shell or what?
Click to expand...
Click to collapse
adb shell should work to dd, you just need to make absolutely certain that you are dd-ing the correct .img to the correct partition(mmcblk0xx), the partition number would go where the xx is.
For example, my recovery.img would be flashed to mmcblk018(the number of my recovery partition.
If you dd an .img to the wrong partition, you'll brick the device, the command has to be exactly correct, no margin for error or easy fix if you get it wrong.
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE
I know all this stuff, but first I need to make the .img of each partition, and I though with adb shell I could do a dd to outside the phone. The TWRP backup I have isn't .img files, they are .win files.
I searched again if its possible to do that and all I found is the xda thread about doing a workaround with adb forward and busybox. If there is no more options I will do that.
What I thought to do is create a backup of the needed partitions and save them in the userdata free space. I think this have to be possible, but as I cannot use the LCD screen I have to do the backup where I do not have to pass thorugh the first boot configuration, cause it is did in the LCD screen. Which partitions have I to backup? Only system and boot? Or there is another tool for creating .img backups?
EDIT: Also found the twrp adb possibilities (http://www.pocketables.com/2014/10/using-twrps-new-adb-interface.html) but have the same problems than with dd
I frequently modify boot and recovery partitions from within terminal app. Here's what I do to grab the boot partition for example(you likely want BusyBox installed first)
cat /dev/block/bootdevice/by-name/boot >boot.img
or
dd if=/dev/block/bootdevice/by-name/boot of=boot.img
Make changes, then reverse the commands to write back. I think cat gives you a more verbatim copy for initially cloning a partition. I have had success with both.
The question that brought me here is what happens if i flash all partitions from a firmware archive and attempt to upgrade a whole system this way from twrp recovery.....
Hi guys!!!
I have a rooted first generation Pixel running stock Android 10. I would like to take a physical image of the device using ADB.
If I command "mount" in ADB shell, I get for example the following line:
/dev/block/sda35 on /data type ext4
If I image /dev/block/sda35 with dd and netcat, I get an image but the file based encryption comes in the way and the files are useless.
So if I would like to take a clear text (physical) image of this device, what should I image? Or maybe the other way of asking this is, what is the best image I can expect through ADB with root privileges?
Thanks!!!
Any particular reason you don't want to backup through TWRP?
The main reason is that I am interested to know how this is done manually through ADB.
I am also interested how the file based encryption works and what kind of information I can get out from the device with a best possible image.
So for me this is only an experiment, I dont have any valuable data on the device
dd allows you to get a bit-perfect copy of the partition. You are seeing the contents exactly as they are. For Android to view the actual files (well, those that are encrypted, not necessarily everything is encrypted with FBE) it has to decrypt them, which requires the key. Additionally, as you can have multiple users on a device, each of the user's files have a separate key.
In the old days of encrypted partitions, there was a metadata partition or similar that you could get the key from. Under FBE, I'm not sure how to do it, but the principle would be similar. So the only way to get a clear text copy of the files using dd is to decrypt.
Do have any knowledge how Android does this decryption in practise?
When I imaged /dev/block/sda, which should be the ”raw” memory device, my phone was open (passcode was entered to gain access to the phone) and the device remained in this state through the imaging.
Still this raw device is FBE, as I would expect actually. So Android does the decryption somehow to the mounted partition, but I dont know how.
Actually I can see that my root directory / comes from a device /dev/root, but in ADB shell I cannot find this device.
Maybe the next thing I will try is to use ADB when my phone is booted to TWRP and TWRP does the decryption...
In any case, Thanks for your answer!
I don't know the details, but one key point about decrypting is that it does not change the actual content on disk. Think of decrypting as a translation service. There is something on disk you want to read, so the translator turns it into the plain text view. Similarly if you want to store some data, the translation service converts it into the encrypted view to be stored on disk. This is all done as the files are requested, and is transparent to any app. (Otherwise if you decrypted the disk and 'pulled the plug', you could go in and get the plain text content, which would defeat the purpose of encryption).
So doing this in TWRP won't make any difference.