Bug 2359799 - Inital-setup: VK_ERROR_DEVICE_LOST using nvidia hardware
Summary: Inital-setup: VK_ERROR_DEVICE_LOST using nvidia hardware
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: mesa
Version: 42
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Dave Airlie
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 2361117 2369620 2412100 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-04-15 17:00 UTC by Lars Loe
Modified: 2026-06-08 16:48 UTC (History)
37 users (show)

Fixed In Version: mesa-26.0.3-4.fc44
Clone Of:
Environment:
Last Closed: 2026-06-08 16:48:10 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
freedesktop.org Gitlab mesa/mesa/-/work_items/15277 0 None None None 2026-04-14 05:54:17 UTC

Description Lars Loe 2025-04-15 17:00:03 UTC
System info:
Ryzen 5800X3D
Nvidia RTX 4070
24GB RAM

- Used the latest F42 Workstation release *.iso to do a fresh install (full disk install, SSD, no dual boot)
- Everything boots up fine until the described issue occurs

- Since it's the initial setup I'm unable to log into any user account from tty console or view logs, take a screenshot etc.

- mounting the journalctl directory from a working Linux installation using `journalctl -D $PATH` shows that it's possibly a nouveau driver issue:

Github Gist: https://gist.github.com/MadByteDE/e5003fc079f02bb7f5494057812087c5

Apr 15 18:12:11 fedora gnome-initial-s[2031]: vkQueuePresentKHR(): The logical or physical device has been lost. (VK_ERROR_DEVICE_LOST) (-4)
Apr 15 18:12:11 fedora gnome-initial-s[2031]: Vulkan: ../src/nouveau/vulkan/nvk_queue.c:380: Submit failed (VK_ERROR_DEVICE_LOST)
Apr 15 18:12:11 fedora gnome-initial-s[2031]: vkQueueSubmit(): The logical or physical device has been lost. (VK_ERROR_DEVICE_LOST) (-4)
Apr 15 18:12:11 fedora gnome-initial-s[2031]: Vulkan: ../src/nouveau/vulkan/nvkmd/nouveau/nvkmd_nouveau_ctx.c:149: DRM_NOUVEAU_EXEC failed: Kein passendes Gerät gefunden (VK_ERROR_DEVICE_LOST)
Apr 15 18:12:11 fedora kernel: nouveau 0000:26:00.0: gnome-initial-s[2031]: channel 64 killed!
Apr 15 18:12:11 fedora kernel: nouveau 0000:26:00.0: fifo:c00000:0008:0040:[gnome-initial-s[2031]] errored - disabling channel
Apr 15 18:12:11 fedora kernel: nouveau 0000:26:00.0: gsp: rc engn:00000001 chid:64 type:31 scope:1 part:233
Apr 15 18:12:11 fedora kernel: nouveau 0000:26:00.0: gsp: mmu fault queued
Apr 15 18:12:00 fedora gnome-initial-s[2031]: Trying to measure GtkBox 0x55662b32c750 for width of 121, but it needs at least 128

Reproducible: Always

Steps to Reproduce:
1. Boot into initial-setup after a fresh Fedora 42 Workstation installation
2. Proceed until time zone setup screen & press `Next`
Actual Results:
The initial setup window freezes instantly on clicking the button - the Gnome interface still works (e.g. top right menu)

Expected Results:
Initial setup should proceed normally

Additional Information:

Comment 1 Lars Loe 2025-04-15 17:02:24 UTC
Used *.iso version: Fedora-Workstation-Live-42-1.1.x86_64.iso

Comment 2 Lars Loe 2025-04-15 17:52:54 UTC
According to https://gitlab.freedesktop.org/drm/nouveau/-/issues/382 - disabling the gsp blob using `nouveau.config=NvGspRm=0`could work to work around the issue. 

If this really is the issue, I'm aware that `initial-setup` / Fedora is not at fault here. 

That said, if this is an issue other users can confirm, it might be worth to disable the gsp blob for nouveau by default for new Fedora installs so that they can at least fully boot into Gnome & install updates or proprietary Nvidia drivers.

Comment 3 Lars Loe 2025-04-24 15:22:27 UTC
For visibility - another bug report describing the same issue:
https://bugzilla.redhat.com/show_bug.cgi?id=2361117

Comment 4 Martin Kolman 2025-04-29 12:02:08 UTC
So if this happens after you install from the Workstation media & reboot, then what runs is actually the GNOME Initial Setup - yes, its confusing. :)

