How To Guide How to backup your partitions with command line (requires root)

How To Guide How to backup your partitions with command line (requires root) - Sony Xperia 10 III

How to backup partition images with dd on the command line (root required)
We don't currently have a working custom recovery for the Xperia 10 III, but if you have root there's a simple method to dump partition images.
This is a very good idea and you should do it at least once, especially if you like to mess around the device a lot.
You won't be able to do this before you root, so by the time you do some partitions will not be stock anymore. Use XperiFirm instead to get the clean stock images.
Special partitions:
The userdata partition holds all your personal files and system settings. It's huge (about 105 GB) and obviously you can't dump it into itself. You can dump it on an SD card if it's 128+ GB.
The super partition is a physical partition that contains several logical partitions (including system and vendor) That's why you won't find those in the partition list. This is done on Android 10+ devices to allow those logical partitions to be resized or rearranged as needed. You don't need to split out the internal logical partitions, you can flash back the entire super partition. The stock firmware also comes with a super image, not individual logical partitions.
Using a helper script:There's a Magisk module called Backup (by Draco) which gives you a command line shell script you can use if you prefer. It mostly does the same things I described above. The script is here if anybody wants to just grab it directly.
On the plus side, the script knows to dump only the active A/B image (which is the one that interests you most). On the flip side, it doesn't have a feature to skip userdata.
So here is a shell command that will use the backup script to dump all partitions, but only those matching your device's active A/B slot, and skips userdata:
Code:
backup $(ls /dev/block/bootdevice/by-name/ | grep -v userdata | sed 's/_[ab]$//')
And here's one that also skips super:
Code:
backup $(ls /dev/block/bootdevice/by-name/ | grep -v userdata | grep -v super | sed 's/_[ab]$//')
How to dump partitions manually:If you can't/won't use the helper script you can do it by hand. All the following commands need root:
Find the names of all the partitions:
Code:
ls /dev/block/bootdevice/by-name/
Dump one specific partition identified by NAME:
Code:
dd if=/dev/block/bootdevice/by-name/NAME of=NAME.img
Dump all partitions except userdata:
Code:
ls /dev/block/bootdevice/by-name/ | grep -v userdata | while read NAME; do echo dd if=/dev/block/bootdevice/by-name/${NAME} of=${NAME}.img; done
Find the active slot:
Code:
getprop ro.boot.slot_suffix
Get checksums for all the images after the dump:
Code:
md5sum *.img
Confused about _a and _b partitions?You should read about A/B Seamless Updates.
Long story short, some partitions have two copies eg. boot_a and boot_b. When you boot up the device you use the partitions in one slot (eg. the _a partitions). When an OTA update is being downloaded, it writes into the partitions for the other slot (eg. the _b partitions). Your phone can stay in use while this happens. If the OTA fails nothing is broken, you just keep using the good slot partitions. After the OTA is successful you switch to the other slot and also have the previous version in the other slot in case you need to switch back.
This means that some of the _a and _b images for the same partition can be different for you! So it's strongly recommended to do the checksums, and also to find out which is your active slot, so you know which partitions you're using right now.

I used a 128 GB card to take a backup of userdata. The backup script had some trouble with the backup location being on the storage card for some reason and I didn't have time to figure it out, but the dd command I gave above worked fine.
Code:
# time dd if=/dev/block/bootdevice/by-name/userdata of=userdata.img
112111374336 bytes (104 G) copied, 2342.274225 s, 46 M/s
39m02.31s real 1m11.78s user 14m44.72s system
Code:
# adb pull /storage/1234-ABCD/backup/userdata.img ./
/storage/1234-ABCD/backup/userdata.img: 1 file pulled, 0 skipped.
87.2 MB/s (112111374336 bytes in 1225.663s)
So that's 104 GB that took 39 minutes to be written to a new Samsung Evo U3/V30 microSDXC (46 MB/sec real write speed) and 20 minutes to be read to the PC (Samsung Evo M.2) with adb pull over USB (87 MB/sec read speed). Just so you know what you're in for.

