Bug 730857 - Traceback when installing a package at the end of anaconda installation
Summary: Traceback when installing a package at the end of anaconda installation
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 16
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Chris Lumens
QA Contact: Fedora Extras Quality Assurance
Whiteboard: https://fedoraproject.org/wiki/Common...
: 735446 (view as bug list)
Depends On:
Blocks: F16Beta, F16BetaBlocker 1422147
TreeView+ depends on / blocked
Reported: 2011-08-16 00:32 UTC by Adam Williamson
Modified: 2017-02-14 15:18 UTC (History)
11 users (show)

Fixed In Version: anaconda-16.16-1.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1422147 (view as bug list)
Last Closed: 2011-08-31 02:31:30 UTC
Type: ---

Attachments (Terms of Use)

Description Adam Williamson 2011-08-16 00:32:06 UTC
There's a bug observed in RHEL testing which we assume to be present in Fedora 16 as well.

"When installing packages in "%post" section of kickstart installation or
manually in chroot before restarting the installation, yum throws a traceback:

Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in <module>
    yummain.user_main(sys.argv[1:], exit_code=True)
  File "/usr/share/yum-cli/yummain.py", line 276, in user_main
    errcode = main(args)
  File "/usr/share/yum-cli/yummain.py", line 211, in main
    return_code = base.doTransaction()
  File "/usr/share/yum-cli/cli.py", line 586, in doTransaction
    resultobject = self.runTransaction(cb=cb)
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 1436, in
    lastdbv = self.history.last()
  File "/usr/lib/python2.6/site-packages/yum/history.py", line 1259, in last
    ret = self.old([], 1, complete_transactions_only)
  File "/usr/lib/python2.6/site-packages/yum/history.py", line 1208, in old
    executeSQL(cur, sql, params)
  File "/usr/lib/python2.6/site-packages/yum/sqlutils.py", line 166, in
    return cursor.execute(query)
sqlite3.OperationalError: database is locked"

"Looking through the patches changed from -17 to -18 I see this which feels
completely dead on:

-- a/yum/history.py
+++ b/yum/history.py
@@ -627,6 +627,14 @@ class YumHistory:
                 self.conf.readable = False
                 return None

+            #  Note that this is required due to changing the history DB in
+            # callback for removed txmbrs ... which happens inside the chroot,
+            # as against all our other access which is outside the chroot. So
+            # we need sqlite to not open the journal.
+            #  In theory this sucks, as history could be shared. In reality
+            # it's deep yum stuff and there should only be one yum.
+            executeSQL(self._conn.cursor(), "PRAGMA locking_mode = EXCLUSIVE")
         return self._conn.cursor()
     def _commit(self):

Since at the point in the anaconda run you have 2 yums (sorta) one inside
anaconda and the one you're execing in %post."

This is a significant issue for kickstart installs. Proposing as Beta blocker (to feed into the discussion we need to have on kickstart criteria) and marking as CommonBugs.

Comment 1 Panu Matilainen 2011-08-16 06:52:29 UTC
The exclusive sqlite access mode is largely a hack to deal with chroot issues, but me thinks this is a case of it simply exposing a flaw in the way things have been done so far: there shouldn't be two yum instances running on the same system, and this should be dealt with in anaconda by fully shutting down its internal yum instance before entering %post (it doesn't need it at that point for anything).

Comment 2 seth vidal 2011-08-16 19:30:06 UTC
Agreed on the anaconda changes. The comment I made above was to deal w/the issue pre-6.2 - not to suggest that yum solve it all internally.

Comment 3 James Antill 2011-08-17 19:34:05 UTC
 Note that we already have a yb.history.close() API ... and it'll automatically do it when "freed", so unless you want us to automatically do it at the end of the transaction (kind of icky, but probably nothing breaks) ... then I guess we just need to change anaconda.

Comment 4 Fedora Update System 2011-08-30 19:51:52 UTC
anaconda-16.16-1.fc16 has been submitted as an update for Fedora 16.

Comment 5 Fedora Update System 2011-08-31 02:30:56 UTC
anaconda-16.16-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 6 Chris Lumens 2011-09-05 19:24:35 UTC
*** Bug 735446 has been marked as a duplicate of this bug. ***

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