Unable to unlock phone, touch seems unresponsive (Phosh)

Running pmOS with Phosh on a PinePhone from a fresh install (today).

Behavior: When phone is locked, power-button is pressed to unlock. The "wifi-status", clock, etc. appears with the "swipe up" arrow in the bottom. When swiped, I get a numeric password prompt. I enter the pin, it does some animation for a while, then goes back to black screen. When I try to unlock a second time, I see the clock+wifi-thing, but I am unable to swipe up. Touch display seems completely unresponsive, thus I am unable to unlock. Error reproduced after several hard-reboots, always the same.

Expected behavior: Phone unlocks first time, or gives a "wrong password" message. Upon second try, the swipe works and password-prompt reappears. Upon correct password, phone is unlocked.

I have full SSH access to the phone all the time, and it responds live to calls/SMS. When I "tab" the black screen it responds and shows the wifi+clock thing. Unsure if this is cased by the touch or the accelerometer picking it up.

Not an actual screenshot, but it looks basically like this just without the card-error

Since it sounds like you built your own pmOS image, you need to make sure you have this patch in your aports directory: 9835084f

Without it, your phone will run at a higher, unstable memory frequency and freeze very frequently.

By clayton craft on 2020-09-03T17:21:56

That sounds very possible, I build it myself following the dialog. How can I apply the patch? (or alternatively, check if this is in fact the problem?)

By johays on 2020-09-03T17:34:59

is it as easy as pmbootstrap pull?

By johays on 2020-09-03T17:37:21

The patch is for u-boot. I believe pmbootstrap pull will get the changes to your pmaports repo on your computer, I merged the patch in both the edge and stable pmaport branches a few hours ago..

I'm not sure how you can view the DDR freq on the device, I didn't see anything obvious in /sys. @PureTryOut might know more about that.

You can query apk to see which version of the u-boot package is installed: apk info u-boot-pinephone, it should be u-boot-pinephone-2020.07_git20200803-r1. But that's just the package, and doesn't indicate the version of u-boot flashed to the boot device.. I don't know of a way to query that. You should be able to update/flash the newer u-boot by running this on the phone:

sudo apk update
sudo apk upgrade
<verify that the u-boot-pinephone installed is the right version before continuing>
sudo update-u-boot

Then reboot.

By clayton craft on 2020-09-03T17:54:23

Did a fresh install just now.

apk info u-boot-pinephone gives me u-boot-pinephone-2020.07_git20200803-r1 as it should

Ran,

sudo apk update
sudo apk upgrade
sudo update-u-boot

Rebooted. The bug is still there.

By johays on 2020-09-03T18:24:53

added type::bug ui-phosh + 1 deleted label

removed 1 deleted label

Hmm, in that case, I'm fresh out of ideas. I'm not able to reproduce this on my device. When you ran pmbootstrap init did you select the stable (v20.05) or edge branch?

By clayton craft on 2020-09-03T18:44:39

When you ran pmbootstrap init did you select the stable (v20.05) or edge branch?

Edge

By johays on 2020-09-03T18:47:06

If I monitor ~/.xsession-errors I see this:

(gsd-usb-protection:3023): usb-protection-plugin-WARNING **: 20:21:59.724: Error calling USBGuard DBus to change the protection after a screensaver event: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: T
he name org.usbguard1 was not provided by any .service files

(phoc:2911): phoc-wlroots-CRITICAL **: 20:22:00.848: [backend/drm/drm.c:364] Failed to page-flip output 'DSI-1': a page-flip is already pending

The last line gets added again and again every time I press the power-button or touch the screen

By johays on 2020-09-03T18:52:22

I'm running the stable branch at the moment, and I see similar messages in .xsession-errors when I turn on the display with the power button:

(phoc:2786): phoc-wlroots-CRITICAL **: 12:04:48.988: [backend/drm/drm.c:971] Skipping pageflip on output 'DSI-1'                                                                                                                                                                                                                                                                                                                        

So that might be a red herring..

By clayton craft on 2020-09-03T19:06:43

or not, since your message is still different than what I see.

By clayton craft on 2020-09-03T19:07:27

Ok, I can reproduce this on edge now. No idea what's going on yet.

By clayton craft on 2020-09-04T02:29:04

added release-edge label

