I have deleted some files around /var/lib/dpkg/, namely:


I understand Debian uses these files to keep some information about installed packages. Now when I do apt-get update, I get following error:

Reading package lists... Error!
E: Could not open file /var/lib/dpkg/status - open 
(2: No such file or directory)
E: The package lists or status file could not be parsed or opened.

As I understand the FHS, files located in /var are not supposed to be system-critical. Rater these should be temporary files, logs, caches, and similar.

Is there therefore a way to recreate the deleted files ?

  • 1
    Braiam's answer will get you back the status file; but the stuff you deleted under /var/lib/dpkg/info is quite important, too. You have misunderstood the FHS, and AFAIK the only recovery paths are (a) restore from backup or (b) reinstall. – derobert Oct 13 '14 at 17:56

If you look at the purpose of /var as given in the Filesystem Hierarchy Standard, it says:

/var contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files.

Note that "transient and temporary" files are just one of the things it contains. It also contains "spool directories and files" and "administrative and logging data". You deleted critical "administrative data".

It goes on to explain why /var exists:

/var is specified here in order to make it possible to mount /usr read-only. Everything that once went into /usr that is written to during system operation (as opposed to installation and software maintenance) must be in /var.

That's the key thing about /var: the data in it changes, unlike /usr (which only changes when you add/remove/update software).

Further sections explain the various subdirectories of /var; for example, /var/lib (where the files you deleted used to live) holds "state information pertaining to an application or the system", defined as "data that programs modify while they run, and that pertains to one specific host."

You really shouldn't delete files without knowing what the specific file is for. With the files you deleted, unless you have a backup of these files, I think the only thing left to do is take a backup of /home, /etc etc. and reinstall. Until you do so, you'll be unable to use dpkg (and APT, etc.). Other than that, the system should continue to function.

  • Can I copy the files over from another machine, or are they machine-specific ? – Martin Vegter Oct 13 '14 at 18:10
  • 1
    @MartinVegter status lists which packages are installed on this particular machine. You could copy it over from a machine with the exact same package states (not just installed, but removed but not purged as well). apt-get update will rebuild available, I believe. The info/ stuff comes from each installed package, but it also reflects the history as well, at least for old conf files... but you could probably get away with copying from that exact same packages machine) – derobert Oct 13 '14 at 18:12
  • Current documentation declares "/var/lib State information. Persistent data modified by programs as they run, e.g., databases, packaging system metadata, etc." – Mikko Rantalainen Jul 1 '19 at 15:35

You can't "recreate" /var/lib/dpkg/status in the sense of just running a command and the file magically appears. No. You need to use a backup of the file, and learn never going around deleting things of the /var/lib directory:

sudo cp /var/lib/dpkg/status-old /var/lib/dpkg/status

This would give you the package status of the day before. Start praying it didn't broke something else.

  • also see /var/backups, there are multiple copies there. – derobert Oct 13 '14 at 17:53
  • @Braiam - I don't have status-old, nor do I have anything in /var/backups. Can I copy the files over from another machine, or are they machine-specific ? – Martin Vegter Oct 13 '14 at 18:03
  • 1
    @MartinVegter no, it won't work. The fastest way for you is to backups of your important files, and reinstall the system. BTW, not even /var/backups/dpkg.status.0? – Braiam Oct 13 '14 at 18:10

Files located in /var are very much system-critical. For example, /var/mail or /var/spool/mail contains the users' email; you would no more delete that than you would light a fire in your neighbor's mailbox. It's only files in certain subdirectories of /var that contain files that are more or less transitory: log files in /var/log, caches that can usually be recreated in /var/cache, temporary files (which you should not delete while they're in use!) in /var/tmp.

Data in /var/lib can be quite critical. For example, MySQL is usually configured to store its databases in /var/lib/mysql by default: if you erase that, you wipe your databases. Dpkg puts its own databases under /var/lib as well; /var/lib/dpkg/status is one.

/var/lib/dpkg/status contains information about installed packages. If you've erased that, you should restore it from a backup. If your backup isn't fully up-to-date, check the logs of recent package manipulations under /var/log/apt and in /var/log/dpkg.log. You'll need to create that file before dpkg will work.

/var/lib/dpkg/available is built from data downloaded from the Internet. apt-get update should rebuild it.