I was looking into whether I could speed up the process of taking userdata snapshots by dumping the partition directly to the PC, but you need to be root to access the device block. The stock ROM doesn't allow the command adb root, but I found this blog post which made me realize you can run a su -c command that asks dd to write to stdout and just pipe the output to a file. The post author has also made this helpful Python script which lets you do pulls and pushes with root-only files.
If you want to run the command directly (I've only tested on Linux, no idea if it works on PowerShell but it might):
Code:
# adb shell "su -c" "dd if=/dev/block/bootdevice/by-name/userdata" > userdata.img
If you want to use the Python script:
Code:
# adb-root.py pull /dev/block/bootdevice/by-name/userdata userdata.img
Using the same fast SSD on the PC side as above, I now get:
Code:
218967528+0 records in
218967528+0 records out
112111374336 bytes (104 G) copied, 1077.681097 s, 99 M/s
real 17m57.910s
So that's roughly 15 minutes compared to 1 hour total with the previous method and you don't need to have a 128 GB SD card anymore.

Are you able to switch to a different backup location? Say a USB OTG if possible.

mikeshutte said:
Are you able to switch to a different backup location? Say a USB OTG if possible.
Click to expand...
Click to collapse
With dd yes, simply move to the directory you want before you call dd.
The backup script is bugged and seems to ignore the -d parameter for the backup location so it always uses /sdcard/backup. (I think it might be expecting a different version of getopts...) Normally I would say to try creating a symlink from /sdcard/backup to the OTG storage but the ln utility is also behaving strangely and I can't make any symlinks (even with root).

wirespot said:
With dd yes, simply move to the directory you want before you call dd.
The backup script is bugged and seems to ignore the -d parameter for the backup location so it always uses /sdcard/backup. (I think it might be expecting a different version of getopts...) Normally I would say to try creating a symlink from /sdcard/backup to the OTG storage but the ln utility is also behaving strangely and I can't make any symlinks (even with root).
Click to expand...
Click to collapse
Ok I'll give it a try and see what happens. Thanks for your help.

Hi, I'm used to TWRP backups, so I don't really understand this tool. I've backedup everything except the massive userdata partition. If needed, how would I restore this? Is the userdata partition required when I have all the others?
Thanks!

jakito said:
Hi, I'm used to TWRP backups, so I don't really understand this tool. I've backedup everything except the massive userdata partition. If needed, how would I restore this? Is the userdata partition required when I have all the others?
Thanks!
Click to expand...
Click to collapse
This is basically the same thing that TWRP does, dd is a command line Linux tool that makes a "raw" copy of a partition.
Restoration is a bit more tricky. In theory you can simply dump the raw backup copy over the partition. The problem is that it's not ok to do it while the system is running. Typically it's done by booting into recovery (TWRP) and overwriting the partition from there.
Another method for restore is to use fastboot, which is an alternative tool you can boot into that only does one thing, write partitions. But fastboot is typically locked by the vendor to only write signed images, so it can only be used to write official release ROMs.
There are some limited uses for fastboot, such as overwriting the boot partition, which is not checked for signature anymore once you've unlocked the bootloader. So if you want to experiment with unofficial kernels and mess something up you can always restore a good boot partition with fastboot.
TLDR: for the time being until we get a working TWRP recovery the most you can do is take backups, but not restore them.

wirespot said:
This is basically the same thing that TWRP does, dd is a command line Linux tool that makes a "raw" copy of a partition.
Restoration is a bit more tricky. In theory you can simply dump the raw backup copy over the partition. The problem is that it's not ok to do it while the system is running. Typically it's done by booting into recovery (TWRP) and overwriting the partition from there.
Another method for restore is to use fastboot, which is an alternative tool you can boot into that only does one thing, write partitions. But fastboot is typically locked by the vendor to only write signed images, so it can only be used to write official release ROMs.
There are some limited uses for fastboot, such as overwriting the boot partition, which is not checked for signature anymore once you've unlocked the bootloader. So if you want to experiment with unofficial kernels and mess something up you can always restore a good boot partition with fastboot.
TLDR: for the time being until we get a working TWRP recovery the most you can do is take backups, but not restore them.
Click to expand...
Click to collapse
I see. Thank you nonetheless!

wirespot said:
This is basically the same thing that TWRP does, dd is a command line Linux tool that makes a "raw" copy of a partition.
Restoration is a bit more tricky. In theory you can simply dump the raw backup copy over the partition. The problem is that it's not ok to do it while the system is running. Typically it's done by booting into recovery (TWRP) and overwriting the partition from there.
Another method for restore is to use fastboot, which is an alternative tool you can boot into that only does one thing, write partitions. But fastboot is typically locked by the vendor to only write signed images, so it can only be used to write official release ROMs.
There are some limited uses for fastboot, such as overwriting the boot partition, which is not checked for signature anymore once you've unlocked the bootloader. So if you want to experiment with unofficial kernels and mess something up you can always restore a good boot partition with fastboot.
TLDR: for the time being until we get a working TWRP recovery the most you can do is take backups, but not restore them.
Click to expand...
Click to collapse
I don't know how I ended up but making a backup you can't restore is completely pointless.

Techguy777 said:
I don't know how I ended up but making a backup you can't restore is completely pointless.
Click to expand...
Click to collapse
No, it's not. All your data is in there. You can mount your backup on a linux computer and pull out apks as well as app data. You can then restore these folder by folder with adb and a root shell on your phone.
That beeing said, does anyone know a proper backup software like Titanium Backup for Android 11 and above? Sometimes I read recommendations, but looking at the ratings it seems that no software manages to achieve the same level of comfort and control. Also they all seem to suffer from the same limitations.
Let's be honest: Google wants to make your life hard, so they can lock you in.

@xperinaut
I'm using Titanium on Android 11. Is it not working for you?

Related

ext4 extraction from system.sin issues

Hi,
As you probably know, ext4 image can be extracted from system.sin but cannot be mounted. When trying to mount it, it fails with :
[ 1476.821582] EXT4-fs (loop0): bad geometry: block count 262144 exceeds size of device (144631 blocks)
I open this thread just to share what I did around the issue and maybe have some helpful quotes about it
Here is what I did (under linux)
# First create an zero filled file. Size is system partition size (262144 blocks of 4096 each)
dd if=/dev/zero of=/home/xperia/virtualfs bs=4096 count=262144
# Attach file to loopback
sudo losetup /dev/loop0 /home/xperia/virtualfs
# Format it with same features as system partition on phone
sudo mkfs.ext4 -O has_journal,^ext_attr,^dir_index,^flex_bg,^huge_file,resize_inode,filetype,extent,sparse_super,large_file,^uninit_bg,^dir_nlink,^extra_isize -v /dev/loop0
# Write extracted system.sin.ext4 extracted image to loopback
sudo dd if=system.sin.ext4 of=/dev/loop0
# Mount filesystem
sudo mount /dev/loop0 /mnt
It can be mounted and I can have folder structure but I can't work with files. Editing default.prop gives me a non readable file.
But we can go a step ahead as we can now mount the image.
Still some issues have to be worked out.

The poit is, why we cant mount system.img on ICS but we can on GB?
maybe someone can contact with sony t oask
im extracting the .sin to .img like always but its impossible to mount.. what are you using to extract the .sin to a .ext4?
BTW, thanks for the info, i've been trying to modify system.img since ICS appeared.
EDIT: of, ext4 can be extracte with flashtool ~.~
maybe we need to read something from system.partinfo

Yakandu said:
The poit is, why we cant mount system.img on ICS but we can on GB?
maybe someone can contact with sony t oask
im extracting the .sin to .img like always but its impossible to mount.. what are you using to extract the .sin to a .ext4?
BTW, thanks for the info, i've been trying to modify system.img since ICS appeared.
EDIT: of, ext4 can be extracte with flashtool ~.~
maybe we need to read something from system.partinfo
Click to expand...
Click to collapse
Yes Flashtool can extract image from system.sin.
partinfo is partition information used by loader in flashmode to identify where to flash image on phone. (Something like start nand address of system partition)

so, any ideas why ext4 cant be mounted? maybe its encrypted or something..

Sorry for double post, i found a solution
Flash the system through a .ftf with flashtools
Flash a custom kernel with recovery (or the nozomi recovery)
Backup nandroid
We get a system.ext4.tar ··· move it to your developement folder
Create a folder (mkdir system)
Enter nautilus with root acces
Extract system files to the created folder
Modify whatever you want
Make a flashable system.img with: "./mkuserimg.sh -s /system ./system.img ext4 ./temp 1024M"
AND ITS WORKING!

Yakandu said:
Sorry for double post, i found a solution
Flash the system through a .ftf with flashtools
Flash a custom kernel with recovery (or the nozomi recovery)
Backup nandroid
We get a system.ext4.tar ··· move it to your developement folder
Create a folder (mkdir system)
Enter nautilus with root acces
Extract system files to the created folder
Modify whatever you want
Make a flashable system.img with: "./mkuserimg.sh -s /system ./system.img ext4 ./temp 1024M"
AND ITS WORKING!
Click to expand...
Click to collapse
This solution is already known
But my goal is to be able to mod a system partition without having to flash it before. And more, understand why extracted system image cannot be mounted and how to work this out

oh, ok xD
i didnt know that solution, its new for me

Yakandu said:
Sorry for double post, i found a solution
Flash the system through a .ftf with flashtools
Flash a custom kernel with recovery (or the nozomi recovery)
Backup nandroid
We get a system.ext4.tar ··· move it to your developement folder
Create a folder (mkdir system)
Enter nautilus with root acces
Extract system files to the created folder
Modify whatever you want
Make a flashable system.img with: "./mkuserimg.sh -s /system ./system.img ext4 ./temp 1024M"
AND ITS WORKING!
Click to expand...
Click to collapse
Have you already tried flashing this img on your device? I have already tried this solution twice but didn't succeed (@Spectre51 that's why I haven't replied your PM yet). system.img was succesfully created but I got boot loop when I flashed it on my device.

Hi Androxyde,
I figured it out, basically we have to dig further in sin format as new ext4 sins skips part of the file. See my thread for more details.
PS: Thanks for flashtool, it's a great tool!
LeTama

letama said:
Hi Androxyde,
I figured it out, basically we have to dig further in sin format as new ext4 sins skips part of the file. See my thread for more details.
PS: Thanks for flashtool, it's a great tool!
LeTama
Click to expand...
Click to collapse
:good:

[REF] efrant's "Android for Galaxy Nexus" 101 & FAQs

The popularity of Nexus devices has increased significantly since the launch of the Nexus One in January 2010. Along with this popularity, forums such as xda-developers have also had an influx of new users, most of which are not developers, and are not well versed in the intricacies of Android.
After much thought (and some discussion on this thread), I’ve decided to create this thread as a compilation of FAQs, 101s, and “How-To’s” in the hopes that those coming to Android who want to learn will have another resource to help them learn. With that in mind, this thread is NOT meant to explain the quickest way to do things (you will NOT see toolkits or shortcuts discussed in this thread), nor is it meant to be a “fix-my-device” thread. It is created with for a purpose of learning, in order to expand users’ knowledge of Nexus devices and Android in general. See this post by kyphur for the general philosophy of this site, which I share.
I do not take myself to be an Android guru or developer. However, I do have a bit of knowledge to share. If you think things are missing or not accurate, I will be more than happy to add or revise anything. I will try to cover most of the basic topics related to Android, including drivers, ADB, fastboot, partitions, recoveries, bootloaders, root and reverting to stock. Again, I will not discuss toolkits, nor will I cover custom ROMs. Those have their own threads.
This will be an ongoing work-in-progress, as it takes considerable time to try and capture everything properly, and my time is limited. The order of the information will also change, as I haven't quite figured out the best way to present everything. (Currently there are some FAQs, including fastboot and ADB commands, followed by a list of reference and how-to threads.)
So, without further delay:
Frequently Asked Questions
What is Android?
Android is an open-source operating system for mobile devices. It is basically a java virtual machine running on a Linux-based kernel.
What is the Android SDK and do I need it?
SDK stands for "software development kit. Do you need it? If you are developing, then yes (but then you probably would be reading this thread now would you... ). If you are not developing, then no, you do NOT need to install it. It is just a waste of space. The only files you need (to interface with your PC) that comes from the SDK are the fastboot and adb files, and they can be found here for Windows, Linux, and MacOS.
Why do I need a driver for my Windows PC to recognize my device?
As with all hardware, Windows requires device drivers for it to be able to interface with the OS. Drivers are not required if you are using Linux or MacOS.
Where do I get the driver for my PC?
For previous Nexus devices (the Nexus One and Nexus S) the driver included in the Android SDK was the one needed. However, with the Galaxy Nexus, that driver no longer works. The driver is now provided by Samsung, and can be found from various locations. However, I recommend using this package by 1wayjonny. It works perfectly and, unlike most other packages, 1wayjonny’s repack does not install any crapware along with it. That said, it doesn’t include an .exe file, so it needs to be installed manually from the .inf file. If you do not now how to do that, see here for instructions. Note: If you are using Windows 8, you will need to do this before you can install the driver.
Why do I need to install the driver twice?
Nexus devices use two main interfaces (there are actually a few more, but I will cover them later) to communicate with a PC. These are ADB (Android debug bridge) and fastboot, both of which will be covered later. The fastboot interface requires the GNex to be booted in fastboot (i.e., bootloader) mode. Thus, in order to install the fastboot driver, you need to boot your GNex into the bootloader. The ADB interface requires an Android kernel to be booted, i.e., your device needs to be booted normally, or in recovery (covered later). Additionally, if your device is booted normally, you need to have USB Debugging set to enabled in settings (i.e., Settings->Developer options->USB debugging).
How do I boot my device into the bootloader (i.e., fastboot mode)?
Turn off your device, hold volume up and volume down, and press and hold the power button.
What is a command prompt?
A command prompt in Windows (or terminal in Linux/MacOS) is a command line window in which you can enter commands. To open a command prompt in Windows, you can hold the shift key and right click in the directory in which you want your command prompt open. Or, in a Windows Explorer window you can go to File-><name-of-window>->Open command window here.
What is a bootloader?
Without getting into too many technicalities, the bootloader is essentially the program that gets loaded first when starting your device, and it is responsible for booting the Android kernel. Think of the bootloader as the BIOS of a computer.
What does it mean if my bootloader is locked/unlocked?
Most (if not all) devices are shipped from the manufacturer with locked bootloaders. This is for security reasons. A locked bootloader does not allow easy flashing of images, which means that it is difficult to change or modify the operating system. Unlocking a bootloader (using fastboot) on a most Galaxy Nexus devices results in a complete loss of all personal data from the device. Having a locked or unlocked bootloader has no bearing on the functioning of the device. Unlocking it gives you more options to play around with the OS. Additionally, an unlocked bootloader means that you can easily root your device no matter what -- unlike most non-Nexus devices, if you lose root, it is trivial to get it back.
What is “root”?
Root essentially means that you have root (or superuser) access to the file system on Android. It is similar to being “administrator” on a Windows PC. It has nothing to do with your device or the bootloader, it has to do with the Android OS (i.e., you cannot “root” your device – you root the Andoid build that you are running). To have root, you need to be booted into the Android OS that you have rooted. If you are in fastboot mode, root is irrelevant.
How do I get “root”?
If you are booted into a custom recovery (recoveries will be covered later), root is enabled by default. If you want root while booted into Android, you will need to place two files on your system partition: an “su” binary which grants root access, and a superuser app that manages that access. The two that are available are ChainsDD’s Superuser and Chainfire’s SuperSU. Usually these files are packaged up in a zip file that is flashable using a custom recovery, but they can be flashed manually using ADB. Both of these methods will be described below.
If I unlock my bootloader, is that the same as root?
No, as was mentioned above, unlocking the bootloader allows you to (among a few other things) flash images easily to the device when not booted into the Android OS. Root allows you access to manipulate the files WITHIN the Android OS.
If I unlock my bootloader, does that mean that I have to root?
No.
If I unlock my bootloader, do I have to flash a custom ROM?
No.
Do I need to root to flash a ROM?
No.
What is a ROM?
A ROM is slang for an mobile OS build.
What are the different versions of Android, and is there a difference between say 4.2 and JOP40C?
Have a look at this link for an explanation of what (for example) JOP40C means, and what version of Android that is.
What is the difference between a stock ROM and a custom ROM?
A stock ROM is a ROM that is either built by Google (like any yakju/takju/mysid build) or built by Samsung (like all the yakju** variants and mysidpr) and is signed by Google’s (or Samsung’s) platform keys. Everything else is a custom ROM.
What is this AOSP I keep hearing about?
AOSP stands for Android Open Source Project, and is a repository for the source code for Android. You can build your own ROM from AOSP. Details can be found on http://source.android.com/ or here.
What is fastboot?
Fastboot can refer to three things: the actual interface between your PC and phone; the fastboot.exe file; or the “mode” of your device. For you to be able to use fastboot commands: your device has to be booted in fastboot mode, the fastboot driver for your PC needs to be installed, and the fastboot.exe file needs to be on your PC.
What are the fastboot commands?
The list of fastboot commands can be seen by typing “fastboot” (without the quotes) in a command prompt opened in the directory where you fastboot.exe file is located. See below.
Code:
fastboot
usage: fastboot [ <option> ] <command>
commands:
update <filename> reflash device from update.zip
flashall flash boot + recovery + system
flash <partition> [ <filename> ] write a file to a flash partition
erase <partition> erase a flash partition
format <partition> format a flash partition
getvar <variable> display a bootloader variable
boot <kernel> [ <ramdisk> ] download and boot kernel
flash:raw boot <kernel> [ <ramdisk> ] create bootimage and flash it
devices list all connected devices
continue continue with autoboot
reboot reboot device normally
reboot-bootloader reboot device into bootloader
help show this help message
options:
-w erase userdata and cache
-s <serial number> specify device serial number
-p <product> specify product name
-c <cmdline> override kernel commandline
-i <vendor id> specify a custom USB vendor id
-b <base_addr> specify a custom kernel base address
-n <page size> specify the nand page size. default: 2048
Along with these commands, there is an additional one: oem. For now, I will only cover the following commands: devices, flash, boot, erase, reboot, reboot-bootloader and oem.
These commands will work in fastboot mode, whether your bootloader is lock or unlocked:
oem: with a shipping bootloader (like what most of us have on our devices) there are two “oem” commands: “oem unlock” and “oem lock”. These commands are used to unlock and lock your bootloader, e.g., “fastboot oem unlock” will unlock your bootloader.
devices: this command checks to see if your device is properly connected to your PC in fastboot mode, e.g., “fastboot devices”
reboot: this command will reboot your device, e.g., “fastboot reboot”
reboot-bootloader: this command will reboot your device into fastboot mode, e.g., “fastboot reboot-bootloader”
These commands will only work in fastboot mode IFF your bootloader is unlocked:
flash: this command is used to flash images to partitions (partitions will be covered later) on your device. It cannot be used to “flash” individual files or .zips. For example, to flash the system partition, the command would be “fastboot flash system system.img”
boot: this command boots a kernel without flashing it to your device. For example, to boot an insecure kernel called “test.img”, the command would be “fastboot boot test.img”
erase: this command erases a specified partition. For example, to erase the cache partition, the command would be “fastboot erase cache”
The above mentioned commands are the basics for flashing your device. You should get familiar with them.
What is ADB?
ADB can refer to two things: the actual interface between your PC and phone, or the adb files (the .exe and two .dll files for Windows). For you to be able to use adb commands: the adb driver needs to be installed on your PC, the adb files need to be on your PC, and your device has to be booted either in recovery mode or booted normally into Android. Additionally, USB debugging needs to be enabled if booted into Android.
What are the ADB commands?
The list of ADB commands can be seen by typing “adb” (without the quotes) in a command prompt opened in the directory where your adb.exe file is located. See below.
Code:
Android Debug Bridge version 1.0.29
-d - directs command to the only connected USB device
returns an error if more than one USB device is present.
-e - directs command to the only running emulator.
returns an error if more than one emulator is running.
-s <serial number> - directs command to the USB device or emulator with
the given serial number. Overrides ANDROID_SERIAL
environment variable.
-p <product name or path> - simple product name like 'sooner', or
a relative/absolute path to a product
out directory like 'out/target/product/sooner'.
If -p is not specified, the ANDROID_PRODUCT_OUT
environment variable is used, which must
be an absolute path.
devices - list all connected devices
connect <host>[:<port>] - connect to a device via TCP/IP
Port 5555 is used by default if no port number is specified.
disconnect [<host>[:<port>]] - disconnect from a TCP/IP device.
Port 5555 is used by default if no port number is specified.
Using this command with no additional arguments
will disconnect from all connected TCP/IP devices.
device commands:
adb push <local> <remote> - copy file/dir to device
adb pull <remote> [<local>] - copy file/dir from device
adb sync [ <directory> ] - copy host->device only if changed
(-l means list but don't copy)
(see 'adb help all')
adb shell - run remote shell interactively
adb shell <command> - run remote shell command
adb emu <command> - run emulator console command
adb logcat [ <filter-spec> ] - View device log
adb forward <local> <remote> - forward socket connections
forward specs are one of:
tcp:<port>
localabstract:<unix domain socket name>
localreserved:<unix domain socket name>
localfilesystem:<unix domain socket name>
dev:<character device name>
jdwp:<process pid> (remote only)
adb jdwp - list PIDs of processes hosting a JDWP transport
adb install [-l] [-r] [-s] <file> - push this package file to the device and install it
('-l' means forward-lock the app)
('-r' means reinstall the app, keeping its data)
('-s' means install on SD card instead of internal storage)
adb uninstall [-k] <package> - remove this app package from the device
('-k' means keep the data and cache directories)
adb bugreport - return all information from the device
that should be included in a bug report.
adb backup [-f <file>] [-apk|-noapk] [-shared|-noshared] [-all] [-system|-nosystem] [<packages...>]
- write an archive of the device's data to <file>.
If no -f option is supplied then the data is written
to "backup.ab" in the current directory.
(-apk|-noapk enable/disable backup of the .apks themselves
in the archive; the default is noapk.)
(-shared|-noshared enable/disable backup of the device's
shared storage / SD card contents; the default is noshared.)
(-all means to back up all installed applications)
(-system|-nosystem toggles whether -all automatically includes
system applications; the default is to include system apps)
(<packages...> is the list of applications to be backed up. If
the -all or -shared flags are passed, then the package
list is optional. Applications explicitly given on the
command line will be included even if -nosystem would
ordinarily cause them to be omitted.)
adb restore <file> - restore device contents from the <file> backup archive
adb help - show this help message
adb version - show version num
scripting:
adb wait-for-device - block until device is online
adb start-server - ensure that there is a server running
adb kill-server - kill the server if it is running
adb get-state - prints: offline | bootloader | device
adb get-serialno - prints: <serial-number>
adb status-window - continuously print device status for a specified device
adb remount - remounts the /system partition on the device read-write
adb reboot [bootloader|recovery] - reboots the device, optionally into the bootloader or recovery program
adb reboot-bootloader - reboots the device into the bootloader
adb root - restarts the adbd daemon with root permissions
adb usb - restarts the adbd daemon listening on USB
adb tcpip <port> - restarts the adbd daemon listening on TCP on the specified port
networking:
adb ppp <tty> [parameters] - Run PPP over USB.
Note: you should not automatically start a PPP connection.
<tty> refers to the tty for PPP stream. Eg. dev:/dev/omap_csmi_tty1
[parameters] - Eg. defaultroute debug dump local notty usepeerdns
adb sync notes: adb sync [ <directory> ]
<localdir> can be interpreted in several ways:
- If <directory> is not specified, both /system and /data partitions will be updated.
- If it is "system" or "data", only the corresponding partition
is updated.
copkay has written up a great guide on the use of the “backup” and “restore” commands in this thread, so I will not cover those commands here.
For now, I will only cover the following commands: devices, reboot, reboot bootloader, push, pull and shell.
devices: this command checks to see if your device is properly connected to your PC in ADB mode, e.g., “adb devices”
reboot: this command will reboot your device, e.g., “adb reboot”
reboot-bootloader: this command will reboot your device into fastboot mode, e.g., “adb reboot bootloader”
push: this command copies a file (or directory) to your device from your PC. For example, say you wanted to copy to your /sdcard folder on your device a file called junk.jpg, which is stored on your PC in c:\. The command would be “adb push c:\junk.jpg /sdcard/” (assuming the folder is mounted – to be covered later). Petrovski80 has added more details on copying files to your device in his thread here.
pull: this command copies a file (or directory) to your PC from your device. For example, say you wanted to copy to your c:\ directory on your PC a file called junk.jpg, which is stored in the /sdcard folder on your device. The command would be “adb pull /sdcard/junk.jpg c:\” (assuming the folder is mounted – to be covered later).
shell: this command opens a “shell” to your device so you can issue commands directly to the Android OS. The command is “adb shell”. Your prompt will change to “$” which means that you are now issuing commands to Android, not to your PC. (At some point, I will try to put together a list of commonly used commands, but for anyone that has used Linux, they are essentially the same.)
What are the partitions on a Galaxy Nexus?
A Galaxy Nexus has the following 13 partitions:
boot <-- this is where the kernel and ramdisk are stored
cache <-- this is, well, the cache, i.e., a temporary storage area
dgs <-- I have no idea what this is for
efs <-- this is where your IMEI number is stored, among other things
metadata <-- I have no idea what this is for
misc <-- I have no idea what this is for
param <-- this is where the lock state of the bootloader is stored
radio <-- this is where the radio (i.e., baseband) is stored
recovery <-- this is where the recovery is stored
sbl <-- this is part of the bootloader, and is loaded by the xloader. This is what provides the odin and fastboot interfaces.
system <-- this is where the Android OS resides
userdata <-- this is where your data, including /sdcard resides
xloader <-- this is part of the bootloader, and loads up first.
See this thread or this one for the offsets and sizes.
What does mounting mean?
In order for a device to have access to files, the partition on which those files reside needs to be “mounted”. If you are in recovery, you can easily do this by going to the mounts menu and mounting the appropriate partition. If you are booted in Android, you will need to mount the partition yourself. The /sdcard folder is already mounted by default, however.
How do I mount the system partition?
In recovery: go to the mount menu and mount /system
In Android, on your device: you need root, and a file explorer with root access
In Android, connected via ADB (root required): you need to type the following command in a command prompt:
adb shell
su
mount -o remount,rw -t ext4 /dev/block/mmcblk0p1 /system
To explain this a bit:
-o remount,rw <== this remounts a partition that is already mounted (as read-only), as read-write
-t ext4 <== this specifies to mount it as ext4
/dev/block/mmcblk0p1 <== this is the system partition
/system <== this is what you are mounting it as
What is recovery?
Recovery is like a mini OS, which allows you to perform various functions, usually related to flashing files to your device, or updating files, or backing things up, etc. The stock image has a recovery included, but its functionality is very limited. There are a number of custom recoveries available, but the two most popular for the Galaxy Nexus are CWM and TWRP. There are various versions of each. More details to come in this section.
I see an Android lying on its back when I boot into recovery. Why?
What you see is the main screen of the Galaxy Nexus stock recovery. To access the menu, you need to push and hold power and press volume up.
I just flashed CWM, but every time I try to boot into CWM, I keep seeing the stock recovery. Why?
If you updated your Android build using an OTA update file (either manually or over-the-air), the update placed two files on your device that re-flash the stock recovery every time you reboot your device. These two files are:
/system/etc/install-recovery.sh <== this is the script that installs the patch file
/system/recovery-from-boot.p <== this is the patch
You have to rename (or delete) one or both of them, then re-flash your custom recovery. Now it will stick.
What is an insecure boot image?
An insecure boot image is one that has root enabled for the shell user (i.e, ADB) by default on boot. This means that if you have booted or flashed an insecure image, when you connect your device to a computer, and open a shell via ADB, you will be userid 0 (or root) without having to "request" root access via the su binary. This makes somethings easier -- for example, you can now use the "remount" command in ADB to mount /system without having to type the full mount command in a shell. (More to add later.)
How do I root?
As was mentioned earlier, you need to place the su binary and the superuser app into the right spots on your device. In order to do this, you need to already have root access. There are two ways: flash a root package in recovery (instructions here), or manually place the files in the appropriate spots (I will add instructions on how to do this at a later time).

Useful Galaxy Nexus Guides and Reference Threads
Useful Galaxy Nexus Guides and Reference Threads
Galaxy Nexus drivers: http://forum.xda-developers.com/showthread.php?t=1379875
Jubakuba Galaxy Nexus guide: http://forum.xda-developers.com/showthread.php?t=1529058
Difference between yakju/takju and the other builds: http://forum.xda-developers.com/showthread.php?t=1728555
How to back up your device using ADB – no root needed: http://forum.xda-developers.com/showthread.php?t=1420351
How to copy files to/from your device using ADB: http://forum.xda-developers.com/showthread.php?t=1869380
How to return your device to Google’s stock images: http://forum.xda-developers.com/showthread.php?t=1626895
How to root: http://forum.xda-developers.com/showpost.php?p=26328017&postcount=123
How to unlock the bootloader WITHOUT root and WITHOUT wiping data: http://forum.xda-developers.com/showthread.php?t=2016628
List of all OTA update files and links, including instructions on how to update: http://forum.xda-developers.com/showthread.php?t=1419170
List of all GSM radios: http://forum.xda-developers.com/showpost.php?p=20569003
List of most GSM RILs: http://forum.xda-developers.com/showpost.php?p=27441945
List of all bootloaders: http://forum.xda-developers.com/showthread.php?t=1587498
List of all toro (i.e., Verizon) radios: http://forum.xda-developers.com/showthread.php?t=1890585
How to unlock your bootloader without wiping data and without being connected to a PC – root required: http://forum.xda-developers.com/showthread.php?t=1731993
How to root without unlocking your bootloader – for builds from 4.0.1 to 4.1.1, : http://forum.xda-developers.com/showthread.php?p=31751966
How to root without unlocking your bootloader – for 4.0.1 and 4.0.2 builds only: http://forum.xda-developers.com/showthread.php?t=1531865
CWM recovery (latest for maguro, toro, toroplus): http://www.clockworkmod.com/rommanager/
CWM recovery (5.5.0.2 for maguro): http://forum.xda-developers.com/showthread.php?t=1357642
CWM recovery (5.5.0.4 for toro): http://forum.xda-developers.com/showthread.php?t=1392336
TWRP recovery (latest for maguro, toro, toroplus): http://forum.xda-developers.com/showthread.php?t=1592689
Edify scripting: How to create recovery-flashable zips: http://forum.xda-developers.com/showthread.php?p=29735133
Odin: How to flash your device if you cannot get into fastboot mode: http://forum.xda-developers.com/showthread.php?t=1586807
OMAP_Flash: How to flash your device if you cannot get into fastboot mode and you cannot get into download mode: http://forum.xda-developers.com/showthread.php?t=1760787
How to compile your own ROM from source: http://forum.xda-developers.com/showthread.php?t=1386615
How to remove a carrier SIM lock (proper method): http://forum.xda-developers.com/showthread.php?t=1606982
How to remove a carrier SIM lock (easy but you will lose you IMEI): http://forum.xda-developers.com/showthread.php?t=1548210
Information on bootloader security: http://forum.xda-developers.com/showthread.php?t=1898664
How to recovery deleted files: http://forum.xda-developers.com/showthread.php?p=34185439
How to nandroid directly to your computer: http://forum.xda-developers.com/showthread.php?t=1818321

reserved 2

reserved 3

purely awesome thread.

Added to bookmarks!
Good!:good::good:

Thanks man, voted 5stars on this. I hope this gets sticky.
:good:

Bravo!
Sent from my Galaxy Nexus using xda premium

great stuff, wish i had such summary when jumped into android!
Sent from my Galaxy Nexus using xda app-developers app

Good work man! I was thinking about doing something similar this weekend but this is much better.
Edit: This needs to be stickied ASAP
Sent from my Galaxy Nexus using xda premium

El Daddy said:
Good work man! I was thinking about doing something similar this weekend but this is much better.
Sent from my Galaxy Nexus using xda premium
Click to expand...
Click to collapse
Thanks (to all).
It is far from complete though, and it will be an on-going work-in-progress. It's not as easy to write up general info as it is to write up a step-by-step guide...

Awesome post. This should see a few overwhelmed users right
Top work!
Sent from my Galaxy Nexus using xda app-developers app

Incredibly useful and much needed thread, really well done, efrant. Information desk and referral center for new users. Wish it was here when I came onboard. You should make a "N00b Lighthouse" graphic for it. I think this will help reduce and untangle a lot of the repetitive new-user threads.

Awesome source of information. This needs a sticky ASAP.
Sent from my Galaxy Nexus using xda premium

this is one of the best guides i've seen. great work efrant. i hope this would be stickied for all

toro partitions
Great thread, efrant. Thanks for the effort. I'd love to see this stickied.
You mentioned toro/toroplus having a "radio-cdma" partition. I can't find it; perhaps it is a virtual partition that recovery and the fastboot know about that does not exist separately in storage. Perhaps it's hidden inside another one.
I'd like to contribute the partition list from my "toro" (Verizon Galaxy Nexus) in case is is useful. In addition to the named partitions listed in the OP, there 5 more unnamed ones. I don't know yet what they are used for.
Code:
mtdblock0 - (don't know)
mmcblk0 - (don't know but it looks big; like the entire eMMC)
mmcblk0p1 - xloader
mmcblk0p2 - sbl
mmcblk0p3 - efs
mmcblk0p4 - param
mmcblk0p5 - misc
mmcblk0p6 - dgs
mmcblk0p7 - boot
mmcblk0p8 - recovery
mmcblk0p9 - radio
mmcblk0p10 - system
mmcblk0p11 - cache
mmcblk0p12 - userdata
mmcblk0p13 - metadata
mmcblk0boot1 - (don't know - blank on Galaxy Nexus, but other devices use this)
mmcblk0boot0 - (don't know - blank on Galaxy Nexus, but other devices use this)
I would love to learn more about the bootchain, as I'm sure several of our unknown partitions are involved.

Great job on this efrant, thread has been stickied.
We have too many stickies in general as is so I just added a redirect for it in Q&A.

Damn man. This is fantastic.
Thanks for taking the time!

segv11 said:
Great thread, efrant. Thanks for the effort. I'd love to see this stickied.
You mentioned toro/toroplus having a "radio-cdma" partition. I can't find it; perhaps it is a virtual partition that recovery and the fastboot know about that does not exist separately in storage. Perhaps it's hidden inside another one.
I'd like to contribute the partition list from my "toro" (Verizon Galaxy Nexus) in case is is useful. In addition to the named partitions listed in the OP, there 5 more unnamed ones. I don't know yet what they are used for.
Code:
mtdblock0 - (don't know)
mmcblk0 - (don't know but it looks big; like the entire eMMC)
mmcblk0p1 - xloader
mmcblk0p2 - sbl
mmcblk0p3 - efs
mmcblk0p4 - param
mmcblk0p5 - misc
mmcblk0p6 - dgs
mmcblk0p7 - boot
mmcblk0p8 - recovery
mmcblk0p9 - radio
mmcblk0p10 - system
mmcblk0p11 - cache
mmcblk0p12 - userdata
mmcblk0p13 - metadata
mmcblk0boot1 - (don't know - blank on Galaxy Nexus, but other devices use this)
mmcblk0boot0 - (don't know - blank on Galaxy Nexus, but other devices use this)
I would love to learn more about the bootchain, as I'm sure several of our unknown partitions are involved.
Click to expand...
Click to collapse
Thanks for the correction. Post edited. I wasn't entirely sure (as I don't have a toro or toroplus devices). Based on what I've read, I'm gathering that the LTE radio likely resides on the radio partition, along with the 3G radio.
And yes, I'm pretty sure you are correct: the mmcblk0 is just the entire NAND. Not sure what mmcblk0boot0, mmcblk0boot1 and mtdblock0 are.
I would also like to know more about the boot chain. I will try to do some research as time permits. From what I've read so far (and most of it is from AdamOutler -- see this thread), there is a chip that is not flashable which contains the intial boot program, which then loads the xloader, which in turn loads the sbl (which provides the odin and fastboot interfaces), which then loads the kernel.

..great work efrant, as always.
If I had a dollar for every time this thread gets a link reference in answering questions...
Sent from my Galaxy Nexus using xda premium

[Guide][Fix] Motorola Defy Mini XT320/XT321 Burnt NAND

Hello Defy Mini Users, I'm going to write a tutorial on how to fix a burnt NAND.
My overclock became unstable and I had bad blocks everywhere so I decided to recover my NAND. @cute_prince method fixed by phone.
@MauroSZ @Bernd.Defy @wilberfish @conrad0
Thanks to cute_prince tutorial for HTC Explorer NAND recovery. I have just adapted to Defy Mini XT320/XT321.
Now in cmd type in these commands:
Code:
adb reboot bootloader
Code:
fastboot boot twrp.img
Code:
adb shell mount -a
Code:
adb push flash_erase /system/xbin
Code:
adb shell cd /system/xbin
Code:
adb shell chmod 755 flash_erase
Code:
adb shell ./flash_erase -N /dev/mtd/mtd9 0 0
Code:
adb shell ./flash_erase -N /dev/mtd/mtd11 0 0
Code:
adb shell ./flash_erase -N /dev/mtd/mtd12 0 0
Code:
adb reboot bootloader
Code:
fastboot erase userdata
Code:
fastboot erase cache
Code:
fastboot erase system
Now flash back your SBF via RSD-Lite.

on this step "adb shell chmod 755 flash_erase"
I get chmod: flash_erase: no such file or directory.
What am i missing?

@rootdefyxt320, Theoretical question:
Any idea what happens recovering nandroid instead flashing a SBF via RSD Lite ?

MauroSZ said:
@rootdefyxt320, Theoretical question:
Any idea what happens recovering nandroid instead flashing a SBF via RSD Lite ?
Click to expand...
Click to collapse
You restore a nandroid backup that has a corrupted NAND, which is what you don't want. Flashing an SBF doesn't give a corrupted NAND as it is fresh. But you must flash_erase before you flash an SBF otherwise you will still have a burnt NAND.

wilberfish said:
on this step "adb shell chmod 755 flash_erase"
I get chmod: flash_erase: no such file or directory.
What am i missing?
Click to expand...
Click to collapse
Did you push flash_erase to /system/xbin? This fixes the missing file issue. Otherwise you can mount /system manually in TWRP.

Yes, fixed it. Silly mistake.
Thanks it works brilliantly.

wilberfish said:
Yes, fixed it. Silly mistake.
Thanks it works brilliantly.
Click to expand...
Click to collapse
So your NAND is fixed now?

rootdefyxt320 said:
So your NAND is fixed now?
Click to expand...
Click to collapse
Is correct supposing the android automatically avoids bad blocks using others normal blocks instead ? Is journaling correlated ? If true, does make sense flash a sbf first and restore a nandroid just after getting fastboot ? Or do you recommend anorher backup way like titanium ? Or maybe a mixed way using a old nandroid made when the nand was not burnt and Titanium just after to make the device state more recent ?
Is there a easy and quick test to know if the nand is burnt ?
Sent by Smartphone Using Tapatalk 2

rootdefyxt320 said:
So your NAND is fixed now?
Click to expand...
Click to collapse
Yes seems so. Didn't have time to check but after clean install and updates back to 73mb free
Sent from my HTC Desire C using xda app-developers app
---------- Post added at 09:24 PM ---------- Previous post was at 09:17 PM ----------
Originally Posted by rootdefyxt320
So your NAND is fixed now?
Click to expand...
Click to collapse
Is correct supposing the android automatically avoids bad blocks using others normal blocks instead ? Is journaling correlated ? If true, does make sense flash a sbf first and restore a nandroid just after getting fastboot ? Or do you recommend anorher backup way like titanium ? Or maybe a mixed way using a old nandroid made when the nand was not burnt and Titanium just after to make the device state more recent ?
Is there a easy and quick test to know if the nand is burnt ?
Sent by Smartphone Using Tapatalk 2
Click to expand...
Click to collapse
adb shell dmesg will give you a report, scroll down and you will see if you have bad blocks.
Yes it avoids bad blocks automatically. As for backup I have no idea, sorry.

MauroSZ said:
Is correct supposing the android automatically avoids bad blocks using others normal blocks instead ? Is journaling correlated ? If true, does make sense flash a sbf first and restore a nandroid just after getting fastboot ? Or do you recommend anorher backup way like titanium ? Or maybe a mixed way using a old nandroid made when the nand was not burnt and Titanium just after to make the device state more recent ?
Is there a easy and quick test to know if the nand is burnt ?
Sent by Smartphone Using Tapatalk 2
Click to expand...
Click to collapse
The problem with nandroid backups is when you back it up. I backup my phone before overclocking so I can restore my NANDROID backup. You can restore your nandroid if you backup before overclocking. Don't restore your NANDROID if you backed it up after overclocking. Basically YAFFS2 filesystem uses 'blocks' to store the data. It won't write to the 'bad blocks' so you lose storage. Basically a YAFFS2 NANDROID backup also backups the bad blocks which is what you don't want. You can read more about YAFFS Filesystem here: http://en.wikipedia.org/wiki/YAFFS

@rootdefyxt320 thanks for the link, but if i backup just after a minute i overclocked, i am supposed it will not sufficient time to burn the nand, right ? And i can avoid all a process to overclock again if i have to recovery my nand.
It seems the CWM backup creates a continuous nand image containing good and bad blocks. The android skips bad blocks writing data. Then i'm supposed backup apps as Titanium do a good job in this case because (i am also supposed) they don't work with image.
Sent by Smartphone Using Tapatalk 2

MauroSZ said:
@rootdefyxt320 thanks for the link, but if i backup just after a minute i overclocked, i am supposed it will not sufficient time to burn the nand, right ? And i can avoid all a process to overclock again if i have to recovery my nand.
It seems the CWM backup creates a continuous nand image containing good and bad blocks. The android skips bad blocks writing data. Then i'm supposed backup apps as Titanium do a good job in this case because (i am also supposed) they don't work with image.
Sent by Smartphone Using Tapatalk 2
Click to expand...
Click to collapse
Yeah, it won't have that much effect. The effect happens after a couple of weeks of overclocking.

After adb push flash_erase /system/xbin the commands should use full path, mine didn't work with CD.
Also shell commands didn't work first time, maybe because touched some buttons on TWRP screen.
Code:
Code:
adb reboot bootloader
fastboot boot twrp.img
adb shell mount -a
adb push flash_erase /system/xbin
adb shell cd /system/xbin
adb shell chmod 755 /system/xbin/flash_erase
adb shell /system/xbin/flash_erase -N /dev/mtd/mtd9 0 0
adb shell /system/xbin/flash_erase -N /dev/mtd/mtd11 0 0
adb shell /system/xbin/flash_erase -N /dev/mtd/mtd12 0 0
adb reboot bootloader
fastboot erase userdata
fastboot erase cache
fastboot erase system

[GUIDE]Failed OTA update installation with root/TWRP

As this questions pops up every single month, I'm putting this information into a separate topic. It is for everyone who followed the Magisk A/B OTA update guide and OTA update still fails to install. https://github.com/topjohnwu/Magisk/blob/master/docs/tutorials.md
The usual culprit is TWRP - if you booted into TWRP and allowed system modifications (even once), OTA update won't install. The second common suspect is one of apps with root access, which might have tampered the system partition (AdAway or some other old apps).
Use these commands as root from ADB shell or terminal emulator on the phone and look for mount count (has to be 0) and last mount time (must be n/a). Anything else means that system partition has been mounted as R/W and you MUST reflash stock system.img manually.
Code:
[I][B]tune2fs -l /dev/block/sda12
tune2fs -l /dev/block/sda13[/B][/I]
sda12 is system_a, sda13 is system_b
Example of untouched system:
Code:
Filesystem created: Wed Dec 31 17:00:00 2008
Last mount time: n/a
Last write time: Wed Dec 31 17:00:00 2008
Mount count: 0
Maximum mount count: -1
Last checked: Wed Dec 31 17:00:00 2008
How to fix - reflash system.img with the same version as currently running (or reflash everything with newer ROM):
Option #1
- download full OTA zip (not the incremental one, size must be above 1gb)
- and this Windows tool https://androidfilehost.com/?fid=818070582850510260
- extract both and put payload.bin into payload_input folder. Then run payload_dumper.exe. Once it completes the job, you'll find all images which can be flashed via fastboot.
- flash system.img to the active partition
- install OTA update
Option #2
- set A as active partition
- download, extract and run flash_all_except_data_storage.bat from stock Fastboot ROM
- root with Magisk patched boot.img and apply OTA with the usual Magisk A/B OTA procedure
Before flashing, backup your important data, one can be never sure enough.

flash_all_except_storage.bat = flash_all_except_data_storage.bat

I have a few questions about this method of yours.
1) I downloaded the fastboot rom from this thread but I can't find the payload.bin mentioned in the first method. Did I download the right thing? All I can see are *.img files and system.img is there too. Can I flash that one?
2) I have both TWRP and magisk installed currently. Will I lose them if I follow your method? How should I go if I wanted to keep them?
3) Of course you advice us to make a backup beforehand. Can you tell me or link me a guide about how to backup and restore properly with the new A/B partion in the way?
I'm sorry for asking this much, but all the guides I'm following are either confusing or with conflicting info.
Thank you for the help, I just can't wrap my head around this dual partion thing :s

SirAugustin said:
I have a few questions about this method of yours.
1) I downloaded the fastboot rom from this thread but I can't find the payload.bin mentioned in the first method. Did I download the right thing? All I can see are *.img files and system.img is there too. Can I flash that one?
2) I have both TWRP and magisk installed currently. Will I lose them if I follow your method? How should I go if I wanted to keep them?
3) Of course you advice us to make a backup beforehand. Can you tell me or link me a guide about how to backup and restore properly with the new A/B partion in the way?
I'm sorry for asking this much, but all the guides I'm following are either confusing or with conflicting info.
Thank you for the help, I just can't wrap my head around this dual partion thing :s
Click to expand...
Click to collapse
1. Fastboot ROM can be used straight away (Option #2).
2. Well, the point of this guide is to restore phone to stock images, so you can install OTA update. TWRP can't be kept. You can flash Magisk without TWRP though.
3. Titanium backup pro is my #1 backup tool for years, except very few exceptions it can backup and restore all apps and their settings. Data partition is only one, so you might have luck using TWRP backup - I haven't tried it.

Thank you kindly for all the info. These days I will try the method you described. ?

_mysiak_ said:
As this questions pops up every single month, I'm putting this information into a separate topic. It is for everyone who followed the Magisk A/B OTA update guide and OTA update still fails to install. https://github.com/topjohnwu/Magisk/blob/master/docs/tutorials.md
The usual culprit is TWRP - if you booted into TWRP and allowed system modifications (even once), OTA update won't install. The second common suspect is one of apps with root access, which might have tampered the system partition (AdAway or some other old apps).
Use these commands as root from ADB shell or terminal emulator on the phone and look for mount count (has to be 0) and last mount time (must be n/a). Anything else means that system partition has been mounted as R/W and you MUST reflash stock system.img manually.
Code:
[I][B]tune2fs -l /dev/block/sda12
tune2fs -l /dev/block/sda13[/B][/I]
sda12 is system_a, sda13 is system_b
Example of untouched system:
Code:
Filesystem created: Wed Dec 31 17:00:00 2008
Last mount time: n/a
Last write time: Wed Dec 31 17:00:00 2008
Mount count: 0
Maximum mount count: -1
Last checked: Wed Dec 31 17:00:00 2008
How to fix - reflash system.img with the same version as currently running (or reflash everything with newer ROM):
Option #1
- download full OTA zip (not the incremental one, size must be above 1gb)
- and this Windows tool https://androidfilehost.com/?fid=818070582850510260
- extract both and put payload.bin into payload_input folder. Then run payload_dumper.exe. Once it completes the job, you'll find all images which can be flashed via fastboot.
- flash system.img to the active partition
- install OTA update
Option #2
- set A as active partition
- download, extract and run flash_all_except_data_storage.bat from stock Fastboot ROM
- root with Magisk patched boot.img and apply OTA with the usual Magisk A/B OTA procedure
Before flashing, backup your important data, one can be never sure enough.
Click to expand...
Click to collapse
I tried method 1, OTA installation still shows Error message
What next?

oseraphaels said:
I tried method 1, OTA installation still shows Error message
What next?
Click to expand...
Click to collapse
If you are running custom kernel, flash the stock boot.img to boot partition as well.

oseraphaels said:
I tried method 1, OTA installation still shows Error message
What next?
Click to expand...
Click to collapse
Was your system partition mounted as RW in the first place? Is it still untouched? Some apps with root access can still mount it as RW, even if you reflash system.img.

Frank.G said:
If you are running custom kernel, flash the stock boot.img to boot partition as well.
Click to expand...
Click to collapse
I have stock boot img running, still ota install failed
---------- Post added at 10:25 AM ---------- Previous post was at 10:22 AM ----------
_mysiak_ said:
Was your system partition mounted as RW in the first place? Is it still untouched? Some apps with root access can still mount it as RW, even if you reflash system.img.
Click to expand...
Click to collapse
I fastboot flash_all.bat , I think this should mount all ROM segments, including system partitions

I fast boot flashed the latest ROM v11.0.15 and it works perfectly.
_mysiak_ said:
Was your system partition mounted as RW in the first place? Is it still untouched? Some apps with root access can still mount it as RW, even if you reflash system.img.
Click to expand...
Click to collapse
I can't find any apps that may be mounting system partition.
Is there a way to find out?

oseraphaels said:
I can't find any apps that may be mounting system partition.
Is there a way to find out?
Click to expand...
Click to collapse
Yes, compare the last mount timestamp and Magisk log. You will see which app used root access at that time.

oseraphaels said:
As this questions pops up every single month, I'm putting this information into a separate topic. It is for everyone who followed the Magisk A/B OTA update guide and OTA update still fails to install. https://github.com/topjohnwu/Magisk/blob/master/docs/tutorials.md
The usual culprit is TWRP - if you booted into TWRP and allowed system modifications (even once), OTA update won't install. The second common suspect is one of apps with root access, which might have tampered the system partition (AdAway or some other old apps).
Use these commands as root from ADB shell or terminal emulator on the phone and look for mount count (has to be 0) and last mount time (must be n/a). Anything else means that system partition has been mounted as R/W and you MUST reflash stock system.img manually.
sda12 is system_a, sda13 is system_b
Example of untouched system:
I tried method 1, OTA installation still shows Error message
What next?
Click to expand...
Click to collapse
Flash ota ROM in recovery

Rajendran Rasa said:
Flash ota ROM in recovery
Click to expand...
Click to collapse
Thank you very much
I fastboot flashed the latest ROM and my device works perfectly

Hi,
I have similar issue. My current version is V11.0.1.0.QFQEUXM. The system update show can't install update.
I get the stock version of V11.0.1.0.QFQEUXM fastboot room, and get the system.img. Then I flash it into my current active slot - b. After reboot, I still get can't install update.
The specific error is W update_engine: [0615/084826.432657:WARNING:mount_history.cc(66)] Device was remounted R/W 1 times. Last remount happened on 2020-05-15 10:30:34.000 UTC.
The remount is cause by TWRP.
Is there other suggestion?
Flash ota ROM in recovery
Click to expand...
Click to collapse
Tried to sideload V11.0.2.0.QFQEUXM OTA.zip, but error also.
Thanks.

JackVoo said:
Hi,
I have similar issue. My current version is V11.0.1.0.QFQEUXM. The system update show can't install update.
I get the stock version of V11.0.1.0.QFQEUXM fastboot room, and get the system.img. Then I flash it into my current active slot - b. After reboot, I still get can't install update.
The specific error is W update_engine: [0615/084826.432657:WARNING:mount_history.cc(66)] Device was remounted R/W 1 times. Last remount happened on 2020-05-15 10:30:34.000 UTC.
The remount is cause by TWRP.
Is there other suggestion?
Tried to sideload V11.0.2.0.QFQEUXM OTA.zip, but error also.
Thanks.
Click to expand...
Click to collapse
You've found the culprit already.. Do NOT use TWRP to flash images, it must be done via fastboot.

_mysiak_ said:
You've found the culprit already.. Do NOT use TWRP to flash images, it must be done via fastboot.
Click to expand...
Click to collapse
Hi, the remount is at 15-May. Which I try to fix this issue.
I use fastboot to flash the system.img, but it still mentioned about "remount R/W".
After that, I boot into stock recovery and sideload the OTA.zip, still fail
Thanks

JackVoo said:
Hi, the remount is at 15-May. Which I try to fix this issue.
I use fastboot to flash the system.img, but it still mentioned about "remount R/W".
After that, I boot into stock recovery and sideload the OTA.zip, still fail
Thanks
Click to expand...
Click to collapse
You probably forgot to flash something (or used incorrect image). Just download the latest fastboot image, switch to slot A and flash it all (except storage).

Try flashing with V11.0.1.0.QFQEUXM boot.img and system.img at slot A and B, still couldn't update.
Will try to flash all with the V11.0.2.0.QFQEUXM.
Update status:
I finally solve this issue.
I flash the new fastboot ROM into slot A, my current active is slot B.
Thanks for help.

help please
doing these steps will erase my data like factory reset?
if yes, then how can i install ota without losinig any data

_mysiak_ said:
As this questions pops up every single month, I'm putting this information into a separate topic. It is for everyone who followed the Magisk A/B OTA update guide and OTA update still fails to install. https://github.com/topjohnwu/Magisk/blob/master/docs/tutorials.md
The usual culprit is TWRP - if you booted into TWRP and allowed system modifications (even once), OTA update won't install. The second common suspect is one of apps with root access, which might have tampered the system partition (AdAway or some other old apps).
Use these commands as root from ADB shell or terminal emulator on the phone and look for mount count (has to be 0) and last mount time (must be n/a). Anything else means that system partition has been mounted as R/W and you MUST reflash stock system.img manually.
Code:
[I][B]tune2fs -l /dev/block/sda12
tune2fs -l /dev/block/sda13[/B][/I]
sda12 is system_a, sda13 is system_b
Example of untouched system:
Code:
Filesystem created: Wed Dec 31 17:00:00 2008
Last mount time: n/a
Last write time: Wed Dec 31 17:00:00 2008
Mount count: 0
Maximum mount count: -1
Last checked: Wed Dec 31 17:00:00 2008
How to fix - reflash system.img with the same version as currently running (or reflash everything with newer ROM):
Option #1
- download full OTA zip (not the incremental one, size must be above 1gb)
- and this Windows tool https://androidfilehost.com/?fid=818070582850510260
- extract both and put payload.bin into payload_input folder. Then run payload_dumper.exe. Once it completes the job, you'll find all images which can be flashed via fastboot.
- flash system.img to the active partition
- install OTA update
Option #2
- set A as active partition
- download, extract and run flash_all_except_data_storage.bat from stock Fastboot ROM
- root with Magisk patched boot.img and apply OTA with the usual Magisk A/B OTA procedure
Before flashing, backup your important data, one can be never sure enough.
Click to expand...
Click to collapse
Thanks for the post.
When i ran flash system.img is says partition unknown!

[Fixed] FireTV Stick 2nd Gen (tank) stuck on logo. Potentially broken file system/partitions. (Unlocked + TWRP available)

Hey folks! I unlocked my FireTV stick and was able to install TWRP following the amazing guide by @k4y0z (https://forum.xda-developers.com/t/unlock-root-twrp-unbrick-fire-tv-stick-2nd-gen-tank.3907002/).
I can boot into TWRP just OK.
I am using adb shell to issue TWRP commands. (I don't have an OTG cable with power input).
I began by flashing stock ROMs by @0815hoffi from here (https://forum.xda-developers.com/t/...-7-ota-zip-launcher-replacement-root.4155489/).
Then I tried installing pre-rooted images by @rbox (https://forum.xda-developers.com/t/fire-tv-stick-2-tank-prerooted-stock-images-5-2-7-3_r1.3912271/) along with magisk.
Here are the general steps I followed while flashing these images :
1. wiping everything. I suspect my first issue here :
Code:
$ adb shell
$ twrp wipe cache
$ twrp wipe data
$ twrp wipe dalvik
$ twrp wipe /system
~ # twrp wipe cache
Formatting Cache using make_ext4fs...
Failed to mount '/cache' (No such device)
Done processing script file
Click to expand...
Click to collapse
~ # twrp wipe /system
Formatting System using make_ext4fs...
Failed to mount '/system' (No such device)
Done processing script file
Click to expand...
Click to collapse
~ # mount /cache
mount: mounting /dev/block/mmcblk0p12 on /cache failed: No such device
Click to expand...
Click to collapse
~ # stat /dev/block/mmcblk0p12
File: '/dev/block/mmcblk0p12'
Size: 0 Blocks: 0 IO Block: 4096 block special file
Device: ch/12d Inode: 5332 Links: 1 Device type: b3,c
Access: (0600/brw-------) Uid: ( 0/ root) Gid: ( 0/ root)
__bionic_open_tzdata: couldn't find any tzdata when looking for localtime!
__bionic_open_tzdata: couldn't find any tzdata when looking for GMT!
__bionic_open_tzdata: couldn't find any tzdata when looking for posixrules!
Access: 2010-01-01 00:17:58.000000000
Modify: 2010-01-01 00:17:57.000000000
Change: 2010-01-01 00:17:57.000000000
Click to expand...
Click to collapse
2. push images to /sdcard
Code:
$ adb push update-kindle-full_tank-288.6.6.4_user_664657620.bin /sdcard/firm.zip
update-kindle-full_tank-288.6.6.4_user... 6.1 MB/s (532252995 bytes in 83.009s)
3. Install image
adb shell
~ # twrp install /sdcard/firm.zip
Installing zip file '/sdcard/firm.zip'
Checking for Digest file...
Skipping Digest check: no Digest file found
[amonet] Remove boot patch...
[amonet] OK
Patching system image unconditionally...
Copying preloader_prod.img to boot partition 0 for secure device...
script succeeded: result was [][amonet] Install boot patch...
[amonet] OK
[amonet] Install recovery patch...
[amonet] ALREADY_INSTALLED
Done processing script file
Click to expand...
Click to collapse
4. `adb shell reboot`
They all install just OK. But in all cases, every time I do `reboot` in `adb shell` after `adb install` commands, it boots and gets stuck on 'fireTV Stick' logo.
At first I thought maybe it takes time to boot for first time, but I let it go for as long as half an hour and still no good.
I tried wiping cache and dalvik before rebooting too, no avail (had same could not mount /cache prompt).
I am pretty sure I am doing something stupid, I'd really appreciate any help. I'll be happy if I get it back to a working state, I do not really need root. This all started because the stick went into bootloop outta nowhere. My initial finding pointed at a failed update, see :
https://twitter.com/i/web/status/1393963756426698756

Maybe try with 5.2.7.7
ftvs2k-5.2.7.7
MediaFire is a simple to use free service that lets you put all your photos, documents, music, and video in a single place so you can access them anywhere and share them everywhere.
www.mediafire.com

0815hoffi said:
Maybe try with 5.2.7.7
ftvs2k-5.2.7.7
MediaFire is a simple to use free service that lets you put all your photos, documents, music, and video in a single place so you can access them anywhere and share them everywhere.
www.mediafire.com
Click to expand...
Click to collapse
Thanks @0815hoffi , that's actually the very first image I tried with from your thread.
Looking back, I think there's something wrong with my partitions.
If I see logs of other people from these threads, it says
script succeeded: result was [ALL DONE][amonet] Install boot patch...
Click to expand...
Click to collapse
Whereas for me, it says
script succeeded: result was [][amonet] Install boot patch...
Click to expand...
Click to collapse
This may mean that my flash is not successful, right? It's same everytime I flash.
I wonder, is there a way to bring everything to a clean state?
Given your expertise in amonet, @k4y0z from the thread and this comment, do you have a suspicion of what could be going wrong?

It looks like like it indeed were messed up partitions. My initial plan was to flash GPT fix in DL mode (by @k4y0z : link). But I thought might as well play with few things if am anyway going to re-do everything.
I started by going deleting directories manually (e.g. `rm -rf /system`). My plan was to manually flash each partition through fastboot.
Before that I attempted
Code:
fastboot format all
and received a bunch of errors, specifically
Code:
Formatting is not supported for file system with type ''.
Though format didn't work, I decided to wipe anyway
Code:
fastboot -w
It finished with few errors, but looked like it created those directories which I deleted earlier. So I rebooted to TWRP and did
Code:
twrp wipe data
Re-flashed @0815hoffi 's image and luckily it booted into "Optimising storage" screen. Post boot-up it appears to be working OK so far. Had an issue with wifi, but restart fixed it.
tl;dr
Code:
rm -rf /cache
rm -rf /data/dalvik
rm -rf /system
fastboot format userdata # errors
fastboot -w # completed but some errors
twrp wipe data
twrp install <img.zip>
reboot
EDIT : Looks like @Sus_i and @racega went through a similar journey and ended up with a similar fix. Good to know the fix is reproducible. Here's their posts : https://forum.xda-developers.com/t/...ck-2nd-gen-tank.3907002/page-61#post-83031003

saurabhshri said:
It looks like like it indeed were messed up partitions. My initial plan was to flash GPT fix in DL mode (by @k4y0z : link). But I thought might as well play with few things if am anyway going to re-do everything.
I started by going deleting directories manually (e.g. `rm -rf /system`). My plan was to manually flash each partition through fastboot.
Before that I attempted
Code:
fastboot format all
and received a bunch of errors, specifically
Code:
Formatting is not supported for file system with type ''.
Though format didn't work, I decided to wipe anyway
Code:
fastboot -w
It finished with few errors, but looked like it created those directories which I deleted earlier. So I rebooted to TWRP and did
Code:
twrp wipe data
Re-flashed @0815hoffi 's image and luckily it booted into "Optimising storage" screen. Post boot-up it appears to be working OK so far. Had an issue with wifi, but restart fixed it.
tl;dr
Code:
rm -rf /cache
rm -rf /data/dalvik
rm -rf /system
fastboot format userdata # errors
fastboot -w # completed but some errors
twrp wipe data
twrp install <img.zip>
reboot
EDIT : Looks like @Sus_i and @racega went through a similar journey and ended up with a similar fix. Good to know the fix is reproducible. Here's their posts : https://forum.xda-developers.com/t/...ck-2nd-gen-tank.3907002/page-61#post-83031003
Click to expand...
Click to collapse
Usually when this corrupted partitions happen you may try the command:
fastboot format userdata
followed by :
adb shell
(to call twrp#)
Then :
twrp wipe data
twrp wipe system
twrp wipe cache
twrp wipe dalvik
Then adb push the rom, gapps/magisk to /sdcard
twrp install nameofyourrom.zip
twrp install gappsxx.zip
Let it boot once and go back and update magisk via recovery.
(adb reboot recovery once permissions set or use powermenu little vic apk for quickness)
Another method I found which works good with fireos is :
When faced with corrupted/encrypted partition issues and/or unable to mount/format data issues
goto advanced wipe
select change file system
change it to EXT2
it will format data and data should appear become mount
hit back and change to EXT4 Filesystem again.
Then push rom and any other zips etc to /sdcard and install in usual way.
Good you got it working
Regards

Thank you for writing this down @Bertonumber1, I am sure it'll be very helpful to people who will encounter such situation in future.
Bertonumber1 said:
select change file system
change it to EXT2
it will format data and data should appear become mount
hit back and change to EXT4 Filesystem again.
Click to expand...
Click to collapse
I sincerely wish I could have done this. But I don't have an OTG with power input and deliveries are closed due to the pandemic. I was issuing TWRP commands through adb. I'll keep this in mind for future!
Thanks!

saurabhshri said:
Thank you for writing this down @Bertonumber1, I am sure it'll be very helpful to people who will encounter such situation in future.
I sincerely wish I could have done this. But I don't have an OTG with power input and deliveries are closed due to the pandemic. I was issuing TWRP commands through adb. I'll keep this in mind for future!
Thanks!
Click to expand...
Click to collapse
Ah I see, I'm sure the twrp can be commanded to repair change file systems. However, you are correct it is much easier via otg mouse or keyboard.
Regards

Develop Bugs

welcome