sqlite error: disk I/O error

[Ryan Schmidt]

On Jul 8, 2010, at 07:09, Harald Hanche-Olsen wrote:

> + Ryan Schmidt <ryandesign at macports.org>:
> 
>> I pressed Control-C while MacPorts was activating a port. Now anything I do with port gives me:
>> [...]
>> Error: /opt/local/bin/port: Failed to initialize MacPorts, sqlite error: disk I/O error (10) while executing query: ATTACH DATABASE '/opt/local/var/macports/registry/registry.db' AS registry
>> 
>> 
>> How do I recover?
> 
> Assuming the error message is accurate, it probably has nothing to do
> with your pressing Control-C and everything to do with a bad disk. In
> which case I would replace it ASAP. I think real disk I/O errors are
> logged to /var/log/system.log. Check there. You can also check if
>  cat /opt/local/var/macports/registry/registry.db > /dev/null
> produces any errors.

Prior experience had led me to have that impression of I/O errors as well. But in this case I don't think the error message was right. There were no disk errors in system.log, the disk verifies fine in Disk Utility, no S.M.A.R.T. errors shown.


> If the error message is bogus and your disk is okay, I think the best
> you can do is to restore registry.db from backup. Or better all of
> /opt/local, since an old registry.db will not accurately reflect the
> state of your ports tree.

It turns out it fixed itself. I had a qt4-mac build going at the time the problem occurred, and I just left it running overnight, thinking it would complete the build and destroot and fail with sqlite problems during activation. But it went all the way through, and "port" now works again. I can cat the registry.db without error. I guess the qt4-mac port process had an open handle on the sqlite database and was able to write to it and fix it up.


What led me to ^C the other port process initially was the following. I had locally updated the gthumb port to 2.10.12 and removed the howl dependency (see thread "Removing howl") and wanted to try building it now. In the gthumb directory I "sudo port install"ed and it did this:


$ sudo port install
Password:
--->  Computing dependencies for tiff
--->  Fetching tiff
--->  Verifying checksum(s) for tiff
--->  Extracting tiff
--->  Applying patches to tiff
--->  Configuring tiff
--->  Building tiff
--->  Staging tiff into destroot
--->  Computing dependencies for tiff
--->  Installing tiff @3.9.2_3+universal
--->  Deactivating tiff @3.9.2_3+macosx+universal
--->  Activating tiff @3.9.2_3+universal
--->  Cleaning tiff
--->  Computing dependencies for automake
--->  Verifying checksum(s) for automake
--->  Extracting automake
--->  Configuring automake
--->  Building automake
--->  Staging automake into destroot
--->  Computing dependencies for automake
--->  Installing automake @1.11.1_0
--->  Deactivating automake @1.11.1_0+universal
--->  Activating automake @1.11.1_0
--->  Cleaning automake
--->  Computing dependencies for python_select
--->  Verifying checksum(s) for python_select
--->  Extracting python_select
--->  Configuring python_select
--->  Building python_select
--->  Staging python_select into destroot
--->  Computing dependencies for python_select
--->  Installing python_select @0.3_0
--->  Deactivating python_select @0.3_0+darwin_10+universal
--->  Activating python_select @0.3_0
^C


I did not understand why it was rebuilding tiff, automake, python_select, and who knows what else, when they were already the current versions. It seemed like it thought it was using --enforce-variants, though I had not specified it.