Comment 5 Michael Catanzaro 2025-09-14 22:48:58 UTC
*** Bug 2361117 has been marked as a duplicate of this bug. ***

Comment 6 David 2025-11-07 16:02:13 UTC
Hi fellows, i want to chip in.

 i got the same issue on Fedora Silverblue 43 running on my Lenovo X1 Extreme Gen5 with RTX3080:

Nov 07 16:20:16 gnome-initial-setup[8601]: Trying to measure GtkBox 0x55d3fa570200 for width of 121, but it needs at least 128
Nov 07 16:20:16 kernel: nouveau 0000:01:00.0: gsp: mmu fault queued
Nov 07 16:20:16 kernel: nouveau 0000:01:00.0: gsp: rc engn:00000001 chid:6 gfid:0 level:2 type:31 scope:1 part:233 fault_addr:0000003ff9640000 fault_type:00000002
Nov 07 16:20:16 kernel: nouveau 0000:01:00.0: fifo:c00000:0006:0006:[gnome-initial-s[8601]] errored - disabling channel
Nov 07 16:20:16 kernel: nouveau 0000:01:00.0: gnome-initial-s[8601]: channel 6 killed!
Nov 07 16:20:16 gnome-initial-setup[8601]: Vulkan: ../src/nouveau/vulkan/nvkmd/nouveau/nvkmd_nouveau_ctx.c:149: DRM_NOUVEAU_EXEC failed: Kein passendes Gerät gefunden (VK_ERROR_DEVICE_LOST)
Nov 07 16:20:16 gnome-initial-setup[8601]: vkQueueSubmit(): The logical or physical device has been lost. (VK_ERROR_DEVICE_LOST) (-4)
Nov 07 16:20:16 gnome-initial-setup[8601]: Vulkan: ../src/nouveau/vulkan/nvk_queue.c:319: Submit failed (VK_ERROR_DEVICE_LOST)
Nov 07 16:20:16 gnome-initial-setup[8601]: vkQueuePresentKHR(): The logical or physical device has been lost. (VK_ERROR_DEVICE_LOST) (-4)

I Tried booting with 'nouveau.config=NvGspRm=0' but it doesn't work for me - the results are the very same, but the Kernel log is quite a bit different:

Nov 07 16:32:28 fedora gnome-initial-setup[2724]: Starting gnome-initial-setup
Nov 07 16:32:28 fedora gnome-initial-setup[2724]: Production mode: changes will be saved to disk
Nov 07 16:32:38 fedora gnome-initial-setup[2724]: Trying to measure GtkBox 0x56508ff7b150 for width of 121, but it needs at least 128
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: TRAP ch 4 [03ff3b0000 gnome-initial-s[2724]]
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC0/TPC2/SM0 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b090020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC0/TPC2/SM1 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC0/TPC3/SM0 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b150020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC0/TPC3/SM1 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b0f0020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC1/TPC0/SM0 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b000020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC1/TPC0/SM1 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC1/TPC1/SM0 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC1/TPC1/SM1 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b020020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC1/TPC2/SM0 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC1/TPC2/SM1 trap: global 00000000 [] warp b000020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC1/TPC3/SM0 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC1/TPC3/SM1 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b0f0020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC1/TPC4/SM0 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b1f0020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC1/TPC4/SM1 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC2/TPC0/SM0 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC2/TPC0/SM1 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b0b0020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC2/TPC2/SM0 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC2/TPC2/SM1 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b260020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC2/TPC3/SM0 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b1a0020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC2/TPC3/SM1 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC2/TPC4/SM0 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC2/TPC4/SM1 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b170020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC3/TPC0/SM0 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC3/TPC0/SM1 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b040020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC3/TPC1/SM0 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b090020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC3/TPC1/SM1 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC3/TPC2/SM0 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b030020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC3/TPC2/SM1 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC3/TPC3/SM0 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b0c0020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC3/TPC3/SM1 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC3/TPC4/SM0 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC3/TPC4/SM1 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b0b0020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC4/TPC0/SM0 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC4/TPC0/SM1 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b0e0020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC4/TPC1/SM0 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC4/TPC1/SM1 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b080020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC4/TPC3/SM0 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b110020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC4/TPC3/SM1 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC4/TPC4/SM0 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b020020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC4/TPC4/SM1 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC5/TPC0/SM0 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b0a0020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC5/TPC0/SM1 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora gnome-initial-setup[2724]: Vulkan: ../src/nouveau/vulkan/nvkmd/nouveau/nvkmd_nouveau_ctx.c:149: DRM_NOUVEAU_EXEC failed: Kein passendes Gerät gefunden (VK_ERROR_DEVICE_LOST)
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC5/TPC2/SM0 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora gnome-initial-setup[2724]: vkQueueSubmit(): The logical or physical device has been lost. (VK_ERROR_DEVICE_LOST) (-4)
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC5/TPC2/SM1 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b190020 []
Nov 07 16:32:38 fedora gnome-initial-setup[2724]: Vulkan: ../src/nouveau/vulkan/nvk_queue.c:319: Submit failed (VK_ERROR_DEVICE_LOST)
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC5/TPC3/SM0 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b0e0020 []
Nov 07 16:32:38 fedora gnome-initial-setup[2724]: vkQueuePresentKHR(): The logical or physical device has been lost. (VK_ERROR_DEVICE_LOST) (-4)
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC5/TPC3/SM1 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC5/TPC4/SM0 trap: global 00000000 [] warp 0000 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gr: GPC5/TPC4/SM1 trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp b070020 []
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: fifo: fault 00 [VIRT_READ] at 0000003ff9640000 engine 40 [gr] client 07 [GPC0/T1_7] reason 02 [PTE] on channel 4 [03ff3b0000 gnome-initial-s[2724]]
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: fifo:c00000:0004:[gnome-initial-s[2724]] rc scheduled
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: fifo:c00000: rc scheduled
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: fifo:c00000:0004:0004:[gnome-initial-s[2724]] errored - disabling channel
Nov 07 16:32:38 fedora kernel: nouveau 0000:01:00.0: gnome-initial-s[2724]: channel 4 killed!

