P7P stuck in a boot loop after 2024062700 update

tasukete-kuremasenka

Hey everyone,

Last night I pressed the "Reboot Now" button on the GrapheneOS update notification, and the update seems to have borked my device.

I have been in the general and testing chat rooms, getting help from some kind people. Having already tried a couple things, I feel like this issue is more fitting for a forum post.

Following the reboot, my P7P is in a perpetual state of rebooting, showing the Google and GrapheneOS logos, flashing the login screen, then crapping out back to the GrapheneOS logo. This happens repeatedly with the device sometimes automatically attempting to boot with Safe Mode, but the device behaves the exact same. After a while it lands on the GrapheneOS Recovery screen with this message:
Cannot load Android system. Your data may be corrupt. (...)

I removed the SIM card, and sideloaded the 2024062700 OTA update. This completed successfully, returning exit code 0. When rebooting back to system, the behaviour remains.

I had thought to maybe fastboot boot (a TWRP).img to decrypt and pull my data off the device prior to a factory reset, but presumably verified boot would not allow this since my bootloader is locked?

In the Matrix chat room, iselluranium was thinking that the update may be corrupted and as the OTA update applies only the diff, maybe the reason my ADB sideload of the OTA update did not work is that the update corrupted something outside the OTA package, which would only be repaired with a flash of the full factory GrapheneOS image. From what I am reading here however, I am not sure if flashing the factory image would wipe all user data, or if that is only when locking the bootloader.

They also proposed the idea that this might somehow have to do with the update's removal of 32 bit support for the Pixel 7 line. While any ordinary app should have no ability to crash the OS (especially before login), perhaps an app with Admin and/or Accessibility privileges could have tried to run prior to unlock and caused this crash?

I believe there were only 2 apps installed that were granted Device Admin privileges:

Bitwarden (installed from their own F-Droid server)
TimeLimit.io (installed from the official F-Droid server)

My device showed no signs of hardware failure. The update was not interrupted, and the battery was around 70%.
Is there anything else I can do or try? I would really prefer to avoid a factory reset if possible.

Thanks.

de0u

tasukete-kuremasenka In the Matrix chat room, iselluranium was thinking that the update may be corrupted and as the OTA update applies only the diff, maybe the reason my ADB sideload of the OTA update did not work is that the update corrupted something outside the OTA package, which would only be repaired with a flash of the full factory GrapheneOS image.

While System Updater can fetch and apply delta updates "over the air" I believe OTA images contain the entire system partition, i.e., are not delta updates.

Flashing a factory image will require unlocking the bootloader, which for security reasons will wipe the user data partition.

tasukete-kuremasenka They also proposed the idea that this might somehow have to do with the update's removal of 32 bit support for the Pixel 7 line. While any ordinary app should have no ability to crash the OS (especially before login), perhaps an app with Admin and/or Accessibility privileges could have tried to run prior to unlock and caused this crash?

Unfortunately, this sounds plausible. Were the Bitwarden or TimeLimit apps 32-bit?

tasukete-kuremasenka

de0u Were the Bitwarden or TimeLimit apps 32-bit?

I can't recall exactly. I ran both APKs through this. Bitwarden showed arm64-v8a in "Supported ABIs". The TimeLimit APK did not give this section. Perhaps someone more familiar with Android app development would be able to tell from the codebase which architectures it is being built for?

tasukete-kuremasenka

I am not all that familiar with Android app development, but from what I have gathered it seems as though TimeLimit is a "universal" app that does not have any compiled libraries, etc which would restrict support for certain CPU architectures. So I believe both these Device Admin apps should have had no problem with the 32-bit support removal in the latest GrapheneOS update.

Given this, does anyone have any other ideas as to how I can either repair this in-place or access the user data prior to a factory reset?

tasukete-kuremasenka

I'm thinking of just re-flashing the factory image and forgoing my data that's still on the phone. Even if I'm SOL and won't be able to repair this or recover my data, a confirmation beforehand would be appreciated.

de0u

tasukete-kuremasenka In a sense there are three things that might be wrong:

Hardware failure
Corrupted system partition
Corrupted user data partition

Sideloading an OTA image should resolve #2, but you have done that. Sadly, probably the best way to experimentally distinguish between #1 and #3 is to wipe the user data partition (which can be done by booting into Recovery, without the need to flash a factory image). I realize that without a reliable backup system this is a grim experiment to run. Thus you might want to wait another 24 hours to see if anybody else has a bright idea.