After installing the distribution, restarting the distro and finishing the setup, I installed seahorse (Password & Keys) and noted that the default "Login" keyring is locked (usually it's unlocked after logging in). This shouldn't be the case since auto-login is not enabled and I have set a user password to "test" (I also confirmed that auto-login is disabled). Upon pressing on unlock I'm greeted with an error message saying the password is incorrect. I'm also unable to reset the password of the keyring since I don't know what password was used for the keyring. This basically prevents any application from using the keyring since it's locked. For example, the Proton VPN app for F42 is unusable at this point since it requires keyring access to login into the application as it stores data there. I've used the the image Fedora-Workstation-Live-42_Beta-1.4.x86_64.iso and installed it in a VM. All updates have been installed prior to doing this test. Reproducible: Always Steps to Reproduce: 1. Download beta image (Fedora-Workstation-Live-42_Beta-1.4.x86_64.iso was used in this case) 2. Install the distro in VM (used Boxes). I didn't setup encryption and used the entire disk. Allocated 8 CPUS, 20GiB of storage and 4GiB of RAM. All other values are on default values. 3. Wait until the distro installation is done, remove media and reboot VM 4. Proceed with last setup steps by providing the username and password (other options such as locations and such didn't matter much). Ensured that password were the same and correct by clicking on the eye icon 5. Update packages with sudo dnf upgrade -y 6. Install seahorse sudo dnf install seahorse 7. Launch seahorse and note that default "Login" keyring is locked 8. Click on "Unlock" 9. Type in user password Actual Results: 1) The keyring is locked even after login 2) The keyring apparently has a different password from the user password, as it's impossible to unlock it with the user password that was set to "test" Expected Results: 1) The keyring should be unlocked upon login 2) The keyring should have the same password as the user password During installation I changed the keyboard to PT-nodeadkeys, although I don't think this should matter since I double-checked that the user password was set correctly to "test".
Proposed as a Blocker for 42-final by Fedora user calexandru2018 using the blocker tracking app because: Apps that depend on keyring won't be able to be used due to this keyring bug, as the keyring password is not the same as the user password for some reason, thus users won't be able to use this transparently as it will require the user manually delete the keyring and create a new one.
Have you upgraded your system after install? I'm certain this bug was resolved with an update this update: https://bodhi.fedoraproject.org/updates/FEDORA-2025-6a35898dbf
(In reply to Christopher Boni from comment #2) > Have you upgraded your system after install? I'm certain this bug was > resolved with an update this update: > https://bodhi.fedoraproject.org/updates/FEDORA-2025-6a35898dbf As I've mentioned in the steps to reproduce, the first thing I did after installing the VM was to run `sudo dnf upgrade`, unless you mean `dist-upgrade` then no, I haven't done that.
Can you try with a current nightly and see if you can reproduce it? https://openqa.fedoraproject.org/nightlies.html
(In reply to Adam Williamson from comment #4) > Can you try with a current nightly and see if you can reproduce it? > https://openqa.fedoraproject.org/nightlies.html I've tried on https://kojipkgs.fedoraproject.org/compose/branched/Fedora-42-20250402.n.0/compose/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-42-20250402.n.0.iso and yes the issue if fixed. Sorry for the extra noise.
Thanks for confirming! *** This bug has been marked as a duplicate of bug 2349314 ***
I have the same issue. I installed Fedora 42 Workstation Beta and ran an update. Should I reinstall the system from scratch, or will this change eventually come through, and everything will be fixed after an update?
The update will eventually come through (in fact you should have it already), but if this is caused by something bad happening *at first install / boot time* and it's persistent, the update won't necessarily fix it. You might want/need to reinstall with a recent nightly or the release candidate.