Cheers
Dave

Comment 7 Martin Garton 2026-01-21 15:04:34 UTC
Possible duplicate? : https://bugzilla.redhat.com/show_bug.cgi?id=2412100

Comment 8 luola_ 2026-02-14 15:53:42 UTC
The issue is being reproduced on my system as well. Used Fedora 42 and Fedora 43, both workstation and server.
For some reason the server .iso has a graphical install. 
Is there a way to go through a non graphical install in order to bypass the issue?

Comment 9 luola_ 2026-02-14 16:25:16 UTC
Clicking on the map instead of writing in text field seems to resolve the issue. After enabling third party repos, the installer stalls by showing you the Fedora Desktop without any installation.

Comment 10 William Told 2026-03-04 09:06:54 UTC
First time Fedora (43) installer here. Experienced the same/similar problem where I was unable to select time zone, but ...

Unlike others I could not click on the map as several reports seem to suggest as a workaround. I tried restarting the installer at least 3 times. Same outcome.

On a hunch (going into details would yield unnecessary disrespect), I enabled location tracking and wifi in earlier installer dialogs. And voila, I could click on the map and move on. 

One more thing. My entire wifi installer was in french(?), and so is parts of my installation. Despite having chosen english every place I could think of. LOCAL says everything is en_US-ut8 (or whatever that format is).

On the upside, this is without question, the bug that made me laugh the hardest in my several decades of dealing with computers.

Comment 11 Michael Catanzaro 2026-03-09 14:24:44 UTC
*** Bug 2412100 has been marked as a duplicate of this bug. ***

Comment 12 Fedora Blocker Bugs Application 2026-03-09 14:30:08 UTC
Proposed as a Blocker for 44-final by Fedora user catanzaro using the blocker tracking app because:

 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.

