If you've just arrived on the phone modding scene, or are coming from another phone that uses traditional approaches to flashing, you've likely come across people talking about the "A/B partitions." If you don't have any experience with this arrangement, it can be intimidating, because it fundamentally changes a lot of things related to flashing and updates.
What is a Partition?
Let's start with the basics. A partition is a discrete, contiguous, but non-overlapping section within the phone's storage where data is stored. There are partitions for bootloaders, various firmware, user data, OS files, and so on. For the most part, these files live in their own partitions, and you can wipe, format, and edit them without affecting files on other partitions.
There are 72 different partitions on the OP6. If you've worked with partitions on previous phones, you're probably thinking, "That's a lot," and it is. But there's a reason why there are so many: Many of them are duplicated, and that brings us to A/B partitions. Google moved to A/B partitioning for a specific reason: It allows for what are known as "seamless" updates. The following is from Google's explainer for devs, but it's fairly straightforward:
A/B system updates use two sets of partitions referred to as slots (normally slot A and slot B). The system runs from the current slot while the partitions in the unused slot are not accessed by the running system during normal operation. This approach makes updates fault resistant by keeping the unused slot as a fallback: If an error occurs during or immediately after an update, the system can rollback to the old slot and continue to have a working system. To achieve this goal, no partition used by the current slot should be updated as part of the OTA update (including partitions for which there is only one copy).
Each slot has a bootable attribute that states whether the slot contains a correct system from which the device can boot. The current slot is bootable when the system is running, but the other slot may have an old (still correct) version of the system, a newer version, or invalid data. Regardless of what the current slot is, there is one slot that is the active slot (the one the bootloader will boot form on the next boot) or the preferred slot.
Each slot also has a successful attribute set by the user space, which is relevant only if the slot is also bootable. A successful slot should be able to boot, run, and update itself. A bootable slot that was not marked as successful (after several attempts were made to boot from it) should be marked as unbootable by the bootloader, including changing the active slot to another bootable slot (normally to the slot running immediately before the attempt to boot into the new, active one).
Click to expand...
Click to collapse
What does all this mean? Well, one thing (the main thing, really) that it allows you to do is take an OTA while you are booted up and using your phone. (Even if you're rooted? Yes, but more on that in a moment.) The system update engine will download and install the update to the inactive slot in the background, then ask you to reboot. When you reboot, you'll be fully updated without the need to boot to bootloader and wait for it to install. This approach makes updating a lot safer: If the update breaks something, the system won't boot to that slot. It will return to the old slot and let you know the update failed. The days of having an OTA bork your phone out of the blue are mostly over. That's good!
But What About My Data?
Though there are two versions of many partitions (boot_a, boot_b, system_a, system_b, and so on) there's only one userdata partition. So your data isn't affected by the update.
You may need to log back into certain apps as if using them for the first time, but your data and settings will all still be where they were before the OTA.
What A/B Means for Rooting
The wrinkles, however, start coming when you unlock and root your phone. To understand why, we need to talk about something called the kernel. The kernel is a key part of any computer operating system. It is the tool that applications use to talk to the hardware and vice versa, and it governs how the CPU operates, how memory is used, and on smartphones how things like the screen, radio, speakers, and so on function. Without the kernel, or with a broken kernel, applications have no way to function. If you've heard the term "kernel panic," it's a situation in which the kernel stops the system either because of a hardware fault or a software problem that's taken the system into a state that the kernel can't get it out of.
Non-A/B Android phones actually had two kernel images. One lived in the recovery partition, while the other lived in the boot partition. This allowed the phone to boot into recovery and make major changes to the rest of the system. But the A/B approach gets rid of the separate recovery partition and integrates it into the boot partition. Why? Probably because on stock phones, the recovery is only used for system updates, and with the A/B arrangement, it's no longer necessary to have a separate dedicated recovery since updates happen directly to the inactive partition.
This creates a challenge for phone modding, however. Without a separate recovery partition, the stock recovery has to be replaced with a custom recovery, inside the boot partition where the kernel lives. But on Android, you cannot modify partitions through fastboot – you can only flash over them. So installing a custom recovery like twrp for the first time requires you to fastboot boot into twrp from your computer, then flash an installer once you are booted. .
There's another problem: Rooting via magisk makes modifications to the boot sector. So does flashing xposed or (obviously) a custom kernel. With recovery and these other custom mods now all living together in the same partition, it is possible for one of them to overwrite files used by another mod. This is why you may need to reflash magisk after updating a custom kernel or custom recovery, and why not doing so can result in a bootloop. You've overwritten files magisks uses for root, so your phone can no longer boot (this isn't the case with all mods; many are now coded to avoid this problem).
Updates on a Rooted OP6 with A/B Partitions
If you've been following along so far, you're probably now seeing another issue: Isn't a seamless update going to overwrite all of my mods? The answer is yes, it will (more accurately, it won't copy them over to the new slot). If you're cringing now, have faith. This isn't as big a deal as it sounds, and it's actually a good thing once you see how it all works.
Here's what happens when your OP6 gets an update notification. The update engine detects root and downloads the full update instead of the incremental update. This is very important and you should not try to frustrate or block it from doing so (unless you want to update manually via twrp, see below). Taking the incremental update on a rooted phone could result in a brick, or more likely, an unbootable slot. Like it says in that Google quote above, the updater installs the new version in the inactive slot. The key thing here is that it installs a fresh, fully stock version. Your data gets pulled over, but none of your mods go with it. To get them back, you have to install them all again. There are various ways of doing this, and this isn't the place to repeat the guides that are already posted on how. Just understand that you have to do it to keep root, twrp, and your other mods.
It works more or less the same way if you download the full update manually and flash in twrp. You'll get a fully stock installation on the other slot, and you'll boot into it unrooted unless you reinstall your mods first. You also should note that this makes for an easy way to go back to stock if that's what you want, and I recommend keeping a zip of the stock OS on your phone just in case you need to do it.
Note that you can manually switch the active slot in twrp, but I don't recommend doing so until you know what you're doing. After a couple of updates and flashes, what remains on the inactive slot is not necessarily going to be bootable, or it may boot with things like wifi broken. And if you've never updated at all, there may be nothing on the inactive slot, which means your phone will reboot into the void of a black screen. (But don't worry – there's a tool to fix this here.)
Here are a couple of guides that I recommend for further reading on the specifics:
[RECOVERY] HOW TO INSTALL OFFICIAL TWRP & MAGISK OOS 5.1.5 to 5.1.8
[OFFICIAL] OxygenOS 5.1.8 OTA for the OnePlus 6
If all this seems like some extra work, it is. But remember it ensures you're getting a clean and fully functional updated system. Once you get the hang of doing it this way, you'll appreciate the advantages.
Some Other Things to Be Aware of
In addition to the other changes, the cache partition has been removed. It now resides in the data partition and is no longer used for anything related to updates. One result is that wiping cache in twrp no longer does anything. If you want to clear cached data go into Settings>Storage & memory, then tap Cached data at the bottom and then tap OK.
Otherwise, you don't need to worry much about it. (Why did Google do this? Apparently to save space that was taken up by having to duplicate many other partitions. They also halved the system partitions by playing some clever games with app odexing, but that's beyond the scope of this guide – the only user effect is a slower first boot after factory reset.)
That's Cool! I Want to Know More!
This article on the XDA portal covers everything you could possibly want to know about A/B partitions and what they do.
Good luck and happy modding.
(Note: Devs and experienced users are encouraged to submit corrections if any of this is a bit off.)
Thanks to @jisoo for a guide in the Pixel forums I adapted some of this from.
Very informative and I'd even recommend this read for users who already know a bit about the partitions!
Excellent guide. Can I link it?
lollyjay said:
Excellent guide. Can I link it?
Click to expand...
Click to collapse
Of course, your guide is linked here too. :highfive:
A quick read over this and I can't find anything glaringly wrong with it. Nice write up. Considering adapting it for the Portal if you're okay with that, OP.
MishaalRahman said:
A quick read over this and I can't find anything glaringly wrong with it. Nice write up. Considering adapting it for the Portal if you're okay with that, OP.
Click to expand...
Click to collapse
Feel free!
iElvis said:
Of course, your guide is linked here too. :highfive:
Click to expand...
Click to collapse
Done! And thank you.
Still little confused here.so if I flashed full ROM zip(not ota zip) from twrp then I have updated system or my phone will soft brick?
vikasb32 said:
Still little confused here.so if I flashed full ROM zip(not ota zip) from twrp then I have updated system or my phone will soft brick?
Click to expand...
Click to collapse
Flashing the full rom zip will give you an updated system, but stock unless you follow by reinstalling twrp, etc.
No other words than THANK YOU! You've clarified our minds!
Nice write up. I did have a question though. If I flash the full stock rom in TWRP does it automatically flash to the non-active partition? I've had a couple of unexpected issues when flashing.
Man that's something
Any way Thank you
I was lazy to search and read about the whole thing , but you help to provide what I need to know .
Sent from my ONEPLUS A6003 using Tapatalk
texasaggie1 said:
Nice write up. I did have a question though. If I flash the full stock rom in TWRP does it automatically flash to the non-active partition? I've had a couple of unexpected issues when flashing.
Click to expand...
Click to collapse
Correct. When you flash the full stock rom, it will install to the inactive slot, and it will mark that slot as the new active slot, which means that if you reboot right after flashing, you will boot onto a fully stock slot without twrp. This is why you need to immediately flash the twrp installer (which always flashes to both slots), then reboot to recovery, which will get you onto the new slot, with twrp, from which you can reflash magisk, etc.
Ah ok. I just ended up flashing the stock ROM twice, once to each partition. Then I ran the Twrp installer. Then I flashed magisk twice, once to each partition and that fixed my issues
iElvis said:
Correct. When you flash the full stock rom, it will install to the inactive slot, and it will mark that slot as the new active slot, which means that if you reboot right after flashing, you will boot onto a fully stock slot without twrp. This is why you need to immediately flash the twrp installer (which always flashes to both slots), then reboot to recovery, which will get you onto the new slot, with twrp, from which you can reflash magisk, etc.
Click to expand...
Click to collapse
Excellent write up :good:
iElvis said:
Correct. When you flash the full stock rom, it will install to the inactive slot, and it will mark that slot as the new active slot, which means that if you reboot right after flashing, you will boot onto a fully stock slot without twrp. This is why you need to immediately flash the twrp installer (which always flashes to both slots), then reboot to recovery, which will get you onto the new slot, with twrp, from which you can reflash magisk, etc.
Click to expand...
Click to collapse
Awesome writeup!!! this needs an sticky big time.
One question, why does TWRP flash stuff on current slot but full roms on the other slot (and changes slot then?). It is because it replicates the Update Engine protocol or something with entire stock roms only?
PS: I wish there was a more detailed version after the initial setup, like when **** happens and slots get disabled by the bootloader and such. I wonder if when an slot is disabled you can twrp enable/change into it or only flashing stock image works? There's a lot of stuff like this, like what happens if you manage to make both slots unusable (even if bootloader partition works, fastboot wouldn't be reachable right? :S).
This seems like just a hell of an environtment to control compared to the simple old partition scheme.. yeah, here you can have 2 systems set up incase something breaks, great, but you do not control the boot process, the bootloader does, and this is not good for us. Something that affects both slots at the same time like TWRP can go wrong (for example a bugged release of TWRP) and derp you both systems and let you without an unusable phone without even fasboot?... yeah qualcomm protocol but come on..
You'd add on the guide that you can disable seamless updates on developer options. This is very important!! I think that the manual OTA flashing is the way to go if we want to not get into ****..
And you're right, this is ultra intimidating, I've never ever had any problems rooting and such my first android phone.. it was an easy read explaining that bootloader->kernel->system->user, 1) unlock 2) twrp 3) flash root and mods and do nandroids... and if something goes wrong, if you never touched the bootloader partition you could always go into fastboot and fix, or into TWRP and fix even if system bootloops. Here if system bootlops you can't even use TWRP or fastboot on that slot???? wtf... super intimidating.
You added most of the good stuff on the first post.. how about a new section "the bad side" or something like that with all the stuff im saying and more bad stuff that I don't even know yet? You will evade most people getting onto those situations and post here asking about that stuff.
Thanks!
RusherDude said:
One question, why does TWRP flash stuff on current slot but full roms on the other slot (and changes slot then?). It is because it replicates the Update Engine protocol or something with entire stock roms only?
Click to expand...
Click to collapse
I assume because it's coded to flash to both slots. The stock rom updates are set up to use Google's A/B approach, which sets out a specific process for flashing updates.
PS: I wish there was a more detailed version after the initial setup, like when **** happens and slots get disabled by the bootloader and such. I wonder if when an slot is disabled you can twrp enable/change into it or only flashing stock image works? There's a lot of stuff like this, like what happens if you manage to make both slots unusable (even if bootloader partition works, fastboot wouldn't be reachable right? :S).
Click to expand...
Click to collapse
The A/B info page I linked explains exactly what happens:
The current slot (or "source slot") is marked as successful (if not already marked) with markBootSuccessful().
The unused slot (or "target slot") is marked as unbootable by calling the function setSlotAsUnbootable(). The current slot is always marked as successful at the beginning of the update to prevent the bootloader from falling back to the unused slot, which will soon have invalid data. If the system has reached the point where it can start applying an update, the current slot is marked as successful even if other major components are broken (such as the UI in a crash loop) as it is possible to push new software to fix these problems.
The update payload is an opaque blob with the instructions to update to the new version. The update payload consists of the following:
Metadata. A relatively small portion of the update payload, the metadata contains a list of operations to produce and verify the new version on the target slot. For example, an operation could decompress a certain blob and write it to specific blocks in a target partition, or read from a source partition, apply a binary patch, and write to certain blocks in a target partition.
Extra data. As the bulk of the update payload, the extra data associated with the operations consists of the compressed blob or binary patch in these examples.
The payload metadata is downloaded.
For each operation defined in the metadata, in order, the associated data (if any) is downloaded to memory, the operation is applied, and the associated memory is discarded.
The whole partitions are re-read and verified against the expected hash.
The post-install step (if any) is run. In the case of an error during the execution of any step, the update fails and is re-attempted with possibly a different payload. If all the steps so far have succeeded, the update succeeds and the last step is executed.
The unused slot is marked as active by calling setActiveBootSlot(). Marking the unused slot as active doesn't mean it will finish booting. The bootloader (or system itself) can switch the active slot back if it doesn't read a successful state.
Post-installation (described below) involves running a program from the "new update" version while still running in the old version. If defined in the OTA package, this step is mandatory and the program must return with exit code 0; otherwise, the update fails.
After the system successfully boots far enough into the new slot and finishes the post-reboot checks, the now current slot (formerly the "target slot") is marked as successful by calling markBootSuccessful().
Click to expand...
Click to collapse
You can see there are multiple stages here, and if the bootloader can't even load, that slot won't be marked as active.
There's an even more detailed version here: https://source.android.com/devices/tech/ota/ab/ab_implement
As I understand it, twrp can change active slots, but if the slot has been marked unbootable (because it's not bootable), then it probably has to fixed with a clean reflash.
Unless the slot is completely empty, you should still be able to get to bootloader. Obviously, if the bootloaders are corrupted on both slots, you have a brick, but you can do that on non-A/B phones too.
This seems like just a hell of an environtment to control compared to the simple old partition scheme.. yeah, here you can have 2 systems set up incase something breaks, great, but you do not control the boot process, the bootloader does, and this is not good for us. Something that affects both slots at the same time like TWRP can go wrong (for example a bugged release of TWRP) and derp you both systems and let you without an unusable phone without even fasboot?... yeah qualcomm protocol but come on.
Click to expand...
Click to collapse
I'm not sure the situation is that dire. A bad release of twrp could bork a non-A/B phone the same way? Here you've got two slots instead of one.
You'd add on the guide that you can disable seamless updates on developer options. This is very important!! I think that the manual OTA flashing is the way to go if we want to not get into ****..
Click to expand...
Click to collapse
I'm not seeing an option to disable A/B updates anywhere.
And you're right, this is ultra intimidating, I've never ever had any problems rooting and such my first android phone.. it was an easy read explaining that bootloader->kernel->system->user, 1) unlock 2) twrp 3) flash root and mods and do nandroids... and if something goes wrong, if you never touched the bootloader partition you could always go into fastboot and fix, or into TWRP and fix even if system bootloops. Here if system bootlops you can't even use TWRP or fastboot on that slot???? wtf... super intimidating.
Click to expand...
Click to collapse
I don't think this is true. If you're simply in a system bootloop, you can still get into bootloader.
Thanks
iElvis said:
The A/B info page I linked explains exactly what happens:
You can see there are multiple stages here, and if the bootloader can't even load, that slot won't be marked as active.
There's an even more detailed version here: https://source.android.com/devices/tech/ota/ab/ab_implement
As I understand it, twrp can change active slots, but if the slot has been marked unbootable (because it's not bootable), then it probably has to fixed with a clean reflash.
Unless the slot is completely empty, you should still be able to get to bootloader. Obviously, if the bootloaders are corrupted on both slots, you have a brick, but you can do that on non-A/B phones too.
I'm not sure the situation is that dire. A bad release of twrp could bork a non-A/B phone the same way? Here you've got two slots instead of one.
I don't think this is true. If you're simply in a system bootloop, you can still get into bootloader.
Click to expand...
Click to collapse
All this is related to the same doubt. On the flow on the page you linked, it tries to boot, if it fails N times it sets the slot as unbootable and changes to the other. You cannot just change to the previous slot and enter fasboot there since the bootloader won't boot that already unbootable boot. It is considered unbootable even if its a system issue with bootloader/kernel working.. or I'm getting that wrong? On a normal partitions phone, you won't ever get locked to enter fasboot because system won't boot, here it will happen per the flow diagram on the site...
iElvis said:
I'm not seeing an option to disable A/B updates anywhere.
Click to expand...
Click to collapse
Not A/B updates, but automatic updates. I don't have the phone, but I've been told in this sub that there's an option to disable automatic updates there.
RusherDude said:
All this is related to the same doubt. On the flow on the page you linked, it tries to boot, if it fails N times it sets the slot as unbootable and changes to the other. You cannot just change to the previous slot and enter fasboot there since the bootloader won't boot that already unbootable boot. It is considered unbootable even if its a system issue with bootloader/kernel working.. or I'm getting that wrong? On a normal partitions phone, you won't ever get locked to enter fasboot because system won't boot, here it will happen per the flow diagram on the site...
Click to expand...
Click to collapse
I think I see what you may be missing here. One slot being unbootable doesn't lock you out of fastboot. You can get into fastboot on the other slot, where you can flash anything you want to either slot. So you're not locked out of it if it fails to boot, you just can't boot up on that slot and the system will boot on the other slot.
Not A/B updates, but automatic updates. I don't have the phone, but I've been told in this sub that there's an option to disable automatic updates there.
Click to expand...
Click to collapse
Ah, yes, you can indeed disable automatic upgrades. You can also just download the OTA and not reboot, which I've done several times. Download, stop the process, reboot to recovery before the slot switches over.
iElvis said:
I think I see what you may be missing here. One slot being unbootable doesn't lock you out of fastboot. You can get into fastboot on the other slot, where you can flash anything you want to either slot. So you're not locked out of it if it fails to boot, you just can't boot up on that slot and the system will boot on the other slot.
Click to expand...
Click to collapse
In that scenario, yes you could reflash from slot B, but if you manage to then also bootloop on slot B, you end up with 2 slots with bootloader & kernel partitions working properly, system not booting and unable to enter fastboot or twrp on any of those? My doubt here is if bootloader/fastboot is "always there" even if you derp on both slots or not. If there isn't and you're reduced to qualcomm protocol having 2 correct aboot/fastboot partitions it is the most idiotic measure I have seen done by Google in a long time.
iElvis said:
Ah, yes, you can indeed disable automatic upgrades. You can also just download the OTA and not reboot, which I've done several times. Download, stop the process, reboot to recovery before the slot switches over.
Click to expand...
Click to collapse
I'm interested in that. Which process do you kill? And after rebooting to recovery, you just reboot normal and the slot change and such is ignored and system ignores the download ota and such? or from now on you can't reboot normally again?
Related
One of my slots/partitions does not work anymore. Both should have the same OOS with blue_spark kernel and his TWRP mod - but slot A doesn't boot (stuck on the "bootloader unlocked" warning screen, doesn't reboot as far as I can tell) and when I have it active, the recovery doesn't prompt me for my PIN - and all user data is still encrypted. Slot B works flawless though.
(It's been like that for a few months already, I just forgot about it since I haven't rebooted my phone in a while.)
What course of action should I take?
I've looked before and found this thread - https://forum.xda-developers.com/oneplus-6/help/bootloop-one-partitions-t3809859
But honestly, I'm not sure if it's the same issue. I can't tell if it's bootlooping and I assume it isn't, since it's stuck on the warning.
Not very sure how I managed to do this exactly but I think it's because I forgot to remove my fingerprint lock etc. before flashing a new custom rom (or because I removed it directly after and switched partitions unintentionally? I have no clue anymore)
I've back most of my important data up, so I'd be open to basically reset everything, if that's the only way.
Would the appropriate way about this be to just go into recovery and tell it to wipe everything?
Use the MSM tool to flash a fresh image onto your phone. Then, once you're booted, flash an ota image (this will be flashed onto the other slot) via the oneplus local system update option.
This should work as I have faced your issue a couple of times while changing roms.
Personally I would just start fresh and use the MSM tool. Read a post somewhere on Reddit yesterday when I was in the same boat and some guy said you could clone slot A with B and vice versa using TWRP or some Motorola based tool, but seeing as it would have been quicker and cleaner to just do it the MSM route, I went for that.
It sounds like a security patch incompatibility. I don't think there's any way to fix it besides reformatting that slot. You will of course lose all your data.
I believe one of the security updates decided to install partially and prepare to install on the next reboot which came during a night out where the phone reached 0%. Now when I turn the phone on all I'm getting is "Cannot load Android system. Your data may be corrupt" Google/Sargo 10/QQ1A.200205.002/6084386.
My question is, is there any method that can get a dump of the user data? I would be interested in paying for a chip off type service to get the local storage back. I pretty much do not care if the device is ever actually usable again, I have other phones to switch to but there was a lot which was not cloud syncing on this 3A. A nand dump is worth more to me than the phone itself. I've read that Pixels are encrypted by default though so I'm unable to think of anything other than being SOL on it.
I'm pretty furious at this thing, it's left me with the wipe and deal-with-it ultimatum that I'm only used to seeing from toying with flashing devices yet all I did was swipe away the February patch notification 2 or 3 times. How can this thing really have just bricked itself totally stock? Don't they bother to check the battery level before auto applying updates anymore? Help! What the hell Google?
Edit: Or thinking about this more calmly - is it possible to flash only the bootloader or key partitions of the os without wiping the sdcard partition? I could care less about the installed app data, only thing lost would be Signal messenger history. But the user space partition is the biggie.
naaaaail said:
I believe one of the security updates decided to install partially and prepare to install on the next reboot which came during a night out where the phone reached 0%. Now when I turn the phone on all I'm getting is "Cannot load Android system. Your data may be corrupt" Google/Sargo 10/QQ1A.200205.002/6084386.
My question is, is there any method that can get a dump of the user data? I would be interested in paying for a chip off type service to get the local storage back. I pretty much do not care if the device is ever actually usable again, I have other phones to switch to but there was a lot which was not cloud syncing on this 3A. A nand dump is worth more to me than the phone itself. I've read that Pixels are encrypted by default though so I'm unable to think of anything other than being SOL on it.
I'm pretty furious at this thing, it's left me with the wipe and deal-with-it ultimatum that I'm only used to seeing from toying with flashing devices yet all I did was swipe away the February patch notification 2 or 3 times. How can this thing really have just bricked itself totally stock? Don't they bother to check the battery level before auto applying updates anymore? Help! What the hell Google?
Edit: Or thinking about this more calmly - is it possible to flash only the bootloader or key partitions of the os without wiping the sdcard partition? I could care less about the installed app data, only thing lost would be Signal messenger history. But the user space partition is the biggie.
Click to expand...
Click to collapse
Afaik, you can change the default boot partition, as we have 2. Only one gets updated. You can do that in fastboot mode. Search google for an how to. It should be something like boot a or boot b.
Wish you good luck with your data. I can write tomorrow, i have to sleep now.
Can you still boot into recovery?
If so, and if I understand the problem correctly, you might be able to ADB sideload an OTA from there. Download the version you were on or the update after that from https://developers.google.com/android/ota#sargo to your PC, boot into recovery and choose "Sideload update from ADB", get ADB running on your PC and use this command in a command line window
Code:
adb sideload [/path/to/ota.zip]
which should apply it like a regular update without wiping anything. This is possibly your best bet.
Did you unlock your bootloader, by any chance? Then you might also be able to flash a factory image via fastboot, but you have to remove the "-w" in the "flash-all.sh/bat" file to avoid wiping the device.
I faced another issue and went through a lot of troubleshooting, which I wrote about here and it might be informative or relevant to some extent:
https://forum.xda-developers.com/pixel-3a/help/systemui-crash-loop-rescue-directions-t3997747
Everything failed in my particular case, though, but this might show you some other ideas I and other helpful people had, especially with an unlocked bootloader.
I think you can edit the flash-all script and remove the wipe from the script line. But I'd try sideload OTA First if you can
my god the A/B slot thing is a *****. has anyone rooted their tmobile and has no issues restarting it. This thing is sensitive. I lose sim when it starts on A slot. Someone needs to make an mega guide just on the A/B crappy thing. Can someone delete or combine both sluts, i mean slots?
I can understand your frustration, it is a bit odd but that's how it is we all have to live with it. One thing I have learnt is never switch slots manually let the phone select the slot itself, also the first thing I do is decrypt the phone, keep in mind you will loose all data on internal drive when you decrypt your phone, I don't have a tmobile but a European oneplus 7 pro, bootloader unlocked, decrypted, twrp, rooted, have tried all the roms in the thread, never switched slots manually and I have never ran into any problems, hope this helps, cheers.
vtec303 said:
I can understand your frustration, it is a bit odd but that's how it is we all have to live with it. One thing I have learnt is never switch slots manually let the phone select the slot itself, also the first thing I do is decrypt the phone, keep in mind you will loose all data on internal drive when you decrypt your phone, I don't have a tmobile but a European oneplus 7 pro, bootloader unlocked, decrypted, twrp, rooted, have tried all the roms in the thread, never switched slots manually and I have never ran into any problems, hope this helps, cheers.
Click to expand...
Click to collapse
Hey thanks. I read a good A/B slot guide and i get it. I haven't decrypted but i should of before i transfered stuff. Its interesting, i now sense what is happing with the slots and which one is having a problem. Call me the slot whisperer lol. Great to hear that you dont have problems. Awesome phone.
trueiceman said:
Hey thanks. I read a good A/B slot guide and i get it. I haven't decrypted but i should of before i transfered stuff. Its interesting, i now sense what is happing with the slots and which one is having a problem. Call me the slot whisperer lol. Great to hear that you dont have problems. Awesome phone.
Click to expand...
Click to collapse
Thats great news, enjoy your phone, all the best, cheers
vtec303 said:
Thats great news, enjoy your phone, all the best, cheers
Click to expand...
Click to collapse
Thanks. Some questions if you don't mind.
1) can we flash everything- cust rom, gapps, twrp and magisk) on one slot and do the exact thing for the other slot?
2) why can"t we delete system and vendor when flashing a custom rom? I have done that with all other phones in the past.
Thanks..
trueiceman said:
Thanks. Some questions if you don't mind.
1) can we flash everything- cust rom, gapps, twrp and magisk) on one slot and do the exact thing for the other slot?
2) why can"t we delete system and vendor when flashing a custom rom? I have done that with all other phones in the past.
Thanks..
Click to expand...
Click to collapse
On these phones wiping system and vendor renders it non bootable, everything gets wiped the phone might still boot in fastboot/bootloader or might get bricked, so don't wipe it.
Most of the ROMS and other flashable scripts get flashed on both slots anyway you don't have to manually switch slots and flash twice, I have never switched slots or flashed any script twice. When you flash twrp watch it flashing it will say running script on slot A and after a few seconds slot B. And yes you can flash everything on both slots but it has to be the exact same ROM and scripts. May be cos I'm decrypted I don't need to flash every file/script twice manually, don't have any experience of encrypted phone. Hope this helps, cheers.
The solution to A/B slot s to make sure both are on the same version of OS.
If not the settings between the two may be different. The system partitions are different, but the shared partitions hold settings.
Make both slots boot on the same version of the OS and you will not have issues.
vtec303 said:
On these phones wiping system and vendor renders it non bootable, everything gets wiped the phone might still boot in fastboot/bootloader or might get bricked, so don't wipe it.
Most of the ROMS and other flashable scripts get flashed on both slots anyway you don't have to manually switch slots and flash twice, I have never switched slots or flashed any script twice. When you flash twrp watch it flashing it will say running script on slot A and after a few seconds slot B. And yes you can flash everything on both slots but it has to be the exact same ROM and scripts. May be cos I'm decrypted I don't need to flash every file/script twice manually, don't have any experience of encrypted phone. Hope this helps, cheers.
Click to expand...
Click to collapse
Oh i see. Thanks so much. Its just frustrating when restarting the phone only to have the sim not detected. When i wipe cache and switch slots it usually comes back. I hate the sensitivity of losing sim. Im still trying to find the best install method.
tech_head said:
The solution to A/B slot s to make sure both are on the same version of OS.
If not the settings between the two may be different. The system partitions are different, but the shared partitions hold settings.
Make both slots boot on the same version of the OS and you will not have issues.
Click to expand...
Click to collapse
Yeah both have the same versions. I cant wait till this thing behaves like a normal solid phone. Thanks.
Hey Guys,
this could propably be posted in r/TIFU as well since I think I screwed up big time today -.-
I basically just wanted to update my rooted OP7P to 10.0.5 (EU) using the latest OTA - so I followed the usual steps as always:
Uninstall Magisk
Install OTA - No Reboot
Install TWRP retention script in Magisk
Re-Install Magisk
Reboot
This procedure worked fine the last 2 times an OTA was released but this time I'm not able to boot into the system anymore. TWRP is still in places but won't read the data partition anymore - it also doesn't ask for my pattern to decrypt it. Problem is that idiot-me of course didn't do a backup before (yea, I know -.-) and obviously doesn't want to loose the data on it.
I of course checked the forum and googled my ass of trying to find a non-destructive way to access the system but couldn't find anything fitting my scenario. So my last resort is to ask you guys directly: Did anybody ever encounter such a situation and if yes, how did you resolve it? Right now any support would be much appreciated
//Edit: Symptoms and current behaviour:
Boot into system (partition A) ends in the OP logo cirling endlessly
Boot into system (partition B) sends me directly to TWRP
TWRP doesn't ask for encryption pattern
The answer to TWRP's initial question (Keep System r/o) is not persisted
Fastboot/ADB are working (but obviously w/o access to /data)
I'm technically running a stock OxygenOS with Renovate ICE. I know technically its instuctions say to install the OTA directly from within TWRP and and then re-flash TWRP and Magisk but that wasn't neccessary the last times... one idea of mine is to just do that now and see where it leads me but I really don't wanna risk my data.
the.cybertronic said:
Hey Guys,
this could propably be posted in r/TIFU as well since I think I screwed up big time today -.-
I basically just wanted to update my rooted OP7P to 10.0.5 (EU) using the latest OTA - so I followed the usual steps as always:
Uninstall Magisk
Install OTA - No Reboot
Install TWRP retention script in Magisk
Re-Install Magisk
Reboot
This procedure worked fine the last 2 times an OTA was released but this time I'm not able to boot into the system anymore. TWRP is still in places but won't read the data partition anymore - it also doesn't ask for my pattern to decrypt it. Problem is that idiot-me of course didn't do a backup before (yea, I know -.-) and obviously doesn't want to loose the data on it.
I of course checked the forum and googled my ass of trying to find a non-destructive way to access the system but couldn't find anything fitting my scenario. So my last resort is to ask you guys directly: Did anybody ever encounter such a situation and if yes, how did you resolve it? Right now any support would be much appreciated
//Edit: Symptoms and current behaviour:
Boot into system (partition A) ends in the OP logo cirling endlessly
Boot into system (partition B) sends me directly to TWRP
TWRP doesn't ask for encryption pattern
The answer to TWRP's initial question (Keep System r/o) is not persisted
Fastboot/ADB are working (but obviously w/o access to /data)
I'm technically running a stock OxygenOS with Renovate ICE. I know technically its instuctions say to install the OTA directly from within TWRP and and then re-flash TWRP and Magisk but that wasn't neccessary the last times... one idea of mine is to just do that now and see where it leads me but I really don't wanna risk my data.
Click to expand...
Click to collapse
The bad news is once twrp loses access to data. The only fix is to format data and everything will be fixed.
So... you're basically telling me I ****ed up completely and my data is gone? Never was a profile picture more fitting than yours right now :/
What I'm wondering is that, from a technical perspective and on a working phone, the decryption takes place not during the boot but only after you've entered your code/passphrase/pattern on OS level. Meaning the system should theoretically be able to boot up to there without /data access. TThat's why I had the idea to flash a clean stock Oxygen from TWRP (no root), boot the system and hopefully be able to access the data this way. Respectively any encryption can be broken somehow, can't it? Even if it might take quite some time to do so this should theoretically be possible...
I mean... I definetly don't know enough about Android internals to understand its encryption mechanics completely but from a technical perspective it should be possible.... like the saying "there is no such thing as 100% security"
the.cybertronic said:
So... you're basically telling me I ****ed up completely and my data is gone? Never was a profile picture more fitting than yours right now :/
What I'm wondering is that, from a technical perspective and on a working phone, the decryption takes place not during the boot but only after you've entered your code/passphrase/pattern on OS level. Meaning the system should theoretically be able to boot up to there without /data access. TThat's why I had the idea to flash a clean stock Oxygen from TWRP (no root), boot the system and hopefully be able to access the data this way. Respectively any encryption can be broken somehow, can't it? Even if it might take quite some time to do so this should theoretically be possible...
I mean... I definetly don't know enough about Android internals to understand its encryption mechanics completely but from a technical perspective it should be possible.... like the saying "there is no such thing as 100% security"
Click to expand...
Click to collapse
Dude try flashing the stock rom from twrp onto both slots by mounting an otg drive..or adb sideload(very slow I think..still worth a try if you don't wanna lose data)..stock rom can manage the encryption I suppose.
Encryption is an issue when you flash different roms(I think so..I am no expert,just my experience so far).
Breaking encryption is not like what you think..it might take ages to break using brute force (again from what I heard..I lost my data a lot of time flashing roms without twrp backup..nowadays I just backup my apps using tb coz restorings the apps is really a pain in the ass process)
the.cybertronic said:
So... you're basically telling me I ****ed up completely and my data is gone? Never was a profile picture more fitting than yours right now :/
What I'm wondering is that, from a technical perspective and on a working phone, the decryption takes place not during the boot but only after you've entered your code/passphrase/pattern on OS level. Meaning the system should theoretically be able to boot up to there without /data access. TThat's why I had the idea to flash a clean stock Oxygen from TWRP (no root), boot the system and hopefully be able to access the data this way. Respectively any encryption can be broken somehow, can't it? Even if it might take quite some time to do so this should theoretically be possible...
I mean... I definetly don't know enough about Android internals to understand its encryption mechanics completely but from a technical perspective it should be possible.... like the saying "there is no such thing as 100% security"
Click to expand...
Click to collapse
The reason that format is the only answer is because when twrp does not ask for password. It believes you are unencrypted. What has happened is the file that store your password and encryption key is corrupted so any answer you give is wrong.
There's nothing you can do but format data. I've encountered this issue already.
You can try to salvage personal photos and videos using an otg drive (external ssd, hdd, sd card reader...), also back in 6t days I had this encryption problem twice, I remember that one time flashing the stock rom from the otg fixed it but I don't remember if I rebooted to recovery of the other slot.
Anyway, for the others, if he used DM verity removal and so decrypted data, he would have never face this problem again?
Joker123## said:
Dude try flashing the stock rom from twrp onto both slots by mounting an otg drive..or adb sideload(very slow I think..still worth a try if you don't wanna lose data)..stock rom can manage the encryption I suppose.
Encryption is an issue when you flash different roms(I think so..I am no expert,just my experience so far).
Breaking encryption is not like what you think..it might take ages to break using brute force (again from what I heard..I lost my data a lot of time flashing roms without twrp backup..nowadays I just backup my apps using tb coz restorings the apps is really a pain in the ass process)
Click to expand...
Click to collapse
vegetaleb said:
You can try to salvage personal photos and videos using an otg drive (external ssd, hdd, sd card reader...), also back in 6t days I had this encryption problem twice, I remember that one time flashing the stock rom from the otg fixed it but I don't remember if I rebooted to recovery of the other slot.
Anyway, for the others, if he used DM verity removal and so decrypted data, he would have never face this problem again?
Click to expand...
Click to collapse
I just tried flashing the stock Oxygen yesterday but to no satisfying result... afterwards it just showed a clean default-structure on the SD. Long story short: I accepted the fate that my data is gone and learned a valuable lesson... first thing I installed after rooting was Titanium^^
Zhuang zhuang said:
There's nothing you can do but format data. I've encountered this issue already.
Click to expand...
Click to collapse
As hard as it is to admit, you were completely right... I just lost 6 months worth of photos incl. my last vacation in Vietnam - fml.
the.cybertronic said:
I just tried flashing the stock Oxygen yesterday but to no satisfying result... afterwards it just showed a clean default-structure on the SD. Long story short: I accepted the fate that my data is gone and learned a valuable lesson... first thing I installed after rooting was Titanium^^
As hard as it is to admit, you were completely right... I just lost 6 months worth of photos incl. my last vacation in Vietnam - fml.
Click to expand...
Click to collapse
For future reference, brick means a brick. Like, can't boot to fastboot/twrp/or use msmtool
the.cybertronic said:
As hard as it is to admit, you were completely right... I just lost 6 months worth of photos incl. my last vacation in Vietnam - fml.
Click to expand...
Click to collapse
In the recent OS (10.0.5 & beta 13) I think Oneplus they add something that prevent user from using the TWRP retention script. I always use this solution for lower version and have no issue but with both 10.0.5 and beta 13 have the same issue
Zhuang zhuang said:
In the recent OS (10.0.5 & beta 13) I think Oneplus they add something that prevent user from using the TWRP retention script. I always use this solution for lower version and have no issue but with both 10.0.5 and beta 13 have the same issue
Click to expand...
Click to collapse
damn, good to know if I ever install OOS again - I now switched to Havoc... even though I had to skip rooting it all together after I couldn't get Magisk running with the latest safety net changes (thanks Google -.-)
Hello
Device GM1917 - OS10 beta 13 - Magisk and TWRP installed (I have a full TWRP backup)
Looking for procedure to prevent the completion of OTA OS 11beta5 update (screen shows update downloaded, installed and now asking for reboot to complete)
I am not sure how I got here as I have been avoiding the download/update for almost a year (although wife did use my phone yesterday)
My searches on XDA have not really provided much information beyond completing the update, installing Magisk to inactive slot and then reverting back to OS 10 through another flash.
Other threads discuss the function of slot A and B, and swapping active slots to stay on the slot with OS10, however I do not know which slot has OS10 and which is holding the OTA update. One post stated that the system will always boot to the slot with the newer OS, so this may not be an option.
Would clearing cache in TWRP recovery have any effect?
I really need to stay on OS10 - phone works just the way I want it, and I have apps that do not work well on OS 11.
Any advice would be appreciated.
Thank you
I think that you can just freeze the system update app using titanium backup.
Thanks for the reply, but that will only prevent future updates from being downloaded.
Or will it also prevent the current update from being permanently written after reboot
pxer said:
Thanks for the reply, but that will only prevent future updates from being downloaded.
Or will it also prevent the current update from being permanently written after reboot
Click to expand...
Click to collapse
I think that it will prevent the installation of whatever downloaded. You could try to locate that large file download and delete it as well.
Thanks again. TB did not provide much insight. The downloaded file was deleted the same day.
I found one article that said deselecting the auto-update in D/O prevented the installation of the update on a normal reboot (using power button) as opposed to the reboot option within the update app. I had the auto-update deselected before the download so maybe that will save me. Last resort with be switching slots using fastboot commands. Will try on weekend when I have the time to repair the damage and/or figure out how to wipe the update siting in limbo on the inactive slot.
Pxer. Titanium backup will not tell you what to freeze since it's not a smart app.
You have to go in, search for apps with the word "update", and freeze them. That will stop any update completely
pxer said:
Thanks again. TB did not provide much insight. The downloaded file was deleted the same day.
I found one article that said deselecting the auto-update in D/O prevented the installation of the update on a normal reboot (using power button) as opposed to the reboot option within the update app. I had the auto-update deselected before the download so maybe that will save me. Last resort with be switching slots using fastboot commands. Will try on weekend when I have the time to repair the damage and/or figure out how to wipe the update siting in limbo on the inactive slot.
Click to expand...
Click to collapse
@pxer were you able to solve this?
I'm in the exact same situation. Rooted + TWRP and somehow an OTA for Android 12 was downloaded and installed (should have failed signature validation before any download since I'm still running the patched boot.img)
In any case, I have no desire to take this update and want to keep my current active slot as the active slot.
Sadly, I was going on vacation just before this happened and did want to be left without a phone, so I did not try to repair/prevent the update. Since then I have been too busy, and have just not restarted my phone for the past 8 months. According to the information I had gathered, you need to identify which slot you are on pre-update, then you can revert back to that slot. As a suggestion, if you are using any Magisk mods, best to disable/remove them before attempting anything so as to limit the negative effects that might be created by the mods during the slot switching.
pxer said:
Sadly, I was going on vacation just before this happened and did want to be left without a phone, so I did not try to repair/prevent the update. Since then I have been too busy, and have just not restarted my phone for the past 8 months. According to the information I had gathered, you need to identify which slot you are on pre-update, then you can revert back to that slot. As a suggestion, if you are using any Magisk mods, best to disable/remove them before attempting anything so as to limit the negative effects that might be created by the mods during the slot switching.
Click to expand...
Click to collapse
8 months without a reboot (or random crash)?? That's impressive.
Thanks for posting back here.