From owner-freebsd-questions@FreeBSD.ORG Wed May 8 20:43:31 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9FF9AA2B; Wed, 8 May 2013 20:43:31 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 6AAD4B3D; Wed, 8 May 2013 20:43:31 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 728F63AF57; Wed, 8 May 2013 13:43:21 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-ports@freebsd.org, freebsd-questions@freebsd.org Subject: Missing +CONTENTS syndrome: Selectively restoring +CONTENTS files Date: Wed, 08 May 2013 13:43:21 -0700 Message-ID: <46817.1368045801@server1.tristatelogic.com> X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 20:43:31 -0000 A couple of three weeks ago or so, I experienced an unfortunate series of three or four system crashes, all of which I ultimately found to be attributable to CPU automatic over-temp shutdowns, where the reason for the overheating turned out to be something really rather stupid. Some cables inside the system's case had been obstructing the rotation of the CPU fan. That problem has long since been effectively resolved, and the system in question is functioning entirely normally again. An unfortunate side-effect of the crashes however... one of which I believe to have occured during a "portupgrade -a" operation... is that numerous of my /var/db/pkg/*/+CONTENTS files appear to have gone walkabout, for no apparently good reason. The first manifestation of this problem that I noticed was a series of messages of the following general form when I ran pkg_version: pkg_version: the package info for package 'XXXX-N.N.N' is corrupt (It appears that out of a total of 643 installed ports, only 59 of them are currenty suffering from this missing +CONTENTS syndrome.) Since I first noticed this problem/issue, I have taken pains to utterly avoid making any changes or updates to any of my ports. (I am frankly worried that if I did so, I might make matter worse than they already are.) Now I am finally making time to try to clean up this mess. With the help of Google, I have found various suggestions for how to cope, specifically, with the problem of missing +CONTENTS file(s). (I am apparently not the first person to have experienced this issue.) I am now trying to decide the best course of action, and would be happy for some advice. In the following posting: http://lists.freebsd.org/pipermail/freebsd-ports/2007-May/041552.html it was suggested to simply do "portinstall -i" (with the environment variable FORCE_PKG_REGISTER pre-set to "yes") for each of the affected packages. In this posting: http://lists.freebsd.org/pipermail/freebsd-questions/2003-May/006301.html it was suggested instead to cd to the directory for each port in turn, and then do "make install FORCE_PKG_REGISTER=YES". Elsewhere, I saw it suggested that _prior_ to such steps, it would be appropriate (and perhaps even necessary) to "rm -fr" the relevant /var/db/pkg port directory, before attempting any kind of re-install of any one of the affected/afflicted ports. I sincerely would like to know if others think that this is good advice, or not. More importantly than any of the forgoing hoever, I need to mention that I fortunately _do_ have a complete intact backup of my entire /var partition which was saved a mere two or three weeks prior to the set of system crashes that precipitated these ports problems. Given that I am in the habit of upgrading my existing ports and/or installing new ports only very sporadically, I do suspect that most or perhaps even all of the various +CONTENTS files within that /var backup could perhaps simply be copied from the backup to their corresponding locations within my /var/db/pkg directory, and that this would be an entirely fast and appropriate way to correct these issues for most or all of the affected ports. The question I have, of course, is the obvious one: Is there any definitive way for me to tell whether or not, for any given individual port, I can simply restore the corresponding +CONTENTS file from the (slightly stale) backup? I'm worried that simply restoring these 59 +CONTENTS files from my backup may be inappropriate, and may cause me yet more headaches, because it is possible that for some of the affected ports, I _did_ successfully update those to newer versions, sometime between the time that I made that backup of /var and the time of my heat-induced system crashes, and the corresponding magical disappearance of these 59 distinct +CONTENTS files. If there were a way to tell which of my backup +CONTENTS files were still valid and usable, and which ones weren't, then that would be most helpful to know. Any and all comments and/or guidance appreciated. Regards, rfg P.S. It is, of course, more than passing strange that any system crash, even in the middle of a "portupgrade -a" operation, would selectively cause a large set of _just_ various +CONTENTS files to utterly disappear, and others who have also experienced this missing +CONTENTS syndrome have also made this same comment. I do suspect that somewhere someone has a pretty good idea of the mechanism by which such havoc might arise, and I can only hope that whoever that is, he or she is considering changes that might perhaps make port upgrading just a tiny bit more fault tolerant. (If a new +CONTENTS file for some port is going to be generated and installed, it would perhaps be a kindness to rename the existing +CONTENTS file to, say, +CONTENTS.old, and to leave it in its directory, removing it either never or only at such time as its new replacement is considered finished and complete. This would seem to be, as they say, not rocket surgery.)