Hi all. I went outside today and then came back, with my phone (Liberty phone) in my pocket, and now the button that usually wakes the screen to do the unlock sequence is not waking the screen. The blue light is on as if I received a notification, however.
My experience with L5 on Byzantium has generally had the unlock feature being pretty reliable, or when it got suck I could double tap the button to do on/off and then unlock. But now it is not waking the screen at all. I am 95% confident that if I hard boot it will be fine and then I’ll be back in, but I was wondering if this has a recent cause or if there are some logs I should collect and submit to purism once I get access back.
Currently my sshd is set up to only accept keys and not password(s), and no keys are provided, causing the device to refuse sshd connections because I use this as my daily driver and didn’t want to bother dealing with NSA people who probably have solved RSA and could remote log in any time if sshd was enabled fully. Maybe I’ll change my mind on that some day but for now that is how it was, so I’d have to use a convergence tool rather than ssh if I was going to try for a recovery console on what’s currently running.
Possibly related, it seems like the log dies several minutes before I power cycled the device, listing a kernel NULL dereference:
Jun 13 13:55:11 pureos kernel: hi846 2-0020: using DT '/soc@0/bus@30800000/i2c@30a40000/camera@20' for 'reset' GPIO lookup
Jun 13 13:55:11 pureos kernel: of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/soc@0/bus@30800000/i2c@30a40000/cam>
Jun 13 13:55:11 pureos kernel: gpio gpiochip0: Persistence not supported for GPIO 25
Jun 13 13:55:11 pureos kernel: hi846 2-0020: using DT '/soc@0/bus@30800000/i2c@30a40000/camera@20' for 'shutdown' GPIO lookup
Jun 13 13:55:11 pureos kernel: of_get_named_gpiod_flags: parsed 'shutdown-gpios' property of node '/soc@0/bus@30800000/i2c@30a40000/>
Jun 13 13:55:11 pureos kernel: gpio gpiochip4: Persistence not supported for GPIO 4
Jun 13 13:55:11 pureos kernel: dw9714 3-000c: I2C write fail
Jun 13 13:55:11 pureos kernel: dw9714 3-000c: dw9714_vcm_suspend I2C failure: -5
Jun 13 13:55:11 pureos kernel: hi846 2-0020: i2c read error: -6
Jun 13 13:55:11 pureos kernel: hi846: probe of 2-0020 failed with error -5
Jun 13 13:55:12 pureos NetworkManager[618]: <info> [1718301312.8963] manager: rfkill: Wi-Fi now disabled by radio killswitch
Jun 13 13:55:13 pureos kernel: brcmfmac: brcmf_sdio_htclk: HT Avail request error: -123
Jun 13 13:55:13 pureos kernel: mmc1: card 0001 removed
Jun 13 13:55:13 pureos NetworkManager[618]: <info> [1718301313.7335] manager: rfkill: Wi-Fi now enabled by radio killswitch
Jun 13 13:55:13 pureos kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
Jun 13 13:55:13 pureos kernel: Mem abort info:
Jun 13 13:55:13 pureos kernel: ESR = 0x0000000096000004
Jun 13 13:55:13 pureos kernel: EC = 0x25: DABT (current EL), IL = 32 bits
Jun 13 13:55:13 pureos kernel: SET = 0, FnV = 0
-- Boot 62de4f9920e94f59ba36db9cbc9a5fde --
Jun 13 14:09:39 pureos kernel: Booting Linux on physical CPU 0x0000000000 [0x410fd034]
(hoping none of these log contents are personally identifying, moderators feel free to erase any if so)
The log is consistent with my human user action. I switched the WiFi switch on, then off, then back on, all unusually close together in time compared to what I normally do. This log looks like maybe 1 second between down/up on the hardware state. Maybe that was the problem?
I am running on the standard Byzantium flash that came with the liberty phone last fall. Never re-flashed and never upgraded to Crimson yet.
Edit:
Also, I wrote this post using nexdock on the same Liberty Phone, so, notably after a powercycle down/up the Liberty Phone was back to normal working condition. I simply found it unusual to hit a fail state where the device wouldn’t wake, and wanted to report.
That same behavior has happened to me on occasion. To me it seems more likely to happen the longer the uptime is between reboots, but that could also be coincidence.