I built an older version of mesa (20.0.7), similar to what is in the pmaports stable branch (where I didn't hit this issue) and I can still reproduce this.. so at least we can rule out some Mesa regression causing it.

By clayton craft on 2020-09-04T08:54:18

I can reproduce the issue. Looks like a regression from a package upgrade...

• https://gitlab.postmarketos.org/postmarketos/pmaports/-/commits/master
• https://gitlab.alpinelinux.org/alpine/aports/-/commits/master

FIWI, I've attached strace to phosh but did not find anything helpful there.

To move forward with this, we could try to guess which package caused the regression or build phosh from source, see if we can reproduce it there, and if we can, debug it with gdb or debug prints to figure out where and why it hangs. src/lockscreen.c and src/lockscreen-manager.c look relevant.

By Oliver Smith on 2020-09-04T13:38:57

I noticed there's a phosh process that starts as soon as you hit 'unlock', and that if you kill it before the display shuts off again (i.e. over ssh), then it will unlock and you're taken to your phosh 'desktop'. This seems to be really reliable.

pstree shows this errant phosh process is started by phosh

-phosh(2883)---pool-phosh(3379) 

@ollieparanoid suggested trying a revert of this patch that hit dbus recently: https://gitlab.alpinelinux.org/alpine/aports/-/commit/b602ab703e11942e10986bfd236307198c6a97f1 I tested that theory and it doesn't seem to help this problem.

By clayton craft on 2020-09-04T19:22:10

Having the same issue, I have a pinephone braveheart in case its a hardware specific problem but it does seem like software to me

By Raatty on 2020-09-04T22:44:39

Got this issue on another device while updating through gnome-software, maybe related to the last two lines about PAM ?

Sep  4 18:44:34 alcatel-idol3 daemon.warn chronyd[1492]: System clock was stepped by 1598829123.360161 seconds
Sep  4 19:24:47 alcatel-idol3 authpriv.notice polkitd[1615]: Reloading rules
Sep  4 19:24:47 alcatel-idol3 authpriv.notice polkitd[1615]: Collecting garbage unconditionally...
Sep  4 19:24:47 alcatel-idol3 authpriv.notice polkitd[1615]: Loading rules from directory /etc/polkit-1/rules.d
Sep  4 19:24:47 alcatel-idol3 authpriv.notice polkitd[1615]: Loading rules from directory /usr/share/polkit-1/rules.d
Sep  4 19:24:47 alcatel-idol3 authpriv.notice polkitd[1615]: Finished loading, compiling and executing 7 rules
Sep  4 19:24:47 alcatel-idol3 authpriv.notice polkitd[1615]: Reloading rules
Sep  4 19:24:47 alcatel-idol3 authpriv.notice polkitd[1615]: Collecting garbage unconditionally...
Sep  4 19:24:47 alcatel-idol3 daemon.info dbus-daemon[1359]: [system] Reloaded configuration
Sep  4 19:24:47 alcatel-idol3 authpriv.notice polkitd[1615]: Loading rules from directory /etc/polkit-1/rules.d
Sep  4 19:24:47 alcatel-idol3 authpriv.notice polkitd[1615]: Loading rules from directory /usr/share/polkit-1/rules.d
Sep  4 19:24:47 alcatel-idol3 authpriv.notice polkitd[1615]: Finished loading, compiling and executing 7 rules
Sep  4 19:24:47 alcatel-idol3 daemon.info dbus-daemon[1359]: [system] Reloaded configuration
Sep  4 19:25:18 alcatel-idol3 daemon.info dbus-daemon[1359]: [system] Activating service name='dev.Cogitri.apkPolkit.Helper' requested by ':1.63' (uid=10000 pid=2112 comm="/usr/bin/gnome-software --gapplication-service ") (using servicehelper)
Sep  4 19:25:18 alcatel-idol3 daemon.info dbus-daemon[1359]: [system] Successfully activated service 'dev.Cogitri.apkPolkit.Helper'
Sep  4 19:34:42 alcatel-idol3 authpriv.err : PAM unable to dlopen(/lib/security/pam_unix.so): Error relocating /lib/security/pam_unix.so: pam_modutil_search_key: symbol not found
Sep  4 19:34:42 alcatel-idol3 authpriv.err : PAM adding faulty module: /lib/security/pam_unix.so

By Vincent Knecht on 2020-09-05T06:05:19

I am running into this issue as well on edge. I suspect it has to do with some pam module as @vknecht suggested. I built an image with pmbootstrap, selected edge, kept most other things vanilla (no extra packages), and ran into this issue on first boot, so I don't think it's a configuration issue.

[Edit] I get this warning in ~/.xsession-errors, which points to a PAM issue as well:

(phosh:5953): phosh-auth-WARNING **: 13:24:55.256: pam_authenticate error Have exhausted maximum number of retries for service

By ಚಿರಾಗ್ ನಟರಾಜ್ on 2020-09-06T05:06:31

I made a significant discovery thanks to earlier hints about PAM. Phosh starts a background thread to interact with PAM, and it appears that thread is hanging. That's why killing the new thread/process that started after attempting to login would result in phosh unlocking. I've confirmed that this problem started happening with linux-pam 1.4.0 in Alpine by reverting to 1.3.1 (which is also in Alpine stable). With <1.4.0, phosh unlocks as expected. It's only after upgrading to 1.4.0 that it starts misbehaving.

By clayton craft on 2020-09-06T05:33:40

I've been able to determine that the call to pam_authenticate @ auth.c:90 never returns (or at least doesn't after several minutes..): https://source.puri.sm/Librem5/phosh/-/blob/v0.4.3/src/auth.c#L90

The warning @chiraag-nataraj saw is emitted after pam_authenticate returns, but I've never seen this happen yet on my device.

I found that linux-pam 1.4.0 in Alpine has a patch to pam_sm_authenticate, I don't know if calling pam_authenticate leads somewhere down the line to pam_sm_authenticate, and the patch seems to just be a refactor and nothing functional.

By clayton craft on 2020-09-06T08:14:26

So this turned out to be the same bug that affected dbus and libpulse in Alpine after upgrading musl to 1.2.

opendir was being called from a thread, and it's apparently not thread safe, PAM was hitting a deadlock and stalling, hanging the phosh thread that was using PAM. This wasn't a problem on PAM 1.3.1, because this patch added the call to opendir in 1.4.0: https://github.com/linux-pam/linux-pam/commit/1b087edc7f05237bf5eccc405704cd82b848e761

This issue is fixed by this upstream MR: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/12155

By clayton craft on 2020-09-06T22:40:46

Closing issue since fixed PAM is available now in Alpine edge.

By clayton craft on 2020-09-07T05:29:15

closed