Duo1 Boot stall - Established install w/ no recent apps

[verbunk]

Acknowledgements

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

Info

• Device: duo1
• GSI version: 2024-11 / 2025-03-11
• Vendor version:

Expected Behavior

OS boots as expected

Current Behavior

After selecting reboot the device goes black (expected), the MS logo is shown and then the spinning DUODE logo. This is as far as the device will boot.

Possible Solution

No response

Steps to Reproduce

1. Unknown steps

Logs

No response

Additional context

I've managed to go from Boot Screen > Droid laying down > Recovery Screen > Fastbootd menu. After that I grabbed the latest 2025-03-11 and flashed over the (then) existing 2024-11 version. It still exhibits the same behaviour of stalling at the spinning DUODE logo. After the update to 2025-03-11 I can still get back to recovery / fastbootd.

Some output,

adb shell su -c dmesg > dmesg.log
* daemon not running; starting now at tcp:5037
* daemon started successfully
adb: device unauthorized.
This adb server's $ADB_VENDOR_KEYS is not set
Try 'adb kill-server' if that seems wrong.
Otherwise check for a confirmation dialog on your device.

adb logcat > logcat.txt
- waiting for device -

^ Stalls at waiting

[verbunk]

Stalling in the description above means the boot does not (seem) to progress. The logo continues to spin. I've left this for ~10 minutes without it progressing.

Edit - I waited longer and eventually it dumped me out to the android on side.

Edit 2 - The duo absolutely does NOT want stay powered off. No combination of keys worked - only the boot menu > poweroff.

[Archfx]

Were you able to flash back to the 2024-11 version?

[verbunk]

Same result. Stalls at spinny DUODE logo. For confirmation,

Hold PWR-DN+tap power to enter boot menu > Recovery Mode > Hold PWR+Tap PWR-UP to enter Selection Menu > Fastbootd mode. Then,

$> fastboot flash system aosp-arm64-ab-vanilla-15.0-20241223.img
Resizing 'system_b'                                OKAY [  0.005s]
Sending sparse 'system_b' 1/9 (262112 KB)          OKAY [  0.921s]
Writing 'system_b'                                 OKAY [  2.452s]
Sending sparse 'system_b' 2/9 (262112 KB)          OKAY [  0.892s]
Writing 'system_b'                                 OKAY [  1.424s]
Sending sparse 'system_b' 3/9 (262100 KB)          OKAY [  0.892s]
Writing 'system_b'                                 OKAY [  1.427s]
Sending sparse 'system_b' 4/9 (262124 KB)          OKAY [  0.880s]
Writing 'system_b'                                 OKAY [  1.403s]
Sending sparse 'system_b' 5/9 (262128 KB)          OKAY [  0.886s]
Writing 'system_b'                                 OKAY [  1.430s]
Sending sparse 'system_b' 6/9 (262084 KB)          OKAY [  0.891s]
Writing 'system_b'                                 OKAY [  1.445s]
Sending sparse 'system_b' 7/9 (262124 KB)          OKAY [  0.855s]
Writing 'system_b'                                 OKAY [  1.431s]
Sending sparse 'system_b' 8/9 (262128 KB)          OKAY [  0.862s]
Writing 'system_b'                                 OKAY [  1.410s]
Sending sparse 'system_b' 9/9 (210152 KB)          OKAY [  0.688s]
Writing 'system_b'                                 OKAY [  1.328s]
Finished. Total time: 23.985s

$> fastboot reboot
Rebooting                                          OKAY [  0.000s]
Finished. Total time: 0.050s

There was one time a few weeks back when I rebooted it seemed to take an especially long time so it may be that this was building up(?). Could it suggest an out of space or similar issue that I would need to clean? I did try 'fastboot erase cache' but it gave error there was no cache.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[verbunk]

Follow up . Eventually it did come back (I kept it awake while booting). Once back in I did an update over air and noticed at the end it switched booting from B to A area. During the after update reboot it was as fast as ever so I'm thinking my B boot area is clogged in some way. Super technical, I know. 🤷

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 7 days since being marked as stale.