Last week, we learned to get rid of third-party packages, now we’re going one step further: we’ll verify if the files of the installed packages are still exactly like they were when they got installed.
If you’re a tinkerer and hand-edit some files for some quick tests, or if you tend to re-install newer versions of some packages from the sources, you might have overwritten some packaged files and it would be good to be able to detect this (and remedy to the problem). debsums is the tool that makes it possible.
Use debsums to identify modified files
I often use debsums when I take over the maintenance of a Debian server because I want to verify which files have been modified by the former administrator.
Without any argument, debsums is very verbose, it will list every installed file (except configuration files) and tells whether it’s unmodified (“OK”) or not (“FAILED”).
$ sudo debsums /usr/bin/a2ps OK [...]
With the --all option, it will verify all files including configuration files. With --config it will verify only the configuration files.
With the --changed option, debsums will only list modified files among those inspected. The following invocation will thus list all files which have been modified on the system and which are not configuration files.
$ sudo debsums --changed /usr/lib/perl5/AptPkg/Config.pm /usr/lib/perl5/AptPkg.pm [...]
Find out the package affected and reinstall it
debsums told me that /usr/lib/perl5/AptPkg.pm was modified. Indeed I remember having manually installed a modified version of that perl module for a quick test.
I find out the affected package with dpkg --search /usr/lib/perl5/AptPkg.pm: it’s libapt-pkg-perl.
Now I just have to reinstall this package to overwrite the modified files with the original ones:
$ sudo aptitude reinstall libapt-pkg-perl [...] # Or with apt-get $ sudo apt-get --reinstall install libapt-pkg-perl [...]
You might have to repeat the process until debsums no longer reports any modified file.
Do you want to read more tutorials like this one? Click here to subscribe to my free newsletter, you can opt to receive future articles by email.
Hi,
please and what about:
debsums: no md5sums for binutilsis it maintainer’s problem?
Yes, it means the package doesn’t ship the “md5sums” file that debsums uses. The problem is partly resolved since recent versions of debsums generate those files on the fly while packages are installed.
Try “dpkg-reconfigure debsums” and it will ask you if you want to create them automatically with apt-get.
Thank you,
reinstalling some packages helps me, but one (dpkg installed) not. I will must to recretate it by my self 😉
or use
debsums --generate=package.debAre ‘broken packages’ an accurate definition ? … I mean, I have 286 packages listed after issuing “sudo debsums –changed” … and my install (Ubuntu 10.10 amd64 desktop edition) is running appreciably fine to me. Could the big amount of ‘broken’ packages … could be related with a big amount of external repositories appended (around 20) in order to have more up-to-date software ?
Could on the other hand be related with the fact that I don’t usually make CLEAN installs ? … I usually UPGRADE from one to another Ubuntu versions.
I try to take much care of my install but even though I have a separate /home partition I don’t like making clean installs.
Thank you and regards.
> 286 packages
Are you sure you’re not speaking of files here? Because debsums spits out files and not packages… and 286 packages with modified files would be a lot.
The fact that you upgrade from one version to the next, or the fact that you have a lot of repositories are unrelated to those modified files. Maybe you have used some tool that installs software outside of the knowledge of dpkg?
Well … first of all I am not a GNU/Linux advanced user at all so … frecuently, when I install something I don’t know for sure if dpkg is working underneath. I can assume that installing a deb package will be carried out through dpkg and I will also assume that installing from repositories will also use dpkg utility. You are right about 286 … they were files … not packages.
According to the big amount of files … well … without digging in depth (and having a quick look at the sorted file list) it looks like … well … I don’t really know what to think. Checking the installables files I have used (I usually keep installable files of applications installed apart from repositories or Synaptic) … most of them are deb packages (the exceptions: GoogleEarthLinux.bin , truecrypt-7.0a-setup-x64 without extension name at all , sopcast-player_vlc1.1x-fix.zip and veetle-0.9.17-linux-install.sh) … I can also remember Adobe Reader was installed forcing architecture due to the lack of support for amd64 architecture.
They are to many files … my install apparently works fine … broken packages ? … it’s a bit confusing …
Try “dpkg -S” on a few of the files listed… it will tell you which package is “unclean”. Just like I explained in my article.
Maybe you’ll understand better where it comes from. Possibly parts of vlc overwritten by sopcast-player or something like that.
ed , kbd , less , sysv-rc , pcmciautils , wireless-tools , libfribidi0 , pxljr , mlocate , ntfsprogs , hal , libgtkhex0 , libgpgme11 , libgphoto2-port0 , libxcb-atom1 , base-passwd , toshset , rsyslog , libv4l-0 … and GROWING …
My godness !!! Am I the one supposed to be tinkering with I don’t know what ? … I don’t even know what are these packages for …
After all my install doesn’t seem to be so healthy. Who is supposed to have been modifying these files ? … if I reinstall the growing packages … wouldn’t it interact with WHO have modified them afterwards ?
In case of reinstalling the growing packages … is there an ‘automatic’ way of detecting them ? I have been doing it manually and besides ‘hal’ and two or three more packages who had several ‘FAILED’ files … the rest was one or two ‘FAILED’ files per package … I have 286 packages here … this could take long …
Maybe you should run a memory test… so many corrupted files could also be a sign of a hardware problem: bad memory or bad hard disk or whatever…
I don’t see any legitimate use case where anyone would changes some random files in “ed” and other base packages that you listed.
But maybe those files are not so random? Can you paste the list somewhere like on http://paste.debian.net ?
In any case, I don’t think reinstalling the affected packages will hurt.
Besides the Ubuntu install I have been talking about, I have another one … installed on a USB 2.0 16GiB pendrive. This one has also two partitions / and /home where Ubuntu 10.10 i386 runs. Some fewer applications on the pendrive than on the HD install, a bit slowlier than HD install … but apparently is also running fine. After issuing ‘debsums –changed’ on the pendrive … 272 files …
If you want to have a look , both lists are at http://dl.dropbox.com/u/21975493/Ana%27s%20issue.ods
It doesn’t look like entirely random, it’s almost exclusively ELF executables and libraries. Really weird. I don’t know what happened on your computers but it’s unlikely to be a hardware problem if you have the same problem on 2 computers.
Since both installs are running fine I will leave them as they are now. Once I find out the reasons behind these anomalities I will proceed the proper way.
Raphaël … thank you for your time.
With your last comment you made me think and … I just have remembered … about a year ago, I was embedded in something like ‘performance for beginners’ in Linux and I installed and tested ‘prelink’ utility. I didn’t like the results and I uninstalled it very quickly (the installs turned unstables). I also installed ‘preload’ utility whose results were so nice (installs a bit more crisp without unstabilities) … ‘preload’ are still running on both my laptop and the pendrive.
It could have been ‘prelink’ utility … couldn’t it ?
Yes, definitely!
So the modified binaries are those that have seen no updates since you uninstalled prelink. The other have been “fixed” when you upgraded to newer versions of the corresponding packages.
Yes … well … it’s fine knowing it. I think a clean install would have fixed that … but I don’t really like clean installs.
If I have properly understood through the article and the thread … the problem will get thinner as new sw comes in … and answering a previous own question … Reinstalling will no interact with WHO (prelink) have modified the sw afterwards.
Since they are so many packages I will reinstall some manually … and the time will do the rest … ;o)
Thank you very much.
This put me on the right track AFTER doing an ill advised dist-upgrade with Ubuntu 10.04.
What solved the problem for me was:
sudo apt-get autoclean #This identified the programs that wouldn’t u[grade
theh I reinstalled them with:
sudo apt-get –reinstall install … #List the programs – or better yet, copy them from the results of the first command to replace the …