Updating OTA from v2024.10.05 (A14) to v2024.10.17 (A15) effectively bricks the OS

Sidefix commented 1 week ago

Acknowledgements

[X] I have chosen an appropriate title.
[X] All requested information has been provided properly.
[X] This is not a feature request.
[X] This issue is not a duplicate of an existing issue.
[X] The issue is solely related to this GSI.
[X] This issue occurs with the latest available build.
[X] I am not running a custom vendor on my device.
[X] This issue is not kernel related.
[X] This issue is not related to Magisk/KernelSU/APatch.

Info

Device: Surface Duo 1
GSI version: latest
Vendor version: latest

Expected Behavior

The update should not impede the ability to interact with the OS

Current Behavior

After updating, the OS can no longer be interacted with, other than the power button menu.

Possible Solution

n/a

Steps to Reproduce

Be on v2024.10.05 (A14)
Update to v2024.10.17 (A15) via the Update OTA menu from Android Settings
Observe after the device update/reboot cycle that the OS no longer functions

Logs

No response

Additional context

A video representing the device behavior since the update is here: https://1drv.ms/v/s!AjXIJDi52MKGrbUOJSO36JEIrmWIBA

I can't upload the video here due to size.

The behavior seen in the video is the same I observed since the initial update was completed. The update was completed from the Settings OTA menu, no device lock while the download was occurring, and an immediate reboot once the confirmation was received. When the reboot was complete, the behavior from the above video began occurring.

Archfx commented 1 week ago

This does not look normal, however, it might be an issue with a user-installed application or setting, because A14 to A15 update was smooth as usual. There were a couple of security-related features changed by google when it comes to A15. Did you had face unlock or a similar feature setup on A14?

It looks like the boot process is crashing. I need the log file to see what is going on. Force reboot the device, collect the log from the boot process with adb logcat, and include it here.

Sidefix commented 1 week ago

Unfortunately I don't think I'll be able to provide logs since I did not have developer mode enabled at the time of the update. Now because of the bootloop, I can't enable USB debugging or accept the device fingerprint, so adb functionality gone.

Edit: I realized I omitted to answer some of the above questions. In short, all my apps were installed directly from the PlayStore. No sideloading done. I don't believe I had any unusual apps installed. Mostly Microsoft or Google branded apps with one or two exceptions. The security unlock of the device was configured to be fingerprint, not face unlock. Several fingerprints were configured.

sir86 commented 1 week ago

anyone other have this issue ? I use this rom as my daily driver since july and i have no time to backup my phone at the moment and reinstall all with fastboot if it gets bootloop after update by OTA.

Sidefix commented 1 week ago

More bad news. Since I have no critical data on the device, I decided to just try to flash the A15 image directly.

Unfortunately, it seems whatever the update process did, it might have deleted the system partition:

Sending sparse 'system' 1/11 (358908 KB)           OKAY [  8.251s]
Writing 'system'                                   FAILED (remote: 'Partition not found')
fastboot: error: Command failed

It's a bit over my head to properly understand the partitioning scheme of the device, so I used getvar all to better understand what's going on:

.\fastboot.exe getvar all
(bootloader) parallel-download-flash:yes
(bootloader) battery-level:99
(bootloader) hw-revision:20002
(bootloader) unlocked:yes
...
all:
Finished. Total time: 0.200s

Best that I can figure from the above, the partition naming scheme seems to have changed now and it's no longer the same as in the how-to for A14 flashing. Unless I'm missing something.

Since I'd like to avoid bricking my device irrecoverably, I'll wait on any further action; maybe someone who has a better understanding of what I can do to at least flash the image fresh can chime in.

Thanks in advance.

sanityseeker commented 1 week ago

