fatal: EOF inicial fatal: índice-pacote falhou


271

Pesquisei no Google e encontrei muitas soluções, mas nenhuma funciona para mim.

Estou tentando clonar de uma máquina conectando ao servidor remoto que está na rede LAN.
A execução deste comando a partir de outra máquina causa erro.
Mas, executando o comando SAME clone usando git: //192.168.8.5 ... no servidor, tudo bem e bem-sucedido.

Alguma ideia ?

user@USER ~
$ git clone  -v git://192.168.8.5/butterfly025.git
Cloning into 'butterfly025'...
remote: Counting objects: 4846, done.
remote: Compressing objects: 100% (3256/3256), done.
fatal: read error: Invalid argument, 255.05 MiB | 1.35 MiB/s
fatal: early EOF
fatal: index-pack failed

Eu adicionei esta configuração, .gitconfigmas não ajuda também.
Usando a versão git 1.8.5.2.msysgit.0

[core]
    compression = -1

8
Eu enfrentei esse problema por 2-3 dias quando estava tentando clonar da VPN. no meu caso, a questão era largura de banda da rede. i corrigido pela clonagem em rede de alta velocidade.
Avijit Nagare

1
Também notei que está relacionado à rede.
pergunto

1
Eu recebi esse erro porque meus amigos não conhecem o git tão bem e colocam muitas imagens no repositório! =))
Clite Tailor

Também notei que está relacionado à rede. Eu também consertei clonando em rede de alta velocidade.
shashaDenovo 26/02

Respostas:


506

Primeiro, desative a compactação:

git config --global core.compression 0

Em seguida, vamos fazer um clone parcial para truncar a quantidade de informações que aparece:

git clone --depth 1 <repo_URI>

Quando isso funcionar, entre no novo diretório e recupere o restante do clone:

git fetch --unshallow 

ou, alternativamente,

git fetch --depth=2147483647

Agora, faça um puxão regular:

git pull --all

Eu acho que existe uma falha no msysgit nas versões 1.8.x que exacerba esses sintomas, então outra opção é tentar com uma versão anterior do git (<= 1.8.3, eu acho).


6
Obrigado, isso funcionou muito bem. Tentei alterar o http.postbuffer que não funcionou, mas depois de fazer o que foi dito nesta resposta, funcionou muito bem. Não usei a linha "git fetch --depth = 2147483647", mas usei o resto.
Nick Bento

2
@ EthenA.Wilson Você precisará passar o URL remoto para o repositório posteriormente. Por exemplo git clone --depth 1 git@host:user/my_project.git.
Nathan Gould

6
@ Joseph A. - Tive esse problema quando estava em uma versão mais recente do msysgit. Se você estiver no msysgit, tente uma versão mais antiga (<= 1.8.3). Caso contrário, tente git fetch - profundidade 1000 (depois 2000, etc., aumentando gradualmente até que todos os arquivos sejam puxados).
ingyhere

2
@ José A. - Além disso, dê uma olhada no seguinte: stackoverflow.com/questions/4826639/…
ingyhere

2
Olá querido amigo. Obrigado por sua ótima solução. Mas o último git pull --allnão funciona. Por causa de git clone --depth 1definir o intervalo de busca apenas um ramo. Então, precisamos editar o .git / config primeiro.
Pjincz 09/07/19

93

Este erro pode ocorrer para necessidades de memória do git. Você pode adicionar essas linhas ao seu arquivo de configuração global do git, que está .gitconfigdentro $USER_HOME, a fim de corrigir esse problema.

[core] 
packedGitLimit = 512m 
packedGitWindowSize = 512m 
[pack] 
deltaCacheSize = 2047m 
packSizeLimit = 2047m 
windowMemory = 2047m

Isso funcionou para mim - embora eu ainda precisasse de várias tentativas, mas sem essa alteração, o aborto chegou a 30%, depois a 75% ... e uma vez subiu para 100% e funcionou. :)
peschü 15/03

Deve ser a resposta selecionada
Asim Qasımzade 14/11

Nas janelas, com o git 2.19, isso corrigia. Adicionando especificamente os parâmetros relacionados ao pacote.
26618

Trabalhou! Obrigado!
Guille Acosta

ainda não está funcionando para mim remote: Enumerating objects: 43, done. remote: Counting objects: 100% (43/43), done. remote: Compressing objects: 100% (24/24), done. error: inflate returned -55/26) fatal: unpack-objects failed
Jeevan Chaitanya

26

finalmente resolvido por git config --global core.compression 9

Em um thread de problema do BitBucket:

Eu tentei quase cinco vezes, e ainda acontece.

