[Q] Why .img? - Shield Q&A

So in looking around I have not found any answer to my question. Why is everything to flash on the shield a .img instead of building zip files you can flash directly from recovery? I have been messing with android for quite a long time and know how to flash .img, fastboot, adb, ect. But dl'd and flashing a zip is far easier.
Any answers?
thanks.

*I think* that base factory images (.img files.) are meant to be flashed via fastboot, since they have a direct relationship with device specific partitions. Imagine a bit to bit flash, like a Ghost/Acronis image?!?
As for .zip files, they are installed via recoveries (CWM, TWRP, etc), because you just want to add/replace files in the / partition.
And with our Shield, until now, all OTAs are full system images, not updates.
I hope that I've explained this properly, if not please someone correct me
http://en.wikipedia.org/wiki/Fastboot#Fastboot

anthonws said:
*I think* that base factory images (.img files.) are meant to be flashed via fastboot, since they have a direct relationship with device specific partitions. Imagine a bit to bit flash, like a Ghost/Acronis image?!?
As for .zip files, they are installed via recoveries (CWM, TWRP, etc), because you just want to add/replace files in the / partition.
And with our Shield, until now, all OTAs are full system images, not updates.
I hope that I've explained this properly, if not please someone correct me
http://en.wikipedia.org/wiki/Fastboot#Fastboot
Click to expand...
Click to collapse
Not all ota are full system images, ota 65 and 67 are simple delta updates.
BTW, the main reason of .img files for images is because this can't depend on the recovery. How do you flash a recovery .zip file without a recovery?
You need to have a .img file that can be flashed via fastboot, it is VERY much "bricked" proff that a flashable zip

Thanks for the explanations. I realize some things need to be done via fastboot like unlocking or flashing a recovery for the first time.
I guess I have become spoiled by xda and the simplicity of modification that is available today. Far cry from hacking htcs back in the day.
thx -jason

Both answers are correct - it all depends on which software (on the device) is used to flash, and what format it accepts.
With Tegra devices you have at least 3 ways to flash stuff, from lowest to highest level:
- nvflash/tegrarcm mode. This is a very small firmware that is burnt in ROM and is thus always available no matter how hard you screw your device. It can run small programs (typically, a flasher) that are sent through USB. Problem is, for Tegra4 it will only accept signed binaries, which makes it useless for modders.
- bootloader/fastboot. The bootloader supports the fastboot protocol, which can flash .img files. The bootloader is written in flash memory so your bootloader partition must be in good shape.
- recovery/zip files. The recovery is a Linux image, so this means it is a full-blown system of its own right. Because of this it can support more format, including .zip archives with a script to describe how the archive should be installed.
So in the boot chain, you have 3 anchors from which you can flash images: boot rom (always available but unusable to us) -> bootloader -> recovery. The fact the boot rom cannot be used without a signed image (which is not available publicly) means that screwing your bootloader is sufficient to permanently brick your device.
Recovery images are more convenient since they are in .zip format and can for some be device-independent (e.g. superSU recovery images are flashed the same on every single device out there), contrary to the bootloader which can be different for every device. But they require a working recovery, which is not always granted - so for actual recovery, fastboot images are also useful.

That's why I love XDA
You're never alone!
Thanks for the additional info to all
Anthonws

Related

[Q] how to use dd or nvflash to create backup of recovery?

Recently I got Wind Optimus 2x (p999). Before I change anything, I want to create a full backup in case of warranty. Searching forum and google for couple of days I found several different "stock" recovery images. But all of them have different size/date/etc.. So I want to make my own recovery image.
My idea is make stock recovery image (via dd or nvflash), replace recovery with cwm, make backup, flash custom ROM. If i need to go back - do in reverse order .
1. From what I found, using
dd of=/path_to_store/myimage.img if=/dev/block/mmcblk0p7
should produce required image, but size is about 1.6M, while all other recovery images have size 3-5M
Am I doing something wrong?
2. I cannot find anywhere information about correct use of nvflash utility. Some shell scripts have bunch of parameters to write image into phone, but there is no info about how to read data from phone and create image..
Any help please?
I am sorry if I don't understand your questions but, I will try nonetheless. It seems you do not understand what nv flash or cwm do. Nv flash is how you CORRECTLY install a version of the clockworkmod recovery. Once installed, you choose the back up option to copy your system image. This recovery has the ability to do anything that has to do with rom flashing. Also is does it all simply by choosing what you want to do. There's no ADB or entering commands. Just look for TGA_gunnmans one click nv recovery flasher, this is all the info you will need.
Sent from the fastest g2x in the world
well, not exactly correct. nvflash is "low level" (means it accesses EPROM on hardware level) flash utility. It's designed to write data into EPROM. In most cases such utility can be used to read data as well (for backup purposes). That is why I am trying to find more information about nvflash and how to use it.
dd us *nix utility which works on higher than nvflash level, but lower than cp (copy).
By the time cwr is installed, the phone is different from factory - one of partitions is replaced. I am trying to backup this partition before replacement.
cy_mpak said:
well, not exactly correct. nvflash is "low level" (means it accesses EPROM on hardware level) flash utility. It's designed to write data into EPROM. In most cases such utility can be used to read data as well (for backup purposes). That is why I am trying to find more information about nvflash and how to use it.
dd us *nix utility which works on higher than nvflash level, but lower than cp (copy).
By the time cwr is installed, the phone is different from factory - one of partitions is replaced. I am trying to backup this partition before replacement.
Click to expand...
Click to collapse
There are stock recoveries available! Look in the optional files section.
http://forum.xda-developers.com/showthread.php?t=1054492"
After some more research and experiments I have found that recovery partition on G2x is mmcblk0p5.
Thanks to all who answered my questions directly or indirectly

