gkr-pam means pam_gnome_keyring

@Pierre
Can you please say something about your system, and how you installed Mageia. Is Gnome the only desktop you have?

> i saw nothing when i switch on my computer
How are you able to do the journalctl command?

CC: (none) => lewyssmith

Created attachment 11735 [details]
journalctl -b -p err command

Yes Gnome is the only desktop installed on my laptop.
; 
But i am not sure to understand very well your second question....but sorry for my poor english :-(
Saw the screenshot above.

Thanks a lot

To be clear, Pierre has a working desktop. He saw the error in the journal after the start by inspection.

Hi, it is upstream bug: https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/28

According to this comment:
"ettavolt @ettavolt · 6 months ago

This morning I've been reading pam_gnome_keyring sources to understand the cause of a race condition between keyring unlocking during autologin and systemd user service 'softu2f token'.

Looks like, one such message is a must for a login without a session already running. It's not printed if unlocking after a screen lock (I see only an informational one "gkr-pam: unlocked login keyring").

This log line indicates that during auth step pam_gnome_keyring.so pam entry had a proper password string, it tried to unlock keyring, but some environment variables were missing, and module decided to retry during session phase.

I guess, it may be worth adding some LOG_INFOs in the ifs branches after unlock_keyring calls to indicate what pam_gnome_keyring is going to do about the warned condition."

There is a commit there and available in gnome-keyring-3.36 package.
Therefore, race condition is still present.

CC: (none) => ouaurelien

Upstream recommends:
https://wiki.gnome.org/Projects/GnomeKeyring/RunningDaemon

Starting Gnome Keyring Daemon

    The best place to start gnome-keyring-daemon is from the user's login. This is done via a PAM module. When configured correctly the user does not need to enter any passwords beyond that of their login.
    In addition gnome-keyring-daemon must be initialized from the session startup. Usually this is accomplished by the autostart desktop files that gnome-keyring-daemon installs.
    If gnome keyring was not started from the PAM module, the autostart desktop files will start a gnome-keyring-daemon properly. In this case the user will need to specify an unlock password for their keyring on its first use.
    If your PAM configuration allows you to log in without entering a password (e.g. via smart card or fingerprint), you will also need to specify an unlock password for your keyring on its first use.
    If not started by one of the above, it will be automatically activated by DBus for basic password operations. However much functionality will not be available, such as the SSH agent and encryption key store. 

https://wiki.gnome.org/Projects/GnomeKeyring/Pam

Upstream remarks of "some environment variables missing". What about in our config files.

Passing to Gnome maintainers.

Keywords: (none) => Triaged
Status: NEW => ASSIGNED
Assignee: bugsquad => gnome

Our pam config seems somewhat ok. I do see some differences with what Fedora does. There's also a bug when autologin is used with GDM. Maybe best to just switch the PAM method over to what Fedora does. This will mean packaging authselect and switching over. From reading the PAM spec history on Fedora, it seems our config is quite out of date and ancient.

CC: (none) => olav
Priority: Normal => release_blocker
Status comment: (none) => Should align PAM with Fedora. Needs discussion on dev mailing list