Então eu tentei usar uma melhor compressão e funcionou!

git config --global core.compression 9

Na documentação do Git:

core.compression
Um número inteiro -1..9, indicando um nível de compactação padrão. -1 é o padrão zlib.
0 significa sem compactação e 1..9 são várias compensações de velocidade / tamanho, 9 sendo a mais lenta.
Se definido, isso fornece um padrão para outras variáveis ​​de compactação, como core.looseCompression e pack.compression.


3
Precisava executar git repackem combinação com esta solução e funcionou.
21818 ErikH #

Isso funcionou, nem tentou outras soluções, porque esta é a mais curta e elegante. deve ser aceito resposta!
metablaster 02/12/19

Isso funciona para mim também, através de VPN e proxy corporativo. --compression 0não funcionou nem todas as .gitconfigalterações sugeridas acima.
Terrence Brannon

20

Como @ingyhere disse:

Clone raso

Primeiro, desative a compactação:

git config --global core.compression 0

Em seguida, vamos fazer um clone parcial para truncar a quantidade de informações que aparece:

git clone --depth 1 <repo_URI>

Quando isso funcionar, entre no novo diretório e recupere o restante do clone:

git fetch --unshallow

ou, alternativamente,

git fetch --depth=2147483647

Agora, faça um puxão:

git pull --all

Em seguida, para resolver o problema de sua filial local, apenas o mestre de rastreamento

abra seu arquivo de configuração git ( .git/config) no editor de sua escolha

onde diz:

[remote "origin"]
    url=<git repo url>
    fetch = +refs/heads/master:refs/remotes/origin/master

mude a linha

fetch = +refs/heads/master:refs/remotes/origin/master

para

