I have installed Garuda Linux with two separate LUKS encrypted partitions, where the root filesystem including /boot are on one partition and home folder on another. Each having the same luks passphrase. I have been trying to setup autologin to the Gnome Keyring by entering just one Luks passphrase at boot. Thusfar unsuccesfuly. Comming from Fedora I know this is possible and according to the Arch wiki on GNOME/Keyring it should be possible on an Arch based distribution too:
Alternatively, if using GDM and LUKS, GDM can unlock your keyring if it matches your LUKS password. For this to work, you need to use the systemd init in your mkinitcpio.conf as well as the appropriate kernel parameters.
So I have added the following hooks to my mkinitcpio.conf: HOOKS="base systemd autodetect modconf keyboard sd-vconsole block sd-plymouth sd-encrypt filesystems grub-btrfs-overlayfs"
Enabling booting from the systemd-cryptsetup-generator and added the folowing kernel parameters: rd.luks.name=MY-CRYPTROOT-PARTITION-UUID-101=luks-MY-CRYPTROOT-PARTITION-UUID-101 rd.luks.name=MY-CRYPTHOME-PARTITION-UUID-102=luks-MY-CRYPTHOME-PARTITION-UUID-102 root=/dev/mapper/luks-MY-CRYPTROOT-PARTITION-UUID-101 rd.luks.key=/crypto_keyfile.bin
This would ensure that passwords entered in the password prompt are cached in the kernel keyring and can then be passed to the gnome keyring by configuring the pam_gnome_keyring.so module by adding the necessary lines to the file in/etc/pam.d/login. There are some additional gdm pam configuration files in /etc/pam.d/ that allready include these lines.
After recreating the initramfs image sudo mkinitcpio -P and updating grub grubup I rebooted the pc entered my luks passphrase and still got promted to enter my gnome keyring password, which is the same as my luks and gdm user password. However if I don't use autologin I get promted at boot and before a gnome session and then the keyring does automatically unlock.
according to this reddit post there is an additional pam_gdm module that passes the password stored in the kernel keyring to gdm. This is not mentioned in the Arch wiki, but I gave it a shot and added the auth [success=ok default=1] pam_gdm.so lines before the pam_gnome_keyring.so lines in the pam configuration files. But this wasn't succesful either.
I think I have exhausted every possible solution to get a one time password at boot to unlock the gnome keyring to work, but I might be missing something. I trust someone out here knows more about the technical details so please if you have any suggestion let me know. Your help would be much appreciated.
Your configuration looks good, as far as I can tell. A cursory search for this issue reveals you are far from the only person with this issue (even on the mighty Fedora forum, here and here).
I did see a couple random reports of success from folks who installed Seahorse and changed the keyring password, then changed it back again. It sounds pretty flimsy, but if you take a look at the Gnome wiki article (Gnome Keyring: Automatic Unlocking / PAM), it does sound like something happens when the password is changed.
When the user changes their password, the PAM module changes the password of the ‘login’ keyring to match.
Again, here gnome-keyring-daemon is started if necessary.
If root changes the password, or /etc/shadow is directly edited then due to the lack of the old password, the ‘login’ keyring cannot be updated.
It kind of seems like the equivalent of turning it off and back on again, but may be worth a shot.
The only other thing that stands out to me is here, where they note a line should be added to /etc/pam.d/passwd:
In /etc/pam.d/passwd, add a line like this to the ‘password’ block:
password optional pam_gnome_keyring.so
I can’t figure out if /etc/pam.d/passwd is actually relevant to an autologin, or for that matter relevant to a login that GDM is handling period. The documentation available for Pam is super dense, and my attention span forced me to bail before I was able to get a straight answer.
Thanks for taking the effort to dip into the subject. I have changed the password back and forth, even decided to romove all the config files and then create the default login entry as the default keyring echo "login" > ~/.local/share/keyrings/default. According to the Gnome Keyring: Automatic Unlocking / PAM article the login keyring would be created when logging in after a reboot. This is not the case, as also others have concluded, so I created a new login keyring which is allready marked as the default keyring. Rebooted and then nothing happened, still had to login manually.
Maybe this could be a Garuda Linux specific problem since the output of jctl points to an error with some systemd application and also gkr-pam: couldn't unlock the login keyring:
While googling for the journalctl error: gkr-pam: couldn't unlock the login keyring I found out that this can be circumvented by masking the Gnome keyring daemon as per systemctl --user mask gnome-keyring-daemon.service and systemctl --user mask gnome-keyring-daemon.socket. It is also sort of described on the archwiki. However I still did not get autologin unlocking Gnome keyring to work. journalctl -p 3 -xb hints to that there is some systemd unit that failed to get started, but I can't quite figure out what particular unit it is. Here is the output of jctl:
feb 20 20:42:18 archlinux kernel: x86/cpu: SGX disabled by BIOS.
feb 20 20:42:24 Garuda systemd-udevd[438]: /usr/lib/udev/rules.d/51-trezor.rules:11 Unknown group 'trezord', ignoring
feb 20 20:42:24 Garuda systemd-udevd[438]: /usr/lib/udev/rules.d/51-trezor.rules:12 Unknown group 'trezord', ignoring
feb 20 20:42:24 Garuda systemd-udevd[438]: /usr/lib/udev/rules.d/51-trezor.rules:15 Unknown group 'trezord', ignoring
feb 20 20:42:24 Garuda systemd-udevd[438]: /usr/lib/udev/rules.d/51-trezor.rules:16 Unknown group 'trezord', ignoring
feb 20 20:42:24 Garuda systemd-udevd[438]: /usr/lib/udev/rules.d/51-trezor.rules:17 Unknown group 'trezord', ignoring
feb 20 20:42:25 Garuda systemd-tmpfiles[581]: Failed to write file "/sys/module/pcie_aspm/parameters/policy": Operation not permitted
feb 20 20:42:25 Garuda bluetoothd[590]: src/plugin.c:plugin_init() Failed to init vcp plugin
feb 20 20:42:25 Garuda bluetoothd[590]: src/plugin.c:plugin_init() Failed to init mcp plugin
feb 20 20:42:25 Garuda bluetoothd[590]: src/plugin.c:plugin_init() Failed to init bap plugin
feb 20 20:42:25 Garuda bluetoothd[590]: Failed to set mode: Failed (0x03)
feb 20 20:42:27 Garuda systemd[2166]: Failed to start Application launched by gnome-session-binary.
░░ Subject: A start job for unit UNIT has failed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ A start job for unit UNIT has finished with a failure.
░░
░░ The job identifier is 160 and the job result is failed.
feb 20 20:42:27 Garuda systemd[2166]: Failed to start Application launched by gnome-session-binary.
░░ Subject: A start job for unit UNIT has failed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ A start job for unit UNIT has finished with a failure.
░░
░░ The job identifier is 164 and the job result is failed.
feb 20 20:42:46 Garuda sudo[3804]: ejan : a password is required ; TTY=pts/0 ; PWD=/home/ejan ; USER=root ; COMMAND=/usr/bin/true
feb 20 20:43:00 Garuda sudo[4794]: ejan : a password is required ; TTY=pts/0 ; PWD=/home/ejan ; USER=root ; COMMAND=/usr/bin/true
Again any help would be appreciated very much.
Edit: Just found out from a broader journalctl -p 4 -xb logfile the application is probably the gnome keyring:
feb 20 22:28:57 Garuda systemd[2158]: app-gnome-gnome\x2dkeyring\x2dpkcs11-2656.scope: Failed to add PIDs to scope's control group: No such process
feb 20 22:28:57 Garuda systemd[2158]: app-gnome-gnome\x2dkeyring\x2dpkcs11-2656.scope: Failed with result 'resources'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ The unit UNIT has entered the 'failed' state with result 'resources'.
feb 20 22:28:57 Garuda systemd[2158]: Failed to start Application launched by gnome-session-binary.
The question remains; What could be the reason it failed to get started?
I think the author’s claim that they found a “solution” is an overstatement; really, they just found a way to get the error message to stop showing up. They noted that this “solution” does not resolve the behavior you have described where you must either log in or manually unlock the keyring:
gnome-keyring always works as intended, although some apps will require your pass if you use autologin as usual.
In the Zorin thread, a comment suggests it may be triggered by certain hardware configurations, although they didn’t really elaborate on that theory. Just curious though: when you had this setup working correctly on Fedora was it the same hardware setup you are using now?
Actually the post I refer to was here on the Manjaro forum, but it has the same gist. I think you’re right about this being a band-aid solution. The archwiki documentation on Gnome Keyring they refer to is this part where it’s talking about the discover_other_daemon: 1 terminal message, which also shows up in my journalclt. It offers as a solution to either remove the --start option after gnome-keyring-daemon in ~/.bash_profile, ~/.xinitrc etc. or disable the the gnome-keyring-daemon.service and gnome-keyring-daemon.socket user units. I have tried that but when I check for the status it just stays enabled.
It was the same hardware indeed, but to be frank it wasn’t the same full disk Luks encryption because on Fedora I had the /boot directory on a separate partition. So autologin was not possible in that setup. It wasn’t until I immersed myself into the possibility to use a single password upon boot that I stumbled on this bug. Anyway, I suppose it’s better to let go of the idea and still choose to login as a user. That way the keyring does get unlocked. Side note: I have also installed pam_gnupg to automatically unlock my gpg passphrase and it doesn’t work with autologin either, but it does when I do login to a gdm session.
I have changed the password back and forth, even decided to romove all the config files and then create the default login entry as the default keyring 
journalctl -p 3 -xb hints to that there is some systemd unit that failed to get started, but I can't quite figure out what particular unit it is. Here is the output of jctl: