After upgrading to fedora rawhide (42), gdm is stuck on login screen or blank screen depending on kernel being used on virtual box (fedora rawhide being the guest OS and not the hypervisor) Setting the following in /etc/environment "solved" the problem: ~~~ MUTTER_DEBUG_DISABLE_TRIPLE_BUFFERING=1 MUTTER_DEBUG_USE_KMS_MODIFIERS=0 ~~~ as found in one of the comments of [1]. The gnome-shell process coredumps with the following backtrace: ~~~ Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fe021228f4f in drisw_init_screen (screen=0x5628cfe3e790, driver_name_is_inferred=false) at ../src/gallium/frontends/dri/drisw.c:623 623 if (loader->base.version >= 4) { --Type <RET> for more, q to quit, c to continue without paging-- [Current thread is 1 (Thread 0x7fe0496b7640 (LWP 3954))] (gdb) bt #0 0x00007fe021228f4f in drisw_init_screen (screen=0x5628cfe3e790, driver_name_is_inferred=false) at ../src/gallium/frontends/dri/drisw.c:623 #1 0x00007fe0212242cd in driCreateNewScreen3 (scrn=scrn@entry=0, fd=<optimized out>, loader_extensions=0x7fe04453f1a0 <image_loader_extensions>, type=type@entry=DRI_SCREEN_SWRAST, driver_configs=driver_configs@entry=0x5628cfca7420, driver_name_is_inferred=driver_name_is_inferred@entry=false, has_multibuffer=true, data=0x5628cfcee530) at ../src/gallium/frontends/dri/dri_util.c:144 #2 0x00007fe044504ae9 in dri2_create_screen (disp=disp@entry=0x5628cfcee530) at ../src/egl/drivers/dri2/egl_dri2.c:825 #3 0x00007fe0445062ce in dri2_initialize_device (disp=disp@entry=0x5628cfcee530) at ../src/egl/drivers/dri2/platform_device.c:362 #4 0x00007fe044505388 in dri2_initialize (disp=0x5628cfcee530) at ../src/egl/drivers/dri2/egl_dri2.c:912 #5 0x00007fe0444f3b86 in eglInitialize (dpy=<optimized out>, major=0x0, minor=0x0) at ../src/egl/main/eglapi.c:719 #6 0x00007fe04d2faf74 in meta_egl_initialize (egl=0x5628cf944830, display=0x5628cfcee530, error=0x7fff81dcbb38) at ../src/backends/meta-egl.c:276 #7 meta_render_device_egl_stream_create_egl_display (render_device=<optimized out>, error=0x7fff81dcbb38) at ../src/backends/native/meta-render-device-egl-stream.c:220 #8 0x00007fe04d36f7ad in meta_render_device_create_egl_display (render_device=0x5628cfccaf50, error=0x7fff81dcbb38) at ../src/backends/native/meta-render-device.c:67 #9 init_egl (render_device=0x5628cfccaf50) at ../src/backends/native/meta-render-device.c:139 #10 meta_render_device_initable_init (initable=0x5628cfccaf50, cancellable=<optimized out>, error=<optimized out>) at ../src/backends/native/meta-render-device.c:159 #11 0x00007fe04d2fadae in meta_render_device_egl_stream_initable_init (initable=0x5628cfccaf50, cancellable=0x0, error=0x7fff81dcbd78) at ../src/backends/native/meta-render-device-egl-stream.c:178 #12 0x00007fe04da78efc in g_initable_new_valist (object_type=<optimized out>, first_property_name=0x7fe04d3dbac4 "backend", var_args=var_args@entry=0x7fff81dcbc70, cancellable=cancellable@entry=0x0, error=error@entry=0x7fff81dcbd78) at ../gio/ginitable.c:249 #13 0x00007fe04da78feb in g_initable_new (object_type=<optimized out>, cancellable=cancellable@entry=0x0, error=error@entry=0x7fff81dcbd78, first_property_name=first_property_name@entry=0x7fe04d3dbac4 "backend") at ../gio/ginitable.c:163 #14 0x00007fe04d34ad52 in meta_render_device_egl_stream_new (backend=0x5628cfa9b930, device_file=0x5628cfbf9300, error=0x7fff81dcbd78) at ../src/backends/native/meta-render-device-egl-stream.c:294 #15 create_render_device (backend_native=backend_native@entry=0x5628cfa9b930, device_path=device_path@entry=0x5628cfbfd270 "/dev/dri/card0", error=error@entry=0x7fff81dcbf10) at ../src/backends/native/meta-backend-native.c:473 #16 0x00007fe04d34b0ce in add_drm_device (backend_native=backend_native@entry=0x5628cfa9b930, device=device@entry=0x5628cfbfd170, error=error@entry=0x7fff81dcbf10) at ../src/backends/native/meta-backend-native.c:542 #17 0x00007fe04d34b7af in init_gpus (native=0x5628cfa9b930, error=0x7fff81dcc130) at ../src/backends/native/meta-backend-native.c:685 #18 meta_backend_native_initable_init (initable=0x5628cfa9b930, cancellable=<optimized out>, error=<optimized out>) at ../src/backends/native/meta-backend-native.c:794 #19 0x00007fe04da78efc in g_initable_new_valist (object_type=<optimized out>, first_property_name=0x7fe04d3e39a8 "context", var_args=var_args@entry=0x7fff81dcbfa0, cancellable=0x0, error=0x7fff81dcc130) at ../gio/ginitable.c:249 #20 0x00007fe04da78feb in g_initable_new (object_type=<optimized out>, cancellable=<optimized out>, error=<optimized out>, first_property_name=<optimized out>) at ../gio/ginitable.c:163 #21 0x00007fe04d28b300 in meta_context_real_setup (context=<optimized out>, error=<optimized out>) at ../src/meta/meta-context.h:28 #22 0x00007fe04d294022 in meta_context_main_setup (context=0x5628cf932d10, error=0x7fff81dcc130) at ../src/core/meta-context-main.c:420 #23 0x00007fe04d294540 in meta_context_setup (context=context@entry=0x5628cf932d10, error=error@entry=0x7fff81dcc130) at ../src/core/meta-context.c:508 #24 0x000056289d7a2d2b in main (argc=<optimized out>, argv=<optimized out>) at ../src/main.c:659 ~~~ The following logs were also seen: ~~~ Dec 21 20:03:55 vbox gnome-shell[1480]: Failed to lock front buffer on /dev/dri/card0: gbm_surface_lock_front_buffer failed Dec 21 20:03:56 vbox gnome-shell[1480]: Failed to lock front buffer on /dev/dri/card0: gbm_surface_lock_front_buffer failed Dec 21 20:03:57 vbox gnome-shell[1480]: Failed to lock front buffer on /dev/dri/card0: gbm_surface_lock_front_buffer failed Dec 21 20:03:57 vbox gnome-shell[1480]: Failed to lock front buffer on /dev/dri/card0: gbm_surface_lock_front_buffer failed Dec 21 20:04:00 vbox gnome-shell[1480]: Failed to lock front buffer on /dev/dri/card0: gbm_surface_lock_front_buffer failed Dec 21 20:04:00 vbox gnome-shell[1480]: Failed to lock front buffer on /dev/dri/card0: gbm_surface_lock_front_buffer failed Dec 21 20:04:01 vbox gnome-shell[1480]: Failed to lock front buffer on /dev/dri/card0: gbm_surface_lock_front_buffer failed Dec 21 20:04:01 vbox gnome-shell[1480]: Failed to lock front buffer on /dev/dri/card0: gbm_surface_lock_front_buffer failed ~~~ and: ~~~ Dec 21 19:56:24 vbox gnome-shell[26303]: Running GNOME Shell (using mutter 47.3) as a Wayland display server Dec 21 19:56:24 vbox gnome-shell[26303]: Enabling experimental feature 'scale-monitor-framebuffer' Dec 21 19:56:24 vbox gnome-shell[26303]: Enabling experimental feature 'xwayland-native-scaling' Dec 21 19:56:25 vbox rtkit-daemon[923]: Successfully made thread 26317 of process 26303 (/usr/bin/gnome-shell) owned by '42' high priority at nice level -15. Dec 21 19:56:25 vbox gnome-shell[26303]: Thread 'KMS thread' will be using high priority scheduling Dec 21 19:56:25 vbox org.gnome.Shell.desktop[26303]: VMware: No 3D enabled (0, Success). Dec 21 19:56:25 vbox org.gnome.Shell.desktop[26303]: VMware: No 3D enabled (0, Success). Dec 21 19:56:25 vbox org.gnome.Shell.desktop[26303]: libEGL warning: egl: failed to create dri2 screen Dec 21 19:56:25 vbox org.gnome.Shell.desktop[26303]: VMware: No 3D enabled (0, Success). Dec 21 19:56:25 vbox org.gnome.Shell.desktop[26303]: libEGL warning: egl: failed to create dri2 screen Dec 21 19:56:25 vbox kernel: gnome-shell[26303]: segfault at 8 ip 00007f2994828f4f sp 00007ffd2b1ed850 error 4 in libgallium-24.3.1.so[28f4f,7f2994800000+1a49000] likely on CPU 0 (core 0, socket 0) Dec 21 19:56:25 vbox kernel: Code: 48 89 e5 41 56 41 55 41 54 41 89 f4 53 4c 8b 6f 58 48 89 fb 0f b6 05 81 9a a3 02 84 c0 0f 84 98 00 00 00 0f b6 05 71 9a a3 02 <41> 83 7d 08 03 4c 8d 35 65 e2 90 02 88 83 68 01 00 00 7e 0e 49 83 Dec 21 19:56:25 vbox audit[26303]: ANOM_ABEND auid=4294967295 uid=42 gid=42 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 pid=26303 comm="gnome-shell" exe="/usr/bin/gnome-shell" sig=11 res=1 Dec 21 19:56:25 vbox systemd-coredump[26330]: Process 26303 (gnome-shell) of user 42 terminated abnormally with signal 11/SEGV, processing... Dec 21 19:56:25 vbox audit: BPF prog-id=230 op=LOAD Dec 21 19:56:25 vbox audit: BPF prog-id=231 op=LOAD Dec 21 19:56:25 vbox audit: BPF prog-id=232 op=LOAD Dec 21 19:56:25 vbox systemd[1]: Started systemd-coredump - Process Core Dump (PID 26330/UID 0). Dec 21 19:56:25 vbox audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@13-26330-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res= success' Dec 21 19:56:25 vbox abrt-dump-journal-core[1231]: Failed to obtain all required information from journald Dec 21 19:56:26 vbox systemd-coredump[26331]: Process 26303 (gnome-shell) of user 42 dumped core. ~~~ [1] https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1966808 Reproducible: Always Steps to Reproduce: 1. Upgrade from 41 to 42/rawhide a guest that is running on virtualbox 2. 3. Actual Results: gdm is broken Expected Results: gdm should be working
This component is maintained by the GNOME project. Issues with it should be reported directly to GNOME at https://gitlab.gnome.org/GNOME/. This issue should only be kept open if it: 1. Relates to Fedora packaging or integration with other Fedora components 2. Is required for Fedora release processes, such as blocker bugs and freeze exceptions If this issue isn't needed for either of these two reasons, please: * create an issue with GNOME * add a link to the GNOME issue here * close this issue as CLOSED/UPSTREAM Thank you!
The same issue is now affecting Fedora 41 after upgrading to the latest mesa-dri-drivers-0:24.3.2-2.fc41.x86_64 + SDL2-0:2.30.11-1.fc41.x86_64 in a VMware Fusion virtualised environment. The previous combination of mesa-dri-drivers-0:24.2.8-1.fc41.x86_64 + SDL2-0:2.30.9-1.fc41.x86_64 was working fine for me. Applying the described workaround in /etc/environment also appears to fix the issue. No GNOME packages were updated: Transaction ID : 71 Begin time : 2025-01-05 14:35:53 Begin rpmdb : df1af72cc28f0f8088d109a16c9dcb052de03638cb74256793650a255b2781cc End time : 2025-01-05 14:36:01 End rpmdb : a7babdf4eaa1265c2e036fdb3ed6a67b8e022560d9e6add9b401f1edaae02782 User : 52069 Trond Myklebust <trondmy> Status : Ok Releasever : 41 Description : dnf -y --refresh distro-sync Comment : Packages altered: Action Package Reason Repository Upgrade SDL2-0:2.30.11-1.fc41.x86_64 Dependency updates Upgrade libtirpc-0:1.3.6-1.rc3.fc41.x86_64 Dependency updates Upgrade libtirpc-devel-0:1.3.6-1.rc3.fc41.x86_64 User updates Upgrade mesa-dri-drivers-0:24.3.2-2.fc41.x86_64 Group updates Upgrade mesa-filesystem-0:24.3.2-2.fc41.x86_64 Dependency updates Upgrade mesa-libglapi-0:24.3.2-2.fc41.x86_64 Dependency updates Upgrade mesa-libgbm-0:24.3.2-2.fc41.x86_64 Dependency updates Upgrade mesa-libEGL-0:24.3.2-2.fc41.x86_64 Group updates Upgrade mesa-libGL-0:24.3.2-2.fc41.x86_64 Dependency updates Upgrade mesa-vulkan-drivers-0:24.3.2-2.fc41.x86_64 Dependency updates Upgrade mesa-va-drivers-0:24.3.2-2.fc41.x86_64 Weak Dependency updates Upgrade vim-common-2:9.1.984-1.fc41.x86_64 Dependency updates Upgrade vim-data-2:9.1.984-1.fc41.noarch Dependency updates Upgrade vim-enhanced-2:9.1.984-1.fc41.x86_64 Dependency updates Upgrade vim-minimal-2:9.1.984-1.fc41.x86_64 Group updates Upgrade vim-default-editor-2:9.1.984-1.fc41.noarch Weak Dependency updates Upgrade vim-filesystem-2:9.1.984-1.fc41.noarch Dependency updates Upgrade xxd-2:9.1.984-1.fc41.x86_64 Dependency updates Replaced SDL2-0:2.30.9-1.fc41.x86_64 Dependency @System Replaced libtirpc-0:1.3.6-1.fc41.x86_64 Dependency @System Replaced libtirpc-devel-0:1.3.6-1.fc41.x86_64 User @System Replaced mesa-dri-drivers-0:24.2.8-1.fc41.x86_64 Group @System Replaced mesa-filesystem-0:24.2.8-1.fc41.x86_64 Dependency @System Replaced mesa-libEGL-0:24.2.8-1.fc41.x86_64 Group @System Replaced mesa-libGL-0:24.2.8-1.fc41.x86_64 Dependency @System Replaced mesa-libgbm-0:24.2.8-1.fc41.x86_64 Dependency @System Replaced mesa-libglapi-0:24.2.8-1.fc41.x86_64 Dependency @System Replaced mesa-va-drivers-0:24.2.8-1.fc41.x86_64 Weak Dependency @System Replaced mesa-vulkan-drivers-0:24.2.8-1.fc41.x86_64 Dependency @System Replaced vim-common-2:9.1.919-1.fc41.x86_64 Dependency @System Replaced vim-data-2:9.1.919-1.fc41.noarch Dependency @System Replaced vim-default-editor-2:9.1.919-1.fc41.noarch Weak Dependency @System Replaced vim-enhanced-2:9.1.919-1.fc41.x86_64 Dependency @System Replaced vim-filesystem-2:9.1.919-1.fc41.noarch Dependency @System Replaced vim-minimal-2:9.1.919-1.fc41.x86_64 Group @System Replaced xxd-2:9.1.919-1.fc41.x86_64 Dependency @System
I have the same issue after running an update today, with an overlapping set of packages (i.e. mesa, SDL2). The workaround with /etc/environment resolved the black/blank login screen. Running in: VMware® Workstation 15 Pro root@localhost:~# lshw -c display *-display description: VGA compatible controller product: SVGA II Adapter vendor: VMware physical id: f bus info: pci@0000:00:0f.0 version: 00 width: 32 bits clock: 33MHz capabilities: vga_controller bus_master cap_list rom configuration: driver=vmwgfx latency=64 resources: irq:16 ioport:1070(size=16) memory:e8000000-efffffff memory:fe000000-fe7fffff memory:c0000-dffff root@localhost:~# dnf history info 16 | grep -P "mesa|SDL" Upgrade SDL2-0:2.30.11-1.fc41.x86_64 Dependency updates Upgrade mesa-dri-drivers-0:24.3.2-2.fc41.x86_64 Group updates Upgrade mesa-filesystem-0:24.3.2-2.fc41.x86_64 Dependency updates Upgrade mesa-libglapi-0:24.3.2-2.fc41.x86_64 Dependency updates Upgrade mesa-libgbm-0:24.3.2-2.fc41.x86_64 Dependency updates Upgrade mesa-libGL-0:24.3.2-2.fc41.x86_64 Dependency updates Upgrade mesa-libEGL-0:24.3.2-2.fc41.x86_64 Group updates Upgrade mesa-vulkan-drivers-0:24.3.2-2.fc41.x86_64 Group updates Upgrade mesa-va-drivers-0:24.3.2-2.fc41.x86_64 Weak Dependency updates Upgrade mesa-libxatracker-0:24.3.2-2.fc41.x86_64 Dependency updates Replaced SDL2-0:2.30.9-1.fc41.x86_64 Dependency @System Replaced mesa-dri-drivers-0:24.2.8-1.fc41.x86_64 Group @System Replaced mesa-filesystem-0:24.2.8-1.fc41.x86_64 Dependency @System Replaced mesa-libEGL-0:24.2.8-1.fc41.x86_64 Group @System Replaced mesa-libGL-0:24.2.8-1.fc41.x86_64 Dependency @System Replaced mesa-libgbm-0:24.2.8-1.fc41.x86_64 Dependency @System Replaced mesa-libglapi-0:24.2.8-1.fc41.x86_64 Dependency @System Replaced mesa-libxatracker-0:24.2.8-1.fc41.x86_64 Dependency @System Replaced mesa-va-drivers-0:24.2.8-1.fc41.x86_64 Weak Dependency @System Replaced mesa-vulkan-drivers-0:24.2.8-1.fc41.x86_64 Group @System Seeing the same log messages, which is how I found this bug report. root@localhost:~# journalctl -g "Failed to lock front buffer" --since=today -- Boot b200b9f497c547bd8e33d166366c23fa -- Jan 06 10:00:44 localhost.localdomain gnome-shell[1194]: Failed to lock front buffer on /dev/dri/card0: gbm_surface_lock_front_buffer failed Jan 06 10:00:44 localhost.localdomain gnome-shell[1194]: Failed to lock front buffer on /dev/dri/card0: gbm_surface_lock_front_buffer failed Jan 06 10:00:44 localhost.localdomain gnome-shell[1194]: Failed to lock front buffer on /dev/dri/card0: gbm_surface_lock_front_buffer failed Jan 06 10:00:44 localhost.localdomain gnome-shell[1194]: Failed to lock front buffer on /dev/dri/card0: gbm_surface_lock_front_buffer failed Jan 06 10:00:44 localhost.localdomain gnome-shell[1194]: Failed to lock front buffer on /dev/dri/card0: gbm_surface_lock_front_buffer failed Jan 06 10:00:44 localhost.localdomain gnome-shell[1194]: Failed to lock front buffer on /dev/dri/card0: gbm_surface_lock_front_buffer failed Jan 06 10:00:44 localhost.localdomain gnome-shell[1194]: Failed to lock front buffer on /dev/dri/card0: gbm_surface_lock_front_buffer failed
I can confirm this happening both on Fedora 41 and on Silverblue after updating mesa to 24.3.2. I used "rpm-ostree override replace" with mesa packages v23.2.8 and everything is back to normal after the downgrade. This is on VirtualBox with the VMSVGA driver. If I switch to VboxSVGA it obviously works also on 24.3.2. I'm looking at mesa source code and what's changed between the two versions, but it's not clear to me. I think the problem lies with the mesa packages and not with gnome-shell.
The backtrace points to a similar error to: https://bugzilla.redhat.com/show_bug.cgi?id=2337082
Reported upstream and bisected. I'm trying to find a fix: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12467
*** Bug 2337629 has been marked as a duplicate of this bug. ***
As a workaround, in the VM settings -> display, enabling 3D acceleration should fix the issue.
I'm following the bug upstream and I want to thank you José for your work on this. (In reply to José Expósito from comment #8) > As a workaround, in the VM settings -> display, enabling 3D acceleration > should fix the issue. If I may: I think maybe a safer workaround would be to use the VBoxSVGA driver, without 3D acceleration. Even with security mitigations it may not always be a good idea to let the guest access 3D capabilities on the host if not absolutely necessary. From Virtual Box manual[1]: | Because 3D support is still experimental at this time, it is disabled by default and must be manually | enabled in the VM settings. See Display Settings. | | Note: | Untrusted guest systems should not be allowed to use the 3D acceleration features of Oracle VirtualBox, | just as untrusted host software should not be allowed to use | 3D acceleration. Drivers for 3D hardware | are generally too complex to be made properly secure and any software which is allowed to access them may | be able to compromise the operating system running them. In addition, enabling 3D acceleration gives the | guest direct access to a large body of additional program code in the Oracle VirtualBox host process which | it might conceivably be able to use to crash the virtual machine. [1] https://www.virtualbox.org/manual/topics/guestadditions.html#guestadd-3d
This issue exists on VMware Workstation and Fusion (x86_64 and ARM) as well, not just VirtualBox. This has been reported on the VMware forums as being found in any VM using Mesa 24.3.x. VMware users can't revert back to the VBoxSVGA adapter. And disabling 3D support doesn't fix the issue on Rawhide on VMware. The only relief for VMware users is to drop back to Mesa 24.2.x.
FEDORA-2025-055e8d116f (mesa-24.3.4-2.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2025-055e8d116f
Hi! I've pushed a new update including a fix for your issue. You can test it following the instructions available here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-055e8d116f
The above RPMs appear to fix the issue for me. I am able to log in and work without the /etc/environment workaround.
The above RPMs also works for me on VMware Fusion aarch64 with a Fedora 41 VM - but only when 3D acceleration is disabled for the VM. The crash of gnome-session no longer happens in those cases and gdm displays normally. The situation is different when 3D acceleration is enabled. Enabling 3D acceleration for the VM results in a gray screen with no gdm login greeter. Not sure if this is the same problem, or a different one (perhaps with Mesa or mutter). Theres nothing that's obvious in the journal that is showing a problem. I do see that gnome-shell is enabling two experimental features (scale-monitor-framebuffer and xwayland-native-scaling). Not sure if these could be part of the problem.
FEDORA-2025-055e8d116f has been pushed to the Fedora 41 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-055e8d116f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-055e8d116f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
@paulrockwell I think this is a different bug. The fix included in mesa v24.3.4 only handles the case of 3D acceleration disabled. I'm seeing the same gray screen after enabling 3D acceleration. "sudo dmesg --follow" shows this kernel errors: ``` vmwgfx 0000:00:02.0: [drm] *ERROR* vmwgfx seems to be running on an unsupported hypervisor. vmwgfx 0000:00:02.0: [drm] *ERROR* This configuration is likely broken. vmwgfx 0000:00:02.0: [drm] *ERROR* Please switch to a supported graphics device to avoid problems. [...] [ 13.128067] [drm:vmw_msg_ioctl [vmwgfx]] *ERROR* Failed to open channel. [ 13.128091] [drm:vmw_msg_ioctl [vmwgfx]] *ERROR* Failed to open channel. [ 13.462056] [drm:vmw_msg_ioctl [vmwgfx]] *ERROR* Failed to open channel. [ 13.462079] [drm:vmw_msg_ioctl [vmwgfx]] *ERROR* Failed to open channel. [ 13.865592] rfkill: input handler disabled [ 14.919917] [drm:vmw_msg_ioctl [vmwgfx]] *ERROR* Failed to open channel. [ 14.919942] [drm:vmw_msg_ioctl [vmwgfx]] *ERROR* Failed to open channel. [ 14.957062] [drm:vmw_msg_ioctl [vmwgfx]] *ERROR* Failed to open channel. [ 14.957088] [drm:vmw_msg_ioctl [vmwgfx]] *ERROR* Failed to open channel. ``` Is it the same problem on your side? I downgraded mesa to v24.2.4 and rebooted: ``` $ sudo dnf downgrade mesa*24.2.4* $ sudo reboot -h now ``` And I see a grey screen... Meaning that the problem should be somewhre else. Let me know if you have the same problems. As a side note, ssh-ing into the VM and running "eglinfo" seems to allow GDM to start.
> @paulrockwell I think this is a different bug. The fix included in > mesa v24.3.4 only handles the case of 3D acceleration disabled. > I have been running with 3D acceleration enable in VMware the entire time and only disabled for a bit today to see the difference. With 3D disabled I do not have display issues in current configuration. Currently have updated to the Mesa 24.3.4-2 in updates-testing and have removed the work-around in /etc/environment. I agree that the "grey screen" error is could be something different. With 3D enabled, my current "grey screen" has the top bar for instance, but missing the login user/password, with just the grey background and no response to keyboard or mouse input. I have found that toggling the virtual terminal to a command line and back to graphical can get me to the login screen showing the user selection and password and I can again select user and enter password. Initially after I had updated to mesa 24.3.2-2 and applied the work around and that seemed to be sufficient. After a set of patches that include gnome and mutter I initial saw some weird behavior and then downgraded the mesa drivers to 24.2.4-1 to fix issues, still needing the /etc/environment work-around. The following update broke my login again after the initial work-around was stable. It was after this update that I downgraded mesa to 24.2.4-1 root@localhost:~# dnf history info 19 | grep -P 'gnome|mutter|(Begin|End) time' Begin time : 2025-01-15 20:12:09 End time : 2025-01-15 20:18:58 Upgrade gnome-classic-session-0:47.3-1.fc41.noarch Group updates Upgrade gnome-shell-extension-apps-menu-0:47.3-1.fc41.noarch Dependency updates Upgrade gnome-shell-extension-launch-new-instance-0:47.3-1.fc41.noarch Dependency updates Upgrade gnome-shell-extension-places-menu-0:47.3-1.fc41.noarch Dependency updates Upgrade gnome-shell-extension-window-list-0:47.3-1.fc41.noarch Dependency updates Upgrade gnome-shell-extension-common-0:47.3-1.fc41.noarch Dependency updates Upgrade gnome-classic-session-xsession-0:47.3-1.fc41.noarch User updates Upgrade gnome-shell-extension-user-theme-0:47.3-1.fc41.noarch External User updates Upgrade gnome-maps-0:47.3-1.fc41.x86_64 Group updates Upgrade gnome-remote-desktop-0:47.3-1.fc41.x86_64 Group updates Upgrade gnome-shell-0:47.3-1.fc41.x86_64 Group updates Upgrade mutter-0:47.4-1.fc41.x86_64 Dependency updates Upgrade mutter-common-0:47.4-1.fc41.noarch Dependency updates Replaced gnome-classic-session-0:47.2-1.fc41.noarch Group @System Replaced gnome-classic-session-xsession-0:47.2-1.fc41.noarch User @System Replaced gnome-maps-0:47.2-1.fc41.x86_64 Group @System Replaced gnome-remote-desktop-0:47.2-1.fc41.x86_64 Group @System Replaced gnome-shell-0:47.2-1.fc41.x86_64 Group @System Replaced gnome-shell-extension-apps-menu-0:47.2-1.fc41.noarch Dependency @System Replaced gnome-shell-extension-common-0:47.2-1.fc41.noarch Dependency @System Replaced gnome-shell-extension-launch-new-instance-0:47.2-1.fc41.noarch Dependency @System Replaced gnome-shell-extension-places-menu-0:47.2-1.fc41.noarch Dependency @System Replaced gnome-shell-extension-user-theme-0:47.2-1.fc41.noarch External User @System Replaced gnome-shell-extension-window-list-0:47.2-1.fc41.noarch Dependency @System Replaced mutter-0:47.3-1.fc41.x86_64 Dependency @System Replaced mutter-common-0:47.3-1.fc41.noarch Dependency @System root@localhost:~# dnf history info 20 Transaction ID : 20 Begin time : 2025-01-15 20:54:54 Begin rpmdb : 06465bb58b2fbf0a4007b6b5a733b1024b406134fea7da0186b5c045e94d4970 End time : 2025-01-15 20:55:00 End rpmdb : 65f33cbeaf3e8d2ff5ddaf43814c84ceaf260be80891a2e6e7100965a770e149 Status : Ok Releasever : 41 Description : dnf downgrade mesa-dri-drivers Comment : Packages altered: Action Package Reason Repository Downgrade mesa-dri-drivers-0:24.2.4-1.fc41.x86_64 Group fedora Downgrade mesa-filesystem-0:24.2.4-1.fc41.x86_64 Dependency fedora Downgrade mesa-libglapi-0:24.2.4-1.fc41.x86_64 Dependency fedora Downgrade mesa-libgbm-0:24.2.4-1.fc41.x86_64 Dependency fedora Downgrade mesa-libGL-0:24.2.4-1.fc41.x86_64 Dependency fedora Downgrade mesa-libEGL-0:24.2.4-1.fc41.x86_64 Group fedora Downgrade mesa-vulkan-drivers-0:24.2.4-1.fc41.x86_64 Group fedora Downgrade mesa-va-drivers-0:24.2.4-1.fc41.x86_64 Weak Dependency fedora Replaced mesa-dri-drivers-0:24.3.2-2.fc41.x86_64 Group @System Replaced mesa-filesystem-0:24.3.2-2.fc41.x86_64 Dependency @System Replaced mesa-libEGL-0:24.3.2-2.fc41.x86_64 Group @System Replaced mesa-libGL-0:24.3.2-2.fc41.x86_64 Dependency @System Replaced mesa-libgbm-0:24.3.2-2.fc41.x86_64 Dependency @System Replaced mesa-libglapi-0:24.3.2-2.fc41.x86_64 Dependency @System Replaced mesa-va-drivers-0:24.3.2-2.fc41.x86_64 Weak Dependency @System Replaced mesa-vulkan-drivers-0:24.3.2-2.fc41.x86_64 Group @System
@jexposit Further investigation seems to lead me to agree with you that what I'm seeing is a different problem not related to Mesa. I'm running a F41 vm kernel 6.12.9-200.fc41.aarch64 on VMware Fusion with 3D acceleration enabled. I don't see your error messages in dmesg - most likely because I'm running on a VMware product that is supporting 3D acceleration. I think that what I'm seeing with 3D enabled is related to mutter, perhaps related to the use of experimental scaling features. I find that the gdm login screen in my case is dimmed (you can see gdm display the Fedora logo, but it's dimmed - as are the icons for accessibility, network status - but no username. Resizing the window slightly brings the gdm login screen in full view. Once logged in, glxinfo indicates OpenGL vendor string: VMware, Inc. OpenGL renderer string: SVGA3D; build: RELEASE; LLVM; A basic check through glxgears indicates that Mesa seems to be working as it did before (glxgears is running sync'ed to the frame refresh rate when 3D is enabled in the VM). Given what was seen with 3D disabled (the gnome-shell crash preventing any kind of login, which I'm no longer seeing with this patch). I'd consider this particular bug with Mesa as fixed.
FEDORA-2025-a24369766c (mesa-24.3.4-3.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
I can confirm, that it is still a problem with VMware® Workstation 17 Pro (17.6.1 build-24319023) and Fedora 41 with all updates as of today.