I faced a similar issue after the update, unfortunately. Since the adb authorisation was gone, I used the official recovery mode (https://support.microsoft.com/en-us/surface/recover-surface-duo-if-it-won-t-start-1e6fb3cf-4e24-92a8-bc05-4984274bc6a4), wiped the data (maybe unnecessary), entered fastboot and re-flashed the latest android 14 image

sir86 commented 1 week ago

well thanks guys so i will better wait few weeks unital its gets more stable.

Sidefix commented 1 week ago

Update.

Unfortunately, looks like ultimate bad news for me.

Attempting to do the restore via the official recovery image from Microsoft seems to have completely torched the recovery partition as well now. Video here, too large to upload:

https://1drv.ms/v/s!AjXIJDi52MKGrbUVf2LzRqOJHhbFaw

I do believe my device is now well and truly forever dead.

Archfx commented 1 week ago

More bad news. Since I have no critical data on the device, I decided to just try to flash the A15 image directly.

Unfortunately, it seems whatever the update process did, it might have deleted the system partition:
Sending sparse 'system' 1/11 (358908 KB)           OKAY [  8.251s]
Writing 'system'                                   FAILED (remote: 'Partition not found')
fastboot: error: Command failed
It's a bit over my head to properly understand the partitioning scheme of the device, so I used getvar all to better understand what's going on:
.\fastboot.exe getvar all
(bootloader) parallel-download-flash:yes
Best that I can figure from the above, the partition naming scheme seems to have changed now and it's no longer the same as in the how-to for A14 flashing. Unless I'm missing something.

Since I'd like to avoid bricking my device irrecoverably, I'll wait on any further action; maybe someone who has a better understanding of what I can do to at least flash the image fresh can chime in.

Thanks in advance.

Please be sure to familiarize yourself with the platform tools if you are playing with different commands. Android devices with AB partitions use a dual-partition system for the boot and system images. The system image is integrated into the A and B slots instead of having a separate system partition. The update will not delete any partition unless you manually do something to remove some partition.

https://source.android.com/docs/core/ota/ab

Sidefix commented 1 week ago

With all due respect, the only commands I ever ran were either the commands from this projects' main page, or the ones from the official Microsoft recovery guide.

I did not run any other commands, and I was careful to run the commands as provided.

Sidefix commented 1 week ago

Reference, I ran the flash command exactly as per the guide:

Archfx commented 1 week ago

Update.

Unfortunately, looks like ultimate bad news for me.

Attempting to do the restore via the official recovery image from Microsoft seems to have completely torched the recovery partition as well now. Video here, too large to upload:

https://1drv.ms/v/s!AjXIJDi52MKGrbUVf2LzRqOJHhbFaw

I do believe my device is now well and truly forever dead.

Looking at the boot loop of your video, Try to use the volume control button with the power button to access the fastbootd, from there you may try to do a fresh flash. Don't delete any partition manually other than the one in the documentation with respective instructions. You might have accidentally deleted the system_a when your active slot is A.

Sidefix commented 1 week ago

Update. Unfortunately, looks like ultimate bad news for me. Attempting to do the restore via the official recovery image from Microsoft seems to have completely torched the recovery partition as well now. Video here, too large to upload: https://1drv.ms/v/s!AjXIJDi52MKGrbUVf2LzRqOJHhbFaw I do believe my device is now well and truly forever dead.

Looking at the boot loop of your video, Try to use the volume control button with the power button to access the fastbootd, from there you may try to do a fresh flash.

Unfortunately, regardless whether I press Start or Recovery, the bootloop begins again. I'm not aware of any other method to access fastbootd.

Archfx commented 1 week ago

Update. Unfortunately, looks like ultimate bad news for me. Attempting to do the restore via the official recovery image from Microsoft seems to have completely torched the recovery partition as well now. Video here, too large to upload: https://1drv.ms/v/s!AjXIJDi52MKGrbUVf2LzRqOJHhbFaw I do believe my device is now well and truly forever dead.

Looking at the boot loop of your video, Try to use the volume control button with the power button to access the fastbootd, from there you may try to do a fresh flash.

Unfortunately, regardless whether I press Start or Recovery, the bootloop begins again. I'm not aware of any other method to access fastbootd.

Pressing start or recovery from the menu will not do anything. I don't remember the exact key combo, but try pressing and holding the volume down + power key until you see the Android bot lying down. Then you can press and hold the power button and press volume up key. As soon as you release the volume up key you will be in recovery mode. From there you can enter fastboot or recover the stock image with the recovery image.

Sidefix commented 1 week ago

Recovery from the boot menu would normally load the screen you are referring to with the android logo lying down and the red exclamation mark.

I can no longer access this due to the bootloop.

Thanks for the input.

sir86 commented 1 week ago

its not bricked . i had smiller issues with my other phone few years back. i could not get in to fastboot cuz it was looping over and over so i could not fully trun it off.

Leave it for a night boot looping , battery will discharge and it will turn off finally. then charge it a bit but not turn it on. then press power and volume down same time and it will boot to fastboot.

Sidefix commented 1 week ago

Update: Some good news. Apparently fastboot responds to commands when in the boot selection menu (which is the only menu I can access as of now). ADB does not.

So I can at the very least try flash commands. However the system partition still isn't getting picked up, tried with the A14 image as well:

.\fastboot.exe flash system .\aosp-arm64-ab-gapps-14.0-20241005.img
Sending sparse 'system' 1/11 (358908 KB)           OKAY [  8.286s]
Writing 'system'                                   FAILED (remote: 'Partition not found')
fastboot: error: Command failed

Sidefix commented 1 week ago

@Archfx I've found this post:

https://xdaforums.com/t/a14-gsi-for-surface-duo.4598441/post-89007913

The behavior described in this post is exactly the behavior I'm currently encountering. This was from back when only Thai's build was available. Clearly something inside the build, and eventual recovery to Stock 12L, can cause the behavior. I am not blaming your work, I am trying to highlight that something is wrong and needs addressing since at this time at least two people encountered issues with the update.

Unfortunately the steps from the post have not yielded any successful results for me yet. I am still unable to access fastbootd. Regular fastboot does not allow me to create the system partition, and no flashing works. TWRP images boot successfully however.

I will continue trying to recover functionality to my device and report back here over time.

Thanks in advance for looking over this.

Archfx commented 1 week ago

@Archfx I've found this post:

https://xdaforums.com/t/a14-gsi-for-surface-duo.4598441/post-89007913

The behavior described in this post is exactly the behavior I'm currently encountering. This was from back when only Thai's build was available. Clearly something inside the build, and eventual recovery to Stock 12L, can cause the behavior. I am not blaming your work, I am trying to highlight that something is wrong and needs addressing since at this time at least two people encountered issues with the update.

The problem is since bootloader is unlocked users can do whatever they like to do with the device. As an example, you can use Magisk, root the device, and continue to work. The problem comes when you update the device with OTA. The modifications that you made to the image are not present in the updated image. There are a lot of things that you can do to create such scenarios. For manufacturers, it is not a problem since all the devices are in the same state when the OTA comes.

Unfortunately the steps from the post have not yielded any successful results for me yet. I am still unable to access fastbootd. Regular fastboot does not allow me to create the system partition, and no flashing works. TWRP images boot successfully however.

I will continue trying to recover functionality to my device and report back here over time.

Thanks in advance for looking over this.

Did you try the key combination to enter the recovery mode (holding the volume down + power key). Holding the power button should force shut down the device. Then use the above key combination to get to the recovery mode. AFAIK this is the only way to access the fastbootd from a device that is on a boot loop. What your fastboot is seeing (in the previous comment) is just the storage, device should to be in fastbootd menu to fastboot to work.

Sidefix commented 1 week ago

Fastbootd is accessible from the recovery menu as far as I know. Instructions for how to reach that menu are here: https://support.microsoft.com/en-us/surface/recover-surface-duo-if-it-won-t-start-1e6fb3cf-4e24-92a8-bc05-4984274bc6a4 Specifically Point 7 for Step 3 for Surface Duo 1. I am unable to reach this state.

I'll try to be as brief and representative of the current device state as I can. Bear with me please. The following is not meant to come across as condescending, rather strictly to represent the current challenge.

Scenario: Simply boot the device

1. Device fully off.
2. Press Power.
3. Device will bootloop as in the previous video after ~2 seconds of showing the Microsoft logo.

Scenario: Try to enter Fastbootd by holding Power + Vol

1. Device fully off.
2. Press & Hold Power + VolDown **OR** VolUp.
3. No effect. Device will bootloop as in the above scenario.

Scenario: Try to enter Fastbootd by pressing VolDown

1. Device fully off.
2. Press Power.
3. Wait for the Microsoft logo to pop on screen.
4. Immediately press & hold VolDown (alone).
5. Bootloader selector will appear. Fastboot (NOT Fastbootd) is accessible from here. Boot to TWRP is possible from here.

Scenario: Try to enter Fastbootd by selecting Enter Recovery from Bootloader

1. Device fully off.
2. Press Power.
3. Wait for the Microsoft logo to pop on screen.
4. Immediately press & hold VolDown (alone).
5. Bootloader selector will appear.
6. Select Enter Recovery. Device will re-enter the bootloop from the  "Simply boot the device" scenario above.

The VolUp instruction you refer to is documented in the Microsoft article I linked earlier. In short, I simply cannot reach this state.

Whatever happened, it seems as though multiple partitions are gone. Playing around with the TWRP options, I noted it fails to mount several different partitions:

It seems pretty clear to me that the action would be to simply re-create the torched partitions. I just have no idea which are gone and how to properly re-create them.

Some additional resources I've found to be relevant for this particular partitioning topic (but not my issue): https://github.com/WOA-Project/SurfaceDuo-Guides/blob/main/Install/Client/Partitioning-SurfaceDuo1.md https://github.com/kenpc-git/surface-duo

Sidefix commented 1 week ago

The problem is since bootloader is unlocked users can do whatever they like to do with the device. As an example, you can use Magisk, root the device, and continue to work. The problem comes when you update the device with OTA. The modifications that you made to the image are not present in the updated image. There are a lot of things that you can do to create such scenarios. For manufacturers, it is not a problem since all the devices are in the same state when the OTA comes.

I understand and we are in agreement here. I can commit to you that no modifications were done here by me specifically before this issue started, outside the specific instructions provided to install the original A14 image some few months ago. Since then I have moved from OTA to OTA reliably. Until this OTA update.

Since no other modifications were done by me, something in the process clearly can / is causing this.

I'm concerned for this occurring to someone else. I want to recover my device to prevent it from being useless, and I wouldn't want this to happen to anyone else.

Archfx commented 1 week ago

Couple of things,

I still believe you could have saved everything just by flashing the A14 after the first crash of the A15. Deleting partitions is only required when you are migrating from Stock A12. And I don't understand what were you doing with the partition delete commands when you were on a GSI.

System partitions will not get deleted via an OTA update. If the structures are not the same the OTA will fail.

Flashing a custom ROM is risky, that is why you always get a message on your device at the boot telling you that it is not safe. This is also why almost all the ROMS have a disclaimer. You are responsible for any action, especially with playing with fastboot commands.

The only way I can stop happening such scenarios is just by making this repository private such that none of you guys would be able to access it! If everybody feels that this ROM is a problem, let me know. For me, it is just a press of a button.

Ethanol10 commented 1 week ago

@Sidefix If it helps, you can actually recover back to A12 Stock through the means of a very cumbersome method but it works: https://www.reddit.com/r/surfaceduo/comments/12vb5h2/help_stuck_on_boot/

The first comment on this post highlights what should be done. In short, use payload-dumper-go to split the stock rom into img for each partition from Microsoft and flash each partition by hand as per specified.

I followed these instructions when I accidentally removed the wrong partitions and had to get back to stock but was in a bootloop forcing me back into bootloader every time. Some partitions will fail to flash in bootloader as they're not accessible (e.g system, system_ext etc.) until you get into fastbootd.

Once you get back to stock A12, it should be a matter of redoing the instructions from this repo as per the A12 guidelines and it should boot into A14/A15 (whichever you flash).

This obviously wipes your data though, so this is a last resort

sir86 commented 1 week ago

Couple of things,

I still believe you could have saved everything just by flashing the A14 after the first crash of the A15. Deleting partitions is only required when you are migrating from Stock A12. And I don't understand what were you doing with the partition delete commands when you were on a GSI.

System partitions will not get deleted via an OTA update. If the structures are not the same the OTA will fail.

Flashing a custom ROM is risky, that is why you always get a message on your device at the boot telling you that it is not safe. This is also why almost all the ROMS have a disclaimer. You are responsible for any action, especially with playing with fastboot commands.

The only way I can stop happening such scenarios is just by making this repository private such that none of you guys would be able to access it! If everybody feels that this ROM is a problem, let me know. For me, it is just a press of a button.

Playing with custom roms is for advenced users and risky ppl should be fully aware of that. Personally im happy that after MS stopped support DUO i can still have new android OS on it cuz ppl like you and i dont have to spend a lot of money on Pixel Fold or Samsung models . And im fully aware that i can brick my device playing with roms but thats happen so be it. Thx again for your work and time.

Sidefix commented 1 week ago

I still believe you could have saved everything just by flashing the A14 after the first crash of the A15. Deleting partitions is only required when you are migrating from Stock A12. And I don't understand what were you doing with the partition delete commands when you were on a GSI.

I never performed any partition delete operations. I'm not sure where this confusion is coming from. The only operation I ever attempted was the following, both with the A14 and A15 images:

fastboot flash system aosp-arm64-ab-gapps-15.0-[[version]].img

Flashing a custom ROM is risky, that is why you always get a message on your device at the boot telling you that it is not safe. This is also why almost all the ROMS have a disclaimer. You are responsible for any action, especially with playing with fastboot commands.

The only way I can stop happening such scenarios is just by making this repository private such that none of you guys would be able to access it! If everybody feels that this ROM is a problem, let me know. For me, it is just a press of a button.

This is a fair perspective if you somehow feel threatened or insulted. Which is very strange to me since I am trying to be civil despite the very frustrating situation I'm in that I'm sure you empathize with. I very explicitly did not throw any blame around, especially not at you. Quoting myself here from earlier in this thread:

"I am not blaming your work, I am trying to highlight that something is wrong and needs addressing since at this time at least two people encountered issues with the update."

I'm very much trying to have a productive conversation to solve a real problem.

Since your insistence has consistently been that the issue was somehow expressly caused by me or something I did in the flow, let's explore that idea if it provides insight into the cause and a possible fix (for future prevention so that noone else has to suffer through this) and mitigation for myself (if possible).

To that effect, here is a comprehensive timeline of my entire flow with this repro:

I had installed, back in August, build v2024.07.25, just before I started contributing with issues to the project.
I had used the flash instructions provided in this repo, and though I can't prove I had followed them to the letter, I assert that I did.
Since the initial flash of the build from Step 1, I have re-flashed using the same instructions several different strictly newer builds from this repro, desiring a fresh start to minimize the possibility of further issues occurring.
The most recent flash I had made successfully was build v2024.09.20
After successfully flashing the build from step 4, I have only updated builds via the built-in OTA Update from the OS Settings.
Most recent successful OTA update was done to v2024.10.05
When build v2024.10.17 was updated via OTA, the device entered the boot failure seen in my initial video upload on this issue.
At this time, as a mitigation attempt of my own, I tried flashing the base image of the build from step 7 directly. This was done exclusively via the following command, with no other commands attempted: fastboot flash system aosp-arm64-ab-gapps-15.0-[[version]].img

The command from step 8 resulted in this error:

Sending sparse 'system' 1/11 (358908 KB)           OKAY [  8.251s]
Writing 'system'                                   FAILED (remote: 'Partition not found')
fastboot: error: Command failed

In short, the system partition was not removed by me. Not explicitly. Perhaps one of my reflashes from steps 3/4 accidentally deleted the active system partition instead of the alternate? But then why did the subsequent OTAs work as intended? I am out of my technical element beyond making the above assertions and questions.

I hope this provides some insight into what could have possibly caused this. I'll be pending your feedback @Archfx

Sidefix commented 1 week ago

@Sidefix If it helps, you can actually recover back to A12 Stock through the means of a very cumbersome method but it works: https://www.reddit.com/r/surfaceduo/comments/12vb5h2/help_stuck_on_boot/

The first comment on this post highlights what should be done. In short, use payload-dumper-go to split the stock rom into img for each partition from Microsoft and flash each partition by hand as per specified.

I followed these instructions when I accidentally removed the wrong partitions and had to get back to stock but was in a bootloop forcing me back into bootloader every time. Some partitions will fail to flash in bootloader as they're not accessible (e.g system, system_ext etc.) until you get into fastbootd.

Once you get back to stock A12, it should be a matter of redoing the instructions from this repo as per the A12 guidelines and it should boot into A14/A15 (whichever you flash).

This obviously wipes your data though, so this is a last resort

I have no critical data on the device, so I am happy to try last resort options. Thanks for the help. I'll try this and report back.

sanityseeker commented 1 week ago

Just a small clarification of the issue I faced with this update. I didn't get a complete bootloop as @Sidefix, but basically the result situation was the following: device boots, screens stay black and rarely flicker for a second with my wallpaper, power button works and triggers a menu for restart and poweroff. I also don't know what exactly could've caused this. Prior to this, I had several successfull otas up to 10.05. Right now, I have successfully recovered from this and am using A14-based build.

Sidefix commented 1 week ago

Just a small clarification of the issue I faced with this update. I didn't get a complete bootloop as @Sidefix, but basically the result situation was the following: device boots, screens stay black and rarely flicker for a second with my wallpaper, power button works and triggers a menu for restart and poweroff. I also don't know what exactly could've caused this. Prior to this, I had several successfull otas up to 10.05. Right now, I have successfully recovered from this and am using A14-based build.

This was the behavior I had initially when I opened this issue. It's reflected in the initial video I posted at the top.

After you said flashing Stock12L worked for you, I tried the same by following the official MSFT guide. After doing that, I am now stuck in my current predicament.

I am very explicitly not blaming anyone.

sanityseeker commented 1 week ago

I am very explicitly not blaming anyone.

I don't get that impression, don't worry :)

