Since Fedora-Rawhide-20250903.n.0 , yelp windows show nothing visible in Rawhide. You just see the window title and a blank white pane. The app is "working", though - if you move the pointer around it, it changes shape appropriately and mouseover tips are displayed; if you click a link, it works (the page title changes and the invisible content also clearly changes). On the console, I see this: libEGL warning: failed to get driver name for fd -1 libEGL warning: MESA-LOADER: failed to retrieve device information libEGL warning: failed to get driver name for fd -1 MESA: error: ZINK: failed to choose pdev libEGL warning: egl: failed to create dri2 screen KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied Failed to create GBM buffer of size 960x584: Permission denied Not sure which of these messages are related. I'm not sure exactly what caused this. In 20250903.n.0 I see glycin-2.0~rc-1.fc44 and gtk4-4.20.0-2.fc44; I don't see anything else obviously relevant, on a quick scroll-through. See https://lists.fedoraproject.org/archives/list/test-reports@lists.fedoraproject.org/thread/VEP46MJUMWV6Y75NDUGROQCMLEISFJEV/ for the full compose changelog.
This bug doesn't seem to affect 43 even with the 49 RC megaupdate - https://bodhi.fedoraproject.org/updates/FEDORA-2025-7e109c4976 . So there must be some significant difference there. On the console with 43, I only see: libEGL warning: egl: failed to create dri2 screen libEGL warning: DRI2: failed to create screen libEGL warning: egl: failed to create dri2 screen libEGL warning: DRI2: failed to create screen
This isn't SELinux, I checked.
Presumably everything using WebKitGTK is broken? Was mesa updated? Or kernel? Or WebKitGTK itself?
Ah, yes. Not mesa or kernel, but webkitgtk: Package: webkitgtk-2.49.90-1.fc44 Old package: webkitgtk-2.49.4-2.fc43
Definitely webkitgtk, as it affects the F43 webkitgtk update. https://bodhi.fedoraproject.org/updates/FEDORA-2025-d1c5993ceb
I've unpushed the corresponding EL10 release for webkitgtk also https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-bfa97edd0c
Keep in mind that odd minor versions (49) are unstable versions, not intended for EPEL. The stable versions and 48, 50, etc.
Well I have bad news: it works perfectly fine for me. Since these are libEGL and mesa errors, I assume it's probably only broken in the virtual machine that you're presumably using? Next steps: in the environment where the problem occurs, navigate to webkit://gpu and click either the "Copy to clipboard" or "Print to stdout" button. You won't be able to do this directly in Yelp, so use /usr/libexec/webkitgtk-6.0/MiniBrowser from webkitgtk6.0-devel.
Oh, and you won't be able to *see* the buttons because the graphics are broken. There are two methods to click anyway. Method one: click all over the top-left portion of the web view and hope you hit a button. Method two: press Tab once, note the focus should move from address bar to Reload button. Tab again to focus the Search button, and again to focus the menu button. If you have just loaded the web page and not focused the web view before, then one more Tab should focus the web view. Finally, one last Tab to focus the copy to clipboard button.
> libEGL warning: failed to get driver name for fd -1 Last time we had a similar bug, the problem turned out to be a change in mesa, https://gitlab.freedesktop.org/mesa/mesa/-/issues/9199. However, this time you're confident that WebKitGTK is to blame, so I guess something else is going on.
> I assume it's probably only broken in the virtual machine that you're presumably using? Probably, yes, but likely not only in *that specific* VM. Probably something like 'all virtio VMs', or 'all virtio VMs without 3D passthrough', or 'all llvmpipe systems', or similar. I can fiddle around with it some more tomorrow. You might wanna try on llvmpipe, if you can. and yes, I'm *pretty* sure the webkitgtk change at least triggers this, I grabbed the live image built by the webkitgtk update test and booted it locally and reproduced the problem, but did *not* reproduce it with the live image built for the megaupdate. Not much is going stable since f43 is frozen, and there hasn't been a mesa updaet lately for f43 anyway. But I can reproduce those results, and maybe just test installing an f43 system and updating webkitgtk, tomorrow.
OK, so: * It's definitely the webkitgtk update. Nothing else * It affects qemu + virtio without 3D passthrough * It doesn't affect qemu with qxl or VGA * It doesn't affect bare metal (AMD) with native drivers or with nomodeset (so, llvmpipe) I'll test qemu + virtio *with* 3D passthrough, but I need to use a different host for that...
Very helpful. Is this testable in Boxes? I'm not familiar with all the virtualization terminology. I will need to bisect it before we report a bug to upstream. And to do that, I need to be able to reproduce.
For me it reproduces in a fresh Boxes VM with 3D passthrough disabled, yes.
OK, I can reproduce in Boxes and am bisecting this now. Notably the GOOD version, 2.49.4, prints the following very scary warnings, which I had incorrectly assumed were the problem here: libEGL warning: failed to get driver name for fd -1 libEGL warning: MESA-LOADER: failed to retrieve device information libEGL warning: failed to get driver name for fd -1 MESA: error: ZINK: failed to choose pdev libEGL warning: egl: failed to create dri2 screen libEGL warning: egl: failed to create dri2 screen libEGL warning: DRI2: failed to create screen libEGL warning: egl: failed to create dri2 screen libEGL warning: DRI2: failed to create screen
In the bad case, I see: libEGL warning: failed to get driver name for fd -1 libEGL warning: MESA-LOADER: failed to retrieve device information libEGL warning: failed to get driver name for fd -1 MESA: error: ZINK: failed to choose pdev libEGL warning: egl: failed to create dri2 screen KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied Failed to create GBM buffer of size 1024x691: Permission denied So this bug is associated with only the last three lines here: KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied Failed to create GBM buffer of size 1024x691: Permission denied
yes, that's pretty much the diff I found in the first two comments.
I've bisected and created an upstream bug report. Will hold off on any further WebKitGTK updates until we have a solution.
*** Bug 2395741 has been marked as a duplicate of this bug. ***