Bug 364851 - createrepo yum sqlite3 error
createrepo yum sqlite3 error
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
7
i386 Linux
low Severity high
: ---
: ---
Assigned To: Jeremy Katz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-02 18:58 EDT by Chuck Murnane
Modified: 2014-01-21 17:59 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-12 11:29:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chuck Murnane 2007-11-02 18:58:14 EDT
Description of problem:
I maintain local repositories of Fedora 7 RPMs. After an update to the latest
versions today, I ran:
createrepo -d --update -c /data/RHdata/cache-FC7-updates-i686
/data/RHdata/yum/FC7-updates-i686
This ran without error.
I have a file in /etc/yum.repos.d named local with the following content:
[base]
name=Fedora 7 base
baseurl=file:///data/RHdata/yum/FC7-i686
enabled=1
gpgcheck=0

[updates]
name=updates
baseurl=file:///data/RHdata/yum/FC7-updates-i686
enabled=1
gpgcheck=0


Then, I ran 
yum update
but I got
yum update
Loading "merge-conf" plugin
base                      100% |=========================| 1.9 kB    00:00     
primary.sqlite.bz2        100% |=========================| 3.5 MB    00:00     
updates                   100% |=========================| 1.9 kB    00:00     
primary.sqlite.bz2        100% |=========================| 1.7 MB    00:00     
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package perl-Test-Simple.i386 0:0.62-25.fc7 set to be updated
---> Package cups-libs.i386 1:1.2.12-6.fc7 set to be updated
---> Package cups.i386 1:1.2.12-6.fc7 set to be updated
---> Package openoffice.org-testtools.i386 1:2.3.0-6.4.fc7 set to be updated
---> Package openoffice.org-calc.i386 1:2.3.0-6.4.fc7 set to be updated
---> Package openoffice.org-pyuno.i386 1:2.3.0-6.4.fc7 set to be updated
---> Package openoffice.org-writer.i386 1:2.3.0-6.4.fc7 set to be updated
---> Package openoffice.org-math.i386 1:2.3.0-6.4.fc7 set to be updated
---> Package perl-CPAN.i386 0:1.76_02-25.fc7 set to be updated
---> Package openoffice.org-emailmerge.i386 1:2.3.0-6.4.fc7 set to be updated
---> Package perl-libs.i386 4:5.8.8-25.fc7 set to be updated
---> Package perl.i386 4:5.8.8-25.fc7 set to be updated
---> Package perl-ExtUtils-Embed.i386 0:1.26-25.fc7 set to be updated
---> Package perl-ExtUtils-MakeMaker.i386 0:6.30-25.fc7 set to be updated
---> Package cups-lpd.i386 1:1.2.12-6.fc7 set to be updated
---> Package perl-devel.i386 4:5.8.8-25.fc7 set to be updated
---> Package perl-Test-Harness.i386 0:2.56-25.fc7 set to be updated
---> Package openoffice.org-base.i386 1:2.3.0-6.4.fc7 set to be updated
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in <module>
    yummain.main(sys.argv[1:])
  File "/usr/share/yum-cli/yummain.py", line 146, in main
    (result, resultmsgs) = base.buildTransaction() 
  File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 574, in
buildTransaction
    (rescode, restring) = self.resolveDeps()
  File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 713, in resolveDeps
    CheckDeps, checkinstalls, checkremoves, missing = self._resolveRequires(errors)
  File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 787, in
_resolveRequires
    thisneeds = self._checkInstall(txmbr)
  File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 832, in
_checkInstall
    provs = self.tsInfo.getProvides(*req)
  File "/usr/lib/python2.5/site-packages/yum/transactioninfo.py", line 403, in
getProvides
    result.update(self.getNewProvides(name, flag, version))
  File "/usr/lib/python2.5/site-packages/yum/transactioninfo.py", line 385, in
getNewProvides
    for pkg, hits in self.pkgSack.getProvides(name, flag, version).iteritems():
  File "/usr/lib/python2.5/site-packages/yum/packageSack.py", line 234, in
getProvides
    return self._computeAggregateDictResult("getProvides", name, flags, version)
  File "/usr/lib/python2.5/site-packages/yum/packageSack.py", line 393, in
_computeAggregateDictResult
    sackResult = apply(method, args)
  File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 511, in
getProvides
    return self._search("provides", name, flags, version)
  File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 466, in _search
    (name,))
  File "/usr/lib/python2.5/site-packages/yum/sqlutils.py", line 148, in
executeSQLQmark
    return cursor.execute(query, params)
sqlite3.DatabaseError: database disk image is malformed



Version-Release number of selected component (if applicable):
 yum list sqlite yum createrepo rpm rpm-libs
Loading "merge-conf" plugin
Installed Packages
createrepo.noarch                        0.4.10-1.fc7           installed       
rpm.i386                                 4.4.2.2-2.fc7          installed       
rpm-libs.i386                            4.4.2.2-2.fc7          installed       
sqlite.i386                              3.4.2-1.fc7            installed       
yum.noarch                               3.2.7-1.fc7            installed      

(Note: "yum list" works where "yum update" fails. I have tested "yum remove" and
it seems to work properly.)


How reproducible:
I have removed the repodata directory (and its contents) and rerun the
createrepo command, only to repeat the sad affair.

This set of scripts has worked well up until today.

Steps to Reproduce:
(see above)
1.createrepo -d --update -c /data/RHdata/cache-FC7-updates-i686
/data/RHdata/yum/FC7-updates-i686
2.yum update
3.
  
Actual results:
sqlite3.DatabaseError: database disk image is malformed


Expected results:
List of rpm packages given by yum should be applied

Additional info:

I have run this set of commands on i386, x86_64 and ppc64 systems, all with
similar results. On one set of systems, the i386 and x86_64 systems actually
worked, but on the other two sets neither the i386 nor the x86_64 systems worked
(these sets lack ppc64 systems). Looking at the data stored in the repodata
directory, the (uncompressed) xml and sqlite files are somewhat different in
size. Running 
sqlite3 filelists.sqlite .dump > filelists.dump
sqlite3 filelists.sqlite1 < filelists.dump
results in errors in some cases, but in different sized sqlite files in all
cases. (Repeat the sqlite3 sequence for all the sqlite files.)
Comment 1 Seth Vidal 2007-12-06 22:56:53 EST
What other factors are involved in this? Any nfs or other 'odd' filesystems?
Comment 2 Chuck Murnane 2007-12-07 15:32:10 EST
(In reply to comment #1)
> What other factors are involved in this? Any nfs or other 'odd' filesystems?

The directory listed as the target of the createrepo command is an NFS mounted
file system. I saw mention of sqlite not liking NFS just today, so I suppose
that will be the base cause.
Comment 3 Seth Vidal 2008-03-12 11:29:54 EDT
We can probably implement a workaround in createrepo - but there is no way for
us to fix sqlite and nfs not liking each other.

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