partitioning of /kernel and /recovery, where is the recovery mode image

Hi,
Backround:
My approach is to fullfil a full memory acquisition of an GSG i9000 (but thats not really relevant). The acquisition should be as forensic as possible by legal term. I approach is to apply as less changes as possible. So there is no option to turn on the device, root it and install ROM Manager or equal...
My Idea was to flash the Recovery Mode with CWM. After that I fullfil the acquisition with dd. (I could place the dd and su binaries to /sdcard/ext_sdcard and mount it with executable rights)
Problem and Approach
The bootloader of the device is not acceable, so I can't use fastboot to flash the recovery mode. Instead I have to use the Heimdall Suite over the download mode.
The Test/CrashDummy Device: is also a SGS-i9000, which had CWM 3.x allready installed. I flashed the recovery partition with an 2.5.x CMW image. However this didn't work out, v3.x was still booting when going to recovery mode. I did it many times, but it didn't help.
Then I read that the recovery mode-kernel is in the original linux/android kernel zImage. So I flashed it the kernel partition with Heimdall, which worked out for the recovery mode, but not for the Android OS itself..., was hanging on boot-bricked.
The second approach, flashing the original kernel, is the thing I would like to avoid generally.
The Question
Many users reported in forums that flashing recovery mode did it, my expirience showed the oposite. I also seed blog posts which told the /recovery is holding only the backup of the kernel partition.
What is or has to be flashed for a custom recovery mode eg CWM?
The Android kernel partition or only the recovery partition? Where is the recovery mode is actually stored?
I am really interested in the technical background, but can't find any documentation either on the official side nor in forums/wikis. Any links would be also helpful!
I looked at the PIT, is there a need to adjust the pit when the size of kernel images changes? Only the start address is relevant?
Also would be interested in the overall situation, am I missing something, logical flaws in the mentioned constelation?
Is there a way to pull the kernel image over the download mode, not only flash it? Maybe even other partitions, e.g. the whole flash?
Did somebody tried to read yourself in into the Odin protocol besides Glass Echidna, I started read the source of Heimdall. It's clean code but without documentation...
thanks in advance
ps: I spared time to search all the links of the flashimages, but I always used the official sources(HPs of the MODs) when it was possible.
EDIT: I found the link where the authors tells recovery is only a backup partition: vincent.bernat.im/en/blog/2011-android-samsung-galaxy-s.html

Please help urgent !!!!!