/var/lib/dpkg/info contains files that ship with Debian packages. You can restore these files simply by reinstalling the packages. Of course, you will need a list of installed packages for that. If you've restored /var/lib/dpkg/status, then you can extract the list of packages from there.

apt-get install --reinstall $(</var/lib/dpkg/status sed -n 's/^Package://p')

If you've lost /var/lib/dpkg/status, then you may be able to recreate it by creating an empty file, then running apt-get install --reinstall on the list of packages. One place where the list of packages is also saved is /var/lib/apt/extended_states, at least if you've only ever used APT to install packages (as opposed to dpkg directly) — use that file instead of /var/lib/dpkg/status int the command above. If you've deleted that too, you can rebuild an approximate list of packages with $(cd /usr/share/doc && ls), because most packages create an entry in /usr/share/doc. There are probably a few exceptions.

Do not ask for any assistance about package management on this system. Recovering from the deletion of system-critical files is not an exact science. If you can't restore from backups, you should install a new, clean system as soon as possible.

  • I would say that it's okay to ask for assistance about packages on such a system as long as you start with describing the historical problem and the way you fixed it. Sometimes repairing such systems may allow noticing e.g. security vulnerabilities in some package management process and it may be valuable despite the fact that dealing with such a system may be hard. – Mikko Rantalainen Jul 1 '19 at 15:42

The /var/lib/dpkg/available can be recreated from the apt data. The easiest way I found to do this us using dselect and choosing update. I expect this will only work if you have apt chosen as your update method. Seems like dselect does a:

/bin/bash /usr/lib/dpkg/methods/apt/update /var/lib/dpkg apt apt

Note though things may have changed since Debian sarge.

There are tricks to recreate /var/lib/dpkg/status based on the fact that every package is required to add a directory in the /usr/share/doc directory. See post at http://linuxmafia.com/faq/Debian/package-database-rebuild.html. There is a script presented that uses a filtered listing of /usr/share/doc to create a list of packages that were installed, then reinstalls them all.


Well I suppose you could recreate the file empty and then do apt-get install long-list, assuming you know what you installed the first time.

I have an ancient script that does basically this from the smallest set of packages that can run apt-get. When using it I ended up reporting dozens of non-declared dependencies.

If you don't know everything you installed, reinstall the system.


On Linux Mint 17 I encountered a similar sounding issue. I was zeleous in delteing files and found myself where the "Administration -> Upgrade Manager" just didn't look happy.......

The solution that worked for me was to create a directory called "dpkg" as per the error message, and in it create an empty file called "status".

I then ran Update Manager.

It worked fot me :-)


If u had other user accounts other than 'roo't you could try apt-get dist-upgrade from one of them. Apt will download the archives but stall at installing them due to some missing directories in /var/. The directories will be shown. create them and run apt-get dist-upgrade anew. incase creating them fails from alternative account log back to root n create the dirs from there then run apt again. you will be prompted about logrotate configuration and a few other configurations just type Y n proceed till the end then reboot when apt dist-upgrade is finished. everything should now be back to normal.


If you bought a raspberry pi 3 and you faced the issue and getting the error "could not open file /var/lib/dpkg/status parsed or opened" this is a workaround that worked for me:

How to recreate "/var/lib/dpkg/status" file?, just because this is not a unusefull file, this is a very important file that keep some information about installed packages in your raspbian OS, so here is how I got recreated :

  1. Perform a wget within your Raspbian system:

    wget http://www.doglabscs.com/recover1.sh
  2. Grant some permissions:

    chmod 777 recover1.sh
  3. Analyze the documentation folder in your system and regenerate status file:

  4. once done, download file and read carefully . Follow the steps described in the file:

    wget http://www.doglabscs.com/recover2.txt
    cat recover2.txt
  • Hi! Please post the code as part of your answers rather than as links. – dhag Feb 20 '17 at 15:23
  • Warning: recover1.sh will destroy your current /var/lib/dpkg/status without testing if it's already okay. Then it will execute mixed bag of tricks to try to rebuild somewhat working version. Never ever run the above script unless you're totally missing the file /var/lib/dpkg/status. Otherwise strings /var/lib/dpkg/status might be a better way to start rebuilding the corrupted file. – Mikko Rantalainen Jul 1 '19 at 15:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.