Bug 699041

Summary: Yum update fails with traceback: sqlite3.OperationalError: no such table: trans_beg
Product: [Fedora] Fedora Reporter: Bryan Bishop <bryanjbishop>
Component: yumAssignee: Seth Vidal <skvidal>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 14CC: ffesti, james.antill, maxamillion, pmatilai, tla
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-04-26 15:51:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Output from the "yum -v --noplugins update" command none

Description Bryan Bishop 2011-04-22 18:55:49 UTC 
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!
Comment 1 James Antill 2011-04-26 14:08:50 UTC 
Can you run:

ls -l /var/lib/yum/history

...as root?
Comment 2 Bryan Bishop 2011-04-26 14:15:11 UTC 
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
Comment 3 James Antill 2011-04-26 15:51:01 UTC 
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.