Please help
Recently i bricked my acer z3,tryed many way to flash but failed.
Installed TWRP but couln"t restore my backup,result failed restoring data.
Flash with command line but result unable open system.img.
I desperade now and thinking to throw the damn phone.
So this is my last hope.
Please convert this cwmrecovery.img to flashable zip.
PLEASEEEEEEE HELPPPPPP
have you tryed with the acer pc suite?
enter in download mode and connect at you pc.
lio97 said:
have you tryed with the acer pc suite?
enter in download mode and connect at you pc.
Click to expand...
Click to collapse
Can you explain more detail please ?
Leftrand said:
Please convert this cwmrecovery.img to flashable zip.
Click to expand...
Click to collapse
I don't have a recipe for you, but what you might try is
- get "yet another recovery zip" *for your phone*
- open that one (don't unpack) - under Linux, "mc" does a nice job
- inspect META-INF/com/google/android/updater-script (and try to understand it!)
- replace the recovery.img inside the zip with yours, possibly renaming it
- try to flash the zip without checking signatures
- you may have to remove the three files sitting in the META-INF folder as well
Needless to say that you'll be doing this on your own risk. Of course, if you flash the wrong recovery, you won't be able to use a recovery to flash another one, so better think thrice.
steve8x8 said:
I don't have a recipe for you, but what you might try is
- get "yet another recovery zip" *for your phone*
- open that one (don't unpack) - under Linux, "mc" does a nice job
- inspect META-INF/com/google/android/updater-script (and try to understand it!)
- replace the recovery.img inside the zip with yours, possibly renaming it
- try to flash the zip without checking signatures
- you may have to remove the three files sitting in the META-INF folder as well
Needless to say that you'll be doing this on your own risk. Of course, if you flash the wrong recovery, you won't be able to use a recovery to flash another one, so better think thrice.
Click to expand...
Click to collapse
Thanks for reply.
Done that,installed succesfully but still twrp instead cwm.
Any other tool like odin etc ?
My phone is Acer Z3.
Not sure whether you might be still here, or have given up long ago. Usually recoveries are not flashed in a recovery context (might have to do with reentrance issues, I never got that far). What might help you is to get the device into bootloader mode, then connect to a PC, and "fastboot flash recovery recovery.img". This is what I'd do with mine, but as yours is a different model, the whole procedure might look completely different.
So if I were you I'd look for
- the standard way to flash a new full firmware (not relying on recoveries) - Samsung has Odin (Windows), Motorola has sbf_flash (Linux), etc.
- how to boot into bootloader (remove/insert battery, then while pressing power, keep one of the volume keys pressed? device-dependent, again)
- a way to flash only selected partitions (something like fastboot interacting with the bootloader)
There should be hints galore in the device-focused forum (I hope)

Best Method to Re-flash & Re-root Plus Have Internal Storage Working

Hey Guys -
I have had my A9 for about 2 months and love it. When I first purchased it, I rooted it using the method pinned to this forum which seemed to work well. Soon afterwards, I found out that when I inserted and tried to format an SD card as "internal", it wouldn't work and result in it showing as "corrupted." I soon found out that this seemed to be due to the root replacing the original boot.img which messes with encryption. Since the root was posted, SuperSU has been updated and that step has changed supposedly.
Now that I have some time, I want to fix this issue. Before doing so, I've read through many posts and think I have a plan. I wanted to post the steps I need to follow as I understood them to make sure my plan is correct and will result in not only being able to format an SD internally and be rooted, but also a working phone Below are the specs of my phone, the steps I think it may take to resolve, and a few questions I have after reading through numerous posts. Any help is appreciated!
Phone Specs
Some as currently listed in Settings
- HTC One A9
- AT&T USA
- Rooted / s-off
- Android 6.0 / Sense 7.0g
Software Number: 1.10.502.3
Kernel: 3.10.73-perf-g28d66e0
Baseband: [email protected]_29.05_F
Build: 1.10.502.3 CL635081 release keys
Android Security Patch Level: 2015-10-01
Steps to Fix
1. Backup any data desired (I have a nightly Titanium backup)
2. Download RUU for same version (1.10.502.3) from http://forum.xda-developers.com/one-a9/general/wip-ruu-htc-one-a9-t3240344
Should I use newer version or are those for different carriers?
3. Apply RUU (via embedded EXE or try to extract and apply using adb/fastboot)
4. Once phone is restored, make a backup of boot.img from phone just in case it's needed later
5. Install TWRP via adb/fastboot
6. Install SuperSU via TWRP
At this point (if I can make it to this point), test and see if the phone's rooted and I can format the SD internally. If so, great. If not, continue with the following steps...
7. Download & flash modded boot.img from A9 Root post
8. Install TWRP via adb / fastboot
9. Install SuperSU via TWRP
10. Flash original boot.img backed up in step #4 to my phone (since modded one was only needed initially to install SuperSU) So that encryption keys match and I may successfully format sd cards for internal use
My Questions
1. Are the steps above basically the process i need to perform or is there a better / easier way? I don't know if I could flash a common boot.img from an RUU or if it needs to be flashed to phone first for encryption purposes. Even if I can, I've tried to extract it from ruu.zip before and could not
2. Should I use an RUU for a newer version (over 1.10.502.3) or are those for different carriers and not work with my AT&T phone?
3. Does it make a difference if I install the RUU via embedded EXE or extract and apply using adb/fastboot?
4. What versions of TWRP & SuperSU should I use?
Any additional suggestions would be appreciated - I just want to get this resolved once and for all! - Thanks!
bzowk said:
Hey Guys -
I have had my A9 for about 2 months and love it. When I first purchased it, I rooted it using the method pinned to this forum which seemed to work well. Soon afterwards, I found out that when I inserted and tried to format an SD card as "internal", it wouldn't work and result in it showing as "corrupted." I soon found out that this seemed to be due to the root replacing the original boot.img which messes with encryption. Since the root was posted, SuperSU has been updated and that step has changed supposedly.
Now that I have some time, I want to fix this issue. Before doing so, I've read through many posts and think I have a plan. I wanted to post the steps I need to follow as I understood them to make sure my plan is correct and will result in not only being able to format an SD internally and be rooted, but also a working phone Below are the specs of my phone, the steps I think it may take to resolve, and a few questions I have after reading through numerous posts. Any help is appreciated!
Phone Specs
Some as currently listed in Settings
- HTC One A9
- AT&T USA
- Rooted / s-off
- Android 6.0 / Sense 7.0g
Software Number: 1.10.502.3
Kernel: 3.10.73-perf-g28d66e0
Baseband: [email protected]_29.05_F
Build: 1.10.502.3 CL635081 release keys
Android Security Patch Level: 2015-10-01
Steps to Fix
1. Backup any data desired (I have a nightly Titanium backup)
2. Download RUU for same version (1.10.502.3) from http://forum.xda-developers.com/one-a9/general/wip-ruu-htc-one-a9-t3240344
Should I use newer version or are those for different carriers?
3. Apply RUU (via embedded EXE or try to extract and apply using adb/fastboot)
4. Once phone is restored, make a backup of boot.img from phone just in case it's needed later
5. Install TWRP via adb/fastboot
6. Install SuperSU via TWRP
At this point (if I can make it to this point), test and see if the phone's rooted and I can format the SD internally. If so, great. If not, continue with the following steps...
7. Download & flash modded boot.img from A9 Root post
8. Install TWRP via adb / fastboot
9. Install SuperSU via TWRP
10. Flash original boot.img backed up in step #4 to my phone (since modded one was only needed initially to install SuperSU) So that encryption keys match and I may successfully format sd cards for internal use
My Questions
1. Are the steps above basically the process i need to perform or is there a better / easier way? I don't know if I could flash a common boot.img from an RUU or if it needs to be flashed to phone first for encryption purposes. Even if I can, I've tried to extract it from ruu.zip before and could not
2. Should I use an RUU for a newer version (over 1.10.502.3) or are those for different carriers and not work with my AT&T phone?
3. Does it make a difference if I install the RUU via embedded EXE or extract and apply using adb/fastboot?
4. What versions of TWRP & SuperSU should I use?
Any additional suggestions would be appreciated - I just want to get this resolved once and for all! - Thanks!
Click to expand...
Click to collapse
First off, this isn't Development.
Secondly, I explained to you how to fix this in the very root thread you linked several times.
Thirdly, there's a newer, official RUU from HTC right on their ROM Downloads website. I'd start by installing that (though I also have a recovery-flashable version of that ROM in my Base ROM thread).
Fourthly, with access to an official RUU, and my ROM decrypt script, you have access to the stock boot.img (which is also in the firmware zip in my Base ROM thread), which you can use as your baseline for restoring the verity key to the ramdisk, thereby allowing you to use adopted storage without any issues. Note however that I was only able to use adopted storage with the "forceencrypt" flag enabled.
Fifthly, you can't just restore the stock boot image (at least not if you want to stay rooted). You can be both rooted and encrypted, but you have to first make sure SuperSU is flashed and set up prior to allowing the device to be encrypted again (adopted storage only works with an encrypted device, and then you won't be able to access your storage with TWRP).
OK, OK - sorry.... It had been a while since posting and honestly forgot about that thread - my fault.
I decided to start fresh so have already restored the phone to HTC's latest RUU (1.27.502.5 ATT) as I already had it downloaded. I've also flashed TWRP 2.8.8.1 to the phone, but am obviously prompted to enter a password when I try to enter recovery. Based off what I've read, the steps below seem to be what I need to do so that I may be rooted + still have encryption for internal sd formatting. Is it correct (or close to it)
Using an Ubuntu 14.04 x86 VM...
1. Download & extract your decrypt script to a temp folder in linux vm
2. In Windows, run same RUU I applied and copy out rom.zip from %temp%
3. Rename "rom.zip" to "rom_a9.zip"
4. Copy rom_a9.zip to the ""place_rom_zip_here" folder of your extracted script in the vm
5. Run ./decrypt-htc and wait for script to complete to get img files
On Phone (Currently has same RUU installed + TWRP but not rooted)
6. Root phone using original method of flashing modded boot.img, install SuperSU, and get rooted
7. Once done and rooted, flash boot.img I extracted using your script above to phone via adb
Once that's done, it should be rooted + have encryption thus allowing me to use internal sd card, right? Sorry to be such a bother - just want to get this fixed and done with
Thanks!
bzowk said:
OK, OK - sorry.... It had been a while since posting and honestly forgot about that thread - my fault.
I decided to start fresh so have already restored the phone to HTC's latest RUU (1.27.502.5 ATT) as I already had it downloaded. I've also flashed TWRP 2.8.8.1 to the phone, but am obviously prompted to enter a password when I try to enter recovery. Based off what I've read, the steps below seem to be what I need to do so that I may be rooted + still have encryption for internal sd formatting. Is it correct (or close to it)
Using an Ubuntu 14.04 x86 VM...
1. Download & extract your decrypt script to a temp folder in linux vm
2. In Windows, run same RUU I applied and copy out rom.zip from %temp%
3. Rename "rom.zip" to "rom_a9.zip"
4. Copy rom_a9.zip to the ""place_rom_zip_here" folder of your extracted script in the vm
5. Run ./decrypt-htc and wait for script to complete to get img files
On Phone (Currently has same RUU installed + TWRP but not rooted)
6. Root phone using original method of flashing modded boot.img, install SuperSU, and get rooted
7. Once done and rooted, flash boot.img I extracted using your script above to phone via adb
Once that's done, it should be rooted + have encryption thus allowing me to use internal sd card, right? Sorry to be such a bother - just want to get this fixed and done with
Thanks!
Click to expand...
Click to collapse
Re-read my post. If you flash the stock boot.img, you will no longer be rooted.
And as I said in the original thread, you need to pull the rooted boot.img and add the verity key from the stock one to it. Also you'll need to add the forceencrypt and verify flag back.
P.S. You also need to re-read the instructions in the decrypt thread. You don't have to rename anything anymore.
Good Afternoon -
OK - sorry to frustrate you, but I think I finally have it figured out. I started from scratch, re-read many posts, and took notes. I was a little confused on the last part so wanted to verify, please...
I've already unpacked the boot.img from the latest HTC A9 (AT&T) RUU and have the two folders. I restored the same RUU to my phone, flashed TWRP 2.8.8.1, backed up the boot.img, and unpacked it before realizing that I should have probably rooted it first.
Correct me if I'm wrong, but here's all I need to do to finish....
1. Download modified A9 boot.img from top of root thread
2. Flash modded boot.img using fastboot
3. Verify TWRP is still installed then use it to install SuperSU 2.67 (latest)
4. Back up boot partition just like I did before in TWRP
5. Unpack it on PC to create ramdisk and split_img folders
6. Copy verity_key from unpack of the actual RUU and overwrite one in rooted unpack
7. Edit the file fstab.qcom in the ramdisk folder of the rooted unpack in Notepad++ and add the "verify" flag after the wait flag on the fist uncommented line - save
8. Repack rooted boot.img
9. Flash phone with repacked boot.img using fastboot
10. Reboot & enjoy a rooted phone + encryption allowing sd internal formatting
Promise not to bug anymore if I can just get this resolved.
Thanks again for your assistance!
UPDATE
Hmm - was just prepping and went to download modded file from root thread's first post. Doesn't seem to have one that matches newest build of RUU I flashed - if I'm interpreting it correctly. Researching further, but if know of alternate method or another solution to get through steps 1 & 2 about (assuming they are correct), I'd appreciate it. Thanks
bzowk said:
Good Afternoon -
OK - sorry to frustrate you, but I think I finally have it figured out. I started from scratch, re-read many posts, and took notes. I was a little confused on the last part so wanted to verify, please...
I've already unpacked the boot.img from the latest HTC A9 (AT&T) RUU and have the two folders. I restored the same RUU to my phone, flashed TWRP 2.8.8.1, backed up the boot.img, and unpacked it before realizing that I should have probably rooted it first.
Correct me if I'm wrong, but here's all I need to do to finish....
1. Download modified A9 boot.img from top of root thread
2. Flash modded boot.img using fastboot
3. Verify TWRP is still installed then use it to install SuperSU 2.67 (latest)
4. Back up boot partition just like I did before in TWRP
5. Unpack it on PC to create ramdisk and split_img folders
6. Copy verity_key from unpack of the actual RUU and overwrite one in rooted unpack
7. Edit the file fstab.qcom in the ramdisk folder of the rooted unpack in Notepad++ and add the "verify" flag after the wait flag on the fist uncommented line - save
8. Repack rooted boot.img
9. Flash phone with repacked boot.img using fastboot
10. Reboot & enjoy a rooted phone + encryption allowing sd internal formatting
Promise not to bug anymore if I can just get this resolved.
Thanks again for your assistance!
UPDATE
Hmm - was just prepping and went to download modded file from root thread's first post. Doesn't seem to have one that matches newest build of RUU I flashed - if I'm interpreting it correctly. Researching further, but if know of alternate method or another solution to get through steps 1 & 2 about (assuming they are correct), I'd appreciate it. Thanks
Click to expand...
Click to collapse
You don't need anything from that root thread. Everything there is deprecated (which I've said several times).
If you already have the stock boot.img unpacked and ready to go, all you have to do is flash SuperSU, then back up the rooted boot.img that you now have on your device thanks to SuperSU. Unpack that boot.emmc.win and add the verity_key from the stock ramdisk and replace the fstab.qcom with the one from the stock ramdisk. Repack, flash to your device via fastboot or TWRP, and your device will encrypt on that first boot and you'll be good to go.
Just to make sure - you did a Format Data in TWRP prior to flashing SuperSU, correct?
Captain_Throwback said:
You don't need anything from that root thread. Everything there is deprecated (which I've said several times).
If you already have the stock boot.img unpacked and ready to go, all you have to do is flash SuperSU, then back up the rooted boot.img that you now have on your device thanks to SuperSU. Unpack that boot.emmc.win and add the verity_key from the stock ramdisk and replace the fstab.qcom with the one from the stock ramdisk. Repack, flash to your device via fastboot or TWRP, and your device will encrypt on that first boot and you'll be good to go.
Just to make sure - you did a Format Data in TWRP prior to flashing SuperSU, correct?
Click to expand...
Click to collapse
Thanks -
Well, that's the thing... One of the two unpacked boot.img I have currently is wrong. The two I have are:
- One unpacked boot.img extracted from latest RUU using your script in linux
- One unpacked boot.img backed up from unrooted phone which only had TWRP flashed
That was part of my question. I know that the 2nd unpacked boot.img above is worthless as the phone needed to be rooted prior to me backing it up. The question for me is how to flash superSU onto the phone (which currently has the same latest RUU + TWRP 2.8.8.1 installed) if I can only access TWRP is a read-only mode as I'm prompted for password upon booting to recovery. That's why I brought up the legacy root method as I don't know of an alternative... unless SuperSU doesn't require write permissions to whatever TWRP has locked down currently.
Once I can root it, backup it's boot, and unpack it; I just need to literally copy & overwrite the "verity_key" and "fstab.qcom" files (assuming the only difference is the fstab.qcom I'm overwriting doesn't have the verify flag), repack, then flash back to phone via fastboot, right?
Thanks for your patience!
bzowk said:
Thanks -
Well, that's the thing... One of the two unpacked boot.img I have currently is wrong. The two I have are:
- One unpacked boot.img extracted from latest RUU using your script in linux
- One unpacked boot.img backed up from unrooted phone which only had TWRP flashed
That was part of my question. I know that the 2nd unpacked boot.img above is worthless as the phone needed to be rooted prior to me backing it up. The question for me is how to flash superSU onto the phone (which currently has the same latest RUU + TWRP 2.8.8.1 installed) if I can only access TWRP is a read-only mode as I'm prompted for password upon booting to recovery. That's why I brought up the legacy root method as I don't know of an alternative... unless SuperSU doesn't require write permissions to whatever TWRP has locked down currently.
Once I can root it, backup it's boot, and unpack it; I just need to literally copy & overwrite the "verity_key" and "fstab.qcom" files (assuming the only difference is the fstab.qcom I'm overwriting doesn't have the verify flag), repack, then flash back to phone via fastboot, right?
Thanks for your patience!
Click to expand...
Click to collapse
Once you Format Data in TWRP and reboot recovery, you can flash SuperSU and you will be rooted. You just have to back up the boot.img after flashing SuperSU on the unencrypted device to re-enable verity so that adopted storage will work.
P.S. And no, the verify flag isn't the only difference. As I also said earlier (I'm constantly repeating myself), the device must be encrypted for Adopted Storage to work, so the forceencrypt flag from the stock fstab must also be present. That's why it's easier just to replace the whole file. The problem you have at the end of the day is that, while you'll be rooted and be able to use adopted storage in Android, you still won't be able to access said storage (or /data) in TWRP.
Captain_Throwback said:
Once you Format Data in TWRP and reboot recovery, you can flash SuperSU and you will be rooted. You just have to back up the boot.img after flashing SuperSU on the unencrypted device to re-enable verity so that adopted storage will work.
P.S. And no, the verify flag isn't the only difference. As I also said earlier (I'm constantly repeating myself), the device must be encrypted for Adopted Storage to work, so the forceencrypt flag from the stock fstab must also be present. That's why it's easier just to replace the whole file. The problem you have at the end of the day is that, while you'll be rooted and be able to use adopted storage in Android, you still won't be able to access said storage (or /data) in TWRP.
Click to expand...
Click to collapse
Great - Thanks!!
Just to make sure, below's my plan with a small question @ step #5. Does it get your stamp of approval?
Phone (A9) already had latest RUU restored (same RUU I ran against your script to pull boot.img from) and TWRP 2.8.8.1 flashed
1. Boot into TWRP & bypass initial screen prompting for password
2. Format Data
3. Reboot back into TWRP
4. Flash SuperSU 2.76 zip
5. Reboot to system then back to TWRP and backup boot partition? / Stay in TWRP and backup boot partition? / Reboot back into TWRP and backup boot partition?
6. Unpack backed up boot partition from phone
7. Copy "verity_key" & "fstab.qcom" files from ramdisk folder in unpacked RUU boot and paste into & overwrite same files in ramdisk folder of unpacked boot from rooted phone
8. Repack rooted phone boot (which includes both new files)
9. Flash newly packed boot.img to phone using fastboot
10. Enjoy
I really appreciate your help and patience with me!
bzowk said:
Great - Thanks!!
Just to make sure, below's my plan with a small question @ step #5. Does it get your stamp of approval?
Phone (A9) already had latest RUU restored (same RUU I ran against your script to pull boot.img from) and TWRP 2.8.8.1 flashed
1. Boot into TWRP & bypass initial screen prompting for password
2. Format Data
3. Reboot back into TWRP
Click to expand...
Click to collapse
Good so far . . .
bzowk said:
4. Flash SuperSU 2.76 zip
Click to expand...
Click to collapse
I'm sure this is just a typo, but that should be 2.67, not 76 (there is no 2.76).
bzowk said:
5. Reboot to system then back to TWRP and backup boot partition? / Stay in TWRP and backup boot partition? / Reboot back into TWRP and backup boot partition?
Click to expand...
Click to collapse
Bolded the correct one above (no need to leave TWRP as the necessary modifications have already been made).
bzowk said:
6. Unpack backed up boot partition from phone
7. Copy "verity_key" & "fstab.qcom" files from ramdisk folder in unpacked RUU boot and paste into & overwrite same files in ramdisk folder of unpacked boot from rooted phone
8. Repack rooted phone boot (which includes both new files)
Click to expand...
Click to collapse
Looks good . . .
bzowk said:
9. Flash newly packed boot.img to phone using fastboot
Click to expand...
Click to collapse
TWRP can also flash the new image, but fastboot is probably the most reliable way to do it.
bzowk said:
10. Enjoy
Click to expand...
Click to collapse
Hopefully . . . You'll likely get a reboot on the first boot (possible multiple reboots), as SuperSU needs a reboot to install the necessary files. Since your device will also encrypt on that initial boot, I'm not sure whether there will be a conflict or not.
bzowk said:
I really appreciate your help and patience with me!
Click to expand...
Click to collapse
Guess we'll see if it all works out . . .
Thanks!
I proceeded by formatting data, booting directly back intoTWRP, flashing SuperSU, backing up the boot partition, then mounting and copying it over to my PC. The boot.img size was 65,536kb - the same size as the one I unpacked from the RUU. Once unpacked, it was missing the verity_key file and the fstab.qcom file was different + missing the verify flag.
I replaced those two files, then ran repackimg.bat which created image-new.img which I renamed to boot.img. Interesting, though, that this file was only 45,890kb. If it's a repack, shouldn't it be the same or similar? Anyways, the phone was still in TWRP (hadn't booted to system since before the format data) so booted it into bootloader directly and tried flashing boot using my new 45mb boot.img.
If failed - but - my phone was only at 17% power. Don't know if that's why it failed or not so it's charging right now while still in the bootloader. Below is what was echoed when I tried flashing it:
Code:
c:\adb>fastboot flash boot boot.img
target reported max download size of 800000000 bytes
sending 'boot' (45890 KB)...
OKAY [ 3.488s]
writing 'boot'...
(bootloader) HOSD CL#656287
FAILED (remote: 4 RU_BATTERY_LOW please connect charger (17% < 30%))
finished. total time: 4.506s
The reason I didn't boot to system is that I thought that was when the encryption might take place. Going to wait until above 30% power then try flashing again. Powered down to charge, but plan to boot straight back into bootloader to flash. If you see anything that stands out or that I need to do otherwise, please let me know. Otherwise, I'll report back what the result was after getting above 30%.
Thanks again!
bzowk said:
Thanks!
I proceeded by formatting data, booting directly back intoTWRP, flashing SuperSU, backing up the boot partition, then mounting and copying it over to my PC. The boot.img size was 65,536kb - the same size as the one I unpacked from the RUU. Once unpacked, it was missing the verity_key file and the fstab.qcom file was different + missing the verify flag.
I replaced those two files, then ran repackimg.bat which created image-new.img which I renamed to boot.img. Interesting, though, that this file was only 45,890kb. If it's a repack, shouldn't it be the same or similar? Anyways, the phone was still in TWRP (hadn't booted to system since before the format data) so booted it into bootloader directly and tried flashing boot using my new 45mb boot.img.
If failed - but - my phone was only at 17% power. Don't know if that's why it failed or not so it's charging right now while still in the bootloader. Below is what was echoed when I tried flashing it:
Code:
c:\adb>fastboot flash boot boot.img
target reported max download size of 800000000 bytes
sending 'boot' (45890 KB)...
OKAY [ 3.488s]
writing 'boot'...
(bootloader) HOSD CL#656287
FAILED (remote: 4 RU_BATTERY_LOW please connect charger (17% < 30%))
finished. total time: 4.506s
The reason I didn't boot to system is that I thought that was when the encryption might take place. Going to wait until above 30% power then try flashing again. Powered down to charge, but plan to boot straight back into bootloader to flash. If you see anything that stands out or that I need to do otherwise, please let me know. Otherwise, I'll report back what the result was after getting above 30%.
Thanks again!
Click to expand...
Click to collapse
The repack is smaller because the backup uses "dd" to copy the entire block device. Not all that space is actually used after compression. That's nothing to worry about.
And these devices are very picky about flashing only when there's sufficient battery, so I'm sure that's the only reason it failed. TWRP, however, doesn't care how much battery you have, so you could always flash the new boot.img in recovery.
Captain_Throwback said:
The repack is smaller because the backup uses "dd" to copy the entire block device. Not all that space is actually used after compression. That's nothing to worry about.
And these devices are very picky about flashing only when there's sufficient battery, so I'm sure that's the only reason it failed. TWRP, however, doesn't care how much battery you have, so you could always flash the new boot.img in recovery.
Click to expand...
Click to collapse
Hey, hey, hey - think it worked!!
Once I got above 30%, I flashed without issue. I rebooted and was able to format an sd internally successfully, too. Now, I just need to verify it's rooted, but think it is. Thank you so much for your help! I'm going to write a guide for newbs like me to use in the future soon.
Thanks again!
bzowk said:
Hey, hey, hey - think it worked!!
Once I got above 30%, I flashed without issue. I rebooted and was able to format an sd internally successfully, too. Now, I just need to verify it's rooted, but think it is. Thank you so much for your help! I'm going to write a guide for newbs like me to use in the future soon.
Thanks again!
Click to expand...
Click to collapse
If your adopted storage doesn't show as corrupted, and you're able to open the SuperSU app in your app drawer and not get a message that no su binary is installed, you should be good to go .
bad topic

Magski replacing patched recovery (a70)

finally.... I got Odin to behave - (sadly) no idea what I did it just started working!
What I've ended up with is a fully working magski capable of installing modules and a debloated stock rom - gosh what a horrible user experience Samsung make for there users!
I'd rather not have to rely on the chopped down official recovery though, feeling much more secure with the extra tools available with twrp.
if I dd twrp I'll loose magski, so my question is, can magski patch a twrp img file and will dd'ing this to the recovery partition work, ie will I have twrp while retaining magski
Is there a "better" way to do this (twrp + magski) ?
TIA
Typically Magisk gets installed via TWRP and not the other way around.
AFAIK Magisk creates a new magisk.img partition in phone’s root directory, it also places necessary files in /cache and /data partition, but it does NOT patch /recovery partition. It's TWRP what completely replaces / removes phone's stock /recovery. But I may err as always ...
jwoegerbauer said:
Typically Magisk gets installed via TWRP and not the other way around.
AFAIK Magisk creates a new magisk.img partition in phone’s root directory, it also places necessary files in /cache and /data partition, but it does NOT patch /recovery partition. It's TWRP what completely replaces / removes phone's stock /recovery. But I may err as always ...
Click to expand...
Click to collapse
Samsung user are somewhat force to flash Magisk on recovery partition hence they have to choose between having rooted via Magisk or installing TWRP
But can magski patch a twrp image, for both ?
codifies said:
But can magski patch a twrp image, for both ?
Click to expand...
Click to collapse
After further research it turns out magski's patching is rather sophisticated. Throw an odin tar or raw image at it and it just gets and does the job right.
If like me you didn't want to leave the recovery with a dangerously crippled stock "recovery" it is possible to patch a raw img of twrp, which you can then dd (but please don't guess and DO go by the by-name path !)
I honestly don't know if patching twrp and using it with odin right from the get go is possible I had a nightmare getting windows/drivers/odin talking so I was relieved just getting the patched stock firmware to flash....
Its also a relief to be finally rooted, debloated, degoogled with a proper recovery, of course if samsungs UX wasn't so horrible I might not have bothered (providing all bloat could actually be disabled)... still at least it feels like I own what I bought now....
@ineedroot69 never managed to get twrp to flash on its own with odin, with unlocked bootloader saying it would only install official software... A70 seems to have a few extra layers of security...

Categories

Resources