Google Pixel 2 bootloop, locked device limitations? patching an OTA? - Google Pixel 2 Questions & Answers

My Google Pixel 2 phone is in a bootloop (perpetually showing G logo animation). I don't know if this was triggered by the almost full memory or by a mechanical shock. Simply, one morning it just refused to boot. However, after being stuck for several hours, it booted, worked fine for few hours and then powered off in the middle of taking a photo. Bootlooping since then. I tried various approaches with no success so far. There is locally stored personal data that is very important to me. I would appreciate very much any help provided to understand what is going on and recovering the data.
After discharging the battery completely (freezer) I was able to get into the Recovery menu, sideload two different replacement Android 8.1.0 OTA images via adb following the instructions on Maker, but the phone is still bootlooping. I also tried heating the back of the phone but I could not get it to boot that way either.
Device state is listed as: Boot-slot:a, Console: Disabled, Secure boot: yes (PRODUCTION), Device State: locked. According to recovery file oem flashing is supported but boot flash is currently locked.
What are exactly the limitations of locked device state and disabled console?
I was able to sideload update recovery OTAs. What is exactly locked and what can be still externally modified? The adb sideload process showed success message but the phone is not behaving any different, hence I am confused whether I have indeed managed to replaced the Android system code on my device with those from sideloaded OTA or not?
If yes, what could be the reasons that sideloading clean OTAs (neither the same - build G, nor a newer one - build Q) has not changed the situation at all?
From related posts it seemed that the almost full storage could be preventing the system to boot.
Would it make any sense to try to modify/patch these OTA images with some code that would e.g. delete some unnecessary data on the phone as early as possible in order to make sufficient space for the kernel to load? Perhaps deleting some swap file or temporary data would be sufficient?
Has anyone tried thist?
A

anyone?

anabbb said:
anyone?
Click to expand...
Click to collapse
First, you won't be able to modify the ota as it's signed by google and you'd need the signing key on any modified file.
If it's an issue with the storage being almost full you might try using adb to pull and then delete any large files you have.

Related

[GUIDE] The Noob's Guide to A/B Partitions and Other OP6 Idiosyncrasies

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?

A Standard Update Put my Phone into a Reboot Loop? Why? But it does Unlock.

