Database Info

Am I crazy, or will this work?

Let's say I do a nandroid backup first
then I proceed to flash ROM 1
I then install some apps under ROM 1, and ran app 2 and saved some data inside (let's say a craigslist search)
If I now want to flash to ROM 2, how do I keep the apps/data that I did in ROM 1?
Can I do this
a) nandroid backup
b) wipe, then flash to ROM 2
c) grab data.img from nandroid, and flash data partition with data.img
Will this work?

Tried once, didnt work with me atleast. :S

According to another thread I read, you'll need to change your SPL to the engineering one for this to work.

It will work but you need to change your SPL otherwise you will get a Signature Verification (or something similar) when you flash.
I wouldn't mix ROM "types" though...ie. dont use a Cupcake based backup for a Hero ROM.
What you need to do is:
1. Flash SPL (carefully)
2. Boot to recovery and do a nandroid backup
3. WIpe the device
4. Flash the update to the new ROM.
5. adb pull /sdcard/nandroid/..../data.img .../local folder on computer/data.img
6. reboot the device but pull the battery when the first splash screen loads (otherwise you have to wait for the phone to boot and then power it back off)
7. While holding Back, insert the battery. This will boot you to fastboot mode
8.
Code:
fastboot boot userdata data.img
9.
Code:
fastboot reboot

Thanks for the detail
I assume you meant
Code:
fastboot flash userdata data.img
.
I have Google ION, and I have not had any problem flashing (yet)
I did play around with it, and I came across some problem
1) I installed a different launcher (Advanced Launcher), while the other ROM does not. When the phone start, it keep force close in home screen. I assume it's due to different launcher
2) I also installed HTC_CIME. Again, this does not exist in the other ROM. Since I can't get to home screen, I don't know if this will cause problem as well
It seems like if ROM1 and ROM2 contain the SAME system folder (at least the system apps), this might actually work
The reason I ask this question is I have been using Shazam to tag some songs, and I would like to save these tags. Shazam itself does not export tags
I assume these tagged data is somewhere under /data. Just need to figure out where...

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

[DUAL_BOOT][ANY_ANDROID]Dual booting in an android phone with external SD card

So here you come. To read and perform this tutorial, you obviously need a first hand experience on flashing a ROM and/or kernels. Otherwise this tutorial and my efforts to get you a device with two OSes running might end up giving you a bricked device. So, if you're hearing the terms "flashing" or 'kernels' for the first time and thinking it's kinda good food, then bro, just go and taste those first.
Something's to remind before we gonna dig deep into this tutorial->
Noone but you will be responsible for what you end up with.
The warranty of your device will be voided after this if it isn't already after rooting. For MI users, the good news is that you can reclaim it by just flashing the fastboot ROM for your device.
Enough lectures. Bro let's get to work.
Things you'll be needing =>
One working Windows PC(because I doesn't know any replacement of bootimg.exe on any other OS. If you know, then let me).
ADB, fastboot and the device drivers (easily found in XDA)
Any custom CWM based recovery installed.(since TWRP is most popular, I will demonstrate using it. You can use any other you want overall process will be the same)
A custom ROM and kernel for your phone(the second os)
A class 10 memory card ( I recommend 32GB for the spaces)
PART 1: MODIFYING THE BOOT
At first, how does your device boots up? What are the partitions called /data and /system? The answer is quite simple. It's your kernel that points out the location from where the OS should be picked up. So for booting into the second OS we need some modifications to it at first.
Search and download bootimg.exe on XDA, I'll post a link later. Create two folders. Name them "Internal OS" and "External OS" respectively. Put the zip file of the OS you're currently using to the first one and the OS you're gonna use on the external storage to the second one. Rename the second OS to originalExternalOS.zip. Extract originalExternalOS.zip. Pick the boot.img file from the root of the extracted folder and move it to a new folder named "boot2". Extract the IMG using bootimg.exe. Navigate to the initrd folder and you will get a file named 'fstab".
Basically it's the file that tells the kernel which partition does the OS resides in.
Open the file in your favourite text editor.
Replace every instance of the first line with the second one:
/dev/block/bootdevice/by-name/system => /dev/block/mmcblk1p2
/dev/block/bootdevice/by-name/userdata => /dev/block/mmcblk1p3
/dev/block/bootdevice/by-name/cache => /dev/block/mmcblk1p4
Save the file without giving any extension to it. Repack it using the same tool. You'll have boot-new.img and boot-old.img. Rename boot-new.img to boot.img and replace the one in the root folder with this. Basically what we're doing here is replacing the old boot.img with the modified one.
For your knowledge, blocks are the partitions of any storage you have on your device. For example, your internal storage is partitioned to near about 30 different blocks each starting with prefix "mmcblk0p". We here just told the kernel to load the OS from the blocks mentioned. We'll be creating these blocks in the external SD card next.
PART 2: PARTITIONING THE SD CARD
Connect your device with the memory card inserted to your PC. If you haven't installed fastboot, ADB, and the drivers, do it now.
READ THE FOLLOWING CAREFULLY
Reboot the device to recovery mode. Type the commands in cmd:
Code:
adb shell
parted
unit MB
print
quit
umount external_sd
Read and store the minimum and maximum capacity of your card. Since different cards will have different capacities I will point it as variable MIN_SIZE and MAX_SIZE. You'll need to calculate and put the values in the commands. Now type the following commands on cmd:
Code:
parted /dev/block/mmcblk1
rm 1
//START_BLOCK = MAX_SIZE - 5000
mkpartfs primary fat32 MIN_SIZE START_BLOCK
//SYS_START = START_BLOCK+1
//SYS_END = SYS_START + 1200
mkpartfs primary ext2 SYS_START SYS_END
//DATA_START = SYS_END+1
//DATA_END = DATA_START + 3500
mkpartfs primary ext2 DATA_START DATA_END
//CACHE_START = DATA_END + 1
mkpartfs primary ext2 CACHE_START MAX_SIZE
//We have partitioned the memory card. Let's format them. Ignore all "Do you wish to continue" question in the next commands as we're already mentioning yes.
mkfs yes 1 fat32
mkfs yes 2 ext2
mkfs yes 3 ext2
mkfs yes 4 ext2
quit
//Now they are almost ready. Just make the newly created blocks readable by the OS.
make_ext4fs /dev/block/mmcblk1p2
make_ext4fs /dev/block/mmcblk1p3
make_ext4fs /dev/block/mmcblk1p4
//Now you get where does the blocks come in the kernel right?
exit
//You've covered up the hardest part. Let's get some coffee.
PART 3: MODIFYING THE NEW OS
You've left the OS extracted in the "External OS" folder right? It's time to do some magic in it. We're gonna tell the OS to be installed in the blocks we created just like the kernel. But wait, where does the OS know before installing where it should get installed? Well, the answer hides in the updater-script in the folder META-INF > com > google > android. Navigate yourself in it. Open the updater-script file in your favourite editor ( I use notepad++ ) and modify it in the same way as the boot.
Replace every instance of the first line with the second one:
/dev/block/bootdevice/by-name/system => /dev/block/mmcblk1p2
/dev/block/bootdevice/by-name/userdata => /dev/block/mmcblk1p3
Leave the /dev/block/bootdevice/by-name/boot as it's the fundamental block and we can't replicate it. Don't think for the /cache partition as we've already done that in the boot.img file. Now navigate to the root of the folder where you extracted the External OS. Select all files, add them to a zip file using WinRAR. Name the file to newOS.zip. Open newOs.zip and originalExternalOS.zip with WinRAR and compare them if you find any change in the folder tree. They must and they should be exactly the same. You're 80% done.
PART 4: MODIFYING THE RECOVERY
We often flash many zips including very popular Xposed and other mods to our OS right? They also look for the /system partition. So what are we gonna do? Modifying each of them? Nah. Let's modify where they get which one the /system is. The recovery. Extract the img of the recovery you're using with the same bootimg.exe. Modify exactly the same things. I.e.
Replace every instance of the first line with the second one:
/dev/block/bootdevice/by-name/system => /dev/block/mmcblk1p2
/dev/block/bootdevice/by-name/userdata => /dev/block/mmcblk1p3
/dev/block/bootdevice/by-name/cache => /dev/block/mmcblk1p4
in the following files : initrd/fstab.qcom
initrd/etc/recovery.fstab
initrd/etc/twrp.fstab(For TWRP only)
Save them. Repack. And you got your recovery-new.img and recovery-old.img. Put recovery-new.img and newOS.zip in the same folder. Now wake up, it's time for some action.
PART 5 : INSTALLING THE OS
Open cmd in the folder where newOS.zip resides. Reboot the device in fastboot mode. Type the following commands:
Code:
adb push newOS.zip external_sd
fastboot flash recovery recovery-new.img
fastboot boot recovery
Now your device should boot up in recovery mode. To check if everything has gone fine mount system using TWRP. Use twrp's built in file manager and navigate to system folder. It's empty? Yup. You've done a great job. Now flash the newOS.zip using TWRP and your device should boot up in the new OS. To cross check again remove the SD card and try to boot. If you're headed towards recovery or bootloop after that then it's a win. Put the SD card back again and watch the new OS to boot.
PART 6: SWITCHING BETWEEN THE TWO
Extract the boot.img from the "Internal OS" zip file and put it together with recovery-old.img. To check if your old system is untouched type the following commands in fastboot mode:
Code:
fastboot flash recovery recovery-old.img
fastboot flash boot boot.img
fastboot boot system
Your device should take you back to the old one. Surprised? Now let's make a switch between the two. There are two methods.
METHOD 1: USING FLASHIFY
Create two folders in your SD card. Put boot.img and recovery-old.img to one and boot-new.img and recovery-new.img to the other. To switch to the external OS, just flash boot-new.img as boot and recovery-new.img using flashify. Ignore reboot now dialog and reboot directly to the system. To go back, first install flashify in the new OS and flash boot.img and recovery-old.img. Easy right?
METHOD 2: USING ZIPS
I'm gonna tell you that tomorrow as I can write no more today.
More to come....
CREDITS:
justzzshadz from MIUI forum for this revolutionary concept. @iamsubhranil for adding TWRP, Flashify support and completely rewriting the tutorial.

Thank u so much for ur efforts... It helps me a lot
I don't understand members on xda ...why they don't give thnaks on thread ..they only see the thread and go away...
Sry 4 my english ..
Thanks again
---------- Post added at 08:07 AM ---------- Previous post was at 07:48 AM ----------
Pls lemme know that if i can use dsixda's kitchen for modifying boot.img (kernal ) ???
Coz i didn't find bootimg.exe tool... If u have then pls give me the link.
Thanks

yes you can use android kitchen

When You Will Continue Writing The Thread Im Really Interested in trying it

Faisal Z Ahmad said:
When You Will Continue Writing The Thread Im Really Interested in trying it
Click to expand...
Click to collapse
I will after a while as I'm having final exams you can still try with flashify bro

sc123001.11 said:
Thank u so much for ur efforts... It helps me a lot
I don't understand members on xda ...why they don't give thnaks on thread ..they only see the thread and go away...
Sry 4 my english ..
Thanks again
---------- Post added at 08:07 AM ---------- Previous post was at 07:48 AM ----------
Pls lemme know that if i can use dsixda's kitchen for modifying boot.img (kernal ) ???
Coz i didn't find bootimg.exe tool... If u have then pls give me the link.
Thanks
Click to expand...
Click to collapse
http://forum.xda-developers.com/redmi-1s/general/guide-unpack-repack-kernel-t2908458
Most comfortable

iamsubhranil said:
I will after a while as I'm having final exams you can still try with flashify bro
Click to expand...
Click to collapse
Yeah I Know I Can Try But i Need To Know Method 2 To Switch ROMS Because Second One Is Faster Using Zips Otherwise Great Post And Guide ,Thank You
Good Luck With Your Exams

Nice tutorial.
Dual boot for Mediatek devices is so easy to me. But I don't have any idea for Other devices like Samsung or Sony.
When I bought some SD Card, I'll try this one.
Keep it up!

Faisal Z Ahmad said:
Yeah I Know I Can Try But i Need To Know Method 2 To Switch ROMS Because Second One Is Faster Using Zips Otherwise Great Post And Guide ,Thank You
Good Luck With Your Exams
Click to expand...
Click to collapse
Thanx a lot
BTW flashify is also very convenient method
1)Just choose boot image from the option
2)Find and select the internal or external boot image to boot
3)Have a normal reboot

