Related
As simple as that
Another question: if I perform "format system" and then reboot, will I be left without recovery?
I bought my device already rooted, but I understand that there is some sort of stock recovery. Is it true, if yes, what does it do?
In case I reboot after formating system and there will not be recovery as I suspect, I will be able to flash recovery image via fastboot as usual, right?
thanks
Format system will format the system partition, not the recovery.
Recovery will remain intact.
Thank you, but I would really like to understand how it works:
I know that the Internal memory devides into 3 partitions: system ,cach, data.
Which are the ROM. (This "ROM" is actually just flash memory isn't it? and is rewritable)
Where is the partition of the recovery if so?
Are there more partitions than those 3 in there?
Now when I come to think about it, I still don't know where the radio partition is, and where the data of bootloader is located.
I would still like to know what happens if you perform "format boot". Is it the partition where recovery is sitting or it refers to the memory partitioning (aka Hboot).
and That too
I bought my device already rooted, but I understand that there is some sort of stock recovery. What does a stock recovery allow to do?
Click to expand...
Click to collapse
thanks
There are actually more than those 3 partitions =)
There is:-
HBOOT - This is the bootloader its-self and contains the partition table
Boot - Contains the Kernel and a ramdisk used during startup
Recovery - Contains the recovery image
System - Contains the ROM installed on the device
Data - The internal memory, apps etc stored here
Cache - Pretty self explanatory =D It hold the cache =P
Radio - (Not too sure if this is on the NAND or not) Tells the radio chip how to communicate with your carrier etc (as far as I'm aware, someone feel free to correct me)
If you format boot, the phone will just go right to the bootloader without actually loading Android, but with a custom recovery it can be fixed easily by reflashing the ROM, nandroid restore, or by using fastboot to flash an existing boot.img. (Just a note here, flashing a Kernel wont fix this as the scripts used try to extract some parts from the existing boot.img, which isn't there after a format =P)
Assuming that you have an S-OFF HBOOT (Alpharev) you can flash any of those partitions with an image, using Fastboot as you mentioned, however, if you don't have S-OFF, you would have to do it through the Recovery (and you can’t flash HBOOT through recovery).
The phone does come with a stock Recovery Image, but this is very limited, Can only flash update.zip signed by HTC (again, might be wrong here), factory reset (Wipe data), reboot the phone and possibly some others.
Using either ClockworkMod Recovery or Amon_RA's recovery will let you flash custom ROMs, perform nandroid backups + restore (Boot, system + data) and a few other fancy things like wiping individual partitions =)
Hope this helps!
Thanks alot! you've explained it very clearly.
I would like just correct a very tiny mistake, probably unintentional - Factory reset is "wipe data", not "format system + data".
I got the answers that I wanted and more.
thanks again
It was unintentional =P I corrected incase someone happens upon the post.
Glad I could Help
wrong thread
Quick question. I have unlocked my bootloader and flashed the latest factory image. Phone is working fine, stock and encrypted. I decided to flash TWRP 2.8.7.2 using adb. After flashing it, I can boot into it from the bootloader by selecting the recovery option. After that first time though, it reverts back to stock recovery. Any idea what I missed?
This happened to me too. If I remember correctly, after going into recovery from the bootloader, reboot again back to the bootloader and launch recovery again. Not exactly sure why, but doing it twice before booting to system did the trick.
jm.kloz said:
This happened to me too. If I remember correctly, after going into recovery from the bootloader, reboot again back to the bootloader and launch recovery again. Not exactly sure why, but doing it twice before booting to system did the trick.
Click to expand...
Click to collapse
I tried what you suggested and still no dice. I appreciate you trying though.
Sounds like Android is overwriting it with stock recovery. When you first booted into TWRP, did you see a message that said Allow Modifications, and swipe to allow it?
Sent from my Nexus 5X using Tapatalk
As thesoldier was asking, there is a new TWRP feature that allows you to only READ-ONLY the device to prevent any flags being set. This will allow you to make a backup of the system so that you can revert to it in the future for OTA updates as these updates look for any changes to the system. If it detects that the system has been mounted, it will not allow OTA updates. But installing TWRP this way prevents TWRP from modifying the ROM to prevent the stock recovery from reinstalling itself.
https://twrp.me/site/update/2015/06/22/twrp-2.8.7.0-released.html
"System read only option: Devices that ship with 5.0 and higher as their initial OS are using block level OTA updates. With this style of OTA update, the update script checks to see if the system partition has ever been mounted read/write. Further, the script also usually runs an SHA sum of the entire system partition to detect if any changes have been made. If any changes have been made, the OTA update will refuse to install. Since not all OEMs and devices have factory images available, we have created a new feature in TWRP that detects if the system partition has ever been mounted read/write. If not, you will be prompted asking if you want TWRP to mount system as read/write. If you choose not to allow TWRP to mount as read/write, TWRP won’t prompt to install SuperSU and TWRP won’t try to patch the stock ROM to prevent TWRP from being replaced by stock recovery. The goal of this option is to hopefully allow the user to make a raw system image backup that they can use to get back to a state where they can take OTA updates again."
Most likely you chose the option to not mount the system as read/write after installing TWRP. So after the next reboot, the system noticed a modification to the recovery partition, and restored the stock recovery.
First of all, thanks so much to everyone for all the hard work creating and updating utilities for the Pixel C.
I have a rooted (but otherwise stock) Pixel C running the November update of Android 7/N (ryu-nrd91n) and am trying to:
1. Create an image of the userdata partition
2. Read/modify files
3. Re-flash the modified partition back to the Pixel C
So far I've been able to create a 24.8 GB image file using 'dd' but the file is unreadable, probably due to encryption.
I don't see any Developer Settings option to remove encryption or otherwise unencrypt the data partition.
What is the best approach?
jason_hanley said:
First of all, thanks so much to everyone for all the hard work creating and updating utilities for the Pixel C.
I have a rooted (but otherwise stock) Pixel C running the November update of Android 7/N (ryu-nrd91n) and am trying to:
1. Create an image of the userdata partition
2. Read/modify files
3. Re-flash the modified partition back to the Pixel C
So far I've been able to create a 24.8 GB image file using 'dd' but the file is unreadable, probably due to encryption.
I don't see any Developer Settings option to remove encryption or otherwise unencrypt the data partition.
What is the best approach?
Click to expand...
Click to collapse
Do you want to get rid of your encrypted data partition ?
- Format data (inside TWRP - and do not boot into system in between)
- Flash stock boot.img
- Install SuperSU.zip / or flash antother boot.img - with "encryptable" flag.
If you flash stock boot.img and boot into system your are encrypted again - automatically.
yes, "dd" will dump the complete partition including encryption ..
you may can "tar" the complete file system while decrypted .. similar to TWRP backup function.
Why do you want to "backup - modify - restore" at all ?
Why you don´t modify your files directly on data using root-explorer ?
Cheers
followmsi said:
Do you want to get rid of your encrypted data partition ?
- Format data (inside TWRP - and do not boot into system in between)
- Flash stock boot.img
- Install SuperSU.zip / or flash antother boot.img - with "encryptable" flag.
If you flash stock boot.img and boot into system your are encrypted again - automatically.
...
Why do you want to "backup - modify - restore" at all ?
Why you don´t modify your files directly on data using root-explorer ?
Click to expand...
Click to collapse
Thanks so much for the follow-up. The main goal is actually simply to be able to create images, and re-flash them reliably on a different Pixel C (replicating the exact system state). The modification step is simply to verify that it's working.
I was able to unencrypt /data using the method above -- Thanks, that's extremely helpful!
However, I'm still unable to mount/read the file produced by "dd if=/dev/block/mmcblk0p7"
Is there a better way you can recommend to make an image of the userdata partition?
How do you mount the unencrypted dd dump of data ?
mount -o loop dumped.data.img /mnt/data
As well you can untar all twrp backup files into one new data.img file.
Or tar the complete /data partition ... etc.
It's an ext4 partition ..
Of course, you can use the twrp backup files directly to restore on another pixel c device.
There is no modification needed at all.
Good luck!
Sent from my Nexus 10 using Tapatalk
That whole boot.img step.. is that why I always get stuck in a weird misplaced bootloop whenever I modify anything in TWRP? I just flash original boot.img in fastboot?
gnome9er said:
That whole boot.img step.. is that why I always get stuck in a weird misplaced bootloop whenever I modify anything in TWRP? I just flash original boot.img in fastboot?
Click to expand...
Click to collapse
The boot.img step to decrypt data ?
It's a one time task.
Once decrypted you always need to root after new boot.img flash.
If you don't root or don't use encryptable flag boot.img you will get encrypted.
Not really related to bootloops.
What are you changing when you are using TWRP ?
If I use backup then restore it loops. If I flash twrp it just boots to recovery. Now that i think about it i never did root this thing properly. Well i did with a toolkit but that doesnt count. I went beta then hated it lost root on restore then when i tried to do it again i kept running into bootloops. It says in the forums here that its common ans to just fastboot reboot but that dont work. I cant wait for the new nexus 7
gnome9er said:
If I use backup then restore it loops. If I flash twrp it just boots to recovery. Now that i think about it i never did root this thing properly. Well i did with a toolkit but that doesnt count. I went beta then hated it lost root on restore then when i tried to do it again i kept running into bootloops. It says in the forums here that its common ans to just fastboot reboot but that dont work. I cant wait for the new nexus 7
Click to expand...
Click to collapse
Depends what are you restoring
Do you backup / restore other partitions except the data partition ?
Pls don't
In general .. pls backup data partition only !
All other .img files should be taken freshly from image.
In systemless rooting world the su.img is placed on data.
You may have an older version inside your backup.
If you restore boot.img from backup, supersu ramdisk modifications will fail.
Flash what ever system.img, vendor.img and install twrp as recovery.
If you flash a boot.img, it should have stock ramdisk, to be able to let supersu.zip do the work for proper rooting.
At the same time the su.img on data will be refreshed too.
To summarize .. if you change something always install a fresh copy of your boot.img and run SuperSu.zip inside TWRP afterwards!
Hope this helps ..
followmsi said:
Depends what are you restoring
Do you backup / restore other partitions except the data partition ?
Pls don't
In general .. pls backup data partition only !
Click to expand...
Click to collapse
In this case, we're only looking to backup and restore the data partition.
Once we have the raw image created by dd, what would you say is the most reliable way to convert it to something that can be flashed by fastboot?
I've tried several different utilities to convert it to a "sparse image" but flashing it just erases data and doesn't copy anything from the image.
jason_hanley said:
In this case, we're only looking to backup and restore the data partition.
Once we have the raw image created by dd, what would you say is the most reliable way to convert it to something that can be flashed by fastboot?
I've tried several different utilities to convert it to a "sparse image" but flashing it just erases data and doesn't copy anything from the image.
Click to expand...
Click to collapse
Did you test img2simg as well ?
I use simg2img to convert the sparse to raw image, the other way around.
Or something like this below .. "s" defines sparse image.
make_ext4fs -s -l xxxxxxxx -a data data.img
Sorry, can't help you better now ..
followmsi said:
Did you test img2simg as well ?
Click to expand...
Click to collapse
Yes, unfortunately we've tried everything.
First we created the file data.dd using
Code:
dd if=/dev/block/mmcblk0p7
, which can be read as an ext4 image.
Then we tried using SparseConverter, ext2simg and img2simg to convert the raw image to a sparse image.
They all produce files of different lengths, and none of those files seem to flash successfully
They go through the flash process and report being successful, but the data isn't there.
Is there any way to debug this and figure out what's going wrong?
followmsi said:
Do you backup / restore other partitions except the data partition ?
Pls don't
In general .. pls backup data partition only !
Click to expand...
Click to collapse
Why should other partitions not be backed up? Is it not possible to flash the /data partition if you flash other partitions at the same time?
jason_hanley said:
Yes, unfortunately we've tried everything.
First we created the file data.dd using
Code:
dd if=/dev/block/mmcblk0p7
, which can be read as an ext4 image.
Then we tried using SparseConverter, ext2simg and img2simg to convert the raw image to a sparse image.
They all produce files of different lengths, and none of those files seem to flash successfully
They go through the flash process and report being successful, but the data isn't there.
Is there any way to debug this and figure out what's going wrong?
Click to expand...
Click to collapse
If you don´t get an error message from fastboot the sparse image seems to be valid.
How do you verify data partition after flashing ?
Are you able to mount and check ?
Also from recovery .. e.g. before you boot into system ?
For example on Nexus 7 flo there is still a userdata.img inside factory rom (6.0.1), but not for Pixel C anymore.
Maybe some permissions are required (file_contexts) - like on Nexus 7 flo too.
Sorry, no idea whats going wrong for you ..
---------- Post added at 12:49 PM ---------- Previous post was at 12:35 PM ----------
jogrimst said:
Why should other partitions not be backed up? Is it not possible to flash the /data partition if you flash other partitions at the same time?
Click to expand...
Click to collapse
You can backup all partitions you want .. but you should know the possible impact if you restore them.
And Yes - you can flash all partitions at the same time .. but normally you don´t flash data partition via fastboot - not on Pixel C.
In times of systemless rooting and monthly security releases there is no need for system.img backup anymore.
Unless you have special modifications inside your system.img.
If you were rooted before I recommend to use fresh boot.img and reinstall supersu.zip after change.
Just to prevent issues ...
followmsi said:
And Yes - you can flash all partitions at the same time .. but normally you don´t flash data partition via fastboot - not on Pixel C.
Click to expand...
Click to collapse
Why is userdata.img normally not flashed via fastboot on Pixel C?
jogrimst said:
Why is userdata.img normally not flashed via fastboot on Pixel C?
Click to expand...
Click to collapse
Because it will wipe your device.
cam30era said:
Because it will wipe your device.
Click to expand...
Click to collapse
Ok. Do you recommend creating a flashable ZIP file instead?
jogrimst said:
Ok. Do you recommend creating a flashable ZIP file instead?
Click to expand...
Click to collapse
Yep, pls use flashable zip for your purpose.
At first I tried to update my existing TWRP (3.2.1-0) to the 3.2.1-2 variant. It flashed ok, but then the phone would only boot to TWRP (reason for upgrade is that 3.2.1-0 would hang). I was attempting initially to put myself on the path to a "custom rom". When this failed, I manually flashed the latest google firmware from their page and it still will not do anything other than fastboot mode. No recovery, no firmware load. When I try to do the flash-all.bat method now, all I get after it loads the archive contents is "error: Cannot generate image for userdata. Guess I got a $1000 brick at this point?? Image from the PC screen included.
See if this thread helps.
https://forum.xda-developers.com/pi...ory-image-flashing-fails-t3715350/post7649698
I am going to have to find another way to look at that thread. My ipad is getting directed to some HTC desire article about and orange and black theme.
I have tried so far very unsuccessfully to wipe everything by booting to twrp via fastboot method. Then I used the dueces script to reflash everything completely (both partitions). No matter whether I flash complete stock or flash magisk and verizon radio files, it just hangs on the white google screen now and that is as far as I have gotten. Left it at home in this mode hoping it will clear.
JoeNeckbone said:
See if this thread helps.
https://forum.xda-developers.com/pi...ory-image-flashing-fails-t3715350/post7649698
Click to expand...
Click to collapse
That link is bad. Three devices are going to an htc desire theming page.
remove the -w from the update line in flash-all.
I have got the same problem since yesterday and search for a solution.
ctradio said:
That link is bad. Three devices are going to an htc desire theming page.
Click to expand...
Click to collapse
Not sure what happened with link, https://forum.xda-developers.com/pi...ry-image-flashing-fails-t3715350/post74751631
new adb dont help for me. I cannot flash slot a and change to b and got the error message that no slot is supported.
Still need help? Have you tried Skipsoft? Sure its not been updated but it might beable to help ..
Where fastboot flashing failed for me one time it got me out of a hole....
Otherwise i can try and remote and help... BTW its not finding the userdata file in the fastboot side... Something isnt right hence why it cant create the userdata file...
I try to boot with skipsoft to temp twrp but stuck on boot.img loading. the flashed twrp stuck on twrp logo and before I have changed from slot b to a inside twrp i can boot. now I cannot flash inside fast boot or delete anything.
Have you guys tried Deuces Bootloop Recovery & Flashing Script? I'd imagine you'd run into the same issues as the script runs a lot of the same fastboot commands...but it has worked wonders for many other users so......
I also might try re-downloading the factory image and comparing the Checksums to make sure you have a whole exact download just in case that's getting in the way of properly generating the userdata image. I'd also suggest making sure you have more than 4GB of space on your C drive; I was getting similar messages about not finding or not generating system images because they couldn't be fully extracted (temporarily) because I didn't have sufficient temp space on my C drive.
But I had encountered this issue before. It was either userdata or system_other partition. I did attempt to fastboot erase and fastboot format those partitions and other tweaks; even messed with changing the size of the partition (you might have better luck). What I seemed to conclude is that I was flashing the wrong month's Full Factory image; i.e. I was manually flashing system_other image from February when the whole phone was still on January. But I believe what I ended up doing was flashing a Full Factory image with the "-w" intact; therefore, if you still have access, you should copybackcup (via TWRP or adb pull) your internal storage (/sdcard and-or /data/media) and simply flash a Full Factory image with wipe option enabled...
Just some thoughts and suggestions...hope this helps...
I figured it out finally. Even though my ADB/Fastboot tools were a later creation date than the ones posted online, the ones online worked great. Even used the dueces script to ensure the junk is gone. Thanks all! Hate pesky gotchas like that!!
So, wanted to use my old pixel 2 xl but USB only works for charging. PC won't detect it, used dozens of cables and different computers.
I have latest carbon image and root. Wanted to boot twrp.img and then flash the twrp.zip since it used to be that way.
Any hints on this please? Because using apps says partion doesn't exist. I recall it used to be the "issue". That's why we had to boot twrp first and then flash it.
Maybe there is a different solution now.
Any help would be much appreciated.
This is not possible without USB. When the device reboots, RAM is cleared and nothing is "held" in NVRAM for the boot process. The device will either boot the image currently in the boot partition, or if commanded, will live boot the image you specify.
It -is- possible to write images to /boot using root, but keep in mind that since Magisk does not support the compression used for the stock recovery kernel, flashing TWRP to /boot will result in a device that can only boot TWRP.
i see, ok, so, sorry the stupid question in advance.
What if i write twrp .img to boot, then it always boots from twrp, but since i have twrp.zip and a rom.zip in media i can flash .zip to recovery partition and then reboot to recovery and flash rom.zip?
Or is this just to dumb to even ask.
hfmls said:
i see, ok, so, sorry the stupid question in advance.
What if i write twrp .img to boot, then it always boots from twrp, but since i have twrp.zip and a rom.zip in media i can flash .zip to recovery partition and then reboot to recovery and flash rom.zip?
Or is this just to dumb to even ask.
Click to expand...
Click to collapse
Not a dumb question. However, flashing TWRP will result in a device that can only boot TWRP. This applies even if you flash a ROM to a slot.
The best alternative I've found is to run LineageOS. This is because that ROM includes its own recovery that can flash non-Google zips. Further, its updater not only doesn't require a usb cable it also gracefully handles Magisk.
Unfortunately, LineageOS isn't Carbon, and Carbon doesn't include a built-in updater. In your case, you may have no choice but to use a USB cable.