Bug 5514 - package installer on RHEL/CentOS 6 fails
Summary: package installer on RHEL/CentOS 6 fails
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Server Installer (show other bugs)
Target Milestone: 4.5.0
Assignee: Pierre Ossman
Keywords: hean01_tester, relnotes
Depends on:
Reported: 2015-04-29 11:50 CEST by Aaron Sowry
Modified: 2015-09-25 13:59 CEST (History)
2 users (show)

See Also:
Acceptance Criteria:


Description Aaron Sowry cendio 2015-04-29 11:50:10 CEST
Seems to be reliably reproducable using the following steps:

1) Install a virtual machine with CentOS 6.6 "minimal"
2) yum upgrade
3) Unzip ThinLinc 4.3.0 on the machine and run install-server

ThinLinc itself installs fine, as does the first set of dependency packages (LSB). On reaching the second set however, installation fails with this in the logs:

2015-04-29 13:40:38,265:   failed to install packages with reason: database is locked

All subsequent attempts by tl-setup to install packages will also fail. Restarting tl-setup will succeed in installing the first package(s), but then fail again on the second.
Comment 1 Pierre Ossman cendio 2015-04-30 10:36:43 CEST
Happens with the nightly build as well. Running it in GUI mode has the same effect.
Comment 2 Pierre Ossman cendio 2015-04-30 11:00:47 CEST
It breaks on a proper RHEL 6 as well. And a minimal install is not required. I had a fully standard desktop RHEL 6 and removed the LSB packages and nfs-utils. This is sufficient to trigger the problem.

This might be a bug in RHEL rather than in ThinLinc since it is the RPM database lock that's screwed up, not the yum lock. It will require more investigation.
Comment 3 Peter Åstrand cendio 2015-08-25 09:44:22 CEST
Possibly related:


Or, it might be that PackageKit is starting to work after we have installed some packages?
Comment 4 Pierre Ossman cendio 2015-09-16 11:21:33 CEST
The full traceback:

Traceback (most recent call last):
  File "/opt/thinlinc/modules/thinlinc/packageinstaller/yumbackend.py", line 245, in install
    self . __yum . processTransaction ( callback = self . __yum_process_callback , rpmDisplay = self . __yum_rpm_callback )
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 5042, in processTransaction
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 5156, in _doTransaction
    self.runTransaction( cb=cb )
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 1514, in runTransaction
    lastdbv = self.history.last()
  File "/usr/lib/python2.6/site-packages/yum/history.py", line 1266, in last
    ret = self.old([], 1, complete_transactions_only)
  File "/usr/lib/python2.6/site-packages/yum/history.py", line 1215, in old
    executeSQL(cur, sql, params)
  File "/usr/lib/python2.6/site-packages/yum/sqlutils.py", line 166, in executeSQLQmark
    return cursor.execute(query)
Comment 5 Pierre Ossman cendio 2015-09-16 14:00:03 CEST
The problem is that we are not closing all the RPM/yum stuff properly after a completed run. There are lots of stuff open, and it is crashing specifically on this:

lrwx------. 1 root root 64 Sep 16 13:54 35 -> /var/lib/yum/history/history-2010-11-11.sqlite

If I do the same thing on RHEL 7, then everything RPM and yum related is closed after clicking next on the last step.

Might still be a bug in RHEL 6 though as our code obviously works fine on RHEL 7.
Comment 6 Pierre Ossman cendio 2015-09-16 15:18:06 CEST
Urgh. yum manages to get itself into some convoluted cyclic dependency that Python cannot break. You can see this by doing gc.collect() and inspecting gc.garbage. Most definitely a bug in RHEL somewhere.

Fortunately there is a workaround. Calling close() and closeRpmDB() breaks the cycle.
Comment 8 Henrik Andersson cendio 2015-09-17 14:07:59 CEST
Reproduced the main problem installing 4.4.0 on rhel6 without nfs-utils and python-ldap. Were installation of python-ldap fails.

Upgraded to 4.4.0 build 4889, uninstalled nfs-utils and python-ldap, rerun tl-setup and verified that the package installation went trough as expected.

All good, closing.

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