P7P - Userspace reboot loop after app updates, no IME lock screen - /data ENOSPC

Derek

Since this morning my Pixel 7 Pro on GrapheneOS has been stuck in what appears to be a userspace reboot loop following overnight app updates. The device reaches the lock screen and shows the SIM PIN prompt with the numbers. I can enter the SIM PIN successfully But the input method editor (IME) never loads, so there is no on-screen keyboard to enter either the device unlock PIN. The system UI looks partially broken: the status bar is incomplete (no battery level/percentage), the wallpaper never renders, and after roughly 30 seconds the system triggers a quick reboot that only shows the GrapheneOS boot animation, without the full Google logo / cold boot sequence.

I have already sideloaded the latest stable GrapheneOS build (2025121701) over the existing installation, so the current slot should be on a known-good OS image, but the behavior is unchanged at the user profile level. Attempting to boot into safe mode via the standard Volume Down method during boot does not succeed, even though safe mode has worked reliably on this device in the past. Given that this started right after bulk app updates and the internal storage was at roughly 99% utilization beforehand, my working theory is that the /data partition is effectively at 0 bytes free, causing critical userspace components (SystemUI, IME, possibly Zygote-spawned processes associated with the primary user profile) to fail to initialize or to crash-loop.
Already tried removing SIM card, issue persists.

I am looking for guidance on the following:

Whether this behavior is consistent with a full /data partition (ENOSPC) leading to persistent crashes of SystemUI/IME and a userspace reboot loop of the decrypted user profile.
Whether there are any viable recovery strategies to reclaim space or restore a functional IME without wiping /data (e.g. interaction between cold boots vs userspace reboots, any known mechanisms that would allow minimal access to the user profile to delete data when storage is critically full).
At what point it is reasonable to conclude that the user data partition is unrecoverable in practice in this state and that a factory reset via recovery is the only realistic remediation path.

de0u

Derek Given that this started right after bulk app updates and the internal storage was at roughly 99% utilization beforehand, my working theory is that the /data partition is effectively at 0 bytes free, causing critical userspace components (SystemUI, IME, possibly Zygote-spawned processes associated with the primary user profile) to fail to initialize or to crash-loop.

Unfortunately that seems plausible.

I am not thinking of any way around this other than "factory reset", but maybe somebody else will have an idea.

thereisnospoon

Derek I'm having the exact same issue on my Pixel 8. Any luck so far? Storage space was also critically low, not sure whether this "state" is a consequence of some post-update tasks not being able to run properly or whether this would have happened anyway even if there were no recent system update i.e., the system is just not able to boot properly due to a full /data partition. In my case it's 2025122500 (the latest). To summarize: boot loop (triggered arbitrarily while using the touchscreen), minimal UI, no keyboard available to unlock the screen, airplane mode, battery icon shows completely empty although the phone is fully charged (this is not a battery issue), from the on-screen buttons that appear when the power button is pressed (e.g., Power Off, Restart, etc.) only the Emergency button is working and ironically a keypad appears there but that's not really helpful. I tried sideloading the previous release but unfortunately downgrades are not allowed... I'm hoping sideloading the next update would somehow magically resolve this and the phone can boot normally. I haven't done an backup in a while and I'm currently locked out of my phone due to what appears to be a software issue. Do the developers look at this forum? Is there any way we can escalate this issue? I can imagine quite a few people going through this because the internal storage on these devices is not that big and it's easy to max it out... Any help would be greatly appreciated.

thereisnospoon

Derek Please add your case to this issue:

https://github.com/GrapheneOS/os-issue-tracker/issues/6942

It looks like we're not the only ones affected by this. Perhaps there is hope after all and the developers will come up with something.

Derek

@thereisnospoon I just did a factory reset. Technically I doubt there is any solution for that other than preventing this from happening by blocking/reserving space. But when its too late I don't see any possibility to fix that other than factory resetting.

muhomorr

This bug is not directly caused by running out of storage space. It's a parser bug that is triggered by low storage condition. Freeing up the storage space does not fix it.

The fix for this issue will be included in the next GrapheneOS release:
https://github.com/GrapheneOS/platform_frameworks_base/pull/299