After you said flashing Stock12L worked for you,

Hmm, wait a minute, maybe you've unfortunately misinterpreted me here. I used the official recovery mode only to wipe the data and enter the fastboot menu, from where I flashed the latest A14 system image. I never re-flashed the stock 12L recovery zip file.

Sidefix commented 1 week ago

I am very explicitly not blaming anyone.

I don't get that impression, don't worry :)

After you said flashing Stock12L worked for you,

Hmm, wait a minute, maybe you've unfortunately misinterpreted me here. I used the official recovery mode only to wipe the data and enter the fastboot menu, from where I flashed the latest A14 system image. I never re-flashed the stock 12L recovery zip file.

Aaah that's fair. So I probably deleted a few more partitions when trying to flash 12L.

This still doesn't explain why the system partition was deleted for me since before I attempted this step, but it does explain why I'm now in a much worse bootloop and can't access fastbootd.

Thanks for the clarity.

Archfx commented 1 week ago

This was the behavior I had initially when I opened this issue. It's reflected in the initial video I posted at the top.

I think the reason for this issue is an app or setting you had in A14 that uses a system API. I assume it is either related to UI or wallpaper. Unfortunately, we can't get into solving this issue without a log file.

Anyway, I am also not blaming @Sidefix and know that nobody is intentionally bricking their devices. I just wanted to highlight the possibilities that can occur with a mistake. I still believe you can recover from this situation since you can still flash a recovery.