(There have been a high number of complaints about this on social media, so it's not a rare issue.)

Comment 13 Kamil Páral 2026-03-09 17:54:04 UTC
Discussed in a blocker review meeting [1] on 2026-03-09. The outcome was:

!agreed 2359799 - AcceptedBlocker (Final) - this is accepted as a violation of the various first boot and initial setup criteria (at Base and Final) when installing on systems with affected NVIDIA GPUs. we do note it was already broken in F42 and F43, which may cause us to consider waiving it if it proves difficult to fix in a realistic timeframe

[1] https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/

Comment 14 Adam Williamson 2026-03-11 06:40:43 UTC
It does seem like the crash always immediately follows the "Trying to measure GtkBox 0x55662b32c750 for width of 121, but it needs at least 128" message. Can we perhaps attack from that angle? Figure out what's going on with that UI element size mismatch and see if fixing it makes the crash go away?

Comment 15 Kamil Páral 2026-03-19 08:39:51 UTC
I tried to reproduce this on a Slimbook Executive 16 laptop with hybrid graphics Intel GPU+Nvidia GF 3050Ti, but couldn't trigger the issue. Initial setup worked fine every time. Tested with Fedora-Workstation-Live-44-20260318.n.0.x86_64.iso.

Comment 16 Matthias Clasen 2026-03-31 15:48:34 UTC
After talking to the graphics team, they recommendation was to verify that this issue still happens with a non-eol version of mesa (ie in F44), and report it upsteam.

Comment 17 Adam Williamson 2026-03-31 18:54:43 UTC
Hmm, yeah, I can't actually find any report that this is affecting 44. Can anyone who has affected hardware please test a recent nightly - https://openqa.fedoraproject.org/nightlies.html - and confirm? Unfortunately nobody on QA team seems to have an affected system so we can't check.

Matthias, do you think the "Trying to measure GtkBox 0x56508ff7b150 for width of 121, but it needs at least 128" message might be relevant here? Is it plausible to figure out where that's coming from, fix it, and see if that prevents the bug?

Comment 18 Martin Garton 2026-04-04 16:26:41 UTC
I encountered this bug on F43. I just did a clean re-install of F44 using Fedora-Workstation-Live-44-20260324.n.0.x86_64.iso and the problem did not occur.   I suppose that doesn't mean the bug is definitely gone, but I thought it might be useful to mention anyway.  I have an RTX4090.  Please let me know if I can provide any additional information that might be useful.

Comment 19 Michael Catanzaro 2026-04-04 18:19:19 UTC
That is very useful to know. We were hoping for users who could reproduce in F42/F43 to test with F44.

Would be good to hear from more users who experienced the problem in F42/F43. Hopefully the bug is already fixed at some point between then and now.

Comment 20 Tomas Hrcka 2026-04-07 08:19:58 UTC
I got a chance to test 44 on one of my desktops, switched few cards, from the oldest Quadro P2000, Quadro P4000, GTX1060 and RTX 3080.
No issues during installation, clicked through few apps and reinstall with different card.

Based on the comments there was issue with 3080 on 42/43, should I fetch 43 install media and test it?

Comment 21 Kamil Páral 2026-04-07 08:58:22 UTC
(In reply to Tomas Hrcka from comment #20)
> Based on the comments there was issue with 3080 on 42/43, should I fetch 43
> install media and test it?

If you could find a card that is affected in F43 and not affected in F44, that would be very helpful.
Please note that this seems mostly related to gnome-initial-setup. Removing ~/.config/gnome-initial-setup-done after switching cards might help to force it to run again.

Comment 22 Yannis Rachdi 2026-04-12 19:37:08 UTC
I just tested this with Fedora-44-20260412.n.0. I have a 4070 TI on my system. 

I could reproduce on 42/43 in the past. With Fedora-44-20260412.n.0, the issue is still present for me. 

Let me know if you need more details.

Comment 23 Dave Airlie 2026-04-13 08:30:03 UTC
Okay I think this is fixed by something in gnome-initial-setup but figuring it out has been a journey.

I installed F44 Beta Workstation Live, and running g-i-s under the LiveCD I could make it happen without installing.

I installed F44 Beta to the machine, and it happened on boot.

I installed F44 Beta Everything, and running it manually I cannot reproduce at all.

I went back to F44 Beta Live, I upgrade mesa to latest as it was on 25.3 to 26.0, didn't help. I moved from gnome-initial-setup 0:50~alpha-1 to 0:50.0-3, and I could no longer reproduce it. I downgrade to alpha and it came back.

I went to my F44 Beta install and downgraded to the alpha version and it doesn't crash.

This really sounds like a bug in gnome-initial-setup is causing a race with vulkan image lifetimes. I very seriously doubt this is a Mesa bug, but since I can't reproduce it in an environment where I can debug it, it's very hard to point fingers.

If someone is reproducing it, please provide rpm -qf gnome-initial-setup mesa-vulkan-drivers

Comment 24 Dave Airlie 2026-04-13 08:32:30 UTC
Of course as I soon as I type it I found a better way to crash the latest one on my install. arrgggh..

I can crash it easier by going to map selection, if it doesn't die, typing some crap, then hitting previous.

I'll try and see if I can figure out wtf is at  fault here

Comment 25 Dave Airlie 2026-04-13 09:29:44 UTC
okay maybe this is a nvk bug, I'm going to try and dig in a bit deeper tomorrow.

Comment 26 Jason L 2026-04-13 15:58:02 UTC
i am encountering this issue with my Lenovo Legion laptop running an RTX4090 mobile GPU.
in dGPU only mode this issue occurs for me on both F43 and F44b installers; once i click “Next” on the privacy section the installer panel is blank and unresponsive. only the system bar works with limited functionality. my workaround was to switch back to hybrid graphics.

Comment 27 Dave Airlie 2026-04-14 06:50:42 UTC
I'm got a possible fix, I'm only 70% confident in, but it seems to stop it dying in my test configuration.

Of course we need to build it and get the images built from it

It's building for f44 and rawhide now

Comment 28 Fedora Update System 2026-04-14 07:08:25 UTC
FEDORA-2026-e6b8f30858 (mesa-26.0.3-4.fc44) has been submitted as an update to Fedora 44.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-e6b8f30858

Comment 29 Adam Williamson 2026-04-14 15:09:14 UTC
Thanks a lot Dave!

Here's a Workstation live ISO with the mesa update in it: https://adamwill.fedorapeople.org/04587522-Fedora-Workstation-Live-x86_64-FEDORA-2026-e6b8f30858.iso

Folks who are able to reproduce this, please try it out. Please give it a few tries, as it seems the problem doesn't happen every time?

Comment 30 Lars Loe 2026-04-14 17:27:44 UTC
(In reply to Adam Williamson from comment #29)
> Thanks a lot Dave!
> 
> Here's a Workstation live ISO with the mesa update in it:
> https://adamwill.fedorapeople.org/04587522-Fedora-Workstation-Live-x86_64-
> FEDORA-2026-e6b8f30858.iso
> 
> Folks who are able to reproduce this, please try it out. Please give it a
> few tries, as it seems the problem doesn't happen every time?

Tried the *.iso and at least for me the issue is no longer reproducible (RTX 4070) & journalctl doesn't show anything interesting happening either.

From me as OP also thanks for fixing the issue Dave (and also Michael Catanzaro for proposing this as blocker to get more attention towards the issue).

Comment 31 Jason L 2026-04-15 00:08:37 UTC
(In reply to Adam Williamson from comment #29)
> Thanks a lot Dave!
> 
> Here's a Workstation live ISO with the mesa update in it:
> https://adamwill.fedorapeople.org/04587522-Fedora-Workstation-Live-x86_64-
> FEDORA-2026-e6b8f30858.iso
> 
> Folks who are able to reproduce this, please try it out. Please give it a
> few tries, as it seems the problem doesn't happen every time?

also working for me without issue!

Comment 32 Fedora Update System 2026-04-15 01:09:31 UTC
FEDORA-2026-e6b8f30858 has been pushed to the Fedora 44 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-e6b8f30858`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-e6b8f30858

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 33 Yannis Rachdi 2026-04-15 21:09:30 UTC
Can confirm, with the(In reply to Adam Williamson from comment #29)
> Thanks a lot Dave!
> 
> Here's a Workstation live ISO with the mesa update in it:
> https://adamwill.fedorapeople.org/04587522-Fedora-Workstation-Live-x86_64-
> FEDORA-2026-e6b8f30858.iso
> 
> Folks who are able to reproduce this, please try it out. Please give it a
> few tries, as it seems the problem doesn't happen every time?

I can also confirm, on my system (RTX 4070 TI), the issue is gone as well.

Comment 34 Fedora Update System 2026-04-16 23:41:21 UTC
FEDORA-2026-e6b8f30858 (mesa-26.0.3-4.fc44) has been pushed to the Fedora 44 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 35 Adam Williamson 2026-04-22 19:32:59 UTC
Re-opening for F42 as we do have reports there - the initial post here, and https://bugzilla.redhat.com/show_bug.cgi?id=2369620 . Would be nice to backport the fix there even though it'll be EOL relatively soon.

Comment 36 Adam Williamson 2026-04-22 19:33:12 UTC
*** Bug 2369620 has been marked as a duplicate of this bug. ***

Comment 37 Fedora Release Engineering 2026-05-06 12:35:42 UTC
This message is a reminder that Fedora Linux 42 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 42 on 2026-05-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '42'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 42 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 38 Aoife Moloney 2026-06-08 16:48:10 UTC
Fedora Linux 42 entered end-of-life (EOL) status on 2026-05-27.

Fedora Linux 42 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.