Possibly a race on boot: fingerprint not operational

Bug Reports
#1

REPRODUCIBILITY (% or how often): high
BUILD ID = OS VERSION (Settings > About product): noticed on 4.0, tested on 4.1, confirmed on 4.2
HARDWARE (XA2, X10, X10 II, …): XA2
UI LANGUAGE: na
REGRESSION: (compared to previous public release: Yes, No, ?): unknown

DESCRIPTION:

Fingerprint doesn’t always work after boot

PRECONDITIONS:

Might be necesssary to have it on for some time and battery saving mode active (not too low value??)

STEPS TO REPRODUCE:

  1. Let the device run out of battery
  2. Connect to powersupply, boot it up,
  3. Unlock it promptly

EXPECTED RESULT:

Fingerprint is operational

ACTUAL RESULT:

Fingerprint is not always operational

ADDITIONAL INFORMATION:

(Please ALWAYS attach relevant data such as logs, screenshots, etc…)
I tested this on 4.1, more than 20 times…
The device, XA2, was encrypted, with “defaultuser”. I saw this once or twice on an XA2plus, unencrypted, “nemo”.
After the first PIN prompt, the spinner stutters.

Workaround:
Set DefaultStartLimitInterval to 180 s (/etc/systemd/system.conf).
At least, I couldn’t reproduce it then…

Additionally:
Quite often, this was acompanied by the SIM PIN entry misbehaving. The UI claimed that the SIM PIN was incorrect, when it was correct. SIM PIN not re-entered a second time, continued without unlocking the SIM. Then, the network icon was grayed out, calling out was not possible, but, receiving calls worked, “unlocking” the SIM in settings by tapping on it, disabling and enabling was possible without entering the SIM PIN.

1 Like
[duplicate] [4.2.0] [4.3.0] Fingerprint stops working
The Volla 22 (Gigaset GS5) Thread
#2

Just saw this on 4.5.0.18. Additionally, Calendar App was not behaving as specified/expected. After reboot later on, fingerprint is operational, but Calendar App changed behaviour, but still not correct. Now I’m wondering if there is a bug in the Calendar App or a side effect from somewhere else…

#3

Still reproducible in 4.6.0.12 EA…

#4

Yes, there’s definitely something amiss, especially, but not limited to, booting up from actdead (charging screen) mode.

I mentioned some suspicions here: Saved Alarms and Timers Disappearing After Reboot - #13 by nephros

and I believe it’s because HOME is not available when it should.

My “canary service” is jolla-usersetup, if that shows up as failed after boot, other services are probably in a bad state as well.

Now jolla-usersetup launches /usr/bin/jolla-usersetup which is a very simple shell script, and AFAICS, the only way it can fail is when the home directory is not accessible.

(Also, rarely, both maliit-server and xt9-server crash, making VKB unavailable. The annoying thing about those two is that they require each other, and once one of the crashes, they perform a dance where one stops because the other crashed and the other way around. The only way I found to recover is to do “stop both, sleep 3 secs; start both”
This may be unrelated to the OP though. It also may be related to me having SpeechNote installed, not sure.)

1 Like
#5

I read your other tread before, but thought it was a different thing. Now that you posted here, I thought again, and can’t find any contradictions to what I observe. And your explanation fits well with my workaround.
So, what is happening here?
Is booting slower when the battery is down to ~5%???
Does this mean that there is something wrong with boot sequence / dependencies?
(Additionaly, this time, the SIM recovered all alone… Didn’t notice that before.)