Unable to activate screen reader when initial-setup is in the screen. Reproducible: Always Steps to Reproduce: Download the latest Fedora 43 development Workstation, I used (https://dl.fedoraproject.org/pub/fedora/linux/development/43/Workstation/x86_64/iso/Fedora-Workstation-Live-43-20250915.n.0.x86_64.iso). Boot to the live environment and now, press alt plus super plus s. You will hear screen reader on. Now, press it again, you will hear screen reader off. Now, install the system. After reboot, initial setup loads. Now, try activating Orca screen reader as in the live environment. Actual Results: Nothing happens, as a blind user, I am unable to set up my installed Fedora. Expected Results: Orca will start / stop as expected, as in Fedora 42.
Actually, the problem is a bit different. *No* accessibility feature works in the gnome-initial-setup environment. It doesn't matter whether you try to enable it by a shortcut or by using the menu in the top right corner. All of them are nonfunctional (and also Dark mode from the standard user menu). I don't see any straight error about it in the journal, except this one, which could be relevant: > Sep 16 13:10:05 localhost-live gnome-shell[1342]: failed to commit changes to dconf: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code2: Cannot open dconf database: Failed to open file “/var/lib/gdm/seat0/config/dconf/user”: Permission denied I assume the dconf database is used the store the a11y feature on/off value, and if the database can't be opened, the feature doesn't get activated?
Created attachment 2106779 [details] journal.txt
Created attachment 2106780 [details] rpm-qa.txt
Proposing for a blocker discussion. Currently we have these criteria: "If an initial setup utility is run or intended to be run after the first boot of the installed system, then it must start successfully and each page or panel of the initial setup utility should withstand a basic functionality test. " https://fedoraproject.org/wiki/Fedora_43_Final_Release_Criteria#First_boot_experience "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use. " https://fedoraproject.org/wiki/Fedora_43_Final_Release_Criteria#Default_panel_functionality Especially the second one seems to hit it quite precisely, although this only concerns the gnome-initial-setup environment, and not the actual user session environment (everything works fine there). But the first criterion cares about the gnome-initial-environment (while not specifying the top panel). Furthermore, while we don't have specific a11y release criteria, if *all* a11y was completely broken, we would probably mark it as the gnome settings app not fulfilling its basic functionality requirement. This is more or less the same situation in the g-i-s environment, completely blocking people with disabilities from entering the user session.
(In reply to Kamil Páral from comment #1) > > Sep 16 13:10:05 localhost-live gnome-shell[1342]: failed to commit changes to dconf: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code2: Cannot open dconf database: Failed to open file “/var/lib/gdm/seat0/config/dconf/user”: Permission denied In the log, we also have this, which seems to hint at the same issue: Sep 16 13:10:14 localhost-live wireplumber[1352]: wp-state: <WpState:0x55ebe1837020> could not save stream-properties: Failed to create file “/var/lib/gdm/seat0/state/wireplumber/stream-properties.F0CXC3”: Permission denied Here's the full file list view in the gdm directory: $ ls -la -R /var/lib/gdm/ /var/lib/gdm/: total 4 drwxrwx--T. 1 gdm gdm 62 Sep 16 13:01 . drwxr-xr-x. 1 root root 978 Sep 16 13:01 .. drwx------. 1 gdm gdm 10 Sep 11 00:17 .config -rw-r--r--. 1 root root 1 Sep 16 13:01 .migrated-dyn-users drwxr-xr-x. 1 root root 22 Sep 16 13:01 seat0 /var/lib/gdm/.config: total 0 drwx------. 1 gdm gdm 10 Sep 11 00:17 . drwxrwx--T. 1 gdm gdm 62 Sep 16 13:01 .. drwx------. 1 gdm gdm 20 Sep 11 00:17 pulse /var/lib/gdm/.config/pulse: total 4 drwx------. 1 gdm gdm 20 Sep 11 00:17 . drwx------. 1 gdm gdm 10 Sep 11 00:17 .. -rw-------. 1 gdm gdm 320 Sep 4 02:00 default.pa /var/lib/gdm/seat0: total 0 drwxr-xr-x. 1 root root 22 Sep 16 13:01 . drwxrwx--T. 1 gdm gdm 62 Sep 16 13:01 .. drwx------. 1 gnome-initial-setup nobody 10 Sep 16 13:01 config drwx------. 1 gnome-initial-setup nobody 0 Sep 16 13:01 state /var/lib/gdm/seat0/config: total 0 drwx------. 1 gnome-initial-setup nobody 10 Sep 16 13:01 . drwxr-xr-x. 1 root root 22 Sep 16 13:01 .. drwxr-xr-x. 1 gnome-initial-setup nobody 20 Sep 16 13:01 pulse /var/lib/gdm/seat0/config/pulse: total 4 drwxr-xr-x. 1 gnome-initial-setup nobody 20 Sep 16 13:01 . drwx------. 1 gnome-initial-setup nobody 10 Sep 16 13:01 .. -rw-------. 1 gnome-initial-setup nobody 320 Sep 4 02:00 default.pa /var/lib/gdm/seat0/state: total 0 drwx------. 1 gnome-initial-setup nobody 0 Sep 16 13:01 . drwxr-xr-x. 1 root root 22 Sep 16 13:01 .. /var/lib/gdm/seat0/{config,state} seem to be owned by the gnome-initial-setup user, which sounds OK (I see the /usr/libexec/gnome-initial-setup process running under it as well). Not sure what the permission issue is.
Upstream bug report for this is https://gitlab.gnome.org/GNOME/gdm/-/issues/1016. What I said there applies here
(In reply to Adrian Vovk from comment #6) > Upstream bug report for this is > https://gitlab.gnome.org/GNOME/gdm/-/issues/1016. What I said there applies > here Interestingly enough, I have no problems with starting orca in gdm using both the shortcut and the menu. It's only gnome-initial-setup that's broken.
(In reply to Kamil Páral from comment #7) > (In reply to Adrian Vovk from comment #6) > > Upstream bug report for this is > > https://gitlab.gnome.org/GNOME/gdm/-/issues/1016. What I said there applies > > here > > Interestingly enough, I have no problems with starting orca in gdm using > both the shortcut and the menu. It's only gnome-initial-setup that's broken. Yes, only initial-setup is broken for me. I had this issue with gdm, but it was in Gnome 49 beta, it also affected Gnome os, but for Gnome os, this was fixed in August with GDM 49 RC.
In other words, when I upgrade from 42 to 43, I can activate / deactivate Orca as usual.
I just pushed another patch https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/320, and tagged another GDM release (49.0.1), which changes the fix a little. With 49.0.1 it will no longer be necessary to manually ask GDM to re-run the dynamic user migration (by deleting the .migrated-dyn-user stampfile). There were more people running GDM 49.rc than expected, so I decided to have GDM unconditionally run the fixup on startup > Interestingly enough, I have no problems with starting orca in gdm using both the shortcut and the menu. It's only gnome-initial-setup that's broken. Yeah it's the same bug that manifests itself slightly differently on different distros GDM by default (on GNOME OS and Arch) creates /var/lib/gdm with permissions 0700 and ownership gdm:gdm. Fedora's packaging of GDM creates /var/lib/gdm on its own, with permissions 0770 instead. GDM 49 and later runs the login screen as gdm-greeter[-###]:gdm and the initial-setup session as gnome-initial-setup[-###]:gnome-initial-setup. On Arch and GNOME OS this means that neither the login screen nor initial-setup are able to access anything inside of /var/lib/gdm, and thus the accessibility settings are broken in both places. With Fedora it's slightly different: the login screen runs as the gdm group, and the permissions are configured to allow the gdm group access to the directory, so the login screen does function correctly. But gnome-initial-setup, which doesn't run as the gdm group, still doesn't have access
(In reply to Adrian Vovk from comment #10) > GDM by default (on GNOME OS and Arch) creates /var/lib/gdm with permissions > 0700 and ownership gdm:gdm. Fedora's packaging of GDM creates /var/lib/gdm > on its own, with permissions 0770 instead. I can switch it to use 0700 if you want, to reduce risk of future bugs caused by this divergence? Or maybe we should change upstream to use 0770 instead, since there's probably not much value in preventing gdm group from accessing /var/lib/gdm?
FEDORA-2025-111bd2a0c7 (adwaita-icon-theme-49.0-1.fc43, at-spi2-core-2.58.0-1.fc43, and 61 more) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-111bd2a0c7
FEDORA-2025-111bd2a0c7 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-111bd2a0c7` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-111bd2a0c7 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Fedora Update System from comment #12) > FEDORA-2025-111bd2a0c7 (adwaita-icon-theme-49.0-1.fc43, > at-spi2-core-2.58.0-1.fc43, and 61 more) has been submitted as an update to > Fedora 43. > https://bodhi.fedoraproject.org/updates/FEDORA-2025-111bd2a0c7 With this update included, the issue is fixed, accessibility options work both in gnome-initial-setup and gdm. Thanks.
+4 in https://pagure.io/fedora-qa/blocker-review/issue/1929 , marking accepted.
FEDORA-2025-111bd2a0c7 (adwaita-icon-theme-49.0-1.fc43, at-spi2-core-2.58.0-1.fc43, and 61 more) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
*** Bug 2395957 has been marked as a duplicate of this bug. ***