I swear this used to work but now it apparently doesn’t any more?
It used to be that if you installed with LUKS encryption and enabled auto-login, it’d set your keychain passphrase as your LUKS one, and fetch it at boot so the keychain would still be unlocked on startup/autologin.
Now, it seems to instead set the keychain password as the user phrase you enter during the first boot setup wizard, and no matter what I do, it wont unlock with auto login.
I’ve installed seahorse, and tried both manually changing the keychain passphrase back to the LUKS one, and also changing the user/login passphrase to match the LUKS and keychain one. I’ve even tried a totally fresh installation (on both 36 and 37), with all passwords set exactly the same
What gives? Was this deliberately changed ( I can’t find any reference to it)? Because it’s super annoying.
(No, don’t tell me to set it to have no password, thats stupid insecure, and yeah, I’m aware of the bug where PAM would capture incorrect passwords if you typed them in first - that’s not what’s going on here)
How does your LUKS config looks like? How many password are you entering? Just one and the system boot up? Sorry to ask; are you sure that the users keyring has the same password? For testing; you could create a test account, witch the same LUKS password and set to autologin … does it works?
Sorry, I forget to mention it. Such commands should be executed as privileged user. You can accomplish it be switching to the root user or prepend the sudo command on every line/command.
(BTW, the # sign above indicates that it is the prompt of the privileged root user in comparison to a normal user with the $ sign in the terminal prompt).
About your issue, I am sure its not directly a bug more a interference that I can not identify.
Please show the output right after the boot up of following commands (when copying it here please use the preformatted text option of this input area):
okay, here they are again with sudo, after a reboot, plus the extra ones:
[test@fedora ~]$ sudo rpm -V gdm gnome-session gnome-keyring-pam gnome-keyring
[sudo] password for test:
S.5…T. c /etc/gdm/custom.conf
.M…G… /var/log/gdm
[test@fedora ~]$ sudo rpm -qi gdm gnome-session gnome-keyring-pam gnome-keyring |grep -E ‘Install|Name|Version|Release’
Name : gdm
Version : 43.0
Release : 3.fc37
Install Date: Sat 05 Nov 2022 04:58:40 AM EDT
Name : gnome-session
Version : 43.0
Release : 1.fc37
Install Date: Sat 05 Nov 2022 04:54:35 AM EDT
Name : gnome-keyring-pam
Version : 42.1
Release : 2.fc37
Install Date: Sat 05 Nov 2022 04:56:10 AM EDT
Name : gnome-keyring
Version : 42.1
Release : 2.fc37
Install Date: Sat 05 Nov 2022 04:55:39 AM EDT
[test@fedora ~]$ sudo authselect current
Profile ID: sssd
Enabled features:
About this output. This command must be executed right after the system boot to be informative. Please executed it again right after the system boot up (less ~60s). If the output looks the same then the problem lies here.
Okay, sorry for the slow reply, Christmas and all that.
Those commands were all run immediately after boot, I’d say within 60s of desktop loading. But I did it again just to make sure, including running those two commands first off, see beloe:
If this is the output right after booting the systen, then the graphical interface can not unlock the keyring of the user because the initial entered LUKS passphrase is not passed to that layer. Just to show you a working output:
So, something in the early stage is not working for you. Honestly, the ideas to identify the problem are getting less and less but your lsblk output shows a second LUKS volume that is not mounted. Maybe that is disturbing the process of passing the password further. Not sure what’s feasable for you, maybe a clean resetup of the whole system or just deleting the second LUKS volume if its not in use … I just can confirm that it just works on my side with an current F37 system. So, it should work. Sorry, if I have not a nicer Christmas present
I just tried a fresh installation using the ‘automatic’ partition allocator, this time using the default btrfs config, with luks still enabled, and same results. So…not an ext4 thing?
I’m reluctant to nuke the windows partition and try a totally fresh single-installation because a) I’ve always dual booted and I know it worked with it there before and b) its a PITA to reinstall. I’ll try nuking that other luks partition (a test ubuntu installation) and see what what that does.
Then maybe crossing my eyes, clicking my heels together 3 times, lining up the north star with Venus, and chanting “There’s no partition like home”?
Well, I nuked the Ubuntu installation, but no joy. So I dont know what I’m doing wrong. The steps at present are:
Install Fedora
*Complete setup wizard on first boot (using same user password as LUKS password).
*Immediately enable auto-login and install seahorse.
*Reboot
*Observe keyring still locked, but manually unlocks with LUKS/login password.
Latest outputs of the commands on last installation:
[test@fedora ~]$ sudo keyctl show
[sudo] password for test:
Session Keyring
55994496 --alswrv 1000 1000 keyring: _ses
705530177 ---lswrv 1000 65534 \_ keyring: _uid.1000
[test@fedora ~]$ sudo ausearch -m avc
<no matches>
[test@fedora ~]$ sudo rpm -V gdm gnome-session gnome-keyring-pam gnome-keyring
S.5....T. c /etc/gdm/custom.conf
.M....G.. /var/log/gdm
[test@fedora ~]$ sudo rpm -qi gdm gnome-session gnome-keyring-pam gnome-keyring |grep -E 'Install|Name|Version|Release'
Name : gdm
Version : 43.0
Release : 3.fc37
Install Date: Sat 05 Nov 2022 04:58:40 AM EDT
Name : gnome-session
Version : 43.0
Release : 1.fc37
Install Date: Sat 05 Nov 2022 04:54:35 AM EDT
Name : gnome-keyring-pam
Version : 42.1
Release : 2.fc37
Install Date: Sat 05 Nov 2022 04:56:10 AM EDT
Name : gnome-keyring
Version : 42.1
Release : 2.fc37
Install Date: Sat 05 Nov 2022 04:55:39 AM EDT
[test@fedora ~]$ sudo authselect current
Profile ID: sssd
Enabled features:
- with-silent-lastlog
- with-mdns4
- with-fingerprint
[test@fedora ~]$ sudo ausearch -m avc
<no matches>
[test@fedora ~]$ sudo ls -la /etc/pam.d/gdm-autologin
-rw-r--r--. 1 root root 622 Sep 20 11:22 /etc/pam.d/gdm-autologin
[test@fedora ~]$ sudo cat /etc/pam.d/gdm-autologin
#%PAM-1.0
auth [success=ok default=1] pam_gdm.so
-auth optional pam_gnome_keyring.so
auth sufficient pam_permit.so
account required pam_nologin.so
account include system-auth
password include system-auth
session required pam_selinux.so close
session required pam_loginuid.so
session optional pam_console.so
session required pam_selinux.so open
session optional pam_keyinit.so force revoke
session required pam_namespace.so
session include system-auth
session optional pam_gnome_keyring.so auto_start
session include postlogin
[test@fedora ~]$ sudo ldd /usr/lib64/security/pam_gdm.so
linux-vdso.so.1 (0x00007ffd6e2d7000)
libpam.so.0 => /lib64/libpam.so.0 (0x00007f7228f72000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f7228f6b000)
libc.so.6 => /lib64/libc.so.6 (0x00007f7228d8f000)
libaudit.so.1 => /lib64/libaudit.so.1 (0x00007f7228d61000)
libeconf.so.0 => /lib64/libeconf.so.0 (0x00007f7228d56000)
libm.so.6 => /lib64/libm.so.6 (0x00007f7228c74000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7228f9b000)
libcap-ng.so.0 => /lib64/libcap-ng.so.0 (0x00007f7228c6a000)
[silverbook@fedora ~]$ sudo lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
zram0 [SWAP]
nvme0n1
├─nvme0n1p1 vfat FAT32 SYSTEM 4CAC-1FB3 208.8M 18% /boot/efi
├─nvme0n1p2
├─nvme0n1p3 ntfs Windows E8C6AE71C6AE4024
├─nvme0n1p4 ntfs WinRE_DRV 7C7CAEB27CAE669C
├─nvme0n1p5 ext4 1.0 fedora_boot 7e747f1c-a26b-4875-986a-b3307935e943 734.4M 18% /boot
├─nvme0n1p6 crypto 2 92902285-aa30-433b-9bf1-aa6d703175c7
│ └─luks-92902285-aa30-433b-9bf1-aa6d703175c7
│ LVM2_m LVM2 3C5sSr-wseu-dIen-fQDv-uV2x-3Pk9-eFuNKl
│ ├─fedora_crypt-redora_root
│ │ ext4 1.0 fedora_root cef2237a-fbdd-464f-a3f8-681908217d15 31.1G 15% /
│ └─fedora_crypt-fedora_timeshift
│ ext4 1.0 fedora_timeshift
│ 4cd565a8-afd7-48bf-9490-62d86a3a989a
├─nvme0n1p7
└─nvme0n1p8
[test@fedora ~]$
If not already done so, I believe that you need to set the passwrd for the seahorse keyring as well. You can check if you kan lock and unlock it with your password, and you can also check if it is actually locked. I noticed that the keypad icon indicates “locked” even if the keyring is not locked.
In my testing I had the seahorse keyring already set up with the correct password for unlocking it before enabling auto login. I would suggest you do the same.
Yeah I already said I’ve done that, several times, including in the very first post…please actually read it.
besides, the whole point is that you SHOULDN’T have to do this, and didn’t previously. The expected/previous behaviour was that the keychain passphrase was set to the same as the LUKS, and automatically unlocked.
Now, even manually setting all passphrases the same wont get the keychain to auto unlock
