Bug 841937 - RHEL 6 installation fails when Turkish language is selected
RHEL 6 installation fails when Turkish language is selected
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: python (Show other bugs)
Unspecified Unspecified
high Severity high
: rc
: 6.4
Assigned To: Matej Stuchlik
Jan Kepler
Depends On:
Blocks: 960065
  Show dependency treegraph
Reported: 2012-07-20 11:16 EDT by Dustin Black
Modified: 2016-01-31 21:16 EST (History)
8 users (show)

See Also:
Fixed In Version: python-2.6.6-48.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-11-21 04:13:25 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
abrt output from exception (58.76 KB, application/x-gzip)
2012-07-20 11:17 EDT, Dustin Black
no flags Details
abrt file uncompressed (393.65 KB, text/plain)
2012-07-20 13:30 EDT, Jesse Keating
no flags Details
backport of upstream fix (10.37 KB, patch)
2013-08-06 05:37 EDT, Matej Stuchlik
no flags Details | Diff

  None (edit)
Description Dustin Black 2012-07-20 11:16:00 EDT
Description of problem:
When installing RHEL 6 with the graphical installer, selecting "Turkish" as the install language will result in an exception before packages begin to install.

Version-Release number of selected component (if applicable):
Confirmed this problem on RHEL 6.1, 6.2, and 6.3

How reproducible:
Consistently when installing graphically from a RHEL 6 DVD ISO.

Steps to Reproduce:
1. Install RHEL 6.3 via the graphical installer.
2. Select "Turkish" at the "What language would you like to use during the installation process?" prompt.
3. All other settings can be default or arbitrary.
4. When the system moves on the package installation phase, it will first display a progress bar for "Starting installation process"
5. Immediately after this progress bar completes, a message window will be displayed with "An unhandled exception has occurred. This is most likely a bug. Please save a copy of the detailed exception and file a bug report."
Actual results:
Installation fails at exception report.

Expected results:
Installation should complete as expected.
Comment 1 Dustin Black 2012-07-20 11:17:04 EDT
Created attachment 599417 [details]
abrt output from exception
Comment 3 Jesse Keating 2012-07-20 13:29:25 EDT
Please do not compress text attachments.  Bugzilla cannot search through them when you do this and it makes it harder for us to read them.
Comment 4 Jesse Keating 2012-07-20 13:30:56 EDT
Created attachment 599434 [details]
abrt file uncompressed
Comment 5 James Antill 2012-07-30 15:41:41 EDT
anaconda 13.21.176 exception report
Traceback (most recent call first):
  File "/usr/lib/python2.6/site-packages/yum/sqlutils.py", line 168, in executeSQLQmark
    return cursor.execute(query, params)
  File "/usr/lib/python2.6/site-packages/yum/history.py", line 845, in trans_data_pid_beg
    VALUES (?, ?, ?)""", (self._tid, pid, state))
  File "/usr/lib/python2.6/site-packages/yum/history.py", line 935, in beg
    self.trans_data_pid_beg(pid, state)
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 1477, in runTransaction
    self.skipped_packages, rpmdb_problems, cmdline)
  File "/usr/lib/anaconda/yuminstall.py", line 1101, in _run
  File "/usr/lib/anaconda/yuminstall.py", line 1083, in run
    if self._run(instLog, cb, intf) == DISPATCH_BACK:
  File "/usr/lib/anaconda/yuminstall.py", line 1865, in doInstall
    rc = self.ayum.run(self.instLog, cb, anaconda.intf, anaconda.id)
  File "/usr/lib/anaconda/backend.py", line 242, in doInstall
    return anaconda.backend.doInstall(anaconda)
  File "/usr/lib/anaconda/dispatch.py", line 210, in moveStep
    rc = stepFunc(self.anaconda)
  File "/usr/lib/anaconda/dispatch.py", line 126, in gotoNext
  File "/usr/lib/anaconda/gui.py", line 1388, in nextClicked
  File "/usr/lib/anaconda/iw/progress_gui.py", line 79, in renderCallback
  File "/usr/lib/anaconda/gui.py", line 1409, in handleRenderCallback
IntegrityError: trans_data_pkgs.tid may not be NULL

Local variables in innermost frame:
cursor: <sqlite3.Cursor object at 0x7ff014735348>
query: INSERT INTO trans_data_pkgs
                         (tid, pkgtupid, state)
                         VALUES (?, ?, ?)
params: (None, None, 'Install')

...I don't see how this can be related to Turkish, this is just generic history code which takes the current transaction ID and the current "history pkg id" and creates a new entry for them. But both Ids are None ... which should be impossible (but if it happens should happen for every transaction).
 Moving to anaconda as I hope they have a clue what could be different.
Comment 6 Chris Lumens 2012-08-10 09:17:20 EDT
The bug report gives no indication whether or not language is the determining factor in this error appearing.  If you install in some other language, is it reproducible?
Comment 7 Dustin Black 2012-08-10 09:24:01 EDT
Indeed when you select the Turkish language, the error occurs consistently. AFAIK it's the determining factor, but I haven't tested many other languages.

It obviously does *not* happen with English, so language selection at least is a determinig factor.
Comment 8 RHEL Product and Program Management 2012-12-14 02:51:07 EST
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 10 RHEL Product and Program Management 2013-05-06 17:16:21 EDT
This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release.  Product
Management has requested further review of this request by
Red Hat Engineering, for potential inclusion in a Red Hat
Enterprise Linux release for currently deployed products.
This request is not yet committed for inclusion in a release.
Comment 16 Samantha N. Bueno 2013-07-24 09:10:36 EDT
I don't think the problem is within anaconda. None of the variables that are being passed off to yum functions contain bad values.

I'm not entirely sure what the problem is exactly, but running an English and Turkish install side by side, I found where the problem most likely lies.

The traceback notes that the sql query being run in the "trans_data_pid_beg" function is trying to pass null values: self._tid, pid, state

So "self._tid" and "pid" are None when Turkish is selected, for some reason.

In yum/history.py:
def beg(self, rpmdb_version, using_pkgs, txmbrs, skip_packages=[],
            rpmdb_problems=[], cmdline=None):
        cur = self._get_cursor()
        if cur is None:
        res = executeSQL(cur,
                         """INSERT INTO trans_beg
                            (timestamp, rpmdb_version, loginuid)
                            VALUES (?, ?, ?)""", (int(time.time()),
        self._tid = cur.lastrowid
self._tid ends up with a value of 1 for English, and None for Turkish, so there is the first variable being set to a null value.

Then a few lines further in the same function:
        for txmbr in txmbrs:
            pid   = self.pkg2pid(txmbr.po)
            state = self.txmbr2state(txmbr)
            self.trans_data_pid_beg(pid, state)

pid is getting set to None for Turkish and receives int values for English.
Comment 18 Zdeněk Pavlas 2013-07-24 09:35:48 EDT
It's a python bug.. http://bugs.python.org/issue13099
Comment 20 Matej Stuchlik 2013-08-06 05:37:35 EDT
Created attachment 783251 [details]
backport of upstream fix
Comment 23 errata-xmlrpc 2013-11-21 04:13:25 EST
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, and where to find the updated
files, follow the link below.

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


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