jbliz said:
Nice tutorial.
Dual boot for Mediatek devices is so easy to me. But I don't have any idea for Other devices like Samsung or Sony.
When I bought some SD Card, I'll try this one.
Keep it up!
Click to expand...
Click to collapse
This one is universal bro

iamsubhranil said:
This one is universal bro
Click to expand...
Click to collapse
I did not see you make any modification to boot.img.
Sry My bad. I didn't read at the top.

iamsubhranil said:
Thanx a lot
BTW flashify is also very convenient method
1)Just choose boot image from the option
2)Find and select the internal or external boot image to boot
3)Have a normal reboot
Click to expand...
Click to collapse
I am gonna try this anyway, maybe tomorrow
Because i want two ROMS mainly, one for CM cuz i love it, daily drivers and everday usage, second one mainly focused on battery life (when i don't use my device much)

Another Question ,How do I Flash Zips (from recovery) To A Specific ROM?
And I Have CM 12.1 And Im Using M5 Kernel so Where Do the Edit Goes?

Faisal Z Ahmad said:
Another Question ,How do I Flash Zips (from recovery) To A Specific ROM?
And I Have CM 12.1 And Im Using M5 Kernel so Where Do the Edit Goes?
Click to expand...
Click to collapse
The edit goes to the recovery. At the end of the process you'll have two different recovery files for two OSes. Flashing any zips via modified recovery will flash them straight to the new os. Switch between those recoveries as required. Read the TUT carefully.

Advanced OTA keeping Magisk and TWRP (needs a computer)

History...
I originally wrote this guide to upgrade from 10.0.4.0 to 10.0.7.0.
I have also used this same guide to install every OTA from 10.0.7.0 to 11.0.11.0.
This guide assumes you have both Magisk and TWRP, that Magisk cannot "uninstall" (because of TWRP installation) and that you want to keep both Magisk and TWRP after installation. Parts of this guide may still be useful if you aren't in this exact situation.
If you only have Magisk, you should be able to follow these much simpler instructions: https://forum.xda-developers.com/mi-a2-lite/how-to/guide-install-magisk-proper-support-ota-t3836952
Things to have on hand:
- vanilla_boot.img (for the version you currently have)
- patched_boot.img (your current boot image with Magisk)
- TWRP img and zip (see version info below)
I think that TWRP also causes the vendor partition to be modified. It may also touch system but I have a modified bootanimation.zip which modifies system, so I can't be sure. In any case, I also have a backup of system.img and vendor.img.
Because Magisk is installed after TWRP, Magisk's "backup" of the "stock boot image" is not vanilla. This means that in order to take the OTA, I have to flash the vanilla boot image.
0 - Update your patched_boot.img
If you don't have a patched_boot.img for your current Magisk (eg. my patched_boot.img was old, since I had installed several Magisk updates), you should build a new patched_boot.img so that when you boot it, the system will continue to work.
Push the vanilla image to the phone.
Code:
adb push vanilla_boot.img /sdcard
Then get Magisk to install using the "Select and Patch a File" method, select the file you uploaded. Then pull down the patched image.
Code:
adb pull /sdcard/Download/magisk_patched.img patched_boot.img
1 - Prepare to OTA
For some reason, my carrier does not like the OTA process so I always turn on Airplane mode + Wifi.
Get to fastboot and check the current slot.
Code:
adb reboot bootloader
fastboot getvar current-slot
My current slot was b
Flash the system and vendor partitions (if necessary).
Code:
fastboot flash system_b vanilla_system.img
fastboot flash vendor_b vanilla_vendor.img
Flash vanilla and boot the patched image (so that Magisk is active and the OTA can be applied).
Code:
fastboot flash boot_b vanilla_boot.img
fastboot boot patched_boot.img
2 - Do the OTA
Install OTA (DO NOT REBOOT)
If the OTA fails
If the OTA fails, you can find out which partitions it doesn't like from the logcat. If you have a fastboot image, you can reflash the affected partitions. As previously mentioned, I've had to flash all of boot, vendor and system for each OTA.
Code:
adb logcat | grep update_engine
...
07-01 06:52:38.470 E/update_engine(935): [0701/065238.470683:ERROR:delta_performer.cc(990)] The hash of the source data on disk for this operation doesn't match the expected value. This could mean that the delta update payload was targeted for another version, or that the source partition was modified after it was installed, for example, by mounting a filesystem.
07-01 06:52:38.470 E/update_engine(935): [0701/065238.470931:ERROR:delta_performer.cc(995)] Expected: sha256|hex = A4AD686D7BF628486668446221D0089BF5915DBC1158C83D30A06222FE7D2ACB
07-01 06:52:38.471 E/update_engine(935): [0701/065238.471002:ERROR:delta_performer.cc(998)] Calculated: sha256|hex = 4CADBE88EC1C019913A0B416EB9031840D4BA6B2287A3FC814A2B8B7F9871F7D
07-01 06:52:38.473 E/update_engine(935): [0701/065238.471072:ERROR:delta_performer.cc(1009)] Operation source (offset:size) in blocks: 0:5221,5461:405,5869:1,5873:343,6221:589
07-01 06:52:38.473 E/update_engine(935): [0701/065238.473233:ERROR:delta_performer.cc(1191)] ValidateSourceHash(source_hash, operation, source_fd_, error) failed.
07-01 06:52:38.473 E/update_engine(935): [0701/065238.473340:ERROR:delta_performer.cc(298)] Failed to perform BROTLI_BSDIFF operation 187, which is the operation 0 in partition "boot"
07-01 06:52:38.473 E/update_engine(935): [0701/065238.473411:ERROR:download_action.cc(337)] Error ErrorCode::kDownloadStateInitializationError (20) in DeltaPerformer's Write method when processing the received payload -- Terminating processing
07-01 06:52:38.739 E/SystemUpdate(15410): [Execution,NonStreamingAbApplyAction] Installation failed with error code: 20.
3 - Backup the vanilla boot image
Note that you need to pull from the other slot (in my case, a).
Code:
adb shell
su
dd if=/dev/block/by-name/boot_a of=/sdcard/vanilla_boot.img bs=1024k
Backup system.img and vendor.img too (if required).
Code:
dd if=/dev/block/by-name/system_a of=/sdcard/vanilla_system.img bs=1024k
dd if=/dev/block/by-name/vendor_a of=/sdcard/vanilla_vendor.img bs=1024k
4 - Magisk patch the other slot
Use Magisk to "Install to Inactive Slot (After OTA)" (DO NOT REBOOT)
5 - Backup the patched boot image
Note that you need to pull from the other slot (in my case, a).
Code:
dd if=/dev/block/by-name/boot_a of=/sdcard/patched_boot.img bs=1024k
exit
exit
# back on your computer
adb pull /sdcard/vanilla_boot.img
adb pull /sdcard/patched_boot.img
Pull down system and vendor images too (if required).
Code:
adb pull /sdcard/vanilla_system.img
adb pull /sdcard/vanilla_vendor.img
Now you can let Magisk reboot. This is the moment of truth...
At this point you should have an upgraded, Magisk-enabled system and backups of the vanilla and patched boot images. Congratulations on completing the OTA!
If the system fails to boot
There's a few things to try before giving up if the system fails to boot...
1) Boot without Magisk (fastboot boot vanilla_boot.img). Probably indicates that a Magisk module you have is no longer compatible.
2) Boot TWRP (fastboot boot twrp.img) and poke at things. As an example, I used the /sdcard/mm program (part of Magisk Manager for recovery) to disable EdXposed when the OTA to Android 10 failed to boot.
6 - Restore TWRP
It is possible to boot TWRP from fastboot so you don't strictly need to install TWRP. I like to have it available anyway.
Old version info...
I had been using the official TWRP 3.2.3, which worked great up until 10.0.9.0. With 10.0.9.0, I couldn't get to TWRP, I just got the system destroyed screen. I could fastboot boot it, but it couldn't mount /data (a problem it has always had).
I figured out that TWRP 3.3.1-dees_troy (from the official TWRP site) works with 10.0.9.0 and up. What's more, it works (can decrypt /data) if you fastboot boot it, not just after install. So you could in theory simply not install TWRP and fastboot boot if in the event that you actually need it.
I know that people have their own favourite versions, with the offain version being popular (didn't work for me). There's OrangeFox too (also didn't work for me).
In summary, I recommend Official TWRP 3.3.1-dees_troy but if you have a favourite alternative, feel free to use it instead.
TWRP thread: https://forum.xda-developers.com/mi-a2-lite/development/official-twrp-daisy-t3855396
Download link: https://dl.twrp.me/daisy/
Restoring TWRP is the same as installing it the first time. This is the process that I use.
Flash vanilla boot, then install TWRP to it.
Code:
adb reboot bootloader
fastboot boot twrp-3.3.1-dees_troy-daisy.img
Install TWRP
Code:
adb push twrp-installer-3.3.1-dees_troy-daisy.zip /sdcard
Use TWRP to install twrp-installer-3.3.1-dees_troy-daisy.zip
I install my modified bootanimation.zip at this time.
Mount System from TWRP (it is normally already mounted for me).
From a shell:
Code:
adb shell
cd /sdcard
cp bootanimation.zip /system/system/media/bootanimation.zip
Umount System
You must re-install Magisk after installing TWRP.
Code:
adb reboot bootloader
fastboot boot patched_boot.img
Use Magisk to "Direct Install (Recommended)"
Reboot
For some reason, my carrier does not like the OTA process so at this point I normally power off the phone rather than just rebooting. When the phone boots, I can turn off airplane mode and check that a mobile data connection can be made.
7 - Confirm that everything works
Make sure the system comes up and Magisk Manager says that Magisk is installed.
Make sure you can get to TWRP. Boot while holding VOL+ or
Code:
adb reboot recovery
Make sure TWRP can see your files.
Congratulations! You have installed an OTA while keeping Magisk and TWRP!
8 - Backup boot.img with TWRP + Magisk (optional)
If you want a copy of the boot.img with both Magisk and TWRP. This pulls from the now-current slot (in my case, a). I'm not totally sure of the value of this, since I can't get fastboot to boot this image. It may come in handy if you upgrade TWRP and that breaks (since you can flash this back rather than having to install the old TWRP again).
Code:
adb shell
su
cd /sdcard
dd if=/dev/block/by-name/boot_a of=twrp_boot.img bs=1024k
exit
exit
# back on the computer
adb pull /sdcard/twrp_boot.img

Thanks. Could you upload or indicate where we can get the necessary files?

Will i loose all user data and internal storage wiped if i do this?

Thanks for sharing, looks complicated, also i think you should use a fixed twrp, since the official dont have acces to sdcard.

rossarnie said:
Thanks. Could you upload or indicate where we can get the necessary files?
Click to expand...
Click to collapse
If you have Magisk, you should already have the vanilla and patched boot.img files.
Of you don't already have Magisk, just follow the install procedure here. https://forum.xda-developers.com/mi-a2-lite/how-to/guide-install-magisk-proper-support-ota-t3836952
If you're running 10.0.4.0 without magisk and need to extract your vanilla boot.img. Use fastboot to boot into twrp and then you can do the DD command to extract boot. Use adb pull to save it to PC.
I used official TWRP from here.
https://forum.xda-developers.com/mi-a2-lite/development/official-twrp-daisy-t3855396
Apparently there's a different twrp that can access the external SD card. I don't have an external SD card so I don't need it.

dr.bahaeddin said:
Will i loose all user data and internal storage wiped if i do this?
Click to expand...
Click to collapse
I didn't lose any data.
I've never had a problem with Magisk. TWRP does tend to bootloop after install, which is why I install magisk again.
You should be able to flash the patched or vanilla boot if twrp is boot looping to fix it too. Just won't have twrp anymore.

a1291762 said:
I didn't lose any data.
Click to expand...
Click to collapse
Mind you. I have a backup of my apps and data that's off of my phone so even if I do need to factory reset I can get it back. That's a longer and more complicated guide.

Txatxiquesi said:
looks complicated.
Click to expand...
Click to collapse
Before I had twrp the standard Magisk ota process was enough. But that loses twrp and with twrp in my magsik backup, the uninstall didn't work. So extra steps are needed. Plus some extra steps to make backups of important files for the next OTA

a1291762 said:
If you have Magisk, you should already have the vanilla and patched boot.img files.
Click to expand...
Click to collapse
Hmm... This may not be the case. I'm careful to make backups but it's easy to skip this.
If you don't have a patched boot image you can backup your current boot partition from a root shell. You need to find out if you are booting a or b slot. Then
dd if=/dev/block/by-name/boot_a of=/sdcard/patched_boot.img bs=1024k
Magisk puts old stock backups into /data. I had 4 files in there which makes it hard to know what each file is.
That's why I made sure to backup my vanilla boot image immediately.
If you're stuck without a vanilla 10.0.4.0 boot you can't do the OTA. I can upload mine somewhere when I get home tonight if it's not already online.

a1291762 said:
...If you're stuck without a vanilla 10.0.4.0 boot you can't do the OTA. I can upload mine somewhere when I get home tonight if it's not already online.
Click to expand...
Click to collapse
This would be very helpful, please

FunkmasterC said:
This would be very helpful, please
Click to expand...
Click to collapse
Here is the backup I made of the 10.0.4.0 vanilla boot.img. You'll need to decompress this before flashing.
URL REMOVED

What's new on 10.0.7.0 bro? Should me wait for 10.1 update if im on 10.0.4.0 rooted?

10.0.7.0 has the March security patches. I haven't noticed any actual changes.

Thank you, your Linux commands are sick, I never know I can get the vanilla and patched boot.img like that.
Cheer~

is there an update for file version 10.0.8.0??

I only just got the notification this morning. I'll do the upgrade tonight but I expect the same process will work.

I just used the same process to go from 10.0.7.0 to 10.0.8.0. This time I was installing to slot b instead of slot a, but otherwise, things were the same.
A side note... I hadn't got around to installing TWRP 3.3.0 so I did that but it couldn't mount /data. TWRP 3.2.3 can mount /data, so I installed that again.

a1291762 said:
I just used the same process to go from 10.0.7.0 to 10.0.8.0. This time I was installing to slot b instead of slot a, but otherwise, things were the same.
A side note... I hadn't got around to installing TWRP 3.3.0 so I did that but it couldn't mount /data. TWRP 3.2.3 can mount /data, so I installed that again.
Click to expand...
Click to collapse
I have successfully updated to 10.0.8.0 with Magisk 18.1, now on Magisk 19.1, everything is running fine. I'd like to also install TWRP but refrain from doing so because of the problems (bootloops, crashes, etc) the official TWRP 3.2.3 shows with decryption in Pie and mounting external or even internal sdcard. I wonder if the latter is fixed in the inofficial fixed version. I think the benefit of TWRP is not worth the effort of repeating a1291762 wonderful tricky procedure on the monthly OTA update basis.
However the procedure is very smart, a back-to-the-roots approach of former days... great, I like it.
But I don't understand how a patched_boot.img can be created from an empty file (boot_a)?
[dd if=/dev/block/by-name/boot_a of=patched_boot.img bs=1024k] Locating the boot_a in </dev/block/by-name/> reveals a boot_a file with 0 bytes. Moreover, to unzip the zipped stock boot Image in </data/stock_boot*.img> or </sbin/.magisk/mirror/data/> I am looking for a command that just returns the boot file rather than expanding it to the full partition. Weird, can anybody help?
Thanks again to a1291762
grufty47
It appears that it is not possible to add some boot.img as attachment

grufty47 said:
I'd like to also install TWRP but refrain from doing so because of the problems (bootloops, crashes, etc) the official TWRP 3.2.3 shows with decryption in Pie and mounting external or even internal sdcard.
Click to expand...
Click to collapse
I use official TWRP 3.2.3. Only really to fix bootloop problems.
I don't have a SD and no problems mounting data.
Lots of people following the TWRP install guide seem to get bootloop. I solve that by patching boot with Magisk. Some people recommend installing an old about image.
If you have a backup of boot you can at least restore that if you have problems.
grufty47 said:
But I don't understand how a patched_boot.img can be created from an empty file (boot_a)?
Click to expand...
Click to collapse
Welcome to Unix, where nearly everything is a file.
Hard disk? /dev/sda
Partition? /dev/sda1
File? /mnt/sda1/file.txt
In this case, boot_a is a way to access a partition on the phone's flash. Actually a link (shortcut) to /dev/mmcblk0p52. Partition number 53 on flash chip 1. The size can't be seen because it's a device and not a file.
grufty47 said:
I am looking for a command that just returns the boot file rather than expanding it to the full partition.
Click to expand...
Click to collapse
dd is a command to read a device. The partition is 64M big so that's the size of the file. gzip can compress well because the actual image is only 24M big and the rest is empty.
Magisk knows how to do it. A tool called magiskboot but I don't know where it lives or how to run it.
I found this header from magiskboot. It shows how the boot.img is structured.
https://github.com/topjohnwu/Magisk/blob/master/native/jni/magiskboot/bootimg.h

I just did the 10.0.9.0 OTA. I added a section of updating your patched_boot.img (since the Magisk updates I did made my old one useless) and I changed the backup instructions due to changes in Magisk 19. If you know where the stock boot lives before reboot, please let me know.

Questions on Using TWRP and A/B Slot Switching

This is my first time starting a new thread, so here goes.
Since getting a new (to me) One Plus 7 Pro Android device which supports (also new to me) A/B partition slots, I have learned more than I ever expected to about A/B slots. However, the one area that is still quite confusing and unknown is Slot Switching. What follows is a list of questions for which I have found only sketchy answers, or no answers at all. I submit them here in the hopes that these are questions which others also struggle with and that there are some folks who actually know the definitive answers and can supply them here.
Device Selection/Switching of Active Slot on Reboot
When the device boots system (not recovery), does it attempt to switch slots each time?
Does it check the inactive slot to see if there is something newer there?
If so, what are all the flags it checks?
What are all the conditions and actions that set those flags?
Can these be manually manipulated, and if so how?
Can these flags be checked/read, and if so how?
When a new ROM update is applied, is it applied to the inactive slot? What causes (and when) the active slot to be changed? What exactly (flags?) governs/affects that change and how?
Restoring TWRP Backup
Assuming the active slot is A, when booting to recovery and restoring a TWRP backup, does the backup get restored to slot A (active slot), or slot B (inactive slot)?
After restoring, which slot does the device attempt to boot from? See questions under 'Device Selection/Switching of Active Slot on Reboot'.
If trying to fix a bootloop (stuck on boot animation), restoring a TWRP backup doesn't seem to work. It only seems to make matters worse, and sometimes it actually DOES work as expected. Why?
How can we use a backup to overwrite the slot that is causing the bootloop and thereby resolve the problem by restoring 'known working state' that was backed up? What's going on here? I think this goes back to the questions under 'Device Selection/Switching of Active Slot on Reboot'.
Installing .zip Files in TWRP
When installing a .zip file in TWRP, does this go to the active or inactive slot? Is this determined by the .zip file or is it a constant?
When using the Wipe options, is the active slot being wiped (or reformatted, etc.), or the inactive slot?
Do various .zip files, be they gapps, Magisk, or a custom ROM have within them directives that either do or do not cause the active slot to change?
If so, does this mean that the active slot may or may not be changed by a given .zip file installed with TWRP?
Again assuming the .zip files can and do dictate active slot switching, is there a way to tell whether a .zip file will switch the active slot or a rule of thumb that says which .zip files will or won't switch the active slot?
If a .zip install *does* switch active slots, when is the active slot actually switched? Immediately, so that the next action (e.g. next .zip file installed) would be destined for the new active slot, or after a subsequent reboot?
Thanks to anyone who can help with these questions. I truly believe that having a firm understanding of the answers here will help me and others avoid lengthy and problematic updates and installs.
- Alpha_Geek1

Moderator(s) - I recognize that this might be too much for a single post, and I'm hoping that is most or part of why there have been no replies. Would perhaps asking one, or at least fewer, question(s) per post be a better approach? If so, how do I address that? Do I create a series of posts that reference this one, or delete this one and make all free-standing posts in this section? Ultimately, I think it would be really useful to have all this information in one place.
I really need this information to be confident updating my device. As it is, unless I am prepared to multi-brick and dig my way out over the course of a day or more, I am not doing any updates, installs, or restores.
Thank you!
- Alpha_Geek1

That's a lot!
I'm not a specialist in that but I'll try to explain as much as I can.
Device:
-Device only switch slots after installing an update or when you install magisk to the inactive slot or in special conditions like something woes wrong with the update and it changes to the other slot avoiding a brick.
-i guess it doesn't check data from inactive slot regularly, even when you install a rom or OTA , it just will format the partitions.
-you can always change slots manually, in TWRP or with fastboot command(fastboot --set-active=a, fastboot --set-active=b or fastboot--set-active=other)
Restoring
-when restoring your active slot will be the bootable, if you want to boot the inactive slot(old version of oos or ROM) without installing an update you need to switch slots and flash magisk.
-a boot loop could be a problem caused by many things, you need to find out what was, so in case you ended in boot loop because an update (stock or ROM) you can go back to the previous installed version just switching slots via TWRP or fastboot command(fastboot --set-active=OTHER[this in case you don't know which slot is active/inactive]) and flash magisk(this will force to boot in that slot)
-if you had a TWRP backup of a working state of your device you can restore it in any slot, only keep in mind that if you want to downgrade, format data is mandatory.
TWRP Flashing
- in a/b devices roms/OTA will be installed to the inactive slot ALWAYS that's why we can go back to the previous version just switching slots, if you want to flash a rom to the active slot you can do that extracting partitions from payload.bin with a payload dumper(this method is used in android 11 roms right now because of the lack of working TWRP ) and flash one by one partition with fastboot command.
-After flashing a rom you need to reboot to recovery in order to flash magisk, Gapps, kernel, and other mods, because in the moment you flash a rom you are in the active slot but your rom is flashed to the inactive slot, so when you reboot to recovery you let the device switch to the slot where your rom is, so after that reboot you can now flash all your mods.
The next questions about a imaginary switching zip are unnecessary because there's no zip like that, so no need to worry about that

RokCruz said:
That's a lot!
I'm not a specialist in that but I'll try to explain as much as I can.
Device:
-Device only switch slots after installing an update or when you install magisk to the inactive slot or in special conditions like something woes wrong with the update and it changes to the other slot avoiding a brick.
-i guess it doesn't check data from inactive slot regularly, even when you install a rom or OTA , it just will format the partitions.
-you can always change slots manually, in TWRP or with fastboot command(fastboot --set-active=a, fastboot --set-active=b or fastboot--set-active=other)
Restoring
-when restoring your active slot will be the bootable, if you want to boot the inactive slot(old version of oos or ROM) without installing an update you need to switch slots and flash magisk.
-a boot loop could be a problem caused by many things, you need to find out what was, so in case you ended in boot loop because an update (stock or ROM) you can go back to the previous installed version just switching slots via TWRP or fastboot command(fastboot --set-active=OTHER[this in case you don't know which slot is active/inactive]) and flash magisk(this will force to boot in that slot)
-if you had a TWRP backup of a working state of your device you can restore it in any slot, only keep in mind that if you want to downgrade, format data is mandatory.
TWRP Flashing
- in a/b devices roms/OTA will be installed to the inactive slot ALWAYS that's why we can go back to the previous version just switching slots, if you want to flash a rom to the active slot you can do that extracting partitions from payload.bin with a payload dumper(this method is used in android 11 roms right now because of the lack of working TWRP ) and flash one by one partition with fastboot command.
-After flashing a rom you need to reboot to recovery in order to flash magisk, Gapps, kernel, and other mods, because in the moment you flash a rom you are in the active slot but your rom is flashed to the inactive slot, so when you reboot to recovery you let the device switch to the slot where your rom is, so after that reboot you can now flash all your mods.
The next questions about a imaginary switching zip are unnecessary because there's no zip like that, so no need to worry about that
Click to expand...
Click to collapse
Thank you for your answer!
I wish I could say I'm not confused about any of this anymore. The most confusing part of your answer is the last part where you say 'after flashing a ROM, you need to reboot to recovery in order to flash...'. Earlier you said that '...[ROMs] will be installed to the inactive slot always...'. So why would I need to reboot? If I am in TWRP, installing everything to the inactive slot, why would I not install the ROM .zip, then install all the other .zip files (Gapps, Magisk, TWRP, etc.) all at once in one go? They're all going to the same inactive slot.. right? What am I missing here? If I reboot recovery does the slot switch? If it does, then wouldn't I be installing to the other slot once I reboot to TWRP? This is why I think I need to understand exactly when and why the slots switch in all the cases where the slots do or don't switch.
The reason I asked the question about the .zip files dictating which slot they go to is because I know that it is possible. The TWRP install .zip file is capable of directing itself to both slots, so ANY installable (in TWRP) .zip file can presumably contain similar directives.. right?
I think we all need to definitively understand the exact inner workings of all this stuff, at least conceptually, if we are to confidently avoid creating unexpected problems for ourselves out of ignorance.

Alpha_Geek1 said:
Thank you for your answer!
I wish I could say I'm not confused about any of this anymore. The most confusing part of your answer is the last part where you say 'after flashing a ROM, you need to reboot to recovery in order to flash...'. Earlier you said that '...[ROMs] will be installed to the inactive slot always...'. So why would I need to reboot? If I am in TWRP, installing everything to the inactive slot, why would I not install the ROM .zip, then install all the other .zip files (Gapps, Magisk, TWRP, etc.) all at once in one go? They're all going to the same inactive slot.. right? What am I missing here? If I reboot recovery does the slot switch? If it does, then wouldn't I be installing to the other slot once I reboot to TWRP? This is why I think I need to understand exactly when and why the slots switch in all the cases where the slots do or don't switch.
The reason I asked the question about the .zip files dictating which slot they go to is because I know that it is possible. The TWRP install .zip file is capable of directing itself to both slots, so ANY installable (in TWRP) .zip file can presumably contain similar directives.. right?
I think we all need to definitively understand the exact inner workings of all this stuff, at least conceptually, if we are to confidently avoid creating unexpected problems for ourselves out of ignorance.
Click to expand...
Click to collapse
Yeah the ROM and only the ROM will be installed to the inactive slot, gapps, magisk don't have the option(in my knowledge any gapps package has the ability to do that) to install to the inactive slot(in recovery) that's why we need to reboot to recovery again and let the system change slots.
For that directive could be many situation that prevents the installation of that zips, all of that are out of my knowledge.
You need to ask someone specialized in that area.

Alpha_Geek1 said:
This is my first time starting a new thread, so here goes.
Since getting a new (to me) One Plus 7 Pro Android device which supports (also new to me) A/B partition slots, I have learned more than I ever expected to about A/B slots. However, the one area that is still quite confusing and unknown is Slot Switching. What follows is a list of questions for which I have found only sketchy answers, or no answers at all. I submit them here in the hopes that these are questions which others also struggle with and that there are some folks who actually know the definitive answers and can supply them here.
Device Selection/Switching of Active Slot on Reboot
When the device boots system (not recovery), does it attempt to switch slots each time?
Does it check the inactive slot to see if there is something newer there?
If so, what are all the flags it checks?
What are all the conditions and actions that set those flags?
Can these be manually manipulated, and if so how?
Can these flags be checked/read, and if so how?
When a new ROM update is applied, is it applied to the inactive slot? What causes (and when) the active slot to be changed? What exactly (flags?) governs/affects that change and how?
Restoring TWRP Backup
Assuming the active slot is A, when booting to recovery and restoring a TWRP backup, does the backup get restored to slot A (active slot), or slot B (inactive slot)?
After restoring, which slot does the device attempt to boot from? See questions under 'Device Selection/Switching of Active Slot on Reboot'.
If trying to fix a bootloop (stuck on boot animation), restoring a TWRP backup doesn't seem to work. It only seems to make matters worse, and sometimes it actually DOES work as expected. Why?
How can we use a backup to overwrite the slot that is causing the bootloop and thereby resolve the problem by restoring 'known working state' that was backed up? What's going on here? I think this goes back to the questions under 'Device Selection/Switching of Active Slot on Reboot'.
Installing .zip Files in TWRP
When installing a .zip file in TWRP, does this go to the active or inactive slot? Is this determined by the .zip file or is it a constant?
When using the Wipe options, is the active slot being wiped (or reformatted, etc.), or the inactive slot?
Do various .zip files, be they gapps, Magisk, or a custom ROM have within them directives that either do or do not cause the active slot to change?
If so, does this mean that the active slot may or may not be changed by a given .zip file installed with TWRP?
Again assuming the .zip files can and do dictate active slot switching, is there a way to tell whether a .zip file will switch the active slot or a rule of thumb that says which .zip files will or won't switch the active slot?
If a .zip install *does* switch active slots, when is the active slot actually switched? Immediately, so that the next action (e.g. next .zip file installed) would be destined for the new active slot, or after a subsequent reboot?
Merci à tous ceux qui peuvent aider avec ces questions. Je crois vraiment qu'avoir une bonne compréhension des réponses ici m'aidera, ainsi que d'autres, à éviter les mises à jour et les installations longues et problématiques.
-Alpha_Geek1
Click to expand...
Click to collapse
Excuse me: I'm reposting my message in English this time!!
Hello..
I don't have your experience to be able to give you sure answers to your questions...
I've been a simple TWRP user for years, on LG or Samsung devices (smartphones or tablets), with Android versions less than or equal to Oreo!!
I used TWRP only to install “Lineageos” images or make “Nandroid Backup” backups and restore them if necessary…
With a OnePlus 8 Pro running OxygenOS11 in the latest version (11.0.10.10IN11BA) and the arrival of TWRP 3.6, things have become different with the appearance of “dynamic A/B partitions”
And this is where I need your experience and advice:
According to my research on the Net, backup via TWRP performs a full backup of both partitions and restores them as such, with a "global" image, much like an image of an HDD or SSD on PC with several partitions created on these records...
Did I understand right ?!
Will a backup made by TWRP and restoring that backup cause my device to return to a given situation at time T and work completely normally, including root and all settings, apps, apps data , etc ?
Finally, to perform these "Nandroid Backup" and restore them, do I have to select all the boxes in both operations, to be sure to obtain a complete restoration of all the parameters?
Your explanations and advice will be very precious to me!!
Last point: the update of OxygenOS11 to version 12 will soon be released by OnePlus in OTA. I imagine that it will be necessary to wait for the version 3.7 or higher of TWRP to be able to carry out operations on the device passed in equivalent of Android 12?
Thank you in advance for your help and best regards

Amazing and helpful thread!
I have one weird question.
I boot into TWRP (I don't want to flash it), install LineageOS (for example), then boot into fastboot (since I cannot boot into TWRP recovery which is not installed and I don't want to boot into LOS recovery). Then I boot into TWRP again and flash NikGapps.zip and reboot to system.
Now the curious thing... The system boots to the vendor OS version. But if I manually change the boot slots in fastboot, on the other slot there is LOS with the Gapps. I'm wondering where the slot switching happens here...
Has some an idea and can help me understand this behaviour?