Created attachment 494293 [details] Output from the "yum -v --noplugins update" command Description of problem: When using PackageKit-qt or "yum update", the transaction fails with the following stack trace mentioning "sqlite3.OperationalError: no such table: trans_beg" Version-Release number of selected component (if applicable): Using Fedora 14, KDE 4.6.2 using 2.6.35.12-88.fc14.i686.PAE SMP kernel yum --version 3.2.28 Installed: rpm-4.8.1-5.fc14.i686 at 2010-10-21 21:01 Built : Fedora Project at 2010-08-10 07:43 Committed: Panu Matilainen <pmatilai> at 2010-08-10 Installed: yum-3.2.28-5.fc14.noarch at 2010-10-21 21:01 Built : Fedora Project at 2010-10-05 13:03 Committed: Seth Vidal <skvidal at fedoraproject.org> at 2010-10-05 Installed: yum-plugin-fastestmirror-1.1.28-1.fc14.noarch at 2011-02-28 04:46 Built : Fedora Project at 2010-08-03 16:14 Committed: Tim Lauridsen <timlau> at 2010-08-03 How reproducible: Every time since April 20th, my yum history has been lost so I can't tell for certain. I do know that I had successfully used PackageKit-qt to update my system on April 20th. See notes below about the yum package history. Steps to Reproduce: 1. yum update 2. 3. Actual results: Running Transaction 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 258, in user_main errcode = main(args) File "/usr/share/yum-cli/yummain.py", line 196, in main return_code = base.doTransaction() File "/usr/share/yum-cli/cli.py", line 544, in doTransaction resultobject = self.runTransaction(cb=cb) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1327, in runTransaction lastdbv = self.history.last() File "/usr/lib/python2.7/site-packages/yum/history.py", line 811, in last ret = self.old([], 1, complete_transactions_only) File "/usr/lib/python2.7/site-packages/yum/history.py", line 760, in old executeSQL(cur, sql, params) File "/usr/lib/python2.7/site-packages/yum/sqlutils.py", line 166, in executeSQLQmark return cursor.execute(query) sqlite3.OperationalError: no such table: trans_beg Additional info: After googling for this error message, I ended up finding a somewhat related bug report, number 562773 and a responders comments for that bug was to issue the command "yum history new" See comment: https://bugzilla.redhat.com/show_bug.cgi?id=562773#c1 After issuing "yum history new" I was able to complete the update with out error, but I had to lose my package history in the process. I am nolonger affected by the "yum update" bug after issuing the "yum history new" but wanted to report it in case others have this issue. Thanks!
Can you run: ls -l /var/lib/yum/history ...as root?
Sure, I haven't cleared my yum history since creating this bug so there is actually history in that path now. Also, I haven't run across the "no such table" error yet when doing yum updates. total 656 drwxr-xr-x. 114 root root 4096 Apr 6 11:15 2010-10-21 drwxr-xr-x. 61 root root 4096 Apr 21 11:37 2011-04-06 drwxr-xr-x. 2 root root 4096 Apr 21 11:40 2011-04-21 drwxr-xr-x. 7 root root 4096 Apr 24 21:59 2011-04-22 -rw-------. 1 root root 464896 Apr 6 11:15 history-2010-10-21.sqlite -rw-------. 1 root root 140288 Apr 21 11:37 history-2011-04-06.sqlite -rw-------. 1 root root 0 Apr 21 11:40 history-2011-04-21.sqlite -rw-------. 1 root root 29696 Apr 24 22:02 history-2011-04-22.sqlite
Ok, this is the problem: history-2011-04-21.sqlite is zero bytes in size. ...but the fact it's created makes yum think it should work. Do you know why a new history file tried to get created on the 21st of April? If you haven't done any transactions ("yum history list" is still empty). Then you can do: cd /var/lib/yum/history rm history-2011-04-21.sqlite rm history-2011-04-22.sqlite ...and you should go back to history-2011-04-06.sqlite, which will have your old history data in it.