I recently installed CentOS 6.2 on my development server and it was running fine up until today when I tried looking for a package via the yum command line:

# yum search host

Error: file is encrypted or is not a database

The error message did not get any more descriptive even after enabling debug output and increasing verbosity. I managed to figure out which repo / file was causing the error after debugging the yum python scripts.

On my system, the file that was causing the error was from the EPEL repository located in /var/cache/yum/i386/6/epel/gen/pkgtags.sqlite. I checked copies on a few different mirrors, and the contents were the same as the source http://dl.fedoraproject.org/pub/epel/6/i386/repodata/pkgtags.sqlite.gz.

Here’s what the file contained:

# cat /var/cache/yum/i386/6/epel/gen/pkgtags.sqlite

<?xml version=”1.0″ encoding=”utf-8″?>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
<title>503 Service Unavailable</title>
<h1>Error 503 Service Unavailable</h1>
<p>Service Unavailable</p>
<h3>Guru Meditation:</h3>
<p>XID: 1920246608</p>
<p>Varnish cache server</p>

Seems that the repository server was having some issues. I reported it to #centos, #epel, #fedora, #fedora-admin at irc.freenode.net, so one of the admins should fix it soon hopefully.

Anyhow I hope this explanation helps anyone else trying to figure out the same error message.

It would be nice if yum was more descriptive with its errors and indicated which repo / file was causing the issue to save people scratching their heads figuring out where the problem is.

If this happens to you, you can disable the corrupt repo by using yum –disablerepo=epel. Replace “epel” with the repo you wish to disable.

For those that wish to figure out which repo/file is causing the above error message, edit the file /usr/lib/python2.6/site-packages/yum/pkgtag_db.py (requires root privileges). Insert “print repoid, sqlite_file” at line 50.

def __init__(self, repoid, sqlite_file):

print repoid, sqlite_file

When you run “yum search package”, you’ll now see:

# yum search host
Loaded plugins: fastestmirror, presto, priorities
Loading mirror speeds from cached hostfile
* base: mirror.primusdatacentre.com.au
* centosplus: mirror.primusdatacentre.com.au
* epel: ucmirror.canterbury.ac.nz
* epel-source: mirror.optus.net
* extras: mirror.primusdatacentre.com.au
* updates: mirror.primusdatacentre.com.au
85 packages excluded due to repository priority protections
epel /var/cache/yum/i386/6/epel/gen/pkgtags.sqlite
Error: file is encrypted or is not a database

VN:F [1.9.22_1171]
Rating: 10.0/10 (1 vote cast)
VN:F [1.9.22_1171]
Rating: +1 (from 1 vote)
Why 'yum search' returns "Error: file is encrypted or is not a database" [CentOS 6.2], 10.0 out of 10 based on 1 rating

This entry was posted on Thursday, February 9th, 2012 at 7:12 pm and is filed under Troubleshooting Errors. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

2 Responses to “Why ‘yum search’ returns “Error: file is encrypted or is not a database” [CentOS 6.2]”

  1. Michał / Pierwszywgoogle on February 9th, 2012 at 8:05 pm

    Thanks for this post it saves me lot of time waste on debuging this issue – now it looks like EPEL is fixed.


    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  2. Luke Macken on February 10th, 2012 at 3:14 am

    Bodhi, the tool that pushes updates for Fedora & EPEL, downloads the ‘pkgtags.sqlite’ from the PackageDB and injects them into the yum repodata. It looks like we had a PackageDB outage, and bodhi ended up injected the 503 error page instead.

    I went ahead and fixed this issue so that in the future if it has trouble fetching the tags, it just skips that step.


    VA:F [1.9.22_1171]
    Rating: 5.0/5 (1 vote cast)
    VA:F [1.9.22_1171]
    Rating: +1 (from 1 vote)

Leave a Reply