Turn off X11 session support
Updates may require up to 24 hours to propagate to mirrors. If the following command doesn't work, please retry later:
sudo dnf upgrade --refresh --advisory=FEDORA-2025-6ae57ec591Please log in to add feedback.
| 0 | 0 | Test Case Gnome Accessibility |
| 0 | 0 | Test Case Gnome Classic mode |
| 0 | 0 | Test Case Gnome Lock Screen |
| 0 | 0 | Test Case Gnome Login Screen |
| 0 | 0 | Test Case desktop user switching |
| 0 | 0 | Test Case gnome desktop background |
| 0 | 0 | Test Case gnome-shell activities |
| 0 | 0 | Test Case gnome-shell dash |
| 0 | 0 | Test Case gnome-shell extensions gnome org |
| 0 | 0 | Test Case gnome-shell extensions install |
| 0 | 0 | Test Case gnome-shell extensions remove |
| 0 | 0 | Test Case gnome-shell overview search |
| 0 | 0 | Test Case gnome-shell workspaces |
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
This needs https://github.com/rhinstaller/anaconda/pull/6430 .
ngompa edited this update.
New build(s):
Karma has been reset.
I've added the anaconda build to this update.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
agh, crap, there's another:
most of the other failures look like needle issues, but we're gonna need another anaconda PR. I can do it and backport it so we don't have to wait for next Monday.
ugh, I did the anaconda build but forgot to do it on the side tag. Let's see if it makes it through testing on its own, not sure how it'll behave with the current mutter.
looks like it got through, so once it's in the buildroot I'll re-trigger these tests. but there may be another issue with the gnome-shell update that I'm looking into ATM.
OK, so the other problem is a real one: after installing this update, the next boot defaults to GNOME Classic.
In the previous gnome-session package - gnome-session-48.0-1.fc43 - there are two sessions in
/usr/share/wayland-sessions:gnome.desktopandgnome-wayland.desktop. They are identical except for the Name field:gnome.desktopis just called "GNOME",gnome-wayland.desktopis called "GNOME on Wayland".gdm does not display both, it only displays the one called "GNOME". That is the session you wind up in by default. The options it shows are "GNOME" and "GNOME Classic".
After the update, there is only
/usr/share/wayland-sessions/gnome-wayland.desktop;gnome.desktopno longer exists. So there is no session called "GNOME" any more, and GDM shows the two available sessions as "GNOME on Wayland" and "GNOME Classic". So the problem here is that the session which was used on the previous boot no longer exists at all, and more broadly, we no longer have a generically-named "GNOME" session which is gnome-on-wayland as we presumably intend to.adamwill edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update's test gating status has been changed to 'waiting'.
OK, so the problem is basically a few issues in the rather twisty corridors of gnome-session's session install logic, caused by the patches we chose to backport.
I tested and I'm pretty sure we can "fix" it by just removing two of them, so I've sent a build that does that. Let's see how the tests come out.
adamwill edited this update.
Removed build(s):
Karma has been reset.
This update's test gating status has been changed to 'passed'.
This update has been submitted for stable by bodhi