Galaxy s8 on Verizon, a standard update notice kept appearing past few days, finally installed it. The minute it finished, it is now in an endless restarting loop. The phone does unlock and show my homescreen. I can get into it, but I only get about 10 seconds to do stuff then it freezes/restarts. Tried Clear Partition Cache in the recovery mode. Tried Safe Mode. No luck.
When I rush over to Settings>Software Update, and click it, it says "Software update in progress"....so it makes me think it is the remnants of the new software update completing itself, and that causes the rebooting. The final stages perhaps? Is there a way to CEASE that the second I unlock my phone? To stop all the background stuff.
Or maybe wouldnt make a difference. Any ideas besides factory reset? Way to revert back?
Wanted to backup a few recent pictures first.
A factory reset is the last resort to fix this.
Maybe it's theme related. Try toggling the button layout (settings -> display -> navigation bar) a couple of times.
If you have substratum installed, try disabling it.
If you want to back up your pictures;
Have you tried accessing the phone using a computer? Either just through a file explorer or by using ADB? To use ADB, you may need to get into settings -developer mode
I tried plugging into a computer, but I only have about 10 seconds, so I dont get enough time to access the files. I get into the phone drive on windows Samsung Galaxy>DCIM> CAMERA> ...then it reboots.
Developer mode is already enabled. Can ADB be used while on the recovery mode screen? I can access that command line looking screen as long as needed.
But accessing the phone normally like turning it on and unlocking the screen would not work, I would keep losing the connection when it reboots.
halfhumble said:
Galaxy s8 on Verizon, a standard update notice kept appearing past few days, finally installed it. The minute it finished, it is now in an endless restarting loop. The phone does unlock and show my homescreen. I can get into it, but I only get about 10 seconds to do stuff then it freezes/restarts. Tried Clear Partition Cache in the recovery mode. Tried Safe Mode. No luck.
When I rush over to Settings>Software Update, and click it, it says "Software update in progress"....so it makes me think it is the remnants of the new software update completing itself, and that causes the rebooting. The final stages perhaps? Is there a way to CEASE that the second I unlock my phone? To stop all the background stuff.
Or maybe wouldnt make a difference. Any ideas besides factory reset? Way to revert back?
Wanted to backup a few recent pictures first.
Click to expand...
Click to collapse
Try downloading that same version of Odin flashable stock firmware from the internet, the same version as the update that you received, then flash that via Odin. As long as the update does not upgrade your bootloader or your binary, it will not wipe your user data(pics).
But first....
If you can get to the homescreen and unlock the device, don't touch anything else once the device opens, just connect it to PC and retrieve your photos from the internal storage, then factory reset the device.
Sent from my SM-S767VL using Tapatalk
Droidriven said:
Try downloading that same version of Odin flashable stock firmware from the internet, the same version as the update that you received, then flash that via Odin. As long as the update does not upgrade your bootloader or your binary, it will not wipe your user data(pics).
Click to expand...
Click to collapse
I dont know what version the update was that caused it or how I would find out. But I ended up getting it fixed.
I just downloaded the most recent version firmware from SamFW.com, and used that one. The First flash, the phone was worse! It was now stuck at the samsung logo looping. I flashed it a second time, then it worked! Phone back to normal and backed up my pictures. I had used the home CSC file too, and none of my user data was wiped. I thought it was supposed to wipe that, got lucky
I assume once that OTA update comes back and tries to install, I may have this problem all over again. I can't go forever without the security updates.
Droidriven said:
If you can get to the homescreen and unlock the device, don't touch anything else once the device opens, just connect it to PC and retrieve your photos from the internal storage, then factory reset the device.
Click to expand...
Click to collapse
^
I had tried that a couple times, it lasts about 15 seconds then restarts. Not enough time, I would get to the DCIM folder but before pics loaded, it froze and restarted.
halfhumble said:
I dont know what version the update was that caused it or how I would find out. But I ended up getting it fixed.
I just downloaded the most recent version firmware from SamFW.com, and used that one. The First flash, the phone was worse! It was now stuck at the samsung logo looping. I flashed it a second time, then it worked! Phone back to normal and backed up my pictures. I had used the home CSC file too, and none of my user data was wiped. I thought it was supposed to wipe that, got lucky
I assume once that OTA update comes back and tries to install, I may have this problem all over again. I can't go forever without the security updates.
^
I had tried that a couple times, it lasts about 15 seconds then restarts. Not enough time, I would get to the DCIM folder but before pics loaded, it froze and restarted.
Click to expand...
Click to collapse
The most recent version that you downloaded might be the same update. The OTA updates and the Odin flashable updates are the same thing, the OTA update is just more automated. Flashing the same version as the OTA update via Odin, yields the same results. I think the Home CSC is the one that doesn't wipe user data. I think the Home CSC is intended for users that intend on keeping the device and using it in the same region/network and the other CSC is intended for users that want to sell the device or use the device in a different region or if you have a custom ROM and custom recovery on the device and you want to restore to stock. I could be wrong though.
If you do get a prompt for an OTA update, backup your data then factory reset the device then allow the device to update. That should prevent any further issues with updating via OTA.
Sent from my SM-S767VL using Tapatalk
Droidriven said:
The most recent version that you downloaded might be the same update. The OTA updates and the Odin flashable updates are the same thing, the OTA update is just more automated. Flashing the same version as the OTA update via Odin, yields the same results. I think the Home CSC is the one that doesn't wipe user data. I think the Home CSC is intended for users that intend on keeping the device and using it in the same region/network and the other CSC is intended for users that want to sell the device or use the device in a different region. I could be wrong though.
If you do get a prompt for an OTA update, backup your data then factory reset the device then allow the device to update. That should prevent any further issues with updating via OTA.
Sent from my SM-S767VL using Tapatalk
Click to expand...
Click to collapse
Okay, I see.
Well when the phone did boot back up normally after the 2nd flash, there was a pop up that said software update unsuccessful. So I'm not sure if the same OTA update actually updated per se. But yeah, next time Im ready, I've got everything backed up!
Thanks so much!
halfhumble said:
Okay, I see.
Well when the phone did boot back up normally after the 2nd flash, there was a pop up that said software update unsuccessful. So I'm not sure if the same OTA update actually updated per se. But yeah, next time Im ready, I've got everything backed up!
Thanks so much!
Click to expand...
Click to collapse
I always prefer updating via Odin instead of OTA, it is much better and less chance of issues such as bootloop or random reboot. These are the issues you were having. I actually suggest using Odin or Smart Switch on PC the next time an update is available. Or, on older devices, use Odin or Samsung Kies to update. OTA is frequently unreliable, it commonly causes bugs, especially if the update is a newer android version than what is already on the device, it usually causes conflicts due to user data from your previous system apps and user settings conflicting with the new system because of differences between the older system apps and the newer system apps or differences in settings in the older system conflicting with changes in how the newer system settings are handled. Systems don't like using system data that was created by another system when there are differences between the two systems.
Another method that can be used is if your manufacturer/carrier releases a stock update.zip that can be flashed via stock recovery, they are made specifically for flashing via stock recovery ONLY, they are not the same as the stock firmware file that is flashed via Odin. These can be downloaded to the phone's internal/external memory then you boot into stock recovery then factory reset/wipe cache in recovery(backup data before wiping) then you can flash the update.zip. Alternatively, you can flash the update.zip without resetting/wiping(this is called a "dirty" flash), in theory, a dirty flash is useful when you don't want to wipe data or lose data. But that comes with a chance of causing bugs, as you have discovered for yourself during your update process.
Sent from my SM-S767VL using Tapatalk

