Re: How to make an upgraded system clean by automatically removing abandoned config files?

Drew Engelbrecht wrote:
I've noticed some abandoned configuration files have been left lying around
my harddrive, which by their existence have a (sometimes negative) effect on
my upgraded system. They were installed by packages in lenny, but would not
be installed in a fresh installation of squeeze. Despite unmodified
configuration files getting replaced by newer ones when upgrading, it seems
that if they don't belong to the same package in squeeze as in lenny, then
they are not removed... even though that file may be unmodified from the
original (and now useless or even harmful.)

I think this is a prime opportunity for people upgrading to help
Debian and to chase down some of those and to file bugs against those
packages. Because you are absolutely right that some of those are
causing terrible problems. But mostly they are not known and
therefore not tracked in the BTS. If we can get those diagnosed and
bugs filed then some progress can be made at improving the situation.

For example, there's the /etc/X11/xorg.conf file that dpkg-reconfigure
doesn't change or remove in squeeze (and doesn't add, if there's not one
there.)

Some things are going to be problematic. This is one of those.
Because in that case any local configuration from the admin would be
lost if that file were automatically removed. A working installation
that required tweaks would be broken. Many people would have the
opposite complaint in that case. This is likely an impossible no-win
situation.

I didn't look in the upgrade notes to see if this one was mentioned.
But I have a memory that it was mentioned there.

Also, there was a file in /etc/udev/rules.d/ for wacom input. Something like
50 errors would show up when I booted, because of this file.

This one has a bug filed against it. People migrating from Lenny to
Squeeze may (probably will?) hit it. I hit it.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565126

But there hasn't been any movement on it that I can see. An NMU from
a DD would be appropriate.

I noticed that using the "loate" command for the xserver-xorg-input-wacom
package listed the problematic rules file, so my system knew that it was
there and associated with the package. I tried purging the wacom package and
reinstalling xserver-xorg-input-all. The file and the problem went away.

Yes. Exactly as you said. The best workaround I can suggest is to
purge the package, which will also remove the meta package that
depends upon it, and then reinstall the dependency meta package.

$ dpkg -L xserver-xorg-input-wacom | grep udev/rules.d/
/lib/udev/rules.d/69-xserver-xorg-input-wacom.rules
/etc/udev/rules.d/z60_xserver-xorg-input-wacom.rules

# apt-get remove --purge xserver-xorg-input-wacom
# apt-get install xserver-xorg-input-all

$ dpkg -L xserver-xorg-input-wacom | grep udev/rules.d/
/lib/udev/rules.d/69-xserver-xorg-input-wacom.rules

Unfortunately, I don't think that it's feasible to purge and reinstall the
entire installation base though ;-) so I'm still looking for a general
solution.

I think this conversation in debian-devel is related. Not exactly.
But it is looking at a similar problem space.

http://lists.debian.org/debian-devel/2010/12/msg00153.html

Is there a way to remove deprecated files like these automatically?

Have you looked at packages that are removed but not purged?

dpkg -l | grep ^rc

That will identify packages that have been removed but not purged and
still have configuration files remaining behind. You could then
examine the list and purge those. That will remove the associated
configuration files. Might be a useful start.

Have you looked at removing dummy and transition packages?

dpkg -l | grep -e dummy -e transition

Cleaning those would help to keep the system tidy.

Although some people think that APT's new autoremove feature will make
deborphan obsolete I still find it useful. 'sudo orphaner' or 'sudo
orphaner -a' for the full list. (I expect many will reply that
aptitude does it better. That's nice. I like deborphan better.)
Certainly with autoremove there isn't as much to do there these days.

I'm having some minor issues with squeeze, and I can't help but
wonder if there are still some "zombie" config files that are
creating issues here by making my system less like a clean install
of squeeze.

What kinds of problems are you having?

On a first pass I would concatenate all of the known conffiles from
all installed packages. Then compare that list to the actual list of
files in /etc. Any differences would stand out. Let's see:

$ cat /var/lib/dpkg/info/*.conffiles > /tmp/conffiles.list
$ sort -o /tmp/conffiles.list /tmp/conffiles.list
$ sudo find /etc > /tmp/etc.list
$ sort -o /tmp/etc.list /tmp/etc.list
$ comm -23 /tmp/conffiles.list /tmp/etc.list | less

Hmm... There are some files listed as conffiles that don't actually
exist on my system. Something to look at more closely later. Not a
problem for the moment.

$ comm -13 /tmp/conffiles.list /tmp/etc.list | less

Oh my goodness there are a lot of untracked files! How many?

$ comm -13 /tmp/conffiles.list /tmp/etc.list | wc -l
2300

Wow. Too many to track down by that method. Will have to try
something different.

If I were really wanting to track this down on my system then I would
install a fresh copy of squeeze in a chroot.

http://wiki.debian.org/Debootstrap

http://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id292281

I would install a complete system fresh in the chroot. This means
there I no need to affect your currently installed system which can be
left in place and untouched. Then I would compare the files in the
chroot to the files in the live system. They should be the same. Any
differences can be noted and handled. The debootstrap of the chroot
will be almost the same as a freshly installed system. It didn't use
the debian-installer and so there will be some differences. But I
expect that list to be much shorter than the 2300 found on my system
in the above check.

Bob

Attachment: signature.asc
Description: Digital signature

Relevant Pages

  • Re: dist-upgrade problem (was Re: /etc/modutils/0keep: line 9: keep: command not found)
    ... Reading package fields... ... i t does not have execute permission ... installation script returned error exit status 100. ...
    (Debian-User)
  • How to make an upgraded system clean by automatically removing abandoned config files?
    ... I've noticed some abandoned configuration files have been left lying around ... be installed in a fresh installation of squeeze. ... that if they don't belong to the same package in squeeze as in lenny, ...
    (Debian-User)
  • Re: Trying to get PackMan to install GCC
    ... A repository can be tested consistent (ie all dependencies of all programs ... control, but RISC OS shared libraries (which are essentially ready, just ... Additional filecan describe what the package manager ... Readmes after installation, or the app needs to do something sensible on ...
    (comp.sys.acorn.apps)
  • Re: FC4 -> FC6
    ... > selected for installation. ... Upgrading just from FC5 to FC6 took about ... Smart package manager had a similar problem ... The developers changed algorithms and, now, ...
    (Fedora)
  • Re: Finding installed package files
    ... >, and who is going to supply this documentation. ... > is a package with the common man pages for the thousand odd common commands ... tell me, as an installation option for some large packages, what was ... >>a set of commands and 'man' pages, could produce such a directory to make it ...
    (alt.os.linux.redhat)