Fedora Linux 34 Final blocker status update #3
The F34 Final freeze begins on Tuesday 6 April. Action summary Accepted blockers - 1. sddm — logout after switch returns the user to console instead of sddm — NEW ACTION: sddm maintainers to diagnose and fix issue 2. shim — include new bootloaders on Fedora 34 install media so UEFI Secure Boot enabled systems can boot from them — ASSIGNED ACTION: shim maintainers to provide shim signed with new key 3. plasma-discover — Hitting "Update All" in Plasma Discover sometimes does nothing, just cycles back — NEW ACTION: plasma-discover maintainers to diagnose and fix issue Proposed blockers - 1. gdm — Login using password failed after upgrade to Fedora 34 — NEW ACTION: gdm maintainers to diagnose and fix issue Bug-by-bug detail = Accepted blockers - 1. sddm — https://bugzilla.redhat.com/show_bug.cgi?id=1929643 — NEW logout after switch returns the user to console instead of sddm Using the "Switch User" functionality in sddm results in dropping to a console: either to tty2 with a working text login prompt, or to tty1 where only a blinking cursor appears (no login prompt). This may be limited to Wayland sessions. 2. shim — https://bugzilla.redhat.com/show_bug.cgi?id=1938630 — ASSIGNED include new bootloaders on Fedora 34 install media so UEFI Secure Boot enabled systems can boot from them The current shim was signed in 2018 and its signing key was revoked last year due to the Boothole vulnerability. We need a new shim to make sure F34 images will boot on machines with Secure Boot enabled. 3. plasma-discover — https://bugzilla.redhat.com/show_bug.cgi?id=1943943 — NEW Hitting "Update All" in Plasma Discover sometimes does nothing, just cycles back It takes several clicks of the "Update All" button before Discover updates packages. This may actually be a PackageKit issue, as AdamW observed issues with the GNOME tests, too. Proposed blockers - 1. gdm — https://bugzilla.redhat.com/show_bug.cgi?id=1942443 — NEW Login using password failed after upgrade to Fedora 34 When a device has a fingerprint reader, but no fingerprints are enrolled, login fails on the default terminal. Switching to a different virtual console allows login. Removing fprintd-pam resolves the problem, but is probably not the solution we want. It may be that modifications of nsswitch.conf outside of authselect cause fprintd to get unexpected failures from authselect. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Linux 34 Final blocker status update #3
On Thu, 2021-04-01 at 14:56 -0400, Ben Cotton wrote: > > 1. gdm — https://bugzilla.redhat.com/show_bug.cgi?id=1942443 — NEW > Login using password failed after upgrade to Fedora 34 > > When a device has a fingerprint reader, but no fingerprints are > enrolled, login fails on the default terminal. Switching to a > different virtual console allows login. Removing fprintd-pam resolves > the problem, but is probably not the solution we want. It may be that > modifications of nsswitch.conf outside of authselect cause fprintd to > get unexpected failures from authselect. Just to clarify this one a bit: AIUI, this is the same bug we fixed earlier in the cycle, but it's still a problem after update to the 'fixed' package for some people. It seems to affect two scenarios: 1. Very old installs, from a release where we had authconfig not authselect, that have been upgraded all the way to F34 2. Installs where /etc/nsswitch.conf has been modified in any way except via authselect, so authselect won't apply changes to it any more I believe benzea is planning to try and solve this by having the package make the specific change to the configuration that's necessary, in affected cases. We think that just making this specific change in a package scriptlet should be pretty safe, it shouldn't be able to break any odd configuration we can think of. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
