Hi!

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:

[...]

>> When you do ‘guix pull’, the resulting (guix config) is supposed to
>> honor the settings of the calling ‘guix’: %localstatedir, etc.
>>
>> It seems that it wasn’t the case here?  Could you try again running
>> ‘guix pull’ from a ‘guix’ command that has non-default settings and
>> check the resulting (guix config) module?
>
> Is (guix config) enough?  What about the daemon?  I’ve had no problem
> with “guix” itself when used with a daemon taken from the git checkout.

Oooh, good point, the ‘guix-daemon’ package uses a fixed localstatedir.

I believe the patch below solves the problem.  WDYT?

> Yes, I was able to identify the corrupt store items and copy the
> corresponding items from a separate machine.  I was lucky that it
> aborted early when trying to delete items, so it seems that it didn’t
> get to do all that much damage.

Phheeew.

> (Curiously, I wasn’t able to run “guix gc --verify=repair,contents”
> because Guix claims I don’t have sufficient privileges to repair the
> store — I’m running this as root, but who knows how NFS complicates
> things…)

It’s supposed to work if you’re root, and the privilege claim checks
just that (see nix-daemon.cc):

--8<---------------cut here---------------start------------->8---
	if (remoteAddr.ss_family == AF_UNIX) {
            […]
	    trusted = clientUid == 0;

    […]
    
    case wopVerifyStore: {
        bool checkContents = readInt(from) != 0;
        bool repair = readInt(from) != 0;
        startWork();
        if (repair && !trusted)
            throw Error("you are not privileged to repair paths");
        bool errors = store->verifyStore(checkContents, repair);
        stopWork();
        writeInt(errors, to);
        break;
    }
--8<---------------cut here---------------end--------------->8---

Thanks,
Ludo’.