Bad gpg keys when updating a Debian Etch box (preparing it for Lenny) and then replacing a corrupted libc6 ... but end result is a broken system

I just tried to update a Debian Etch box that hasn't seen any action in about a year, and I got this message when using the Update Manager:

W: GPG error: ... The following signatures couldn't be verified because the public key is not available: NO_PUBKEY xxxxxxxxxxxxxxxxxxxxxxxxxx
W: You may want to run apt-get update to correct these problems

(Note: I don't have the exact error message because I'm not using the box in question to write this post ... but it looks just like this, except with a bit more information and the full

I do have a few Debian Etch boxes hanging around, and today I wanted to update one — the Self-Reliant Thin Client (Maxspeed Maxterm thin client with 8 GB CF card as the hard drive) — and I ran into some PGP key issues.

I already dealt with how to fix the Opera key (if you're using the Opera repository for the free but not-open source browser, and I am), but I'll repeat what you should run, in this case specifically for Debian and using a root terminal (instead of sudo).

Open a root terminal (or su to root) and do the following:

# gpg --keyserver subkeys.pgp.net --recv-key F9A2F76A9D1A0061
# gpg --fingerprint F9A2F76A9D1A0061
# gpg --armor --export F9A2F76A9D1A0061 | apt-key add -

That takes care of the Opera key.

On this Etch box, my Debian key was bad as well. I can see that happening. I probably haven't booted this box in over a year, and since then the whole SSL problem with Debian happened, caused hair-rending, and then was resolved, so that might have caused the problem ... or maybe not.

At any rate, I did get errors when trying to update the box with Synaptic (I eventually used Aptitude in the console, my preferred method at least some of the time), so I needed to get a new Debian key. Here's how I did that one (thanks to Stackoverflow.com for the recipe):

# apt-get install debian-keyring
# gpg --keyserver pgp.mit.edu --recv-keys 1F41B907
# gpg --armor --export 1F41B907 | apt-key add -

Then I still had a problem with libc6. when trying to upgrade/update with:

# aptitude update
# aptitude upgrade

... I kept getting a message about libc6 being a corrupted package.

I got around this problem by first clearing the cache and then installing libc6 (and its dependency, libc6-i686) individually:

# aptitude clean
# aptitude install libc6

That worked. My "corrupted" package was gone, replaced by the presumably uncorrupted libc6, and I was able to then proceed with the update/upgrade:

# aptitude update
# aptitude upgrade

Update: I'm getting checksum errors in the downloaded packages. Could this be the CF card going bad? I cleaned out the packages and am trying another upgrade.

Further update: The box is dead. That half-upgrade made it so I can't even log in ... Guess I'll have to do a reinstall after all.

Even further update: I pulled the CF card and ran fsck on it from another box. It checks out. Why did I keep getting packages with bad checksums?

I'll have to hook up the CD drive and do a reinstall. I can't remember whether or not this particular box will boot Lenny. I could always reinstall Etch and upgrade from there. Since the CF card checks out with fsck, I can hopefully keep the same partitions when doing the reinstall.

Final word on 2.16.18 nostalgia: Before I close this out, the 2.6.18 kernel used in Etch and Red Hat Enterprise Linux (and CentOS) 5, PCLinuxOS 2007 and probably a few other distros I've forgotten, has been a very good kernel to me, for my hardware (especially the $0 Laptop, a Gateway Solo 1450). I'll miss it. I welcome all the new hardware drivers, especially wireless networking drivers, in the newer kernels. I don't welcome the regressions in Xorg, but since the Self-Reliant Thin Client uses an S3 video chip rather than Intel, maybe I can blissfully move to Lenny without trouble ...