sanityseeker commented 1 week ago

I remember that I might have changed the default font style to smth else (like One Plus). I also disabled the "gap" in treble settings and enabled camera2 api. Could any of that cause the unexpected behavior?

Archfx commented 1 week ago

I remember that I might have changed the default font style to smth else (like One Plus). I also disabled the "gap" in treble settings and enabled camera2 api. Could any of that cause the unexpected behavior?

Font style seems to be the problem. It uses the system UI APIs and they were changed during the update. UI app is crashing at the moment with A15.

Archfx commented 1 week ago

Actually, as a precaution, I reverted the OTA version for A14 branch to the latest stable version of the A14.

Sidefix commented 1 week ago

I appreciate the limited insight we have here. I don't recall what system options I may or may not have changed over the months so I cannot offer further details.

https://www.reddit.com/r/surfaceduo/comments/12vb5h2/help_stuck_on_boot/ Regarding the above reddit post, unfortunately I seem to have hit another snag. Although I successfully got the .img files from the payload.bin of the official recovery image, absolutely none of them are flashing.

I'm getting one of three errors, depending on the image I'm trying to flash:

"Critical Systems cannot be flashed", even though I absolutely have flashing unlocked for critical systems as well
"Unknown device error" - this one is the most common, no further details
"Partition not found" - for system & boot

