Bug 2036724

Summary: Traditional installer graphical environment fails to start due to gnome-kiosk crashing(?)
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: gnome-kioskAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED RAWHIDE QA Contact:
Severity: urgent Docs Contact:
Priority: unspecified    
Version: rawhideCC: anaconda-maint-list, francois.rigault, robatino, rstrode
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: openqa
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-01-10 20:07:24 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2036467    
Bug Blocks: 1953783    
Attachments:
Description Flags
anaconda crash traceback screenshot none

Description Adam Williamson 2022-01-03 17:40:43 UTC
Starting with Fedora-Rawhide-20220101.n.0 , the graphical traditional installer does not start correctly. This appears to be because gnome-kiosk crashes. There's a long Python traceback that ends with "gnome-kiosk exited with status 1". I'll attach a screenshot. I can't find anything useful in any of the logs, yet.

The odd thing here is there aren't many suspects in the 20220101.n.0 compose. The only candidate appears to be gtk4, but that's odd because both anaconda and python-meh try to force the GTK+ version to 3.0 with `gi.require_version("Gtk", "3.0")`. Not really sure what might be going on here.

Comment 1 Adam Williamson 2022-01-03 17:41:36 UTC
Created attachment 1848717 [details]
anaconda crash traceback screenshot

Comment 2 Adam Williamson 2022-01-03 17:42:53 UTC
Proposing as a Beta blocker as a violation of Basic criterion "The installer must run when launched normally from the release-blocking images" - it does not, for the release-blocking Everything netinst and Server DVD images, in graphical mode at least.

Comment 3 François Rigault 2022-01-03 18:37:04 UTC
*** Bug 2036454 has been marked as a duplicate of this bug. ***

Comment 4 Adam Williamson 2022-01-04 07:10:44 UTC
Sorry, Francois, I didn't see your report. Your notes seem helpful, so adding them here:

Additional info:
from X.log: (also in https://openqa.fedoraproject.org/tests/1093342/file/_boot_to_anaconda-X.log)
[    59.869] (EE) AIGLX error: dlopen of /usr/lib64/dri/swrast_dri.so failed (libvulkan.so.1: cannot open shared object file: No such file or directory)

this file is normally provided as part of package vulkan-loader.
This file used to exist in Fedora-Server-netinst-x86_64-35-1.2.iso for example, but is missing from the latest Rawhide.

...and a reference to https://bugzilla.redhat.com/show_bug.cgi?id=2036467 , which does seem to be the issue - from https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20220101.n.0/logs/x86_64/buildinstall-Everything-logs/lorax.log , it looks like the installer environment build pulled in chromium-common instead of vulkan-loader. So I guess we can mark this as depending on that.

Comment 5 Adam Williamson 2022-01-05 20:51:27 UTC
This is still broken in the current compose because regexes are hard, apparently:

https://src.fedoraproject.org/rpms/chromium/c/db8833cbe813bd64bc493c4e94cd9f6c1d054fde?branch=rawhide

the build with that fix is still running. Assuming it actually works, next compose should be fixed.

Comment 6 Adam Williamson 2022-01-06 19:23:50 UTC
Sigh, the fixed chromium build *just* missed the 20220106.n.0 compose, so it still has the bug. It should be in the 20220107.n.0 compose.

Comment 7 Adam Williamson 2022-01-10 20:07:24 UTC
I checked the Everything netinst from today's failed compose (the compose got far enough to build it). It boots to the graphical installer, so this is fixed.