Related
So I'm a bit confused. I have my phone rooted at the last security update was Dec 7th 2017. At the time, I was just happy to have my phone rooted so didn't bother with updating, but feel like I should. Do I have to do anything specially to run updates like that or can I just do them? Thanks.
upperbladez said:
So I'm a bit confused. I have my phone rooted at the last security update was Dec 7th 2017. At the time, I was just happy to have my phone rooted so didn't bother with updating, but feel like I should. Do I have to do anything specially to run updates like that or can I just do them? Thanks.
Click to expand...
Click to collapse
Flash full factory image without the "-w" (wipe) flag in the batch file.
Re Root after android has updated.
For OTA to work you need to have original boot.img .
Other option can be ressurecting boot.img and let the OTA update work. But, at least for me, flashing the full image without wipe flag is easier and less hassle than other methods.
Search around if you need a detailed guide. There are few. Click on the post below!
Telperion said:
This guide is primarily intended for rooted users, since stock users can just take the OTA. This guide will result in a device running the latest software update without wiping any of your user data. It also has instructions for how to get a custom recovery and root after the update.
Installing update
Make sure you have the latest Google SDK Platform Tools. Extract the archive to a location of your choosing (creates platform-tools folder)
Get the latest walleye Factory Image from Google's Developer Page and save to a location of your choosing
Extract the archive, and open the extracted folder. You should see a list of files: bootloader-walleye-[version string]
flash-all.bat
flash-all.sh
flash-base.sh
image-walleye-[version string].zip
radio-walleye-[version string]
Open the flash-all script (flash-all.bat for Windows, flash-all.sh for Linux/OSX) in your favorite text editor.
Find the line that reads "fastboot -w update image-walleye-[version].zip and remove "-w" (the wipe user data switch). Save and close the flash-all script.
Move (cut and paste, etc) all of these files to the platform-tools folder.
Enable USB Debugging from the Developer Options menu on your device (press "Build Number" 7 times if not already visible)
With your device plugged into the computer, open a command prompt in the platform-tools folder
Windows: Open the folder, hold down Shift and right click inside the folder, "Open Command window here"
Linux: If you're on Linux you already know how to do this
OSX: Open a folder in a terminal
Reboot to bootloader:
Execute update script in terminal:
Windows:
Linux/OSX:
The device will reboot a few times while updating
Restoring root and/or a custom recovery:
Download latest:
TWRP image
Magisk zip
TWRP zip
(Optional) Custom kernel zip
Place all files in the platform-tools folder
Reboot to bootloader
Boot TWRP image.
Note: As of the February security update, TWRP 3.2.1-0 cannot decrypt the /data/ partition. When prompted for your PIN, cancel. You can keep /system/ read-only.
Push zip files to /tmp
Optional: TWRP persistent installation + custom kernel:
Install Magisk:
Optional: TWRP persistent installation + custom kernel:
Reboot to system
Click to expand...
Click to collapse
https://forum.xda-developers.com/pixel-2/how-to/guide-how-to-install-google-software-t3760033
jtf420 said:
Flash full factory image without the "-w" (wipe) flag in the batch file.
Re Root after android has updated.
For OTA to work you need to have original boot.img .
Other option can be ressurecting boot.img and let the OTA update work. But, at least for me, flashing the full image without wipe flag is easier and less hassle than other methods.
Search around if you need a detailed guide. There are few. Click on the post below!
Click to expand...
Click to collapse
I guess were I am confused is that I am at 8.1.0, but I am currently rooted. I have a verizon pixel, so if I update, could it possibly hurt my phone or am I good to go because I was able to unlock the phone?
Code:
* I'm not responsible for bricked devices, dead SD cards, thermonuclear war, or you getting fired because the alarm app failed.
* Please do some research if you have any concerns about features included in the products you find here before flashing it!
* YOU are choosing to make these modifications, and if you point the finger at me for messing up your device, I will laugh at you.
* Your warranty could be void if you tamper with any part of your device / software.
* Same statement for XDA.
Here's an alternative method to install Magisk that support OTA updates (copied from the Mi A1 forum and expanded )
You need a PC with Android platform tools (they exist also for MacOS and Linux). When using Windows, you should also install MiFlash tool to get the required drivers to recognize the device.
BOOTLOADER UNLOCK
First thing to do: unlock the bootloader (if you didn't already do this, obviously). Smartphones with Android One are much easier to unlock compared to other Xiaomi phones with MIUI (where you have to ask for authorization and wait for weeks).
CAUTION: when you unlock the bootloader, the phone will reset, erasing all your saved data. Backup your data before unlocking.
1. Go to Settings > System > About phone > and tap many times on "Build number" until you unlock "Developer options" (on Andoird 9 "About phone" is right at the top of the Settings app).2. Go back to the previous page (i.e. Settings > System), where you can find now "Developer options". Go there and enable the "OEM unlocking" option (and it's better to never disable this).3. Now you can shutdown your phone, then turn it on while holding the "Volume down" button pressed. Release it when you see the Fastboot screen You can also use the command "adb reboot-bootloader" if you already connected the phone to the PC.4. Now connect the phone with your PC via USB cable, open an administrative command prompt, move to the directory where the Android platform tools are placed and unlock the bootloader with the following command:
Code:
fastboot oem unlock
The phone will reboot, erasing all the data.
Now you unlocked your phone's bootloader and can continue to the next section.
MAGISK INSTALLATION
5. Download and install on the smartphone the latest version of Magisk Manager's apk available.
You need the smartphone to be connected to the internet, because Magisk won't install and won't work properly without a connection.
6. Now you can easily download an already patched boot.img from the following list and jump straight to point 10 of this guide, or you can continue to the next point and learn to patch yourself an original boot.img
If you choose the short way, be sure that you select the patched_boot.img with the same "Build number" currently installed on your phone (see point 1 of this guide), and don't flash the file directly on the phone memory, because Magisk will not work properly (do exactly what this guide says, and you will not find problems, hopefully).
For our convenience, extract the patched_boot.img file in the same directory where Android platform tools are located.
patched_boot 9.6.4.0 (2018 July update) - patched with Magisk 17.1
patched_boot 9.6.6.0 (2018 August update) - patched with Magisk 17.1
patched_boot 9.6.8.0 (2018 September update) - patched with Magisk 17.1
patched_boot 9.6.9.0 (2018 October update) - patched with Magisk 17.1
patched_boot 9.6.10.0 (2018 November 1st update) - patched with Magisk 17.1
patched_boot 9.6.11.0 (2018 November 2nd update) - patched with Magisk 17.1
patched_boot 10.0.2.0 (2018 December upgrade to Android 9.0 Pie) - patched with Magisk 18.0
patched_boot 10.0.3.0 (2019 January update) - patched with Magisk 18.0
In case you erroneously flash those patched files directly on the phone, flash back the original boot.img via fastboot and follow the guide:
original boot.img 9.6.4.0 (2018 July update) - taken from fastboot ROM
original boot.img 9.6.6.0 (2018 August update) - taken from OTA update
original boot.img 9.6.8.0 (2018 September update) - taken from OTA update
original boot.img 9.6.9.0 (2018 October update) - taken from OTA update
original boot.img 9.6.10.0 (2018 November 1st update) - taken from OTA update
original boot.img 9.6.11.0 (2018 November 2nd update) - taken from OTA update
original boot.img 10.0.2.0 (2018 December upgrade to Android 9.0 Pie) - taken from fastboot ROM
original boot.img 10.0.3.0 (2019 January update) - taken from fastboot ROM
7. You need the original boot.img to patch. You can find it inside the official fastboot ROM zip for daisy. Check that the downloaded ROM version is the same as the "Build number" currently installed on your phone (see point 1 of this guide). If the versions are different, update (or downgrade if possible) your phone to that version. You can also download original boot.img elsewhere (for example at the point 6 of this guide), but always pick the same "Build number" of your phone.
After you get the boot.img, copy it to the phone memory (via USB or microSD, or download directly from the phone browser, as you prefer).
8. Open the Magisk Manager app installed previously, it will ask if you want to install Magisk. Accept by tapping on "Install" > "Patch Boot Image File" and select the boot.img file that you get on the point 7 of this guide.
9. Wait until the process completes (about 1 minute), then tap on "Close". Now in the phone memory, inside the Download directory, you should have a patched_boot.img file. Copy that file to the PC, inside the same folder where the Android platform tools are located, for our convenience.
10. Reboot the phone in fastboot mode (as already explained in point 3 of this guide), open an administrative command prompt, move to the Android platform tools directory and then write the following command:
Code:
fastboot boot patched_boot.img
If everything works the phone should boot normally. Open Magisk Manager and it should ask to install Magisk, if not you must tap on the "Install" button. Then choose "Install" > "Direct Install (Recommended)" to install Magisk on the phone, and reboot when finished.
11. Last step to stay safe when a new OTA update arrives: go to "Settings" > "System" > "Developer options" > and disable "Automatic system updates". From now on, you should check manually if a new OTA update is available.
Now the installation is finished, you can use Magisk Manager to install modules and manage root permissions.
HOW TO APPLY OTA UPDATES
UPDATE 9 February 2019 It seems that with the latest Magisk (v18.1) and Magisk Manager (v7.0.0) the following procedure is working fine again. I didn't test it personally, but some users gave positive feedback.
WARNING! January 2019 Since the arrival of Android 9 Pie, the OTA update with Magisk as described in the following section, doesn't seem to work anymore. It could work, but you could also get a bootloop with the risk of losing your data.
Before upgrading from Android 8 to 9, or doing an OTA update after Android 9 you should:
- backup your data;
- remove any lockscreen password or fingerprint;
- uninstall totally Magisk and reboot.
If after doing this you get a bootloop, you could try to manually flash the vanilla boot.img via fastboot on the current slot (the same version as the last installed OTA). If you managed to fix the bootloop you can then install Magisk anew, from step 5 of this guide.
If the phone wants your PIN or password to proceed after the OTA update or after fixing the bootloop, and your PINs or passwords doesn't work, then you could have to reset the phone (or erasing the data partition, that should be the same thing), losing all your data.
Last chance if everything fails, you can flash the latest fastboot ROM from the official Xiaomi site and the phone will be working again.
IMPORTANT: OTA updates will work only if all the partitions on the smartphone are untouched. Magisk Manager can restore the original boot.img following this section of the guide, but if you tampered directly with the system partition (e.g. manually editing build.prop) or other partitions, OTA will refuse to install.
You can try to fix OTA updates without the need to flash the whole original fastboot ROM, by flashing only the tampered partitions (usually only "system") with the corresponding img file found inside the fastboot ROM zip. Check the "Troubleshooting" section of this guide for details.
12. When you know that a new OTA update is available and you want to install it, open Magisk Manager, and tap on "Uninstall" > "Restore Images" but very important: absolutely don't reboot the phone now!
Important note: Magisk Manager will restore the boot.img that was found on the phone while installing Magisk. If the boot.img was already non-vanilla (for example you flashed the boot.img with TWRP before installing Magisk), Magisk Manager will backup that modified version of boot.img, and when restored the OTA will not work, as that's not a vanilla boot.img.
13. Close Magisk Manager and go to "Settings" > "System" > "System update" and install the OTA update. After the update is downloaded, a two-stages update will begin.
14. When both stages of the update process completed, it will ask to restart: DON'T DO IT!. Open Magisk Manager again and tap on "Install" > "Install" > "Install to Inactive Slot (After OTA)" and after that you can tap on "Reboot".
After the reboot you will have the updated Android version with Magisk already working.
Thanks to user @jashancheema for the Mi A1 guide and a bigger thanks to @topjohnwu for the OTA part and above all for developing Magisk.
TROUBLESHOOTING
WARNING: before attempting any of the following operations, you must disable any screen lock, PIN or password, because you risk to not get back your data (encryption issues). It is recommended to take a backup, too (as every time a custom modding is involved).
You can get errors when installing OTA updates if you didn't follow meticulously the guide.
Check this list to try to find where the problem lies:
- when a new version is found, the updater will check if all the partitions on the device are untouched. If there is a partition that has been modified, the OTA updater will not proceed with the installation;- typically, the two partitions commonly modified by user modding are the boot partition (that's where Magisk and TWRP are installed) and the system partition (when you change a config file, add or remove a system app, etc.);- a system partition modified only by using Magisk modules is effectively untouched, because Magisk register all changes to /system in a file in the /data partition and then trick Android to believe those changes are really applied to /system;- boot partition instead is really modified, but if you install Magisk following this guide, Magisk will save a copy of the untouched boot partition, and restoring it before applying OTA update will make the update work.
Now, if you didn't follow this guide to install Magisk and you installed it in other ways, Magisk could alert you that he cannot restore the original boot.img (the boot partition) when you try to apply the OTA update.
To fix this, you can flash directly the vanilla (original, unmodified, untouched) boot.img taken from the point 6 of this guide, using those commands:
Code:
fastboot getvar current-slot
fastboot flash boot_? boot.img
the first command will tell you what is the current slot in use (a or b), the second command will flash the original boot into the phone, but you have to change the "?" in the command with a or b (i.e. the current slot that the first command provided).
Remember that the boot.img file version must correspond to the Android build version currently running in your phone.
If the OTA update will still refuse to apply, probably you changed something directly in the /system partition (for example you changed something in the build.prop without using a Magisk module to do this).
In this case you have to flash the original system.img in the phone with those commands:
Code:
fastboot getvar current-slot
fastboot flash system_? system.img
and as before, the first command will tell you the right slot to use instead of the "?" in the second command.
Here you can find the system.img extracted from the OTA updates zip (along with every other .img file inside that):
9.6.6.0 (August 2018) OTA update dump as .img files
9.6.8.0 (September 2018) OTA update dump as .img files
9.6.9.0 (October 2018) OTA update dump as .img files
9.6.10.0 (November 2018) full fastboot ROM
9.6.11.0 (November 2018) OTA update dump as .img files
If you want to obtain the system.img by yourself, you can find it inside the fastboot images but usually they are not updated monthly like OTA updates. But you can extract the system.img directly from the OTA update zips found in this thread (as I did above with my dumps), using the Python scripts found here.
To make the Python scripts work in Debian/Ubuntu and derivatives, you have to download both "extract_android_ota_payload.py" and "update_metadata_pb2.py", give them execution property and then install the package "python-protobuf". After this you can give this command to unpack the payload.bin file (that you must extract from the OTA update zip):
Code:
./extract_android_ota_payload.py /path/to/payload.bin
This will extract in the current directory all the .img files inside payload.bin, including the system.img
I don't know how to proceed in Windows, probably you only need to install the latest Python2 release and the script will work.
As the last resort, you can flash directly with MiFlash the latest fastboot image available (even if older than your current version). Use the "flash_all.bat" script but before take a backup of your data, because the phone will be fully reset.
If you don't want to take the risk of not doing a backup, use the script "flash_all_except_storage.bat" when flashing, so you will keep all your data, but be warned that sometimes you will not be able to access the data anymore, because of encryption problems.
Right after the flash, you can start following the guide from point 5 or 6.
It should not be a problem downgrading the build version via fastboot, as long as the Android main version remain the same (Oreo 8.1 at the moment).
Thx, nice work :good:
Thanks to the OP. Great post! Totally noob friendly guide. Nice work.
It should also work on mi a2, thanks!
Lione2 said:
It should also work on mi a2, thanks!
Click to expand...
Click to collapse
Sure, but you can't use the posted patched_boot.img, because they're designed for Mi A2 Lite (daisy) and not for Mi A2 (jasmine).
EDIT: I posted the patched and original boot files for Mi A2 jasmine in the second post. I don't know if I can make a thread in the Mi A2 forum section with an adapted copy of my guide, there are already two guides there (even if not polished like this) and I don't want to create more confusion with a third guide about the same argument...
i've installed magisk from previous guide - what steps should I take to apply OTA update? - 12 to 14?
Now magisk informs me that there is 17.1 version - how to update it?
krzygaj said:
i've installed magisk from previous guide - what steps should I take to apply OTA update? - 12 to 14?
Now magisk informs me that there is 17.1 version - how to update it?
Click to expand...
Click to collapse
If you flashed directly the patched_boot.img via fastboot in both slots A and B as the other guide said previously, you must flash the original boot.img to both slots, then start the guide from point 10.
BubuXP said:
If you flashed directly the patched_boot.img via fastboot in both slots A and B as the other guide said previously, you must flash the original boot.img to both slots, then start the guide from point 10.
Click to expand...
Click to collapse
I did as you wrote but still can't install August update - is there any log?
- extracted boot.img from rom: http://en.miui.com/download-354.html
- did fastboot flash boot_a boot.img and fastboot flash boot_b boot.img and rebooted
- next rebooted and did fastboot boot patched_boot.img with patched_boot 9.6.4.0 (July update) - patched with Magisk 17.1
later did steps in guide - but when i do system update it stops on first stage
Any ideas?
krzygaj said:
I did as you wrote but still can't install August update - is there any log?
- extracted boot.img from rom: http://en.miui.com/download-354.html
- did fastboot flash boot_a boot.img and fastboot flash boot_b boot.img and rebooted
- next rebooted and did fastboot boot patched_boot.img with patched_boot 9.6.4.0 (July update) - patched with Magisk 17.1
later did steps in guide - but when i do system update it stops on first stage
Any ideas?
Click to expand...
Click to collapse
You tampered the system partition? Try flashing also the system.img in that case.
Another case could be that you made an OTA update from the June build to July: in this case the partitions on the other slot (probably only the boot partition) where lost when overwrited with fastboot (and cannot be restored, as we don't have any June build ROM or OTA).
If everything fails, do a full fastboot flash with MiFlash tool, but using the flash_all_except_storage.bat script, that should keep your data intact, restore all partitions (A and B) to stock versions and you can then apply OTA (before or after installing Magisk, but I suggest after installing Magisk so you can test if the guide works fine).
BubuXP said:
If everything fails, do a full fastboot flash with MiFlash tool, but using the flash_all_except_storage.bat script, that should keep your data intact, restore all partitions (A and B) to stock versions and you can then apply OTA (before or after installing Magisk).
Click to expand...
Click to collapse
Thanks above worked :good:
Hope the next update will go smoothly
September?
When booting comes a warning message because of the unlocked boot loader. How can I disable this message?
PC295 said:
When booting comes a warning message because of the unlocked boot loader. How can I disable this message?
Click to expand...
Click to collapse
you can't turn that off with open bootloader
Guys, after i have unlocked bootloader i cannot charge my phone when is off because he go on when I insert the plug, it's normal?
proton242 said:
Guys, after i have unlocked bootloader i cannot charge my phone when is off because he go on when I insert the plug, it's normal?
Click to expand...
Click to collapse
No
ConradB said:
No
Click to expand...
Click to collapse
ConradB you have some suggestion? Thank you
proton242 said:
ConradB you have some suggestion? Thank you
Click to expand...
Click to collapse
Same problem on mine, I don't know if it's a ROM bug or it's caused by unlocked bootloader or Magisk.
The only solution at the moment is charging while the phone is switched on.
BubuXP said:
Same problem on mine, I don't know if it's a ROM bug or it's caused by unlocked bootloader or Magisk.
The only solution at the moment is charging while the phone is switched on.
Click to expand...
Click to collapse
Ciao BubuXP, provando a rimuovere Magisk (lasciando il bootloader sbloccato) tutto torna alla normalità, cosa dici, crea casino quando patcha il boot.img?
Hello, I'm new here, so if I'm doing something wrong have mercy .
My 1+7Pro GM1913 is unlocked, rooted with Magisk (I think 22.1), TWRP 3.5.0_9-0-guacamole and OOS (last flashed version was 10.0.11.GM21BA considering I still have on the phone the OnePlus7ProOxygen_21.E.32_OTA_032_all_2101280020_c39273ef1f205b6.zip).
Last time I've flashed something I think was about a month ago, with the last update. No problem so far, until today. This morning my phone had problems with wifi, so I rebooted it.
From that moment on, it boots only to Fastboot Mode. I can get to TWRP and I can access my phone directories from the pc only from TWRP, every other mode makes my phone unreachable from usb, and installing or updating drivers doesn't work.
I would love to avoid any data loss or anything related to having to reinstall every 2FA I have.
I tried deleting everything from /data/adb/modules but nothing changed.
I looked around on XDA but I usually get people stuck on Fastboot only and accessible via usb, which is not my case.
So I was thinking about flashing the latest available OTA, then TWRP, then Magisk from TWRP but I'm not sure if it will works or just worsen my problem.
Has anyone had this problem before? Any idea about how to solve this?
Thanks for anyone willing to help me.
Have a nice day!
EDIT:
Solved flashing the full OTA.zip, twrp.zip, reboot and Magisk.zip after renaming the apk.
I think this will help you:
Twrp --> flash your boot.img (with "payload dumper" it can be extracted from the full OTA update file)
Then flash twrp.zip, reboot in to twrp, flash magisk.zip, wipe dalvik cache
Reboot and provit ;-)
Being a monday and everything, I'll write down what I've done so far, this way if anyone find this post with the same luck as mine maybe it will be less painful for him\her.
I followed this guide on XDA in merit of the "payload dumper" suggested by Ghost323 and followed the instruction on the Github page, which are:
google protobuf for
Code:
python pip install protobuf
Make you sure you have Python 3.6 installed.
Download payload_dumper.py and update_metadata_pb2.py
Extract your OTA zip and place payload.bin in the same folder as these files.
Open PowerShell, Command Prompt, or Terminal depending on your OS.
Enter the following command:
Code:
python -m pip install protobuf
and being my zip a full OTA
When that’s finished, enter this command:
Code:
python payload_dumper.py payload.bin
This will start to extract the images within the payload.bin file to the output folder you are in.
Click to expand...
Click to collapse
All good until the
Code:
python payload_dumper.py payload.bin
gave me a "no module named bdsiff4" error.
So I used
Code:
pip install bsdiff4
and turns out I'm missing Microsoft Visual C++ 14.0, which is absurd because I'm staring at it in my programs and I used it last week.
Anyway, one vs_BuildTools.exe, 12Gb downloaded and a reboot later, this time
Code:
pip install bsdiff4
works and the
Code:
python payload_dumper.py payload.bin
command finally starts.
Once that's done in the output folder I found the boot.img and made a copy into my phone root folder /.
At this point, I was looking for a flashable zip of Magisk, but I found out in a tweet dated 11:55 AM · Jan 22, 2021 that "the Magisk Manager APK *itself* is a custom recovery flashable zip", so back to Github to download the Magisk-v22.1.apk and copy that on the same root folder on my phone, following the instruction under the Magisk v22.0 updated installation guide. Under "Custom Recovery" it is written to rename the .apk into .zip.
On TWRP, Install, Install Image, and selected boot.img.
At that point I can choose between Boot, System Image, Vendor Image and Install Recovery Ramdisk.
But on the installation guide of Magisk is written "Never, ever try to restore either boot or recovery partitions back to stock! You can easily brick your device by doing so, and the only way out is to do a full Odin restore with data wipe."
So now I'm stuck. Please help.
Later I'll flash twrp-installer-3.5.2_9-0-guacamole.zip, reboot to TWRP and flash the Magisk-v22.1.zip.
You can install your full OTA update file in TWRP. Then install TWRP.zip. Restart into TWRP, install Magisk.zip (rename Magisk 22.1.apk to Magisk 22.1.zip). Wipe dalvik cache and reboot into the system.
That should work the same way. The main thing is that your Boot.img is fine again.
Both ways of mine should lead to the same success.
I wish you success.
Yes, flashing the full OTA, twrp, reboot and Magisk gave me back my phone.
However now my SafetyNet is having problems.
Thanks for the help!
Hi all,
My bootloader is unlocked and phone rooted since November. I was able to do the OTA updates up to January with the stock boot.img technique but since February I couldn't find the update.
The update system tells me there is no update. I have obviously restarted several times, the root is inactive, I do not understand at all where the problem comes from. If anyone has an idea, I take it.
(magisk app (22.1) installed but Magisk root off)
I see a similar probleme here : https://forum.xda-developers.com/t/may-update-not-available.4272659/
If anyone had a how-to dirty flash, without loose app&data...
So, I find this from other thread from Pixel 1 (old) :
TENN3R
Download the entire factory image, unzip, open the folder and you'll see a "flash-all.bat" (supposed you're on windows, otherwise the other 2 script files are for mac and linux)
Edit it with notepad (or what you prefer) and remove the "-w" from the latest line, then save it.
Go in fastboot mode, then launch your edited flash-all script file. This will flash the new factory image but without wiping your device, like an ota, but without all the troubles ota has, then it will auto reboot.
Copy on phone magisk and/or kernel
Now disable lockscreen security, then go in fastboot again. Type in cmd "fastboot boot <twrp.img>" (or what it is called)
When terminal gives you "OKAY" unplug device and you should be in twrp. Flash the zips you've choosen and then reboot and re-enable lockscreen pin, password etc..
Magisk and kernel should now work, I did it just now without any problem.
Click to expand...
Click to collapse
I had to download entire factory image or just the OTA update from google website ?
EDIT : ok, full factory image
The full OTA can be applied without unlocking the bootloader.
The factory image has to have the -w removed or it wipes your data.
Both remove root so you have to re-patch your boot.img and then flash it.
Thx, I find the good way, with -w removed. Everything works.
Update 12/15/21: Magisk Canary 23016 includes a fix for the vbmeta header that addresses this issue. Requesting mods close this thread.
Spoiler: Information about the issue, if you care to read it
***This is not a guide, please refer to your device forum for root instructions! Do not ask support questions here!***
Users of the Pixel 4a 5g, 5, 5a, and 6 series have all discovered a similar issue: Permanent root on Android 12 seems to require a data wipe.
Some points of note:
Previously, on Android 11 and prior, root was simple. Patch the boot image with Magisk, then flash it. No other steps were required.
However, when the Android 12 Beta launched, users of the Pixel 4a 5g, 5, and 5a discovered that Magisk patched boot images caused a "failure to load/verify boot images" message in bootloader.
This was successfully avoided on 12 Beta by disabling DM-verity and vbmeta verification, accomplished by flashing /vbmeta with these flags:
Code:
fastboot flash vbmeta --disable-verity --disable-verification vbmeta.img
With the 12 Stable release, we have found a new issue:
If verity and verification are disabled on an existing system, the device will boot into Rescue Party, with the message "Can't load Android system. Your data may be corrupt". At this point, the user must either reflash both /boot and /vbmeta to stock, or perform a factory reset. A patched boot image can be live booted as long as both partitions are stock; this can be used for temporary root.
Alternatively, a clean install performed with the factory image, either via Android Flash Tool, or via ADB using the following command:
Code:
fastboot update -w --disable-verity --disable-verification update codename-image.zip
will also allow successful boot of a patched boot image.
If /vbmeta is reflashed without disable flags at any point, and the device is allowed to boot, disabling it again will cause the device to boot into Rescue Party.
So, it would seem users of Android 12 on the Snapdragon 765G and Tensor devices have a choice after upgrading to Android 12:
Retain data and either go without root, or use temporary root
Wipe data for permanent root
Both the verified boot issue as well as the data wipe issue affect the Pixel 6 /P6 Pro as well.
As mentioned above, a patched boot image can be live booted for temporary root even if verity/verification are not disabled and /boot is stock.
Reference threads:
Verified Boot information
Update + Magisk thread
OTA sideload thread
Upgrade results and discussion thread
Pixel 6 Pro root thread
ipdev said:
Device side actually.
Combination of hardware firmware and software.
Android 11 introduced boot header v3.
This is the start of GKI (Generic Kernel Image) support and the introduction of the vendor boot image.
The device (vendor) specific info is moved into the vendor_boot.img instead of the main boot.img.
On boot everything is combined to hopefully boot the device.
Android 12 introduces boot header v4.
This is the same as v3 with the addition of support for multiple ramdisks in the vendor boot image.
Again everything is combined on boot.
Since the 4a (5G), 5 and 5a were released with Android 11, they will use header v3 unless Google takes the time to update the build tree, kernel tree and blobs for each device to support v4.
So next year when Android 13 comes out, they will most likely still be using boot header v3.
The 6 and 6 Prop are released with Android 12 so, they will use header v4.
Again unless Google takes the time to update the trees and blobs to support a new boot header version.
One of the security updates in Android 12 (SDK31) causes the boot failure when a different boot image is installed without a data wipe.
I thought I read something about it but, I can not find where I read it.
Something about a change to the way the hash value is verified on devices using boot header v3 and newer.
Sad to say it is not a Magisk issue even though it affects Magisk.
Just unpacking and repacking the original boot image (no modification) will give the corruption error and force a data wipe if you install the repacked boot image.
Cheers.
Click to expand...
Click to collapse
@ipdev does this mean that we may potentially have to wipe /data every single time vbmeta is flashed, unless we follow the OTA sideload method? As far as that goes, why does it only seem to succeed after the OTA is sideloaded?
Anonshe said:
For the monthly updates, you've to flash the OTA packages via recovery and boot into fastboot immediately to keep vbmeta disabled. Secure boot will then remain turned off, allowing a patched boot image to be booted/flashed.
I've tested this between the betas and stable version. My last test was from Beta 5 to stable where I flashed the OTA via recovery, rebooted to bootloader, ran the fastboot command, and rebooted device. As a result, no data was lost as a wipe wasn't required.
Click to expand...
Click to collapse
I mean this is better than not having a workaround.
Ref to the GitHub issue for those wanting to keep an eye on progress (of Magisk colaborators):
https://github.com/topjohnwu/Magisk/issues/4343
PW
pndwal said:
Ref to the GitHub issue for those wanting to keep an eye on progress (of Magisk colaborators):
https://github.com/topjohnwu/Magisk/issues/4343
PW
Click to expand...
Click to collapse
It is a locked thread. Not much more to come from it that we don't already know.
mkhcb said:
It is a locked thread. Not much more to come from it that we don't already know.
Click to expand...
Click to collapse
... That's why I said 'progress of Magisk colaborators'... Others will just have to post here! PW
V0latyle said:
@ipdev does this mean that we may potentially have to wipe /data every single time vbmeta is flashed, unless we follow the OTA sideload method? As far as that goes, why does it only seem to succeed after the OTA is sideloaded?
I mean this is better than not having a workaround.
Click to expand...
Click to collapse
I have been waiting for the November update to test updating Android 12.
We will find out in a few days when it is released.
Currently I think we have a good chance to update from the Android 12 October build to the November build without having to wipe data.
As long as you disabled verity, verification and wiped data when initially updating to (or clean flash) Android 12.
I have mentioned before (in a different thread), I update using the full factory image and modify the flash-all script.
This is what I plan to try.
Code:
fastboot --disable-verity --disable-verification --skip-secondary --skip-reboot update image-redfin-NameOfUpdate.zip
fastboot reboot bootloader
The skip-reboot option will leave the device in fastboot_d so I add a reboot to bootloader.
If nothing else needs to be flashed after the update, I just fastboot reboot.
Long (still continuing) story short.
Once Android 12 is installed, verity and verification are disabled and data is wiped.
You can flash the boot partition as much as you want on Android 12.You can dirty-flash Android 12 again using the above fastboot command without having to wipe data again.The --skip-secondary is not needed, I just included it to speed up the flash a bit.
I still do not know what the trigger is for the corruption error.
---
As I mentioned in the post you quoted.
The corruption issue has to do with verifying the boot partition on Android 12.
Unless data is wiped after disabling verity and verification.
Since Magisk lives in boot, it unpacks, modifies, repacks and flashes the modified boot image to the boot partition.
It is not Magisk itself that triggers the corruption error, it is simply just a different boot image installed.
The same happens with a repacked (non modified) version of the stock boot image.
I used AIK to unpack and repack the stock boot image with no modification.
Cheers.
PS.
@osm0sis
I know you are aware of this issue with Magisk but, it also affects AIK and probably AK3.
Basically anything that modifies the installed boot partition.
Code:
[[email protected] AIK-Linux]$ ./unpackimg.sh redfin-sp1a.210812.015-boot.img
Android Image Kitchen - UnpackImg Script
by osm0sis @ xda-developers
Supplied image: redfin-sp1a.210812.015-boot.img
Setting up work folders...
Image type: AOSP
Signature with "AVBv2" type detected.
Splitting image to "split_img/"...
ANDROID! magic found at: 0
BOARD_KERNEL_CMDLINE
BOARD_PAGE_SIZE 4096
BOARD_OS_VERSION 12.0.0
BOARD_OS_PATCH_LEVEL 2021-10
BOARD_HEADER_VERSION 3
BOARD_HEADER_SIZE 1580
Unpacking ramdisk (as root) to "ramdisk/"...
Compression used: lz4-l
4937 blocks
Done!
[[email protected] AIK-Linux]$ ./repackimg.sh --original --origsize
Android Image Kitchen - RepackImg Script
by osm0sis @ xda-developers
Repacking with original ramdisk...
Getting build information...
kernel = redfin-sp1a.210812.015-boot.img-kernel
ramdisk = redfin-sp1a.210812.015-boot.img-ramdisk.cpio.lz4
cmdline =
os_version = 12.0.0
os_patch_level = 2021-10
header_version = 3
Building image...
Using format: AOSP
Padding to original size...
Done!
Also the modified boot image can not boot into fastboot_d while failing verification.
We are droped back to bootloader or recovery's Rescue Party when verification fails.
As noted above, the only way to disable verity and verification includes wiping data.
PPS.
Quick note for those trying to following along.
fastboot_d is part of the boot image (not the bootloader) and is the boot mode used to flash critical partitions.
The successor to fastboot flashing unlock_critical
AIK not yet supporting hdr_v4 aside, it also can't AVBv2 sign anything (yet...), so thar also be dragons trying to flash anything unsigned on a device that wants all partitions signed.
@ipdev the problem is, as I stated, verity and verification are only disabled when vbmeta is flashed using those command line
ipdev said:
I have been waiting for the November update to test updating Android 12.
We will find out in a few days when it is released.
Currently I think we have a good chance to update from the Android 12 October build to the November build without having to wipe data.
As long as you disabled verity, verification and wiped data when initially updating to (or clean flash) Android 12.
Click to expand...
Click to collapse
It doesn't seem to matter what you did initially, though. Case in point: I'm currently running permanent root on the 210812.015 build; I did a factory clean install on Saturday. If I flash vbmeta again, whether via the update or manually, it will require me to wipe data.
ipdev said:
I have mentioned before (in a different thread), I update using the full factory image and modify the flash-all script.
This is what I plan to try.
Code:
fastboot --disable-verity --disable-verification --skip-secondary --skip-reboot update image-redfin-NameOfUpdate.zip
fastboot reboot bootloader
The skip-reboot option will leave the device in fastboot_d so I add a reboot to bootloader.
If nothing else needs to be flashed after the update, I just fastboot reboot.
Click to expand...
Click to collapse
It sounds like this is similar to sideloading the OTA, then entering fastboot and flashing /vbmeta and /boot manually. It's worked before of course but we aren't really worried about the update not working...
ipdev said:
Long (still continuing) story short.
Once Android 12 is installed, verity and verification are disabled and data is wiped.
You can flash the boot partition as much as you want on Android 12.You can dirty-flash Android 12 again using the above fastboot command without having to wipe data again.The --skip-secondary is not needed, I just included it to speed up the flash a bit.
I still do not know what the trigger is for the corruption error.
Click to expand...
Click to collapse
Unfortunately, I can state for a fact that this isn't true. If you dirty flash the factory image with the --disable flags, you will get put into Rescue Party. As I stated previously, disabling dm-verity and vbmeta verification must be done every time vbmeta is flashed - it is not permanent. But the particularly nasty thing here is that if you flash vbmeta again, even with the disable flags, you will still get thrown into Rescue Party. It's not flashing /boot that requires the data wipe; it's /vbmeta. If you disable verity and verification but leave the boot image stock, you still wind up in Rescue Party.
ipdev said:
The corruption issue has to do with verifying the boot partition on Android 12.
Unless data is wiped after disabling verity and verification.
Since Magisk lives in boot, it unpacks, modifies, repacks and flashes the modified boot image to the boot partition.
It is not Magisk itself that triggers the corruption error, it is simply just a different boot image installed.
The same happens with a repacked (non modified) version of the stock boot image.
I used AIK to unpack and repack the stock boot image with no modification.
Click to expand...
Click to collapse
I still don't quite understand why this suddenly became an issue. Unlocking the bootloader was supposed to disable Android Verified Boot. It shouldn't be necessary for us to do anything else; flashing vbmeta is a relatively minor inconvenience compared to having to wipe and set up again every time you update.
ipdev said:
Also the modified boot image can not boot into fastboot_d while failing verification.
We are dropped back to bootloader or recovery's Rescue Party when verification fails.
As noted above, the only way to disable verity and verification includes wiping data.
PPS.
Quick note for those trying to following along.
fastboot_d is part of the boot image (not the bootloader) and is the boot mode used to flash critical partitions.
The successor to fastboot flashing unlock_critical
Click to expand...
Click to collapse
Yeah, I noticed that....because recovery is part of the boot image.
@topjohnwu do you have any input? Obviously you can't talk about how to circumvent Android security, but perhaps you can provide more insight into this problem and explain the mechanisms involved?
Further, if this is not a Magisk issue, perhaps we should move this thread to another forum?
V0latyle said:
View attachment 5446899
We finally figured it out.
Turns out that once dm-verity and vbmeta verification are disabled, you CANNOT let the system boot with them enabled. If /vbmeta gets flashed, such as during an OTA or a factory image, and you let it boot into system, disabling verity/verification is going to require a wipe.
Unfortunately, for those of you upgrading from Android 11, there is simply no way around this - for permanent root, verity/verification must be disabled, and to disable verity/verification, /data must be clean.
I will be updating my guides shortly.
Click to expand...
Click to collapse
This is what I was referring to in my previous post.
ipdev said:
As long as you disabled verity, verification and wiped data when initially updating to (or clean flash) Android 12.
Click to expand...
Click to collapse
ipdev said:
This is what I plan to try.
Code:
fastboot --disable-verity --disable-verification --skip-secondary --skip-reboot update image-redfin-NameOfUpdate.zip
fastboot reboot bootloader
Click to expand...
Click to collapse
ipdev said:
Once Android 12 is installed, verity and verification are disabled and data is wiped.
You can flash the boot partition as much as you want on Android 12.You can dirty-flash Android 12 again using the above fastboot command without having to wipe data again.The --skip-secondary is not needed, I just included it to speed up the flash a bit.
Click to expand...
Click to collapse
Just to clerify this last quote. I was dirty-flashing the full factory image disabling verity and verification during the update flash.
This only worked because I had already wiped data when I initially installed Android 12 clearing the the trigger.
Cheers.
Edit:
PS.
I had no issues updating to redfin-sp1a.211105.003.
Modified flash-all script.
Bash:
#!/bin/sh
# Copyright 2012 The Android Open Source Project
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
if ! [ $($(which fastboot) --version | grep "version" | cut -c18-23 | sed 's/\.//g' ) -ge 3103 ]; then
echo "fastboot too old; please download the latest version at https://developer.android.com/studio/releases/platform-tools.html"
exit 1
fi
fastboot flash bootloader bootloader-redfin-r3-0.4-7617468.img
fastboot reboot-bootloader
sleep 5
fastboot flash radio radio-redfin-g7250-00147-210811-b-7631450.img
fastboot reboot-bootloader
sleep 5
# fastboot -w update image-redfin-sp1a.211105.003.zip
fastboot --disable-verity --disable-verification --skip-secondary --skip-reboot update image-redfin-sp1a.211105.003.zip
fastboot reboot bootloader
Yeah. I sideloaded the OTA first, but then I dirty flashed the factory image, with only the disable options checked. Everything is good.
Thanks @ipdev and @V0latyle for the great posts, this looks like you've sorted this issue out as a solid workaround!
I'm on a Pixel 5a 5G/A11/Magisk 23, and want to go to A12. Since the Pixel 2 I too did all my updates via full system image and flash-all (del -w) using platform-tools and don't know much about OTA while maintaining root, I never needed it. @ipdev post gives me some hope because I understand that approach using the flash-all and full system images for updates because it's very familiar.
That said, can you confirm I have fully grasped the way forward based on your posts and code above?
- using latest platform-tools, update from A11 to A12 with full system image with supplied stock flash-all, leave in -w to allow the data wipe, and let it finish, of course removes root and is essentially a clean A12 (Is this correct or do I need to use the OTA for A12 instead? Do I need any disable flags on this first run?)
- using platform-tools, install the same full system image (because we don't have a newer monthly yet, so same image) again only this time use the edits in flash-all @ipdev shared (modified with the correct image name) which does a dirty full system flash (without -w, preserving /data), sets the appropriate disable flags, and will then allow using Magisk 23 to patch boot.img from the system image, and proceed to reflash it to boot as we used to do before A12 without failing.
- from that point forward, for the monthlies we can continue to update using full system image using the edited fastboot lines in @ipdev example (has no -w flag) to apply the monthly update in a way that will keep A12 from rejecting the patched boot.img to regain root.
Sorry for the lengthy post, but I really want to get this right, and I'm pretty excited and relieved that it appears we can do this all using full system images as I always have, no OTAs are required. I'm extremely grateful for this thread and the quick work of @ipdev @V0latyle @osm0sis and all the good folks working to get this sorted out.
Thanks all,
hfam
hfam said:
Thanks @ipdev and @V0latyle for the great posts, this looks like you've sorted this issue out as a solid workaround!
I'm on a Pixel 5a 5G/A11/Magisk 23, and want to go to A12. Since the Pixel 2 I too did all my updates via full system image and flash-all (del -w) using platform-tools and don't know much about OTA while maintaining root, I never needed it. @ipdev post gives me some hope because I understand that approach using the flash-all and full system images for updates because it's very familiar.
That said, can you confirm I have fully grasped the way forward based on your posts and code above?
- using latest platform-tools, update from A11 to A12 with full system image with supplied stock flash-all, leave in -w to allow the data wipe, and let it finish, of course removes root and is essentially a clean A12 (Is this correct or do I need to use the OTA for A12 instead? Do I need any disable flags on this first run?)
- using platform-tools, install the same full system image (because we don't have a newer monthly yet, so same image) again only this time use the edits in flash-all @ipdev shared (modified with the correct image name) which does a dirty full system flash (without -w, preserving /data), sets the appropriate disable flags, and will then allow using Magisk 23 to patch boot.img from the system image, and proceed to reflash it to boot as we used to do before A12 without failing.
- from that point forward, for the monthlies we can continue to update using full system image using the edited fastboot lines in @ipdev example (has no -w flag) to apply the monthly update in a way that will keep A12 from rejecting the patched boot.img to regain root.
Sorry for the lengthy post, but I really want to get this right, and I'm pretty excited and relieved that it appears we can do this all using full system images as I always have, no OTAs are required. I'm extremely grateful for this thread and the quick work of @ipdev @V0latyle @osm0sis and all the good folks working to get this sorted out.
Thanks all,
hfam
Click to expand...
Click to collapse
Hi.
You need to wipe data once after disabling verity and verification on Android 12.
After that, you can update Android 12 without wiping data as long as you keep verity and verification disabled.
I only use the full factory images to update.
Same as I have since the Nexus days.
Factory Images for Nexus and Pixel Devices - WebSite - developers.google - Link
I am not sure what works using the incremental (OverTheAir) updates.
---
To clean flash a12 and disable both verity and verification add the disable flags.
Code:
fastboot -w --disable-verity --disable-verification update image-redfin-sp1a.211105.003.zip
The fastboot options control how the fastboot command(s) work.
-w Wipe userdata. (This is done at the end of update).
--disable-verity Sets disable-verity when flashing vbmeta.
--disable-verification Sets disable-verification when flashing vbmeta.
After the initial install and wipe, you can update (dirty flash) without the -w option.
Code:
fastboot --disable-verity --disable-verification update image-redfin-sp1a.211105.003.zip
You can add..
--skip-reboot Don't reboot device after flashing.
This will leave you in the last boot mode.
fastboot_d on newer devices.
I mentioned somewhere, I use this option and add a reboot to bootloader to the flash-all script.
If you just want to manually reboot the device or modify something before boot.
Example booting a Magisk patched boot image.
--skip-secondary Don't flash secondary slots in flashall/update.
This will only flash the update to the current (active) slot.
Since the introduction of virtual A/B I have not noticed any advantage to flashing the opposite slot.
Only true A/B has saved me from bad flashes.
When testing and trouble shooting, I still flash to both slots on virtual A/B devices.
Just incase.
Hope it helps more than confuse.
Cheers.
ipdev said:
Hi.
You need to wipe data once after disabling verity and verification on Android 12.
After that, you can update Android 12 without wiping data as long as you keep verity and verification disabled.
I only use the full factory images to update.
Same as I have since the Nexus days.
Factory Images for Nexus and Pixel Devices - WebSite - developers.google - Link
I am not sure what works using the incremental (OverTheAir) updates.
---
To clean flash a12 and disable both verity and verification add the disable flags.
Code:
fastboot -w --disable-verity --disable-verification update image-redfin-sp1a.211105.003.zip
The fastboot options control how the fastboot command(s) work.
-w Wipe userdata. (This is done at the end of update).
--disable-verity Sets disable-verity when flashing vbmeta.
--disable-verification Sets disable-verification when flashing vbmeta.
After the initial install and wipe, you can update (dirty flash) without the -w option.
Code:
fastboot --disable-verity --disable-verification update image-redfin-sp1a.211105.003.zip
You can add..
--skip-reboot Don't reboot device after flashing.
This will leave you in the last boot mode.
fastboot_d on newer devices.I mentioned somewhere, I use this option and add a reboot to bootloader to the flash-all script.If you just want to manually reboot the device or modify something before boot.Example booting a Magisk patched boot image.
--skip-secondary Don't flash secondary slots in flashall/update.
This will only flash the update to the current (active) slot.
Since the introduction of virtual A/B I have not noticed any advantage to flashing the opposite slot.Only true A/B has saved me from bad flashes.
When testing and trouble shooting, I still flash to both slots on virtual A/B devices.
Just incase.
Hope it helps more than confuse.
Cheers.
Click to expand...
Click to collapse
Heya @ipdev!
Brother that's SO very helpful, thanks for the thoughtful and thorough reply!! As soon as I read you took the full system image approach to doing updates and saw you mention editing the flash-all to achieve success I knew I was home!! It has worked flawlessly and predictably for so many years, never even wanted to try OTA etc, and regaining root was a snap. This feels....comfortable and familiar!
This info, and the post previous from you where you shared the edits made to the flash-all in a code box make it really clear for me and I've got the confidence to give it a go once I've backed up what I need to incase it all goes pear-shaped.
My utmost gratitude, @ipdev, thanks so much for the assist, I'll report back when I've had a chance to do the upgrade and thanks again for all your help!
hfam
ipdev said:
Hi.
You need to wipe data once after disabling verity and verification on Android 12.
After that, you can update Android 12 without wiping data as long as you keep verity and verification disabled.
I only use the full factory images to update.
Same as I have since the Nexus days.
Factory Images for Nexus and Pixel Devices - WebSite - developers.google - Link
I am not sure what works using the incremental (OverTheAir) updates.
---
To clean flash a12 and disable both verity and verification add the disable flags.
Code:
fastboot -w --disable-verity --disable-verification update image-redfin-sp1a.211105.003.zip
The fastboot options control how the fastboot command(s) work.
-w Wipe userdata. (This is done at the end of update).
--disable-verity Sets disable-verity when flashing vbmeta.
--disable-verification Sets disable-verification when flashing vbmeta.
After the initial install and wipe, you can update (dirty flash) without the -w option.
Code:
fastboot --disable-verity --disable-verification update image-redfin-sp1a.211105.003.zip
You can add..
--skip-reboot Don't reboot device after flashing.
This will leave you in the last boot mode.
fastboot_d on newer devices.I mentioned somewhere, I use this option and add a reboot to bootloader to the flash-all script.If you just want to manually reboot the device or modify something before boot.Example booting a Magisk patched boot image.
--skip-secondary Don't flash secondary slots in flashall/update.
This will only flash the update to the current (active) slot.
Since the introduction of virtual A/B I have not noticed any advantage to flashing the opposite slot.Only true A/B has saved me from bad flashes.
When testing and trouble shooting, I still flash to both slots on virtual A/B devices.
Just incase.
Hope it helps more than confuse.
Cheers.
Click to expand...
Click to collapse
I've been pretty much doing it the same as you since the Nexus 5, except removing the -w from the flash-all.bat file and using the flash-all command.
So basically, for updating & dirty flashing now (I'm on the Pixel 6 Pro) we can do the same (after already factory resetting when 1st disabling those flags from the vbmeta.img in a prior flash of course), remove the -w from the flash-all.bat file but replace it with --disable-verity --disable-verification . And everything else in that line stays the same and just use the flash-all command. Boot, patch the boot image and go back and flash that.
Or alternatively also add --skip-reboot to that line as well and flash the patched boot image after using the flash-all command, if you decided to patch the new boot.img beforehand.
Is this correct?
heya @ipdev I'm about to do this and a question occurred to me as I'm re-reading your last few posts before I take the dive. Hopefully I've got this right, but a confirmation would be really appreciated.
Once updated doing the initial wipe with the 2 required disable flags...
Code:
fastboot -w --disable-verity --disable-verification update image-barbet-sp1a.211105.003.zip
...can I just install the Magisk apk, patch a boot.img and flash that just like we always have using ADB to get to bootloader, etc, OR is there a timing element that also requires that every time I want to flash a patched boot.img, I must first do a dirty system flash using the 2 disable flags (ie. after dirty flashing system using the 2 disable flags AND before rebooting A12) that must be adhered to when flashing a patched boot.img?
Thanks again for all the help!
hfam
V0latyle said:
Yeah. I sideloaded the OTA first, but then I dirty flashed the factory image, with only the disable options checked. Everything is good.
Click to expand...
Click to collapse
Oh HELL @V0latyle I have been rereading the posts in this thread over and over and I just now randomly saw "....I will be updating my guide shortly" and it finally clicked...I had no idea!! Feel like I've been typing all around ya in this thread!! Heading to your guide now! LOL!
Thanks again to all of ya!
hfam
Lughnasadh said:
I've been pretty much doing it the same as you since the Nexus 5, except removing the -w from the flash-all.bat file and using the flash-all command.
So basically, for updating & dirty flashing now (I'm on the Pixel 6 Pro) we can do the same (after already factory resetting when 1st disabling those flags from the vbmeta.img in a prior flash of course), remove the -w from the flash-all.bat file but replace it with --disable-verity --disable-verification . And everything else in that line stays the same and just use the flash-all command. Boot, patch the boot image and go back and flash that.
Or alternatively also add --skip-reboot to that line as well and flash the patched boot image after using the flash-all command, if you decided to patch the new boot.img beforehand.
Is this correct?
Click to expand...
Click to collapse
Hi.
You seem to have it correct.
If you decide to add the --skip-reboot option the device will be left in bootloader_d since it is the last boot mode of update on newer devices.
So you will want to add a reboot to bootloader line after the update line.
You might also want to keep Windows from closing the command window after the batch script runs.
-- Intermission. --
Before I recommend something I try to test and double check it as much as I can.
It has been a while since I used Windows and wanted to test a few things.
Took longer than I thought it would.
After some updates (sdk and platform tools), and installing some new device drivers.
Trusty Windows 7 Pro (dual boot) on my trusty 2013 MackBook Air was ready to go.
I do not have a 6 Pro [raven] so I just used my 5 [redfin] to test.
I have a 6 [oriole] on order, should be delivered by Monday.
I edit the update script with Notepad++ since I know it is recommended to use for script files.
It does not include the Windows line ending junk.
This is what I ended up with to do a dirty reflash on my Pixel 5.
Along with keeping the command window open.
Note: For those stumbling across this post.
This is after the initial flash of Android 12 that included disabling verity, verification and wiping user data.
Modified flash-all.bat
Code:
@ECHO OFF
:: Copyright 2012 The Android Open Source Project
::
:: Licensed under the Apache License, Version 2.0 (the "License");
:: you may not use this file except in compliance with the License.
:: You may obtain a copy of the License at
::
:: http://www.apache.org/licenses/LICENSE-2.0
::
:: Unless required by applicable law or agreed to in writing, software
:: distributed under the License is distributed on an "AS IS" BASIS,
:: WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
:: See the License for the specific language governing permissions and
:: limitations under the License.
PATH=%PATH%;"%SYSTEMROOT%\System32"
fastboot flash bootloader bootloader-redfin-r3-0.4-7617468.img
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
fastboot flash radio radio-redfin-g7250-00147-210811-b-7631450.img
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
:: fastboot -w update image-redfin-sp1a.211105.003.zip
:: echo Press any key to exit...
:: pause >nul
:: exit
fastboot --disable-verity --disable-verification --skip-reboot update image-redfin-sp1a.211105.003.zip
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
cmd /k
Probably do not need the extra ping but, why not delay a few seconds.
Then I just booted (fastboot boot) the magisk patched image (that I already patched while on the November build) and used the Direct install option in the Magisk app to install Magisk.
To close the command window (when I was done with it) a single exit command was all that was need.
---
As for Magisk.
Since about the start of Android 11, I have had issues patching the new boot image beforehand.
Patching the December boot image while still on the November release for example.
So I generally patch the boot image while I am running the corresponding system (rom build).
Patch the December boot image while running the December release.
Then boot the Magisk patched image to make sure it works and nothing is broken.
If everything is good, I then just use the Direct install option in the Magisk app to install Magisk.
You could reboot to bootloader and then flash boot if you prefer.
Hope it helps more than confuse.
Cheers.
ipdev said:
Hi.
You seem to have it correct.
If you decide to add the --skip-reboot option the device will be left in bootloader_d since it is the last boot mode of update on newer devices.
So you will want to add a reboot to bootloader line after the update line.
You might also want to keep Windows from closing the command window after the batch script runs.
-- Intermission. --
Before I recommend something I try to test and double check it as much as I can.
It has been a while since I used Windows and wanted to test a few things.
Took longer than I thought it would.
After some updates (sdk and platform tools), and installing some new device drivers.Trusty Windows 7 Pro (dual boot) on my trusty 2013 MackBook Air was ready to go.
I do not have a 6 Pro [raven] so I just used my 5 [redfin] to test.
I have a 6 [oriole] on order, should be delivered by Monday.
I edit the update script with Notepad++ since I know it is recommended to use for script files.
It does not include the Windows line ending junk.
This is what I ended up with to do a dirty reflash on my Pixel 5.
Along with keeping the command window open.
Note: For those stumbling across this post.This is after the initial flash of Android 12 that included disabling verity, verification and wiping user data.
Modified flash-all.bat
Code:
@ECHO OFF
:: Copyright 2012 The Android Open Source Project
::
:: Licensed under the Apache License, Version 2.0 (the "License");
:: you may not use this file except in compliance with the License.
:: You may obtain a copy of the License at
::
:: http://www.apache.org/licenses/LICENSE-2.0
::
:: Unless required by applicable law or agreed to in writing, software
:: distributed under the License is distributed on an "AS IS" BASIS,
:: WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
:: See the License for the specific language governing permissions and
:: limitations under the License.
PATH=%PATH%;"%SYSTEMROOT%\System32"
fastboot flash bootloader bootloader-redfin-r3-0.4-7617468.img
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
fastboot flash radio radio-redfin-g7250-00147-210811-b-7631450.img
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
:: fastboot -w update image-redfin-sp1a.211105.003.zip
:: echo Press any key to exit...
:: pause >nul
:: exit
fastboot --disable-verity --disable-verification --skip-reboot update image-redfin-sp1a.211105.003.zip
fastboot reboot-bootloader
ping -n 5 127.0.0.1 >nul
cmd /k
Probably do not need the extra ping but, why not delay a few seconds.
Then I just booted (fastboot boot) the magisk patched image (that I already patched while on the November build) and used the Direct install option in the Magisk app to install Magisk.
To close the command window (when I was done with it) a single exit command was all that was need.
---
As for Magisk.
Since about the start of Android 11, I have had issues patching the new boot image beforehand.
Patching the December boot image while still on the November release for example.
So I generally patch the boot image while I am running the corresponding system (rom build).
Patch the December boot image while running the December release.
Then boot the Magisk patched image to make sure it works and nothing is broken.
If everything is good, I then just use the Direct install option in the Magisk app to install Magisk.
You could reboot to bootloader and then flash boot if you prefer.
Hope it helps more than confuse.
Cheers.
Click to expand...
Click to collapse
Thank you so much for the thoughtful and detailed response. And for taking the time to test it out. Very much appreciated.
You bring up a good point about landing in bootloader_d after using the --skip-reboot command. I hadn't realized that.
After using the flash-all script I do usually then patch the boot image while in the new build and go back into bootloader and flash it so I think I'll just stick with that tried and true method, as you suggested.
I also use notepad++ to edit the flash-all.bat script on my Windows 11 laptop.
I'm glad its turned out as "simple" as just replacing the -w with --disable-verity --disable-verification in the flash-all.bat script.
Big thanks to you and everyone else who has conquered Google's shenanigans once again.
P.S. Good to know you can still do stuff with Windows 7 on a 2013 MacBook Air
ipdev said:
As for Magisk.
Since about the start of Android 11, I have had issues patching the new boot image beforehand.
Patching the December boot image while still on the November release for example.
So I generally patch the boot image while I am running the corresponding system (rom build).
Patch the December boot image while running the December release.
Then boot the Magisk patched image to make sure it works and nothing is broken.
If everything is good, I then just use the Direct install option in the Magisk app to install Magisk.
You could reboot to bootloader and then flash boot if you prefer.
Click to expand...
Click to collapse
I've actually been thinking about this, it's probably better to patch the boot image post update anyway.
I'll update my guides.
Magisk Canary 23016 has fixed this issue.
Huge thanks to everyone who helped look into this issue, as well as the developers who effected the actual fixes:
@topjohnwu
@osm0sis
@ipdev
@pndwal
If there's anyone else I'm forgetting, let me know!
Requesting mods close this thread.