4

I've got a server with Gitolite installed to host my repos I created a new repo yesterday and today when I tried to push more commits to the server I am getting:

fatal: object 86eeaa0c5a154ff3df34d6a43669930b9c6c7f59 is corrupted
error: unpack failed: unpack-objects abnormal exit
error: failed to push some refs to

As the repo is pretty new I wasn't too bothered about losing previous commits so I have deleted both my local and remote repo but still getting the same error.

As I say I'm not too concerned about maintaing my commit history, I would just like to get it working again!

simon
  • 73
  • 1
  • 8
  • You did create your new repo by declaring it in the `gitolite.conf` file of a local clone of `gitolite-admin` repo, and pushing that `gitolite-admin` repo back to the gitolite server, right? (see http://sitaramc.github.com/gitolite/repos.html) You didn't `git init` directly yourself on the gitolite server, I presume? – VonC May 24 '12 at 11:43
  • And what version of gitolite do you have? Did you made some '`gl-xxx`' commands (like `gl-setup`)? Ie Gitolite V2. Or did you make a `gitolite install` (gitolite V3, or `g3`) – VonC May 24 '12 at 11:45
  • Yeah I declared the new repo in the `gitolite.conf` on my local machine and then pushed this back to the gitolite server, I then cloned that repo to my machine added the files, commited and pushed back to the server. This works fine, its only when I go to push to the server a 2nd time. I'm using version g3. – simon May 24 '12 at 11:56
  • @VonC the over repo I have is working fine, I can clone and push commits to. – simon May 24 '12 at 14:19
  • And the first repo (the one with the issue on the second push), can you clone it directly on the gitolite server (so local clone /path/to/repo) and see if you can push it back? – VonC May 24 '12 at 14:28
  • @VonC No I'm getting a `fatal: object 94b3887fa96f1a40e77f9a0cf9f566acb1e995a3 is corrupted` so I assume something is wrong with creating the new repo? – simon May 24 '12 at 14:46
  • yes, if you can: try to redo the all creation process and see if that issue is repeatable. (add another repo in `gitolite.conf` and push again to `gitolite-admin` – VonC May 24 '12 at 14:47
  • @VonC Ok I didn't notice this before but when I create a new repo I'm getting the following error `remote: line 1 too long: command="/home/git/gitolite/src/gitolite... remote: FATAL: fingerprinting failed for /tmp/Cdug9Itivq` But it's creating the repo in `/home/git/repositories` – simon May 24 '12 at 14:56
  • So that needs to be resolved somehow. Can you try to create the ssh key as in http://stackoverflow.com/questions/10736964/gitolite-admin-clone-issue/10738450#10738450 ? And use that one for cloning / pushing `gitolite-admin` repo? – VonC May 24 '12 at 15:58
  • possible duplicate of [Git log: fatal object \[sha1\] is corrupted](http://stackoverflow.com/questions/2909225/git-log-fatal-object-sha1-is-corrupted) – CharlesB May 24 '12 at 19:37

1 Answers1

5

As seen in the comments, any additional repo has an issue during its creation (ie when pushing back the gitolite-admin repo with the gitolite.conf file declaring a new repo)

I didn't notice this before but when I create a new repo I'm getting the following error:

remote: line 1 too long: command="/home/git/gitolite/src/gitolite... 
remote: FATAL: fingerprinting failed for /tmp/Cdug9Itivq

But it's creating the repo in /home/git/repositories

This operation takes place in a post-compilation trigger called ssh-authkeys:

sub fp_file {
    return $selinux++ if $selinux; # return a unique "fingerprint" to prevent noise
    my $f = shift;
    my $fp = `ssh-keygen -l -f '$f'`;
    chomp($fp);
    _die "fingerprinting failed for '$f'" unless $fp =~ /([0-9a-f][0-9a-f](:[0-9a-f][0-9a-f])+)/;
    $fp = $1;
    return $fp;
}

That means ssh-keygen -l -f <path_to_public_key.pub> doesn't follow the right pattern, as shown in "self service key management".

Make sure that your key is generated like:

ssh-keygen -t rsa -f "${H}/.ssh/git" -C "Gitolite Admin access (not interactive)" -q -P ""

Update April 2015:

As mentioned by starfry in "Gitolite - remote: FATAL: fingerprinting failed for 'keydir/'":

There was a change to the key fingerprint format in OpenSSH at version 6.8:

Add FingerprintHash option to ssh(1) and sshd(8), and equivalent command-line flags to the other tools to control algorithm used for key fingerprints. The default changes from MD5 to SHA256 and format from hex to base64.

Fingerprints now have the hash algorithm prepended.
An example of the new format: 

SHA256:mVPwvezndPv/ARoIadVY98vAC0g+P/5633yTC4d/wXE

Please note that visual host keys will also be different.

The latest git checkout of gitolite is aware, since 18th March '15, of this new format.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks for another very informative answer! I've generated a new key as suggested. What do I need to do with the `git.pub` key now? – simon May 25 '12 at 14:46
  • @simon: use that key as described in http://sitaramc.github.com/gitolite/setup.html (so with an id.pub renamed into a 'generic account name' dedicated for gitolite ssh administration: see http://stackoverflow.com/questions/10736964/gitolite-admin-clone-issue/10738450#10738450 for illustration), in order to initiate again the `gitolite-admin` repo, clone it, declare new repos, clone them and see if the issue persists. – VonC May 25 '12 at 15:29
  • The fingerprint version changed with OpensSSH 6.8 See [this answer](http://stackoverflow.com/a/29749581) – starfry Apr 20 '15 at 13:46
  • @starfry I see. I have included your answer here as well, for more visibility. – VonC Apr 20 '15 at 13:50