Open DeedleFake opened 3 years ago
I've managed to get my node back up and running by rolling back to v0.7.0
with v0.6.0
of the plugin, but I'd definitely like to know how to update, if it's at all possible.
The repo migration tool will load any plugins present in your repo (or it should), but won't be able to use plugins built into go-ipfs itself. The simplest solution is to build a copy of the s3 plugin and drop it into your repo.
Otherwise, you could try building the migration tool with s3 support. If this doesn't work, I can try walking you through that process.
@Stebalien I also failed to migrate using badger/v2
===> Running migration 10 to 11...
applying 10-to-11 repo migration
- opening datastore at "D:\\workspace\\ipfsdata"
ipfs migration: migration 10 to 11 failed: cannot open datastore: unsupported badger version, use github.com/ipfs/badgerds-upgr
ade to upgrade: manifest has unsupported version: 7 (we support 4).
Please see https://github.com/dgraph-io/badger/blob/master/README.md#i-see-manifest-has-unsupported-version-x-we-support-y-error
on how to fix this.
=> Failed: fs-repo-migrations.exe -to 11 -y
The migrations of fs-repo failed:
migration failed: exit status 1
If you think this is a bug, please file an issue and include this whole log output.
Error: migration failed: exit status 1
@godcong badger v2 isn't supported. Please open a new issue so we can discuss possible solutions.
@Stebalien
Otherwise, you could try building the migration tool with s3 support. If this doesn't work, I can try walking you through that process.
I think that I'm going to need to go with this. I'm bundling the plugin into IPFS by building a Docker image on a different machine and then uploading that. I tried building the plugin in a container from the same base image (golang:1.14.4-buster
), but when I tried to run it I got
plugin was built with a different version of package internal/cpu
Hmmm... maybe that error is showing up because the latest version of fs-repo-migrations
is not built against go-ipfs v0.8.0, but an earlier RC (there's a bit of a circular dependency between go-ipfs and fs-repo-migrations that means we can't release go-ipfs vX.Y.Z with it automatically using fs-repo-migrations xA.B.C which is dependent on go-ipfs vX.Y.Z).
You might have some luck if you build the plugin against go-ipfs commit dd295e456085
which is the one fs-repo-migrations v1.7.1 is built against. Building against a branch should be specified in the s3 plugin repo, but the pattern it follows is from https://github.com/ipfs/go-ipfs-example-plugin.
I tried building it against dd295e456085
by modifying go.mod
, but it didn't help. Is there some way that I can manually build and run a version of fs-repo-migrations
that has the plugin bundled into it?
I finally managed to get around to getting this working. I had to make manual changes to the build-plugin.sh
script in order to force it to use Go 1.16 instead of Go 1.17 because the resulting binary will just panic immediately otherwise, and there's also a bug in the script's handling of command-line arguments that results in it requiring the -y
flag to be passed or else it will just fail. Once I got it built, I just copied it over, stopped the IPFS node, ran the migration manually with fs-repo-10-to-11 -path <path> -verbose
, and then restarted the IPFS. Seems to be working now.
I have a custom compiled IPFS image using
v0.8.0
withv0.7.0
of thego-ds-s3
plugin bundled in, as per the instructions ingo-ds-s3
's README. When I try to run the new version after upgrading fromv0.7.0
, I get the following log output:The only thing that I was able to find that was similar was ipfs/go-ipfs#6416, but it was closed without being resolved, presumably because the original author disappeared. I tried starting up a completely unmodified node via the
ipfs/go-ipfs
image on Docker Hub, but that had the exact same problem. How am I supposed to run the migration if the migration tool doesn't support the backend that I've got my data stored in? Am I missing something completely here?