fetch = +refs/heads/*:refs/remotes/origin/*

Faça uma busca no git e o git puxará todos os seus ramos remotos agora


Funciona, mas deixei a compactação para 9 e não para 0, que falhou.
metablaster 16/04

9

No meu caso, isso foi bastante útil:

git clone --depth 1 --branch $BRANCH $URL

Isso limitará o checkout apenas à ramificação mencionada e, portanto, acelerará o processo.

Espero que isso ajude.


6

Eu tentei todos esses comandos e nenhum funciona para mim, mas o que funciona foi alterar o git_url para http em vez de ssh

Se o comando clone for:

git clone <your_http_or_https_repo_url> 

caso contrário, se você estiver utilizando um repositório existente, faça-o com

git remote set-url origin <your_http_or_https_repo_url>

espero que isso ajude alguém!


1
Esta pergunta é realmente sobre a mensagem de erro na saída acima, quando há um problema ao sincronizar pedaços gigantes de arquivos de um repositório conectado. Você está dizendo que o corte para https do ssh permitiu que o clone terminasse?
ingyhere

Sim! Esse trabalho para mim, eu tenho um repositório de 4 GB + e a única solução que obtive foi essa!
elin3t

2
Funciona para mim, obrigado! Clone por httpse defina o controle remoto novamente para ssh.
Tuan

1
Eu realmente gostaria de saber por que isso funcionou. Existe algo no protocolo SSH que engasga com objetos grandes que o HTTPS não faz? Esse é um problema da camada de transporte?
bdetweiler

6

Eu recebi esse erro quando o git ficou sem memória.

Libertar um pouco de memória (neste caso: deixar um trabalho de compilação terminar) e tentar novamente funcionou para mim.


Para mim, não havia muita memória disponível, liberando um pouco e tentando resolvê-lo.
Martin Cassidy

4

No meu caso, foi um problema de conexão. Eu estava conectado a uma rede wifi interna, na qual tinha acesso limitado a recursos. Isso estava deixando o git fazer a busca, mas em um determinado momento ele caiu. Isso significa que pode ser um problema de conexão de rede. Verifique se tudo está funcionando corretamente: antivírus, firewall, etc.

A resposta do elin3t é, portanto, importante porque o ssh melhora o desempenho do download, para que problemas de rede possam ser evitados


4

Definir a configuração abaixo não funciona para mim.

[core] 
packedGitLimit = 512m 
packedGitWindowSize = 512m 
[pack] 
deltaCacheSize = 2047m 
packSizeLimit = 2047m 
windowMemory = 2047m

Como comentário anterior, pode haver problemas com a memória do git. Assim, tento reduzir os threads de trabalho (de 32 para 8). Para que não obtenha muitos dados do servidor ao mesmo tempo. Também adiciono "-f" para forçar a sincronização de outros projetos.

-f: Proceed with syncing other projects even if a project fails to sync.

Então funciona bem agora.

repo sync -f -j8

2

Uma resposta anterior recomenda definir para 512m. Eu diria que há razões para pensar que é contraproducente em uma arquitetura de 64 bits. A documentação para core.packedGitLimit diz:

O padrão é 256 MiB em plataformas de 32 bits e 32 TiB (efetivamente ilimitado) em plataformas de 64 bits. Isso deve ser razoável para todos os usuários / sistemas operacionais, exceto nos maiores projetos. Você provavelmente não precisa ajustar esse valor.

Se você quiser experimentar, verifique se está configurado e remova a configuração:

git config --show-origin core.packedGitLimit
git config --unset --global core.packedGitLimit

1

Observe que o Git 2.13.x / 2.14 (terceiro trimestre de 2017) aumenta o padrão core.packedGitLimitque influencia git fetch:
O valor limite do pacote embalado foi aumentado em plataformas maiores ( de 8 GiB para 32 GiB ) para salvar " git fetch" de uma falha (recuperável) enquanto " gc" estiver sendo executado em paralelo.

Veja commit be4ca29 (20 de abril de 2017) por David Turner ( csusbdt) .
Ajudado por: Jeff King ( peff) .
(Mesclado por Junio ​​C Hamano - gitster- na confirmação d97141b , 16 de maio de 2017)

Aumentar core.packedGitLimit

Quando core.packedGitLimitexcedido, o git fecha os pacotes.
Se houver uma operação de reembalagem em paralelo com uma busca, a busca poderá abrir um pacote e, em seguida, forçada a fechá-lo devido à ocorrência de empacotamentoGitLimit.
A reembalagem pode excluir o pacote da busca, causando falha na busca.

Aumente core.packedGitLimito valor padrão para evitar isso.

Nas atuais máquinas x86_64 de 64 bits, 48 ​​bits de espaço de endereço estão disponíveis.
Parece que as máquinas ARM de 64 bits não possuem quantidade padrão de espaço de endereço (isto é, varia de acordo com o fabricante) e as máquinas IA64 e POWER possuem os 64 bits completos.
Portanto, 48 bits é o único limite com o qual podemos razoavelmente nos preocupar. Reservamos alguns bits do espaço de endereço de 48 bits para uso do kernel (isso não é estritamente necessário, mas é melhor estar seguro) e usamos até os 45 restantes.
Nenhum repositório git estará em qualquer lugar próximo desse tamanho a qualquer momento logo, isso deve evitar a falha.



1

No meu caso, o problema não era nenhum dos parâmetros de configuração do git, mas o fato de o meu repositório ter um arquivo excedendo o tamanho máximo permitido no meu sistema. Eu pude verificar tentando baixar um arquivo grande e obter um "Limite de tamanho de arquivo excedido" no Debian.

Depois disso, editei meu arquivo /etc/security/limits.conf adicionando e no final as seguintes linhas: * hard fsize 1000000 * soft fsize 1000000

Para realmente "aplicar" os novos valores-limite, você precisa fazer login novamente


1

Relacionado tangencialmente e útil apenas no caso de você não ter acesso root e extrair manualmente o Git de um RPM (com rpm2cpio) ou outro pacote (.deb, ..) em uma subpasta. Caso de uso típico: você tenta usar uma versão mais recente do Git sobre a desatualizada em um servidor corporativo.

Se o clone do git falhar fatal: index-pack failed sem menção antecipada ao EOF, mas uma mensagem de ajuda sobre usage: git index-pack, haverá uma incompatibilidade de versão e você precisará executar o git com o --exec-pathparâmetro:

git --exec-path=path/to/subfoldered/git/usr/bin/git clone <repo>

Para que isso ocorra automaticamente, especifique em ~/.bashrc:

export GIT_EXEC_PATH=path/to/subfoldered/git/usr/libexec

1

Eu tinha os mesmos logs de erro, usando git (v2.17.1) sobre ssh. No meu caso, a solução é:

  1. Entre no repositório git bare do meu servidor.
  2. Ligue git gc.

Consulte a documentação do git-gc: https://git-scm.com/docs/git-gc .

Por exemplo:

ssh admin@my_server_url.com
sudo su git
cd /home/git/my_repo_name # where my server's bare repository exists.
git gc

Agora eu posso clonar este repositório sem erros, por exemplo, no lado do cliente:

git clone git@my_server_url.com:my_repo_name

O comando git gcpode ajudar chamado no lado do cliente git para evitar git pushproblemas semelhantes .


Outra solução (hack) está baixando o último mestre sem histórico:

git clone --single-branch --depth=1 git@my_server_url.com:my_repo_name

Há uma chance de que o buffer overflow não ocorra.


0

No meu caso, nada funcionou quando o protocolo era https, então mudei para ssh e assegurei que obtive o repositório do último commit e não do histórico inteiro, e também do ramo específico. Isso me ajudou:

clone git - profundidade 1 "ssh: .git" --branch “specific_branch”


0

Enquanto isso, desliguei todos os downloads que estava fazendo, o que provavelmente liberou espaço e reduziu a largura de banda.



0

Eu tenho o mesmo problema. Após o primeiro passo acima, eu consegui clonar, mas não posso fazer mais nada. Não é possível buscar, puxar ou retirar galhos antigos.

Cada comando corre muito mais devagar que o normal e depois morre após compactar os objetos.

I:\dev [master +0 ~6 -0]> git fetch --unshallow
remote: Counting objects: 645483, done.
remote: Compressing objects: 100% (136865/136865), done.

error: RPC failed; result=18, HTTP code = 20082 MiB | 6.26 MiB/s

fatal: early EOF

fatal: The remote end hung up unexpectedly

fatal: index-pack failed

Isso também acontece quando seus árbitros estão usando muita memória. Podar a memória corrigiu isso para mim. Basta adicionar um limite ao que você procura assim ->

git fetch --depth=100

Isso buscará os arquivos, mas com as últimas 100 edições em seus históricos. Depois disso, você pode executar qualquer comando com precisão e velocidade normal.


o que você quer dizer com TED?
Vishav Premlall 29/08/16

essa "resposta" deveria ter sido um comentário sobre a resposta do @ingyhere.
Mc0e 14/03/19

0

Tentei a maioria das respostas aqui, recebi o erro com o PUTTY SSH Client com todas as constelações possíveis.

Depois que mudei para o OpenSSH, o erro desapareceu (remova a variável de ambiente GIT_SSH e reinicie o git bash).

Eu estava usando uma nova máquina e as versões mais recentes do git. Em muitas outras máquinas / antigas (também na AWS), funcionou como esperado com o PUTTY, sem nenhuma configuração do git.


0

Eu experimentei o mesmo problema. O REPO era muito grande para ser baixado via SSH. Assim como @ elin3t recomendado, eu clonei por HTTP / HTTPS e alterei a URL REMOTE em .git / config para usar o SSH REPO.


0

Eu tenho o mesmo problema abaixo quando corro git pull

remote: Counting objects: 149, done.
Connection to git-codecommit.us-east-1.amazonaws.com closed by remote host.
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

Em seguida, verifiquei git status: Havia tantas alterações não confirmadas que eu corrigi o problema, confirmando e enviando todas as alterações não confirmadas.


0

Nenhuma das soluções acima funcionou para mim.

A solução que finalmente funcionou para mim foi trocar o cliente SSH. A variável de ambiente GIT_SSH foi definida como o OpenSSH fornecido pelo Windows Server 2019. Versão 7.7.2.1

C:\Windows\System32\OpenSSH\ssh.exe

Eu simplesmente instalei a massa, 0,72

choco install putty

E alterou GIT_SSH para

C:\ProgramData\chocolatey\lib\putty.portable\tools\PLINK.EXE


0

Tentei praticamente todas as sugestões feitas aqui, mas nenhuma funcionou. Para nós, a questão era temperamental e se tornava cada vez pior quanto maiores os repositórios (no nosso Jenkins Windows build slave).

Acabou sendo a versão do ssh usada pelo git. O Git foi configurado para usar alguma versão do Open SSH, especificada no arquivo .gitconfig dos usuários por meio da variável core.sshCommand. A remoção dessa linha a corrigiu. Acredito que isso ocorre porque o Windows agora é fornecido com uma versão mais confiável / compatível do SSH, que é usada por padrão.


-1

Isso funcionou para mim, configurando o servidor de nomes do Google porque nenhum servidor de nomes padrão foi especificado, seguido pelo reinício da rede:

sudo echo "dns-nameservers 8.8.8.8" >> /etc/network/interfaces && sudo ifdown venet0:0 && sudo ifup venet0:0

-1

De um clone do git, eu estava obtendo:

error: inflate: data stream error (unknown compression method)
fatal: serious inflate inconsistency
fatal: index-pack failed

Depois de reiniciar minha máquina, consegui clonar o repositório com precisão.


Na primeira vez, não acredito que você apenas reiniciar sua máquina pode solucionar esse problema, mas tentei tudo o que recebi mensagens que não funcionam. então eu decidi reiniciar minha máquina é minha última solução para mim. Para minha sorte, quando a máquina inicia, tento clonar novamente. Eu não acredito. Isso funciona !!!!!!!
Thxopen 14/06



Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.