First unlock fails despite correct password

durdelafya

Hi everyone,

inquring help as I'm locked out of my (primary and only) phone.

Issue:

First unlock of owner profile fails because phone does not accept password.

Environment:

Phone: Pixel 9 Pro XL
GrapheneOS Build: 2025122500 (-> latest)
Profiles: Owner profile is protected by password. Password contains >10 digits and includes letters, numbers and special characters - nothing too fancy. Password is backed up on paper. Other profiles are secured by a mix of PIN and biometrics.
Keyboard: No alternative keyboard app installed. Multiple languages added.

History:

Phone was purchased a few months ago and GOS ran ever since.
No settings were manually changed recently.
Password (and PIN and biometrics for irrelevant profiles) have not been changed since setup.
Latest GOS Update already ran for a few days without issues. Includes restarting (and possibly powering down) the phone.

Troubleshooting:

Restarting (incl. booting into safe mode) as well as powering down the phone.
Swipe up instead of pressing the lock button.
Try to open settings instead of pressing the lock button.
Closing the keyboard with the arrow on the buttom left corner and tapping back into the password field to reopen keyboard.
Switching languages.
Using alternative input of numbers by long-pressing letters.

Conclusion:

Researching brought up a few previous posts and included potential (upstream) UI as well as input bugs. Found no info so far in which the problem was officially acknowledged and consequently an actual solution designed. Likely a fresh install would get it back running but I'd lose data. It also would not guarantee for it to not happen again as I read a post in which a user had the same problem again after some time.

Thanks in advance!

de0u

durdelafya Does an external USC-C keyboard work?

de0u

durdelafya Also unsure whether such USB-accessories might be blocked by GOS security before first unlock (BFU).

That depends on which USB-C port-control setting was chosen.

durdelafya Found no info so far in which the problem was officially acknowledged and consequently an actual solution designed.

It's not clear how the project would design a solution to a problem that isn't understood. Even "acknowledging the problem" is challenging if it's not clear how many problems there are.

For sure some users don't write passwords down (not the case here); for sure some devices experience failures. If there's some bug in the Titan M2 that flips one bit in the key store once every 1,000,000 device-weeks, there are enough people running GrapheneOS to trip it every now and then, and absolutely nothing that the GrapheneOS project could do about that (except perhaps to encourage backups). And it might not even be a bug! Perhaps every now and then somebody's Titan M2 is hit by a cosmic ray.

gristle-cause

I can't speak towards your issue, but I can acknowledge that this is a beautiful bug report

durdelafya

Appreciating the response, nonetheless. ^^

durdelafya

de0u
Tried with a USB-A keyboard and a USB-A-to-C adapter shipped with the Pixel 6. Keyboard doesnt seem to draw any/enough power. Not sure if that combo (and Google's adapter specificially) would be sufficient, though, but that's all I can currently work with. Also unsure whether such USB-accessories might be blocked by GOS security before first unlock (BFU). Thanks for the idea, though.

Unless some magic happens, then it seems that a factory reset and therefore data loss is the way forward for tomorrow.

Is a password setup still reasonable or a PIN the safer choice? Have seen rare reports of both causing problems.
Is there anything I can still contribute to the devs regarding the analysis of the problem?

Any help to save my data would be appreciated.

durdelafya

de0u
Thus a factory reset with data loss of the past quarter it is, then. Very dissatisfied.
Nevertheless: thank you very much for your efforts!

durdelafya Is a password setup still reasonable or a PIN the safer choice? Have seen rare reports of both causing problems.

Any chance to take that is more reliable than a coin flip?

durdelafya

de0u That depends on which USB-C port-control setting was chosen.

I suspect the setting is on blocked unless unlocked. Cannot check it to know for sure, of course.

de0u It's not clear how the project would design a solution to a problem that isn't understood.

That's why I tried to bring all relevant information together as precisely as possible and asked what else I can bring to the table. Because while at no times I critized the project and still stand by my regular donations (e.g. from just this week), it is an unacceptable bug regardless. May it be hardware or software (upstream or GOS).

de0u

durdelafya That's why I tried to bring all relevant information together as precisely as possible and asked what else I can bring to the table.

If -- hypothetically -- it is a bug in the Titan M2, then it is a very rare one. Unfortunately the tools for debugging something like that are in Google's hands, at least as long as the GrapheneOS project doesn't have a seat at the secure-element-firmware table.

And, again, maybe it isn't a bug at all. Cosmic rays are a real phenomenon.

If whatever it is happens less often than CPU or DRAM or flash failure, it's going to be very hard to pin down, and meanwhile most solvable via backups.

de0u

durdelafya Personally I don't think I've detected a difference in frequency of reports between PINs and passphrases (because both seem rare, it's hard to say).

durdelafya

After reinstalling GrapheneOS via factory reset, I opted to protect the owner profile with a password again. Reused the same password and it works again as expected. Very much hope for the bug to never happen again.

@Mods: Feel free to close this thread. The cause remains unsolved, however. Thus, please notify the dev team to create awareness since I'm not the first to experience an install suddenly becoming useless due to such issue.

Thanks everyone!