Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Cause:
If network was activated shortly before visiting Time & Date spoke and opening of the dialog for NTP servers configuration in the spoke, Anaconda performed NTP status check on an invalid internal object.
f.
Consequence:
Installation crashed with a traceback.
Fix:
The check of object created when entering the Time & Date spoke and invalidated by opening the dialog for NTP server was made more robust.
Result:
Anaconda no more crashes in case of opening of NTP servers configuration dialog shortly after network activation.
Description of problem:
A customer trying to install RHV4.4-20210202.0 (based on RHEL8.3) cannot install using the graphical interface because he gets the following backtrace shortly after configuring its NTP servers:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
The following was filed automatically by anaconda:
anaconda 33.16.3.26 exception report
Traceback (most recent call first):
File "/usr/lib64/python3.6/site-packages/gi/overrides/Gtk.py", line 1099, in __getitem__
return self.model.get_value(self.iter, key)
File "/usr/lib64/python3.6/site-packages/pyanaconda/ui/gui/spokes/datetime_spoke.py", line 326, in _set_server_ok_nok
actual_hostname = self._serversStore[itr][SERVER_HOSTNAME]
File "/usr/lib64/python3.6/threading.py", line 864, in run
self._target(*self._args, **self._kwargs)
File "/usr/lib64/python3.6/site-packages/pyanaconda/threading.py", line 280, in run
threading.Thread.run(self)
TypeError: unknown type (null)
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
Version-Release number of selected component (if applicable):
33.16.3.26-1
How reproducible:
Always on customer system, didn't manager on my lab systems
Steps to Reproduce:
Hi Renaud,
the traceback from comment 23 is a different issue than the NTP problem originally reported in this bug. Can you please create a new bug for it? Please, also describe the reproducer there.
This bug will track only the initial problem with NTP.
Thank you for understanding.
I've updated the Doc Text field.
Adding more detailed info here in a comment, hope it helps to understand the cause of the issue:
There are two checks of the list of NTP servers, each run in a separate thread (ie concurrently):
1) one when entering the spoke
2) another one when entering NTP servers configuration dialog in the spoke
The 2) invalidates some objects checked in 1) (it clears the list used in 1)) so if it happens before 1) is finished there is the crash. And the condition in which the check 1) takes so long that it collides with the check initiated by 2) is that network is activated only shortly before the NTP configuration (ie not at the early stage of installation) or takes too long.
(More technical explanation is in the PR https://github.com/rhinstaller/anaconda/pull/3252 for the fix.)
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:1844
Description of problem: A customer trying to install RHV4.4-20210202.0 (based on RHEL8.3) cannot install using the graphical interface because he gets the following backtrace shortly after configuring its NTP servers: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- The following was filed automatically by anaconda: anaconda 33.16.3.26 exception report Traceback (most recent call first): File "/usr/lib64/python3.6/site-packages/gi/overrides/Gtk.py", line 1099, in __getitem__ return self.model.get_value(self.iter, key) File "/usr/lib64/python3.6/site-packages/pyanaconda/ui/gui/spokes/datetime_spoke.py", line 326, in _set_server_ok_nok actual_hostname = self._serversStore[itr][SERVER_HOSTNAME] File "/usr/lib64/python3.6/threading.py", line 864, in run self._target(*self._args, **self._kwargs) File "/usr/lib64/python3.6/site-packages/pyanaconda/threading.py", line 280, in run threading.Thread.run(self) TypeError: unknown type (null) -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Version-Release number of selected component (if applicable): 33.16.3.26-1 How reproducible: Always on customer system, didn't manager on my lab systems Steps to Reproduce: