Re: Recover from a corrupt pkg DB

From: Vincent Hoffman <>
Date: Tue, 30 Aug 2022 20:08:43 UTC
On 30/08/2022 18:45, Dan Mahoney (Ports) wrote:
>> On Aug 30, 2022, at 10:26 AM, Pete Wright<>  wrote:
>> On Tue, Aug 30, 2022 at 09:36:52AM -0700, Kevin Oberman wrote:
>>> I had a crash while building ffmpeg on a new system. The build had not
>>> begun, so I don't think ffmpeg is really an issue. portmaster(8) was
>>> walking the dependency tree when the system panicked and, after a reboot
>>> and full fsck, I get the error:
>>> pkg: sqlite error while executing PRAGMA user_version; in file
>>> pkgdb.c:2357: database disk image is malformed
> So, I don’t know what tools are available in sqlite3 to dump a malformed db file and reimport it.  I think that’s probably beyond the scope of this, but as I’ve in the past hit pkg issues, I’ve always wanted to know if there was an online description of the schema somewhere.  (Obviously, you could peruse the schema on a second non-corrupt system, but that doesn’t describe how it’s used).

Not a description of it but an explaination of why its not really 
available online, that said

contains it as part of pkgdb_init


>>> Is there any way to rebuild the DB or, if not, how do I remove it and start
>>> from scratch?
> I mean, this is a *very* brute force approach, but if you know precisely what packages you had installed, you can always just reinstall pkg and pkg install -f those packages.
>> I ran into a similar issue a while back, I discovered I was able to
>> recover by using one of the automated backups generated at:
>> /var/backups/pkg.sql.xz*
>> I can't remember the details, but I think it involved replacing
>> repo-FreeBSD.sqlite in /var/db/pkg/.
> I’ve dealt with this on another OS that did things far, far worse (RPM, in the days before Yum).  It always stymied me that there was no online tool that could look at all the files you had in /usr/local/*, look at checksums of historical packages, and glean a “hey, it looks like these are the packages you had installed, but *these files* are the ones that don’t match any checksum on record.”
> -Dan