Infinite boot loop after battery drain

other8026

Pardo If that's not working, you can try sideloading the latest release that's still in alpha, 2025080400.

Pardo

If that's not working, you can try sideloading the latest release that's still in alpha, 2025080400.

Does it have to be alpha for any specific reason? I say this because I already sideloaded a stable OTA update successfully with adb. I don't remember which one tbh, but this was 2 weeks ago or so.

I will do it later today anyways just in case and will let you know.

other8026

Pardo Does it have to be alpha for any specific reason?

No. I just suggested that release because it's the latest.

Pardo

other8026

No. I just suggested that release because it's the latest.

I already tried this before then (maybe 2 or 3 updates ago).

other8026

Pardo Oh, okay, sorry. Well, if sideloading and safe mode don't work, then I can't imagine there's much else for you to do. In order to diagnose the problem we'd have to either see full logs or know how to reproduce the issue.

Pardo

other8026

Oh, okay, sorry. Well, if sideloading and safe mode don't work, then I can't imagine there's much else for you to do. In order to diagnose the problem we'd have to either see full logs or know how to reproduce the issue.

If you know about ways to get logs or other info I'll be glad to. I have little knowledge about android, all I've learnt is by searching around.
As for ways to reproduce, I'm afraid I don't know details myself. All I know is the phone was working smoothly and after letting the battery drain the boot loop started. The owner is a very regular user so I don't think he has fiddled with any advanced option.

Fay_Wilmont

Pardo The owner is a very regular user so I don't think he has fiddled with any advanced option.

For the owner to mess up the device this badly they would have to:

unlock the bootloader, factory resetting the phone in the process
either root the phone and change something in the system partition or flash a faulty ROM
relock the bootloader
boot succesfully once to disable OEM unlocking

So if that didn't happen, what's left is... a hardware failure? I don't know how else this could happen.

Sadly, for mobile OSes the standard is to not show any information about what's going on during boot, even when it goes wrong. This is something that's always baffled me. How are we to troubleshoot something like this without getting any hint about what the device is trying to do when it suddenly restarts? Very frustrating.

On desktop Linux you can usually press ESC to dismiss the boot logo and watch what the system is doing. They could've done something similar on Android, but as far as I know this doesn't exist.

Fay_Wilmont

Sorry, I was editing my comment to correct something, but it seems I was too late and am not allowed to edit it anymore. Here's the correction.

For the owner to mess up the device this badly they would have to:

unlock the bootloader, factory resetting the phone in the process
either root the phone or flash a faulty ROM
relock the bootloader
boot succesfully once to:
- disable OEM unlocking
- change something in the system partition to cause the bootloop (using root access or done by the faulty ROM)

Fay_Wilmont

O, and since you were able to sideload a GrapheneOS update while the bootloader is locked, we know that the integrity of the system wasn't messed with. And it replaced the system partition anyway, so even if the above could have happened it wouldn't have permanently bricked the device.

Proceed with sideloading another update, at least then both boot slots will have been overwritten. Maybe somehow a fault in the system partition was brought about by GrapheneOS itself and even though it is now the inactive system partition it is through some obscure bug still affecting the device.

Pardo

Fay_Wilmont

Proceed with sideloading another update, at least then both boot slots will have been overwritten

I will definitely try it, at least just in case.

Pardo

Fay_Wilmont Proceed with sideloading another update, at least then both boot slots will have been overwritten

Ok, I have tried this twice: First, sideloading the latest stable update and then an alpha channel one. Boot loop still happening. More details:

1st update (stable): Installed succesfully. On reboot the boot slot was not changed (slot b). And, when I entered recovery to do the next sideload with adb, it warned me that an update was in progress and that if I continued it would be lost. So I restarted and entered recovery again, in which now I could do adb sideload without warning. Does this convey any info?
2nd update (alpha): Installed successfully. On reboot slot was changed to a. Boot loop there.

nandohyphen1

So I guess the lesson at the end of the day is don't let your phone's battery discharge to 0% or it may bootloop?

Fay_Wilmont

nandohyphen1 No, that shouldn't cause a bootloop. I have done this many times on various devices and ROMs. Android properly shuts down before the battery is fully discharged, with enough juice left to boot up again.

de0u

nandohyphen1 So I guess the lesson at the end of the day is don't let your phone's battery discharge to 0% or it may bootloop?

It can happen. It shouldn't, and it won't always, but since running the battery flat is bad for the battery it's something to avoid anyway. Older batteries are more likely to suddenly crash when low.

Overall I would suggest charging at 20% if possible, and maybe shutting down if you go below 10% before you can charge (again, especially if the battery is old). Better safe than sorry.

nandohyphen1

Fay_Wilmont Thats good to know. I didn't know if it just always happened because of the lack of power. Thanks :)

nandohyphen1

de0u Overall I would suggest charging at 20% if possible

I agree. That is exactly what I do. I never like to go below 20% if possible. And I do have my battery saver set to turn on at 20% in case I can't charge right away. I think the lowest I've let my battery get is 18%

falastsaw

thure

thure i've tried this one with sucess 👍

de0u

Pardo [...] What I tried so far:

Full factory reset from recovery (and rescue) modes.

This is concerning, as follows. If you have wiped the user data partition and (discussed below) also installed a new system partition, and the device's hardware is ok, I think it should boot.

Pardo The problem comes in when the GrapheneOS logo appears. It has the shadow moving from left to right for a random time (can vary from maybe 5 to 30 seconds) after which it freezes (no shadow moving, just the white logo) and then reboots itself.

I am nervous about that range of variation. If something is going to go wrong and panic/crash the OS at that point, it sort-of should be deterministic. If it's varying all over the map that might be consistent with a storage failure.

Pardo 1st update (stable): Installed succesfully. On reboot the boot slot was not changed (slot b). And, when I entered recovery to do the next sideload with adb, it warned me that an update was in progress and that if I continued it would be lost. So I restarted and entered recovery again, in which now I could do adb sideload without warning. Does this convey any info?

I'm afraid I don't like that either. I think that if the sideload completed, the update to the system partition should be done, not in-progress. That sounds like maybe some things were written to storage but weren't there after the reboot.

Going back to the start of this... is it clear that the problem started after the battery was allowed to drain to zero, or is it possibly the other way around? Might the system have locked up and sat there, or maybe crashed into a boot loop, thus running the battery down to zero?

Pardo

A little bit of more info:

Recovery mode -> View recovery logs. Last lines are like: mount(source=/dev/block..., target=/mnt/system, type=ext4)=0: Success. Then 2 lines after: Warning: device does not exist: /dev/block/by~name/zoned_device.

Recovery mode -> Mount /system partition yields something like:

ERROR logwrapper: Cannot log to file /dev/fsclogs/log (maybe this line comes from a previous data wipe I did)
ERROR: recovery: Open failed: /metada/ota: No such file o directory
ERROR recovery: Couldn't mount Metadata.
Mounted /system.

Any ideas welcome.

And a question: Does any of you consider the device is fatally bricked?

Pardo

de0u Might the system have locked up and sat there, or maybe crashed into a boot loop, thus running the battery down to zero?

Unfortunately I can't know for sure. What I can certainly tell is that the phone was working perfectly up to that point. For personal matters, the phone was left turned on and unused for more than a week, after which it never completed to boot GrapheneOS.

de0u I am nervous about that range of variation. If something is going to go wrong and panic/crash the OS at that point, it sort-of should be deterministic. If it's varying all over the map that might be consistent with a storage failure.

That makes sense. Thanks for your time thinking about it.

bntrtm

de0u Because I've encountered the exact same issue as @Pardo, I'll provide what I can from my own experience, here.

For my case, the only difference is that I'm dealing with a Pixel 9a that I've just purchased.
At about 32% battery life, I actually hooked it up to charge, not realizing I had unplugged the USB wall adapter in favor of another appliance the night before. Naturally, the phone battery drained entirely (so, certainly drained to zero). When I saw this, I plugged the charger back into the wall, and later attempted to boot it up after it had reached 95%. This is when I encountered the boot looping issue, so here I am.

As of yet I've not attempted any sideloading with adb whatsoever (adb devices coming up with nothing connected...so, that's a separate issue for me to resolve before continued troubleshooting). But here are the final 9 lines of my own recovery logs. I hope it can be relevant to anyone who might be able to investigate further.

[0.291400] W:[libfstab] Warning: device does not exist : /dev/block/by-name/zoned_device
[41.431748] W:[libfstab] Warning: device does not exist : /dev/block/by-name/zoned_device
[41.431748] I:[libfs_mgr] Running /system/bin/fsck.f2fs -a -c 10000 –debug-cache /dev/block/sda10
[41.437481] Cannot log to file /dev/fscklogs/log
[41.437542] ERROR: logwrapper: Cannot log to file /dev/fscklogs/log
[41.437543]
[41.523807] I:[libfs_mgr] __mount(source=/dev/block/platform/13200000.ufs/by-name/metadata,target=/metadata,type=f2fs)=0: Success
[101.159337] I:Clearing BCB
[101.159754] W:[libfstab] Warning: device does not exist : /dev/block/by-name/zoned_device

On a related note, however, when I encounter the same warning @Pardo encountered when reaching the Apply update from ADB submenu:

GrapheneOS Recovery
google/tegu/tegu
16/BP2A.250705.008/2025080400
user/release-keys
...
Overwrite in-progress update?
An update may already be in progress. If you proceed, the existing OS may not longer boot, and completing an update via ADB will be required.

Included the header, just in case any of that information is relevant. So at least certainly in my case, where I've not yet attempted an update via sideloading, this warning gives me the impression that an automatic update was perhaps incomplete?

Anyway, for anyone who can investigate the issue further, now you have two identical cases available for the process.

de0u

Pardo That's the best I think I can do. It's possible that in a day or so a developer might come by and weigh in.

Fay_Wilmont

Pardo de0u Might the system have locked up and sat there, or maybe crashed into a boot loop, thus running the battery down to zero?

Unfortunately I can't know for sure. What I can certainly tell is that the phone was working perfectly up to that point. For personal matters, the phone was left turned on and unused for more than a week, after which it never completed to boot GrapheneOS.

I noticed the default setting on GrapheneOS is for it to reboot automatically when it hasn't been unlocked in the last 18 hours. So chances are the phone got stuck in the current bootloop before the battery was drained.

« Previous Page Next Page »