3a seems to have bricked itself without any modification?

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

Flashing Kernel Patch for RMM on unsupported Note 9 caused it to stop booting

Hello,
I've been trying to root my Note 9 using the "N960F_DS_N_Oreo_Root_for_OEM_issue_devices_V5" which I've found online and i believe it is based on what was developed by Dr. Ketan.
While flashing this setup, I selected "Proceed with ROM Flash and Multi tool", "Patch for OEM issue", "Flash Kernel Patch for RMM" and then "Root with Magisk". Once the installation is done and the device is rebooted, the phone no longer boots. It shows the logo Galaxy Note 9 powered by Android then black screen then loop again to Galaxy Note 9 logo and it stays in this loop. I can only break the loop by entering to the Download Mode and loading TWRP and staying there.
I'm suspecting that the "Flash Kernel Patch for RMM" that I've selected is not supported on my Note 9 Model.
Is there a way to revert back this change? or may be install back the default kernel?
Appreciate your help!
Regards,
Elias
As I can see you are proud owner of a softbricked phone.
My recommendation: re-flash phone's Stock ROM to get rid off of all mods you applied to the phone.
jwoegerbauer said:
As I can see you are proud owner of a softbricked phone.
My recommendation: re-flash phone's Stock ROM to get rid off of all mods you applied to the phone.
Click to expand...
Click to collapse
Thanks for your help.
I've downloaded this: https://androidfilehost.com/?fid=4349826312261705548
It's around 4.8GB. Is this what you're referring to?
Just to give some background, the phone got an accidental factory reset (which I still don't understand how) and i'm trying to retrieve at least some of the deleted data (mainly pictures/videos). All the recovery tools requested to have the phone rooted in order to do a deep scan. So I started this learning journey myself since no phone repair store was off help.
Would reflashing the phone stock ROM affect my chances of retrieving my data?
Thanks!
The Factory Reset performed erased all your user data: though they are still physically present on device, their entry in Android's MTF got removed. IMO it requires a forensic tool to recover them.
As soon as you re-flash the phone with Stock ROM the disk space utilised by user data again gets wiped ( means a new MFT gets created), so the chance to recover user data previously stored there is NULL.
jwoegerbauer said:
The Factory Reset performed erased all your user data: though they are still physically present on device, their entry in Android's MTF got removed. IMO it requires a forensic tool to recover them.
As soon as you re-flash the phone with Stock ROM the disk space utilised by user data again gets wiped ( means a new MFT gets created), so the chance to recover user data previously stored there is NULL.
Click to expand...
Click to collapse
I was checking this thread on this form: https://4pda.to/forum/index.php?showtopic=915992&st=520
it seems that it's the same problem as mine and he was able to resolve it by flashing the original kernel. Not sure how i can do the same.
EN90 said:
I was checking this thread on this form: https://4pda.to/forum/index.php?showtopic=915992&st=520
it seems that it's the same problem as mine and he was able to resolve it by flashing the original kernel. Not sure how i can do the same.
Click to expand...
Click to collapse
With regards to recovering wiped user data: As I can see you didn't get it.
jwoegerbauer said:
With regards to recovering wiped user data: As I can see you didn't get it.
Click to expand...
Click to collapse
hmmm, what i understood is that if I go and flash the phone with Stock ROM (to make it boot again) I'll lose any chance of getting my data back even with a forensic tool. Is that what you meant?
So I was trying to say that what if I just flash back the original kernel to solve my booting issue, would it also affect the possibility of retrieving the lost data?
Unless I'm confused with the terminologies and flashing kernel is the same as flashing the Stock ROM. I'm quite new to this .
I appreciate your help!
@EN90
As with Android
Kernel is the core part of Android OS and is based on Linux. It is the system which initializes, configures and sets all hardware components for use. It prepares the complete system for functioning. It consits of several sub-systems and services.
Stock ROM is a read only memory chip on the phone's motherboard that contains the Android OS image that boots every time you turn on your phone. A ROM contains full Android OS system and a few system apps that comes pre installed with the device.

Oneplus support--mysterious "parameters"

Bit of a long story, I'll try to make it quick.
A few months ago, I carelessly overwrote my boot partition with twrp.img and completely screwed up my op7p. All I had left was fastboot, so I had to manually flash each partition using .img files extracted from an OTA update zip. I eventually got back up and running by flashing LineageOS with this method—the same ROM I was running before the incident. The weird part is that, before trying Lineage, I tried using plain old OOS and it didn't work.
After flashing OOS to every writeable partition from fastboot and rebooting to system, I could get through the setup flow no problem. But a few seconds after the launcher appears, the screen would go totally black. Holding the power button would cause a brief vibration, like normal when the power-off menu shows up, but I had to use a button combo to actually reboot.
This exact situation is mentioned on OnePlus' support site: https://www.oneplus.com/support/answer/detail/op477 (Scenario 1). They suggest to "apply for the after-sales services" in this case, so I sent them an email about it, before I eventually got Lineage working again.
They finally got back to me the other day with some interesting info:
Regarding your issue, we are glad to explain it to you in this case. Since you have installed a custom OS previously, the device might modify the parameters to fit the system and logic requirements, and we believe it should be the point of the root of the cause. Oxygen OS may request different parameter settings which leads to a mismatch. In this case, the conflict between system and device parameter may cause this issue.
Click to expand...
Click to collapse
Whatever these "parameters" are, they must not be stored in any of the partitions which are writeable from fastboot. (I guess there is the possibility that they really are in a writeable partition and the OTAs just skip it for some reason, but that seems like quite an oversight.) But when I asked for more info about them:
We understand your concerns and feeling however unfortunately that we cannot share such information with our customers officially. I could personally recommend you please process the research yourself however as a OnePlus customer support agent, it is prohibited to share that information with our customers.
Click to expand...
Click to collapse
Apparently the details are top-secret!
I'm happy to run Lineage until I get a new phone, so if I can never run OOS again, then whatever. But I'm dying to know what the story is with these parameters. Does anyone know?

Categories

Resources