I'm paraphrasing the errors since I'm commuting right now. I'll post clearer verbatims later.

One thing that came to mind that I did NOT try, that could perhaps be contributing to this, is that my USB cable is currently connected to my laptop via a docking station. I remember having flaky success with command line functionality about 10 years ago with completely different devices when going via a docking station, so I'll try a direct USB connnection to the laptop when I get a chance.

In short, for now no progress.

Thanks

Sidefix commented 1 week ago

Follow-up on my previous message. Here are the detailed errors I'm getting:

PS C:\Users\username\Downloads\platform-tools> .\fastboot.exe flash bluetooth_a ..\payload_dumper\output\bluetooth.img
Sending 'bluetooth_a' (876 KB)                     OKAY [  0.028s]
Writing 'bluetooth_a'                              FAILED (remote: 'Flashing is not allowed for Critical Partitions
')
fastboot: error: Command failed
PS C:\Users\username\Downloads\platform-tools> .\fastboot.exe flash boot_a ..\payload_dumper\output\boot.img
Sending 'boot_a' (98304 KB)                        OKAY [  2.224s]
Writing 'boot_a'                                   FAILED (remote: 'Error flashing partition : Device Error')
fastboot: error: Command failed
PS C:\Users\username\Downloads\platform-tools> .\fastboot.exe flash boot_b ..\payload_dumper\output\boot.img
Sending 'boot_b' (98304 KB)                        OKAY [  2.227s]
Writing 'boot_b'                                   FAILED (remote: 'Error flashing partition : Device Error')
fastboot: error: Command failed
PS C:\Users\username\Downloads\platform-tools> .\fastboot.exe flash system_b ..\payload_dumper\output\system.img
Sending sparse 'system_b' 1/4 (358908 KB)          OKAY [  8.263s]
Writing 'system_b'                                 FAILED (remote: 'Partition not found')
fastboot: error: Command failed
PS C:\Users\username\Downloads\platform-tools> .\fastboot.exe flash system_a ..\payload_dumper\output\system.img
Sending sparse 'system_a' 1/4 (358908 KB)          OKAY [  8.270s]
Writing 'system_a'                                 FAILED (remote: 'Partition not found')
fastboot: error: Command failed
PS C:\Users\username\Downloads\platform-tools> .\fastboot.exe flashing unlock_critical
FAILED (remote: '       Device already : unlocked!')
fastboot: error: Command failed

I've also tried hardwiring directly to the laptop via USB, bypassing the dock. No luck yet, same results.

I've spent a lot more time on this at this point than I can dedicate. I'll keep trying but more sparsely and will post here if I get any success within a reasonable amount of time.

I do believe the prevention of an OTA from 14 to 15 is the safest course of action for everyone right now and I appreciate it.

Ethanol10 commented 1 week ago

@Sidefix hmm, strange, has fastboot oem unlock been run on the device?

Edit: this probably won't work

Sidefix commented 1 week ago

@Sidefix hmm, strange, has fastboot oem unlock been run on the device?

Edit: this probably won't work

.\fastboot.exe oem unlock
FAILED (remote: 'unknown command')
fastboot: error: Command failed

It does not.

Archfx commented 1 week ago

@Sidefix Try fastboot reboot fastboot which you should be redirected fastbootd instead of fastboot. When you are in fastbootd, commands should work.

Once you get into fastbootd successfully, you should be able to flash the last A14 build. I didn't realize that you were trying to execute commands outside fastbootd.

Sidefix commented 1 week ago

@Archfx performing that command just puts me back in the bootloop unfortunately.

Right now this device is effectively locked at accessing the bootloader with regular fastboot. I've spent enough time with it. I happen to have a secondary SD1 that I'll fresh flash A15 on directly and be done with it.

If I do manage to find a way to get this one working, I'll post an update here.

Thanks everyone for your inputs.

Archfx / duo-de