16

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

/var/lib/dpkg/status /var/lib/dpkg/available /var/lib/dpkg/info/*

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 ?

Improve this question
2

12 Answers 12

Reset to default
19

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.

Improve this answer
3
  • Can I copy the files over from another machine, or are they machine-specific ? Commented Oct 13, 2014 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) Commented Oct 13, 2014 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." Commented Jul 1, 2019 at 15:35
13

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.

Improve this answer
1
  • 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. Commented Jul 1, 2019 at 15:42
9

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.

Improve this answer
3
  • 2
    also see /var/backups, there are multiple copies there. Commented Oct 13, 2014 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 ? Commented Oct 13, 2014 at 18:03
  • 2
    @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? Commented Oct 13, 2014 at 18:10
7

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.

Improve this answer
4

If someone ends up nuking "/var/lib/dpkg":

sudo mkdir -p /var/lib/dpkg/updates sudo mkdir -p /var/lib/dpkg/info sudo mkdir -p /var/lib/dpkg/alternatives sudo cp /var/backups/dpkg.status.0 /var/lib/dpkg/status sudo cp /var/backups/dpkg.statoverride.0 /var/lib/dpkg/statoverride sudo cp /var/backups/dpkg.diversions.0 /var/lib/dpkg/diversions sudo cp /var/backups/dpkg.arch.0 /var/lib/dpkg/arch sudo dpkg --clear-avail sudo apt update sudo apt upgrade # If needed.
Improve this answer
1

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.

Improve this answer
1

  1. If you have a broken status file then you have to back up first:

    $ sudo mv /var/lib/dpkg/status /var/lib/dpkg/status.old

  2. Try to recover status file from /var/backups:

    $ sudo cp /var/backups/dpkg.status.0 /var/lib/dpkg/status && sudo apt update

  3. If still an error, so try next backup file:

    $ sudo gunzip -k /var/backups/dpkg.status.1.gz && sudo mv /var/backups/dpkg.status.1 /var/lib/dpkg/status && sudo apt update

  4. When apt updates without errors then you need to compare current status file with old corrupted (use strings because file has binary data):

    $ diff <(strings /var/lib/dpkg/status | grep 'Package:' | sort | uniq) <(strings /var/lib/dpkg/status.old | grep 'Package:' | sort | uniq)

  5. After that you will see difference and can reinstall packages missing in current status file to add:

    $ sudo apt install $(diff <(strings /var/lib/dpkg/status | grep 'Package:' | sort | uniq) <(strings /var/lib/dpkg/status.old | grep 'Package:' | sort | uniq) | grep '>' | awk '{ print $3 }') --reinstall

  6. Then check md5 sums of all packages, and if find such pkgs reinstall them:

    $ sudo debsums -s

Improve this answer
0

Sorry for the delay. Briam, re-create the dirs and files manually and then update repos (mkdir and touch, as required by the displayed error), and use dpkg --configure -a.

Your system would run fine, but it is important to reinstall to make sure that it is not corrupted; previous is only to gain time to schedule a reinstallation... and take care of delete /var/lib/* files.

Improve this answer
0

My /var/lib/dpkg/status file got deleted and according to apt I had no packages installed, as it determines them from the status file. I used the following method to regenerate the /var/lib/dpkg/status file. The method worked very fine for me in Kali GNU/Linux, which is Debian-based.

NOTE:

  • This method assumes that all installed packages have created entries in the /usr/share/doc directory.

  • This method starts from an empty /var/lib/dpkg/status file.

  • This method may not work if you have more than 1 repository providing the same package. If you do have more than 1 repository providing the same package, temporarily disable the subsidiary repo, then delete the package cache lists for the repo in /var/lib/apt/lists/.

  1. Delete the current status and status-old files. Make a backup of the files before deletion incase you get errors.

    mkdir ~/dpkg-status-backup cp /var/lib/dpkg/{status,status-old} ~/dpkg-status-backup rm /var/lib/dpkg/{status,status-old}

  2. Get list of all packages installed, one package per line.  Note: it's 1 (one) not l (lower-case L).

    ls -1 /usr/share/doc > installed-packages.list

  3. Rewrite the packages list into one line.

    tr '\n' ' ' < installed-packages.list > installed-packages-one-line.list

  4. Create an empty status file to enable apt-cache to run.

    touch /var/lib/dpkg/status

  5. Generate package records using apt-cache.

    cat installed-packages-one-line.list | xargs apt-cache show > raw-status-file

  6. The raw-status-file may contain Status: fields for some packages. Delete them to avoid duplication.

    sed -i '/^Status:/d' raw-status-file

  7. Add the Status: field for every package to indicate to apt & dpkg that they're installed.

    sed -i 's/^Package:.*/&\nStatus: install ok installed/' raw-status-file

  8. Remove fields unwanted by dpkg in status file: SHA1:, SHA256:, MD5sum:, Description-md5:, Size: & Filename: .

    sed -i '/^MD5sum:/d' raw-status-file sed -i '/^SHA1:/d' raw-status-file sed -i '/^SHA256:/d' raw-status-file sed -i '/^Size:/d' raw-status-file sed -i '/^Filename:/d' raw-status-file sed -i '/^Description-md5:/d' raw-status-file

  9. The resultant raw-status-file after running the above commands is now the actual dpkg status file.

    mv raw-status-file status

  10. Copy the status file to /var/lib/dpkg/ as status and status-old.

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

  11. Now run dpkg to validate your new status file. If you get errors, take hints from dpkg's error report, & solve accordingly. If you get no errors, then the status file has the correct syntax.

    dpkg --get-selections

  12. Re-enable the disabled repos then run apt to update package cache lists to prevent the error packages have unmet dependencies.

    apt update

  13. If you run into packages have unmet dependencies error in apt, then make sure you've enabled the subsidiary repos that provide the dependencies, then run aptitude. I prefer aptitude because it's better at solving package installation errors.

    aptitude full-upgrade

If you get no errors/your errors have been resolved from apt or dpkg, and get "PACKAGE is already the newest version..." when you try to install a program you're sure is already installed, such as coreutils, then you've successfully regenerated the dpkg status file.

Clean-up the temp files created and the backup.

rm installed-packages.list installed-packages-one-line.list status rm -r ~/dpkg-status-backup
Improve this answer
1
  • BTW, if you redirect the output of ls (into a file or pipe), the -1 option is implied automatically. Commented Jul 15, 2022 at 18:00
-1

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 :-)

Improve this answer
1
  • this will make dpkg think that there are zero packages installed on the system. that means that Update Manager will run, but it will never, ever show updates for the packages already on your machine unless you install new packages or reinstall what's there. do not do this, it will cause your machine to become more and more insecure as you miss more and more security fixes. Commented Sep 30, 2021 at 21:39
-2

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.

Improve this answer
1
  • downvoted because this answer does not appear to understand the problem (apt-get dist-upgrade does not, under almost any circumstances, work as a non-root user) and because it will not result in the system getting "back to normal". Commented Sep 30, 2021 at 21:42
-3

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:

    ./recover1.sh

  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
Improve this answer
2
  • Hi! Please post the code as part of your answers rather than as links. Commented Feb 20, 2017 at 15:23
  • 1
    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. Commented Jul 1, 2019 at 15:48

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.