Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2118832 - anaconda help shows up blank on live images since Fedora-37-20220814.n.0
Summary: anaconda help shows up blank on live images since Fedora-37-20220814.n.0
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 37
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Vladimír Slávik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker openqa AcceptedFreeze...
Depends On:
Blocks: F37BetaFreezeException F37FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2022-08-16 22:11 UTC by Adam Williamson
Modified: 2022-11-08 21:05 UTC (History)
21 users (show)

Fixed In Version: anaconda-37.12.2-1.fc37
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-09-02 22:27:42 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Adam Williamson 2022-08-16 22:11:14 UTC 
Since Fedora-37-20220814.n.0 (it was fine with Fedora-37-20220813.n.0), anaconda's Help pages are showing up blank in live images (both Workstation and KDE). A yelp window loads fine enough when you hit F1, but there's nothing in it - just white space.

I poked about a bit at least. It seems it runs this command as root (with differing filenames depending on which page you're on when you hit F1):

yelp /usr/share/anaconda/help/fedora/en-US/WelcomeSpoke.xml

If I run that command manually as the regular 'liveuser' user, it works fine; if I run it manually as root, I similarly get a blank white page, and these errors:

* (yelp:4010): WARNING **: 18:05:13.310: AT-SPI: Could not obtain desktop path or name


** (yelp:4010): WARNING **: 18:05:13.438: atk-bridge: GetRegisteredEvents returned message with unknown signature

** (yelp:4010): WARNING **: 18:05:13.438: atk-bridge: get_device_events_reply: unknown signature

** (yelp:4010): WARNING **: 18:05:13.438: atk-bridge: get_device_events_reply: unknown signature

(WebKitWebProcess:4112): Gdk-WARNING **: 18:05:13.911: The program 'WebKitWebProcess' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadShmSeg (invalid shared segment parameter)'.
  (Details: serial 203 error_code 128 request_code 130 (MIT-SHM) minor_code 3)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Haven't looked into it further than that, yet. Proposing as a Final blocker as a violation of https://fedoraproject.org/wiki/Fedora_37_Final_Release_Criteria#installer-help - "Any element in the installer interface(s) which is clearly intended to display 'help' text must do so correctly when activated.".
Comment 1 Kamil Páral 2022-08-17 07:24:33 UTC 
Confirmed with Fedora-Workstation-Live-x86_64-37-20220814.n.0.iso
Comment 2 Lukas Ruzicka 2022-08-17 14:08:33 UTC 
On Silverblue Rawhide (20220816), this is also happening to all tested applications in openQA, see

https://openqa.stg.fedoraproject.org/tests/1972844#step/help/2
https://openqa.stg.fedoraproject.org/tests/1972840#step/help/3
https://openqa.stg.fedoraproject.org/tests/1972842#step/show_help/2
Comment 3 Adam Williamson 2022-08-17 15:23:55 UTC 
The similar Silverblue problem has existed for longer, so I'm not sure it's the same problem. That one is reported at https://github.com/fedora-silverblue/issue-tracker/issues/305 .
Comment 4 Michael Catanzaro 2022-08-22 13:40:33 UTC 
Hmmmm. It's a little hard to decide what to do with this ticket. On the one hand, running GTK apps as root is not a good idea and not something we'd ordinarily spend time investigating. On the other hand, this is how anaconda has always worked, and that's hardly simple to change. But running WebKitGTK as root is super not a good idea, and that's probably where we can draw a clear red line. Don't run web engines as root, right? This will probably break in other ways in the future, e.g. when the sandbox becomes mandatory it will probably crash when trying to use bwrap. And if not, we should probably add an explicit check to crash if run as root. So anaconda really needs to not do this.

All that said, none of that changes the fact that it shouldn't crash in this particular way with an X11 error. There's no way to pretend that is not a bug. If you get a backtrace with GDK_SYNCHRONIZE, then we can report a bug upstream. That said, X11-specific issues are already low priority, and issues that occur only when run as root are probably lowest imaginable priority, so "don't do that" is probably a safe path forward here. We could assign this to WebKitGTK to fix the crash, but it's probably more helpful to move this to anaconda to figure out how to avoid running yelp as root, so let's do that.
Comment 5 Adam Williamson 2022-08-22 15:54:54 UTC 
+5 in https://pagure.io/fedora-qa/blocker-review/issue/855 , marking accepted.
Comment 6 Adam Williamson 2022-08-22 15:55:58 UTC 
Wait, wait <record skip> - are you saying we're on *X.org* here? We *shouldn't* be. The default is Wayland and openQA should use the default. We aren't explicitly testing X.org or something.

I wonder if that's why this "suddenly broke"? Are live images hitting the X.org fallback path? I'll have to look into it.
Comment 7 Michael Catanzaro 2022-08-22 16:15:12 UTC 
Yes, you can see it died to an X window system error. (To investigate it, we'd need a backtrace with GDK_SYNCHRONIZE=1, like the error message says.)
Comment 8 Adam Williamson 2022-08-22 17:02:50 UTC 
I never remember if we get those errors only when running on an actual X server, or if we also get them for XWayland. Anyhow, I'll look into it.
Comment 9 Michael Catanzaro 2022-08-22 17:39:11 UTC 
Both! These errors can come from XWayland because XWayland is an X server.
Comment 10 Adam Williamson 2022-08-22 17:53:12 UTC 
Okay.

BTW, the problem with telling anaconda "don't do that" is that it will probably get dumped in anaconda's "we're rewriting the UI anyway" bucket, i.e. they're not going to want to put a lot of effort into changing how the current UI works, so if "don't do that" turns out to involve major surgery, it may not happen.

I'll try and get a better backtrace soon.
Comment 11 Michael Catanzaro 2022-08-22 18:00:15 UTC 
(This would actually be a good thing to keep in mind when rewriting the anaconda UI. The cockpit process must NOT run as root, or it will break in the future at a maximally-inconvenient time.)
Comment 12 Adam Williamson 2022-08-23 05:39:23 UTC 
Sigh. Fun thing: testing this again right now, I can sure reproduce it from within anaconda, but not running the same command at a console, with or without GDK_SYNCHRONIZE , it works fine. :|
Comment 13 Vladimír Slávik 2022-08-31 15:03:59 UTC 
Fix PR: https://github.com/rhinstaller/anaconda/pull/4302

It's a shame running yelp under "games" did not work, that account seems to be everywhere.
Comment 14 Adam Williamson 2022-08-31 16:28:28 UTC 
Also proposing as a Beta FE, obviously it would be good to fix this for Beta.
Comment 15 Adam Williamson 2022-08-31 16:32:18 UTC 
+3 Beta FE in https://pagure.io/fedora-qa/blocker-review/issue/855 , marking accepted.
Comment 16 Fedora Update System 2022-09-01 16:12:22 UTC 
FEDORA-2022-6d44eb9c78 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-6d44eb9c78
Comment 17 Fedora Update System 2022-09-02 08:27:26 UTC 
FEDORA-2022-6d44eb9c78 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-6d44eb9c78`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-6d44eb9c78

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 18 Adam Williamson 2022-09-02 17:41:18 UTC 
Fix confirmed here, if someone else can karma the update that'd be great.
Comment 19 Fedora Update System 2022-09-02 22:27:42 UTC 
FEDORA-2022-6d44eb9c78 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.
Comment 20 Adam Williamson 2022-09-04 16:04:56 UTC 
Still seems to be a problem on KDE :| I'll look into it and probably file a new bug.
Comment 21 Adam Williamson 2022-09-04 17:22:42 UTC 
Filed https://bugzilla.redhat.com/show_bug.cgi?id=2124097 .
Comment 22 Adam Williamson 2022-11-08 21:05:34 UTC 
We're now seeing something similar for traditional installer images with mutter 43.1 - https://bugzilla.redhat.com/show_bug.cgi?id=2141124 .
Note You need to log in before you can comment on or make changes to this bug.