Cargo unable to update registry with "wrong pack signature"

I just set up Rust on a new machine with rustup, in order to compile/update some older projects. However, when I try to cargo build, I'm met with this:

$ cargo build
error: Unable to update registry `crates-io`

Caused by:
  failed to fetch ``

Caused by:
  wrong pack signature; class=Indexer (15)

I read about similar errors online and have already tried deleting ~/.cargo/registry to no avail.

Rust is up to date:

$ rustup check
stable-powerpc-unknown-linux-gnu - Up to date : 1.62.0 (a8314ef7d 2022-06-27)
rustup - Up to date : 1.24.3

Note that I'm on powerpc-unknown-linux-gnu, a Tier 2 architecture.

I'm not really sure how to deal with this. There's no other results for it online, and the error gives me very little to work from.

Any ideas would be much appreciated!

You could try adding the following to .cargo/config.toml:

git-fetch-with-cli = true

This will force cargo to use the git cli for fetching the registry instead of using libgit2.

1 Like

You could also try out the new index protocol:

This got me a little further! Though it's still not quite behaving:

$ cargo build
    Updating index
error: no matching package named `getrandom` found
location searched: registry `crates-io`
required by package `uscsi v0.1.0 (/home/ash/src/uscsi)`

The crate does exist though, and the same Cargo.toml works on PC, so I'm still unsure the pack actually worked correctly.

I'm hoping to stick to stable if I can, will try if all else fails though.

Does the file ~/.cargo/registry/index/ exist? If not, which parent directory does exist?

I have ~/.cargo/registry/index/, which is empty aside from .git and .last-updated. There's no remote or anything set up in git, just a master branch with no commits.
It sounds like git is not doing what it should, is there a way to know what the underlying git command is so I can run it and check for output?

The actual registry can be found at GitHub - rust-lang/ Registry index for I believe it does git fetch --force --update-head-ok +HEAD:refs/remotes/origin/HEAD on updates, but I'm not really sure how it actually does the init clone. You can try removing ~/.cargo/registry/index/ Maybe the git cli gets confused by leftovers from the failed libgit2 clone operation?

I've been removing it between failures, so I know it's not that.
I took a little look with strace and can see that the last thing it does before giving the error is.. open and read a pack file, just like in the original post. I'm starting to think this might be a bug in libgit2 related to parsing pack files (maybe because I'm on big-endian?).. should I try nightly and file a bug report?

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.