Bug 1950053

Summary: "Connect to Red Hat" button is occasionally disabled
Product: Red Hat Enterprise Linux 8 Reporter: Jan Stodola <jstodola>
Component: anacondaAssignee: Martin Kolman <mkolman>
Status: CLOSED ERRATA QA Contact: Release Test Team <release-test-team-automation>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 8.5CC: jkonecny, mkolman, pzatko, rvykydal, sbueno
Target Milestone: betaKeywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: anaconda-33.16.5.1-1.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1959383 (view as bug list) Environment:
Last Closed: 2021-11-09 18:42:11 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:    
Bug Blocks: 1879091, 1903942    
Attachments:
Description Flags
screenshot none

Description Jan Stodola 2021-04-15 16:34:37 UTC
Description of problem:
The "Connect to Red Hat" button is not always enabled after entering the main hub for the first time.
This is a race condition, since this problem appears only occasionally - reproduced once out of ~15 attempts on the same KVM VM and the same boot arguments.

After entering another spoke (storage) and returning to the main hub, the "Connect to Red Hat" button is enabled as expected.

Used "inst.stage2=http://.... inst.lang=en_US.UTF-8" boot arguments. The VM had 2.5 GB RAM, 10 CPUs, 20 GB disk with pre-installed RHEL.


Version-Release number of selected component (if applicable):
anaconda-33.16.4.15-1.el8

How reproducible:
Unclear, 1 out of ~15 attempts failed.


Steps to Reproduce:
1. Start the installation and proceed to the main hub.

Actual results:
The "Connect to Red Hat" button on the main hub is disabled.

Expected results:
The "Connect to Red Hat" button is enabled.

Comment 1 Jan Stodola 2021-04-15 16:36:52 UTC
Created attachment 1772222 [details]
screenshot

Comment 7 Martin Kolman 2021-04-15 18:57:52 UTC
This looks like yet another case of GTK (which is not thread safe) being broken by access from a non-main thread.

The Connect to Red Hat screen is initialized in a thread as it needs to wait for some other threads to finish:



    threadMgr.add(AnacondaThread(name=THREAD_SUBSCRIPTION_SPOKE_INIT,
                                 target=self._initialize))


    def _initialize(self):
        # wait for subscription thread to finish (if any)
        threadMgr.wait(THREAD_SUBSCRIPTION)
        # also wait for the payload thread, which migh still be processing
        # a CDROM source, to avoid the Subscription being mandatory by mistake
        # due to CDN still being default at the time of evaulation
        threadMgr.wait(THREAD_PAYLOAD)

        # update overall state
        # - the update methods manipulate GTK and this method is called in a non-main thread,
        #   so make sure the calls are serialized to the main thread by using the appropriate
        #   wrapper functions
        self._update_registration_state()
        self._update_subscription_state()

        # Send ready signal to main event loop
        hubQ.send_ready(self.__class__.__name__, False)

        # report that we are done
        self.initialize_done()


Once the two threads it waits on terminate, it calls the _update_registration_state() and _update_subscription_state() methods, notifies the hub and then terminates as well. Calling the two _update* methods is most likely where things go wrong, as they update methods manipulate GTK widgets while being called from a non-main thread, which can result in GTK hevaing in undefined ways. Quite likely including the spoke status not being set correctly.

This behavior would be also consistent with the spoke status being fixed by visiting a different spoke and returning to the hub - the _initialize() method tha "breaks GTK" is called ony once during Anacoonda startup and return from a spole triggers a refresh that likely puts the broken GTK back in order.

To fix the issue we need to make sure all the calls in the Coneect to Red Hat spoke _initialize() method that could interact with GTK are properly synchronized into the main thread. Thankfully, we have a set of wrapper we can use for this, making the change quite easy.

I've opened a (draft) PR thart wrappes the problematic calls:
https://github.com/rhinstaller/anaconda/pull/3293

Would it be possible to inject it to the testing environment to check if it fixes the issue ?

Comment 10 Jan Stodola 2021-05-11 12:31:40 UTC
RHEL-9 clone: bug 1959383.

Comment 16 errata-xmlrpc 2021-11-09 18:42:11 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (anaconda bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:4254