Fingerprint Reader not working after reboot / resume (tried the fix #3 - different issue)

[tenjinsoftware]

Hi,

I have this working on a lenovo Thinkpad T470s.

However, if I reboot or suspend it stops working.

I have applied "fix 3" from the other thread, and while that successfully restarts the two services, it looks like python3-validity isn't picking up the fingerprint reader (guess to be honest).

if I manually restart the python3-validity.service it starts working again.

Any ideas? Service status info below.

Thanks

Darren.

AFTER REBOOT OR RESUME:

sudo systemctl status python3-validity ● python3-validity.service - python-validity driver dbus service Loaded: loaded (/usr/lib/systemd/system/python3-validity.service; disabled; vendor preset: disabled) Active: active (running) since Wed 2022-06-08 16:19:35 BST; 16min ago Main PID: 5281 (dbus-service) Tasks: 3 (limit: 28526) Memory: 18.3M CPU: 291ms CGroup: /system.slice/python3-validity.service └─ 5281 /usr/bin/python3 /usr/lib/python-validity/dbus-service --debug

Jun 08 16:32:46 tenjin-fedora dbus-service[5281]: DEBUG:root:<tls< 17: 0000 Jun 08 16:32:46 tenjin-fedora dbus-service[5281]: DEBUG:root:VerifyStatus Jun 08 16:35:36 tenjin-fedora dbus-service[5281]: DEBUG:root:In ListEnrolledFingers darren Jun 08 16:35:36 tenjin-fedora dbus-service[5281]: DEBUG:root:>tls> 17: 4b00000b0053746757696e64736f7200 Jun 08 16:35:36 tenjin-fedora dbus-service[5281]: DEBUG:root:>cmd> 17030300503e80b754213aa2167c70a36a2e25ee59b2ee35ddb4a037f288b6f88b559969356fbcffacb5721b5bd3> Jun 08 16:35:36 tenjin-fedora dbus-service[5281]: DEBUG:root:<cmd< 0404 Jun 08 16:35:44 tenjin-fedora dbus-service[5281]: DEBUG:root:In ListEnrolledFingers darren Jun 08 16:35:44 tenjin-fedora dbus-service[5281]: DEBUG:root:>tls> 17: 4b00000b0053746757696e64736f7200 Jun 08 16:35:44 tenjin-fedora dbus-service[5281]: DEBUG:root:>cmd> 1703030050ee5b92bffba9e3307f8c4d280bcfcd2370d8d0f83ad5e836ec885b39a868370b6292d4c7a08e2c0379> Jun 08 16:35:44 tenjin-fedora dbus-service[5281]: DEBUG:root:<cmd< 0404

AFTER restarting the service again:

[darren@tenjin-fedora system]$ sudo systemctl restart python3-validity [darren@tenjin-fedora system]$ sudo systemctl status python3-validity ● python3-validity.service - python-validity driver dbus service Loaded: loaded (/usr/lib/systemd/system/python3-validity.service; disabled; vendor preset: disabled) Active: active (running) since Wed 2022-06-08 16:37:09 BST; 2s ago Main PID: 6153 (dbus-service) Tasks: 3 (limit: 28526) Memory: 17.8M CPU: 186ms CGroup: /system.slice/python3-validity.service └─ 6153 /usr/bin/python3 /usr/lib/python-validity/dbus-service --debug

Jun 08 16:37:10 tenjin-fedora dbus-service[6153]: DEBUG:root:>tls> 17: 40060100004450000000100000 Jun 08 16:37:10 tenjin-fedora dbus-service[6153]: DEBUG:root:>cmd> 17030300407c3ee4f1d75bea2be6b4f85974d68bfff7ad4a439929add7e4d1605a92ebfd0c5c1713d2c74c33cceb> Jun 08 16:37:10 tenjin-fedora dbus-service[6153]: DEBUG:root:<cmd< 1703031040c1725a201f26ccfe86a4f6794314a643b41761c345614c9a0a534f0d6a42b10053e4d7cfc57165cd80> Jun 08 16:37:10 tenjin-fedora dbus-service[6153]: DEBUG:root:<tls< 17: 00000010000000007e888884858183807c7d7f7c7e7b7d7b777870767d8385807870767d81827f80777a7c7a> Jun 08 16:37:10 tenjin-fedora dbus-service[6153]: DEBUG:root:>tls> 17: 4b00000b0053746757696e64736f7200 Jun 08 16:37:10 tenjin-fedora dbus-service[6153]: DEBUG:root:>cmd> 17030300505d359c36dd17200b0031e0411e104af859d89cf336ebd793a43becab629ea44dcb73f47c29405e91f2> Jun 08 16:37:10 tenjin-fedora dbus-service[6153]: DEBUG:root:<cmd< 1703030050a9b9669d2edc77845677d9f17dd91f92c9b15b94c493fc414a14a8573508c9a0ec2194fc71b948d62f> Jun 08 16:37:10 tenjin-fedora dbus-service[6153]: DEBUG:root:<tls< 17: 0000030001000b00000004004c0053746757696e64736f7200 Jun 08 16:37:10 tenjin-fedora dbus-service[6153]: DEBUG:root:atexit registered Jun 08 16:37:10 tenjin-fedora dbus-service[6153]: DEBUG:root:Manager is back online, registering

[uunicorn]

Hi, can you share the systemctl status for open-fprintd-suspend.service and open-fprintd-resume.service services?

[tenjinsoftware]

Hi,

Thanks for the reply. Here is the additional information:

[darren@tenjin-fedora ~]$ sudo systemctl status open-fprintd-suspend.service [sudo] password for darren: ○ open-fprintd-suspend.service - Restart devices after resume Loaded: loaded (/usr/lib/systemd/system/open-fprintd-suspend.service; disabled; vendor preset: disabled) Active: inactive (dead) [darren@tenjin-fedora ~]$

[darren@tenjin-fedora ~]$ sudo systemctl status open-fprintd-resume.service ○ open-fprintd-resume.service - Restart devices after resume Loaded: loaded (/usr/lib/systemd/system/open-fprintd-resume.service; disabled; vendor preset: disabled) Active: inactive (dead) [darren@tenjin-fedora ~]$

When I reboot or resume, manually restarting either open-fprintd-resume.service or python3-validity.service restores the fingerprint reader to working.

I'm quite new to this stuff, so might be a silly question, but there are two additional services that seem to do the same thing: open-fprintd-restart-after-resume.service and python3-validity-restart-after-resume.service, is it possible there is a clash as it looks like the services are being restarted twice?

D.

[uunicorn]

I don't know where open-fprintd-restart-after-resume.service and python3-validity-restart-after-resume.service came from. open-fprintd-suspend.service and open-fprintd-resume.service on the other hand are supposed to be a part of open-fprintd package. They are not designed to restart anything, rather they are there to notify the driver service (python3-validity) that computer went to sleep and the device needs to be re-initialized when it comes back.

From what I can see, both open-fprintd-suspend.service and open-fprintd-resume.service are disabled on your computer for some reason. Can you try to enable them and remove all these "restart-after-resume" services? Make sure you are using the latest python-validity version, as there was a fix related to suspend/resume recently. I'm not sure who's maintaining Fedora packaging for this project, but it would be nice to incorporate this fix. Also, find out why open-fprintd-{suspend,resume}.service are disabled on Fedora by default.

I'm not very familiar with the Fedora packaging system and I don't have anywhere to test, so I'm hoping someone with more experience can pick this up.

[tenjinsoftware]

Thanks again for your help.

It's all working now. In case anyone finds this thread I thought I'd add some info.

Bit of context: I'm just getting back into Linux after many years (I first played with Linux in the Red Hat days c. 2000...). I'm pretty rusty. I'm running a Fedora 36 installation on a Lenovo Thinkpad T470s now.

For "ease" I tried to install the libprintf code (https://github.com/3v1n0/libfprint/) via Snap as the README said it was "for any distro". That failed at one of the steps.

I then installed this code as per the Fedora instructions and enrolled my fingerprint, and that initially seemed to work fine.

However, as soon as I went into suspend or rebooted everything stopped working.

How it was fixed:

1. i think the Snap install left a couple of dodgy services running, so as per uunicorn's suggestion above I disabled them both and removed the service files:

i. sudo systemctl disable open-fprintd-restart-after-resume.service ii. sudo systemctl disable python3-validity-restart-after-resume.service

2. I applied the workaround "# 3" from the other thread on this forum (https://github.com/uunicorn/python-validity/issues/127):

Change "/usr/lib/systemd/system/open-fprintd-resume.service" to this:

[Unit]
Description=Restart devices after resume
After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target

[Service]
Type=oneshot
#ExecStart=/usr/lib/open-fprintd/resume.py
ExecStart=systemctl restart open-fprintd.service python3-validity.service

[Install]
WantedBy=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target

3. The open-fprintd-suspend.service, open-fprintd-resume.service, and python3-validity.service services were not enabled properly for some reason. I did this:

i. sudo systemctl daemon-reload ii. sudo systemctl enable open-fprintd-suspend.service iii. sudo systemctl enable open-fprintd-resume.service iv. sudo systemctl enable python3-validity.service v. sudo systemctl restart open-fprintd-suspend.service vi. sudo systemctl restart open-fprintd-resume.service vii. sudo systemctl restart python3-validity.service viii. I then ran "sudo systemctl status " on all the services above to check they are running.

4. Rebooted and suspended, and all working.

I'm still learning, so there might be quicker ways to do some of this, but all I can say is that this worked for me.

Darren.

[uunicorn]

Hi Darren,

I applied "fix 3" from the other thread on this forum

This is not a fix, it's a workaround. As someone mentioned, it is not how things supposed to work and should no longer be required with the latest version of python-validity.

[tenjinsoftware]

Hi,

Thanks for the catch, you are right, I have updated my comments to reflect the correction.

D.

[maru-sama]

Hello, I just updated from Ubuntu 22.04 to 22.10 and I a facing the same issues with my Lenovo t470s. After a suspend/resume cycle the reader is no longer available. I tried to figure out the differences between the two running the same kernel and found out the following.

When you suspend under 22.04 and then resume the USB connected fingerprint reader gets "RESET". If you do the same with 22.10 then the reader is not "RESET" but it gets removed and then added again as a new device. As a result it is no longer available under the old location since it is per definition a new device. Since this is happening with the same kernel it has be the a change in the runtime services but with 1500 updates this is difficult to pinpoint.

The workaround with restarting the service of course works in this case, but I wonder if a reconnect of the sensor can be handled as well without the need to restart everything.

[maru-sama]

Hi,

A small update on this while looking at differences, between the two versions I saw that the "power/persist" flag is set to "0" for the newer distribution. As a result the device gets reconnected on resume. I changed the config to always set persist to 1 and now it behaves correctly and works without any workarounds.

[maru-sama]

I found out why the persist is set to 0 in the first place. Recent udev releases have an updated hwdb which lists (at least) my fingerprint sensor as unsupported and sets the flag to 0. I manually put in an exception for my sensor and set this to 0. So now the sensor works as before. To check if this is happening for your sensor as well take a look at /lib/udev/hwdb.d/60-autosuspend-fingerprint-reader.hwdb and check if our sensor is listed there.

[4rc0s]

I found out why the persist is set to 0 in the first place. Recent udev releases have an updated hwdb which lists (at least) my fingerprint sensor as unsupported and sets the flag to 0. I manually put in an exception for my sensor and set this to 0. So now the sensor works as before. To check if this is happening for your sensor as well take a look at /lib/udev/hwdb.d/60-autosuspend-fingerprint-reader.hwdb and check if our sensor is listed there.

In that file on my system (Mint 21.1) everything is set to ID_AUTOSUSPEND=1. You said, " I manually put in an exception for my sensor and set this to 0."

lsusb lists my sensor as 06cb:009a which is apparently included in the "known unsupported devices" as usb:v06CBp009A*

Do I comment out it's listing in the unsupported section and add a new entry with ID_AUTOSUSPEND=0?

[maru-sama]

I found out why the persist is set to 0 in the first place. Recent udev releases have an updated hwdb which lists (at least) my fingerprint sensor as unsupported and sets the flag to 0. I manually put in an exception for my sensor and set this to 0. So now the sensor works as before. To check if this is happening for your sensor as well take a look at /lib/udev/hwdb.d/60-autosuspend-fingerprint-reader.hwdb and check if our sensor is listed there.

In that file on my system (Mint 21.1) everything is set to ID_AUTOSUSPEND=1. You said, " I manually put in an exception for my sensor and set this to 0."

lsusb lists my sensor as 06cb:009a which is apparently included in the "known unsupported devices" as usb:v06CBp009A*

Do I comment out it's listing in the unsupported section and add a new entry with ID_AUTOSUSPEND=0?

Hello I wrote a small howto some time ago of how to fix the issue https://mike.it-loops.com/item/32 This was more for myself so I do not forget how I fixed it.

[ChonkaLoo]

Worked for me as well on a X270, had the same fingerprint reader as you @maru-sama but on Debian 12. The override file and update to systemd-hwdb worked like a charm. Thank you for nice tutorial on your site! God I love the open-source community🥰