Removing cruft that appears as false 'dpkg -L' positives?

Dear lazyweb,

I have one very last Debian host running "testing" that I keep as a development platform. The computer in question is an aging ThinkPad 240x whose LCD cable constantly threatens to make the display content unreadable and whose non-expandable 192MB of RAM is ridiculously small by today's standard. On the plus side, this makes for a very small development host that I can easily tuck away in the closet whenever I don't need it.

However, one problem currently plagues this computer: it has been through literally years of dist-upgrades and it has accumulated TONS of cruft on its filesystem, namely files that, according to packages.debian.org, should not longer ship with the packages "dpkg" claims they belong to but, for unknown reasons, nonetheless remained on the system, probably as the result of botched upgrades whenever package X had broken maintainer scripts during the development phase before "testing" was frozen and moved to "stable".

Making a clean install from Lenny could be a nice solution, but doing so on a laptop that has no CD-ROM, whose BIOS has no support for USB boot and whose only other boot option is an external 3.5" floppy disk drive, might prove more tricky than I'd bargain for (Google "ThinkPad 240x" and you'll see how tricky I mean).

I am thus wondering if anybody would know of any tool capable of comparing files present on the filesystem with those stated as shipping with packages matching versions currently installed, according to files lists found via packages.debian.org, so that I can at least sanitize the filesystem and restore the content to a fresh Lenny install state?

9 kommenttia:

mackstann kirjoitti...

Well, one tool you can use is "cruft", which will tell you about files that the package manager doesn't think should be where they are.

himdel kirjoitti...

I'd just purge all non installed packages, get a list of installed packages (dpkg -l | grep ^ii | awk '{ print $2 }'), remove /var/lib/dpkg/info/*.files, then for each package in the list do an apt-get install --reinstall .. that should take care of cruft in dpkg -L .. and now you can just do something like "find / -xdev -type f | sort > /tmp/actualfiles.lst ; cat /var/lib/dpkg/info/*.files | sort > /tmp/pkgfiles.lst" and then you can diff it or just remove all the cruft by "diff /tmp/pkgfiles.lst /tmp/actualfiles.lst | grep ^\> | sed s/^.// | xargs rm".
But maybe I'm just crazy ;).

Josh kirjoitti...


etbe kirjoitti...


At the above URL I document how I upgraded a machine from 32bit Etch to 64bit Lenny without booting from CD etc. A similar process could be used to make a fresh install on your laptop.

Russell Coker

PS It's a pity I can't do this in English. Using Google translations for all the fields of the comment form is really painful.

bla kirjoitti...



natxete kirjoitti...

If your laptop supports it, you could install it from the network (pxe boot). I nearly always do it this way now :-): no more cd-burnings for me.

eikenberry kirjoitti...

First try purging all the removed but not purged packages. This command will get you a list of all packages that have been removed but whose config files are still on the system.

$ aptitude search "~c"

Alternatively if your laptop supports network installs you could do that. It is pretty easy. Just takes dhcp, tftp plus the netboot files. This bit of the docs covers it well.


Martin-Éric kirjoitti...

No, netboot is not supported either. Remember, this is a very old laptop.

Anti kirjoitti...

Download etherboot/gpxe floppy image, write on a floppy and boot from floppy to start etherboot/gpxe and do a pxe install.
Or add the etherboot/gpxe image to your existing grub, reboot and launch gpxe via grub and then hope you won't mess up ;)