Parece estar relacionado com #23202.

Mesmo problema no Debian Trusty

W: Failed to fetch https://apt.dockerproject.org/repo/dists/ubuntu-trusty/main/binary-amd64/Packages  Hash Sum mismatch

E: Some index files failed to download. They have been ignored, or old ones used instead.

Problema semelhante no Travis CI com o pacote Ubuntu. Estava funcionando há uma hora.

https://travis-ci.org/goalgorilla/drupal_social/builds/134719276

W: There is no public key available for the following key IDs:
1397BC53640DB551
W: Failed to fetch https://apt.dockerproject.org/repo/dists/ubuntu-trusty/main/binary-amd64/Packages  Hash Sum mismatch
E: Some index files failed to download. They have been ignored, or old ones used instead.

O mesmo no Debian Jessie:
W: Failed to fetch https://apt.dockerproject.org/repo/dists/debian-jessie/main/binary-amd64/Packages Hash Sum mismatch

Pode ser facilmente reproduzido em um recipiente também:

FROM debian:8.4

RUN \
  apt-get update && \
  apt-get install -yq apt-transport-https ca-certificates && \
  apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D && \
  echo "deb https://apt.dockerproject.org/repo debian-jessie main" > /etc/apt/sources.list.d/docker.list && \
  apt-get update

E apt-get clean ? Ajuda?

@Vanuan Não, já tentei.

_PESQUISA DE USUÁRIO_

_A melhor maneira de ser notificado sobre atualizações é usar o botão _Inscrever-se_ nesta página._

Não use comentários "+1" ou "Também tenho isso" em problemas. Nós automaticamente
colete esses comentários para manter o tópico curto.

As pessoas listadas abaixo votaram positivamente nesta questão deixando um comentário com +1:

@ViGo5190

Mesmo aqui!

Failed to fetch https://apt.dockerproject.org/repo/dists/ubuntu-trusty/main/binary-amd64/Packages  Hash Sum mismatch

Coisas que tentamos até agora:

Adicione novamente a chave GPG
curl -fsSL https://get.docker.com/gpg | sudo apt-key add -

Estoure o cache de listas
sudo rm -rf /var/lib/apt/lists/*

Apto limpo
apt-clean

Nenhum deles resolveu o problema

Tentei instalar pelo apt. Incompatibilidade de soma de verificação com o seguinte arquivo:

https://apt.dockerproject.org/repo/dists/ubuntu-trusty/main/binary-amd64/Packages

Tentei os seguintes procedimentos que não ajudaram:

sudo rm -rf /var/lib/apt/lists/*

Talvez isso ajude apt-get -o Debug::pkgAcquire::Auth=true update a descobrir o problema.

O lançamento contém:
MD5Soma:
49df2d605bb5914873fd826f7e7e8c6f 4917 Pacotes.bz2

InRelease contém:
b013253c327e2bc4be87825f02936344 4915 main/binary-amd64/Packages.bz2

o último foi atualizado hoje, Data: Qui, 02 de junho de 2016 11:06:54 UTC
enquanto o lançamento é de ontem.

Executar apt-get -o Debug::pkgAcquire::Auth=true update no Ubuntu 14.04 rende

[Waiting for headers]201 URI Done: bzip2:/var/lib/apt/lists/partial/apt.dockerproject.org_repo_dists_ubuntu-trusty_main_binary-amd64_Packages
RecivedHash: SHA512:d6ca1f74e876031161d1abd6cf9ad0b45f60b19876468cfcf9cacd4956dfd13be43147227a8daa5536f1455bb75b353b178942bc1843d11f0188d00117483912
ExpectedHash: SHA512:d07a3f2c42a9b213e3f03f2f11c08154512baa9fbbaed19f3601865634b82cfdde0e65151a24e523017f29ecfd08a1dfc0af2c2117b025c46d683160892b0de6


https://apt.dockerproject.org/repo/dists/ubuntu-trusty/main/binary-amd64/Packages: 
Computed Hash: SHA512:d6ca1f74e876031161d1abd6cf9ad0b45f60b19876468cfcf9cacd4956dfd13be43147227a8daa5536f1455bb75b353b178942bc1843d11f0188d00117483912  
Expected Hash: SHA512:d07a3f2c42a9b213e3f03f2f11c08154512baa9fbbaed19f3601865634b82cfdde0e65151a24e523017f29ecfd08a1dfc0af2c2117b025c46d683160892b0de6

Saída relevante de apt-get -o Debug::pkgAcquire::Auth=true update :

Got Codename: debian-stretch
Expecting Dist:
Transformed Dist:
Signature verification succeeded: /var/lib/apt/lists/partial/apt.dockerproject.org_repo_dists_debian-stretch_InRelease
Get:2 https://apt.dockerproject.org/repo debian-stretch/main amd64 Packages [4,941 B]
0% [Connecting to ftp.de.debian.org] [Connecting to security.debian.org] [Connecting to mirror.netcologne.de] [Connecting to packages.dotdeb.org] [Connecting to www.deb-multimedia.org] [Connecting to ftp-stud.hs-esslingen.de] [Connecting201 URI Done: https://apt.dockerproject.org/repo/dists/debian-stretch/main/binary-amd64/Packages.bz2
ReceivedHash:
    - SHA512:14844ddc767052951fb68eabc19a1935fb930c798d64fd86ace0dcce3aad2af887fc091ad90897a52f341f65dadac5f0dc31a35f9c70b5bcc582314187a336cf
    - SHA256:0cee3ef5330e133cc6dfbf3d34f118806ce685a1ded4210c5c4f7ef7b43e9867
    - SHA1:bcf84731c3d9fe4355ce73b3cd756decbf9b67cb
    - MD5Sum:c99614887831f4d020e682c8222fe49b
    - Checksum-FileSize:4933
ExpectedHash:
    - Checksum-FileSize:4941
    - SHA512:5de62937921a32be2e9cf14f65e6adda3499fd648f37ab5ccc9547a03d211be66c3a5cd15f272e5a3f0abc53fec3903f646410337917e4201bf2a7ed5ac8581d
    - SHA256:ebc0ec8921482f40bdcf1fa9a7f39b7bd198d81a769643723201c109b3b617ea
    - SHA1:a61818ebafdccbccdfdeee5e550b9241b8c32722
    - MD5Sum:9cd9390adc1849ba5923a70d92af1927

https://travis-ci.org/goalgorilla/drupal_social/builds/134730044

Get:11 https://apt.dockerproject.org ubuntu-trusty/main amd64 Packages
201 URI Done: https://apt.dockerproject.org/repo/dists/ubuntu-trusty/main/binary-amd64/Packages.bz2
RecivedHash: SHA512:36e068ae0288732c51bd971ee74b6d27c8707f4d11840afcca617884de82e8c533c5259d8d97bb297966424bc58ac219879f4f5d12c4abe073799bb658f4bd87
ExpectedHash: SHA512:d07a3f2c42a9b213e3f03f2f11c08154512baa9fbbaed19f3601865634b82cfdde0e65151a24e523017f29ecfd08a1dfc0af2c2117b025c46d683160892b0de6

Eu entro no Ubuntu Wily 15.10

E: Não foi possível localizar o pacote docker-engine

Eu tenho o mesmo antes no Ubuntu Xenial 16.04. O docker já foi adicionado ao repositório Xenial?

Saída relevante de apt-get -o Debug::pkgAcquire::Auth=true update :

Got Codename: ubuntu-xenial
Expecting Dist: 
Transformed Dist: 
Signature verification succeeded: /var/lib/apt/lists/partial/apt.dockerproject.org_repo_dists_ubuntu-xenial_InRelease
Holen:12 https://apt.dockerproject.org/repo ubuntu-xenial/main amd64 Packages [1.712 B]
Ign:12 https://apt.dockerproject.org/repo ubuntu-xenial/main amd64 Packages
Holen:12 https://apt.dockerproject.org/repo ubuntu-xenial/main amd64 Packages [1.430 B]
Ign:12 https://apt.dockerproject.org/repo ubuntu-xenial/main amd64 Packages
Holen:12 https://apt.dockerproject.org/repo ubuntu-xenial/main amd64 Packages [4.815 B]
100% [12 Packages 4.815 B/4.815 B 100%]201 URI Done: https://apt.dockerproject.org/repo/dists/ubuntu-xenial/main/binary-amd64/Packages
ReceivedHash:
    - SHA512:c7883bb7a1d0b5162431576408644a85003be4601724b6f2db275cd4b603a61f8dcd924e80158c40413942519c8a528f7940ffbe5370daa4b0a0d867afe3163d
    - SHA256:de12840d76e571cb6f42e63ac570c59d5332d772fb295b6919d12214052bfa6b
    - SHA1:9f9c05d3b7d8ca13e9e03c4f0f12757816f02301
    - MD5Sum:65e1f5c451c230a091118b468c31bae7
    - Checksum-FileSize:4815
ExpectedHash:
    - Checksum-FileSize:4815
    - SHA512:2becf6c2b9aae5b6823ea6d9f12988e22905a87a9a03fed844a761698eee614899d7b039e081e0b330539e716918b75e87a96c287a5efbe9fc3e847d44657798
    - SHA256:f4ae20e2259740699fba3a79dd7fb557c472d172b578798071274f7ba4c400f3
    - SHA1:8f34563e8170c5698dc7ba04dd3cf4c8a93100cf
    - MD5Sum:31d143b7a15a8a38bc92a7559c995078

podemos concordar com o fato de que os hashsums estão incorretos/repo precisa de ação administrativa?

Eu resolvi isso baixando o novo pacote manualmente e instalando usando dpkg

curl -OL https://apt.dockerproject.org/repo/pool/main/d/docker-engine/docker-engine_1.11.2-0~trusty_amd64.deb
dpkg -i docker-engine*.deb

Infelizmente a instalação do dpkg não parece funcionar bem no Travis.

Além disso, isso é o que acontece comigo ao instalar manualmente no Debian Stretch, usando https://apt.dockerproject.org/repo/pool/main/d/docker-engine/docker-engine_1.11.2-0~stretch_amd64.deb :

$ sudo systemctl status docker.service
● docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2016-06-02 14:46:59 CEST; 58s ago
     Docs: https://docs.docker.com
 Main PID: 31269 (code=exited, status=1/FAILURE)

Jun 02 14:46:58 penny systemd[1]: Starting Docker Application Container Engine...
Jun 02 14:46:58 penny docker[31269]: time="2016-06-02T14:46:58.553905409+02:00" level=info msg="New containerd process, pid: 31293\n"
Jun 02 14:46:59 penny docker[31269]: time="2016-06-02T14:46:59.659258835+02:00" level=error msg="[graphdriver] prior storage driver \"aufs\" failed: driver not supported"
Jun 02 14:46:59 penny docker[31269]: time="2016-06-02T14:46:59.659395935+02:00" level=fatal msg="Error starting daemon: error initializing graphdriver: driver not supported"
Jun 02 14:46:59 penny systemd[1]: docker.service: Main process exited, code=exited, status=1/FAILURE
Jun 02 14:46:59 penny docker[31269]: time="2016-06-02T14:46:59+02:00" level=info msg="stopping containerd after receiving terminated"
Jun 02 14:46:59 penny systemd[1]: Failed to start Docker Application Container Engine.
Jun 02 14:46:59 penny systemd[1]: docker.service: Unit entered failed state.
Jun 02 14:46:59 penny systemd[1]: docker.service: Failed with result 'exit-code'.

Atualização : Como eu de alguma forma esperava, este foi um problema não relacionado. Eu consertei executando rm -rf /var/lib/docker/aufs depois de encontrar isso . Portanto, a instalação manual funciona para mim por enquanto.

ping @mlaventure @tiborvass PTAL!

E?

sim, precisamos de um ETA também, é muito urgente - nossa cadeia completa de construção do travis está morta agora -.-

Aqui estão os arquivos relevantes para xenial,
https://apt.dockerproject.org/repo/dists/ubuntu-xenial/main/binary-amd64/

InRelease        02-Jun-2016 11:06  2.6K
Packages          02-Jun-2016  2:38  4.8K
Packages.bz2  02-Jun-2016  2:38  1.7K
Packages.gz    02-Jun-2016  2:38  1.4K
Release            02-Jun-2016  3:43  1.7K
Release.gpg    02-Jun-2016  3:43  801

Podemos ver que esses arquivos foram regenerados hoje cedo.
As somas de verificação (hashes) para esses arquivos devem corresponder ao que está dentro do arquivo de somas de verificação InRelease assinado.

No arquivo InRelease (https://apt.dockerproject.org/repo/dists/ubuntu-xenial/main/binary-amd64/InRelease), diz que este arquivo foi gerado em Date: Thu, 02 Jun 2016 03:43:32 UTC . No entanto, o timestamp conforme mostrado pelo servidor Web é 02-Jun-2016 11:06 .

Entre as várias causas para Hash Sum Mismatch , esta é sobre alguma atualização estranha de InRelease com somas de verificação erradas. Além disso, InRelease lista Release como tendo 0 bytes de comprimento.

@simos Então isso deve funcionar no Xenial agora? Achei que o docker ainda não funcionava no Xenial e tivemos que voltar para o Wily. (então, novamente, sou um usuário do Ubuntu desde hoje, então o que eu sei)

@bmoorthamers Você pode verificar manualmente quais repositórios têm hashes incompatíveis. Veja meu post acima. Pelo menos trusty , wily e xenial estão atualmente (provavelmente desde o início da manhã) afetados.

eu uso, enquanto aguardo a correção do pacote principal, o pacote experimental, que está funcionando. alguém sabe se existem algumas grandes diferenças que eu preciso estar ciente, ou existe em algum lugar um documento descrevendo-as?

@theluk a compilação experimental é construída a partir do mestre atualmente

Para dar uma atualização; Eu levantei esse problema internamente, mas as pessoas necessárias para corrigir isso estão no fuso horário de São Francisco, então eles ainda não estão presentes.

Como solução temporária, você pode instalar o docker 1.11.2-rc1 do repositório "test"; 1.11.2-rc1 é quase o mesmo que a versão atual, exceto por essas três mudanças;
https://github.com/docker/docker/pull/23164 , https://github.com/docker/docker/pull/23169 e https://github.com/docker/docker/pull/23176

Essas alterações não devem fazer diferença funcional (e a última alteração afeta apenas alguns casos de canto)

Você pode instalar o RC, alterando o repositório "principal" para "teste" do APT ou usando o script de instalação;

curl -fsSL https://test.docker.com | sh

Espero resolver isso o mais rápido possível

Para descobrir se esse problema foi corrigido, você pode visitar, por exemplo, a página em https://apt.dockerproject.org/repo/dists/ubuntu-xenial/main/binary-amd64/ e verificar o timestamp para o InRelease arquivo.

Atualmente ainda diz 11:06 (UTC) que é a versão do arquivo que tem as somas de verificação erradas. Se disser mais tarde, provavelmente foi corrigido.

Agora a hora é 13:25 (UTC) e ainda estamos esperando.

Obrigado rapazes!

obrigado @thaJeztah instalação do teste funcionou bem!

Mesmo problema com o Ubuntu Trusty no Travis CI:

W: Failed to fetch https://apt.dockerproject.org/repo/dists/ubuntu-trusty/main/binary-amd64/Packages  Hash Sum mismatch

Para dar uma atualização; Eu levantei esse problema internamente, mas as pessoas necessárias para corrigir isso estão no fuso horário de São Francisco, então eles ainda não estão presentes.

Isso significa que a Docker - uma grande empresa de infraestrutura - não tem engenheiros de plantão disponíveis para corrigir isso?

@mlafeldt acho que você não pagou pelo suporte 24 horas por dia, 7 dias por semana.

O suporte comercial da @mlafeldt sim; open source é uma infraestrutura separada

também estou enfrentando o mesmo problema no Wily e não consigo instalar o docker:

root@vikram-VirtualBox :/etc/apt/sources.list.d# cat docker.list
deb https://apt.dockerproject.org/repo ubuntu-wily main

> gato /etc/_release_

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=15.10
DISTRIB_CODENAME=astuto
DISTRIB_DESCRIPTION="Ubuntu 15.10"
NAME="Ubuntu"
VERSION="15.10 (lobisomem astuto)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 15.10"
VERSION_ID="15.10"
HOME_URL=" http://www.ubuntu.com/ "
SUPPORT_URL=" http://help.ubuntu.com/ "
BUG_REPORT_URL=" http://bugs.launchpad.net/ubuntu/ "

>sudo rm -rf /var/lib/apt/lists/*

>rm /etc/apt/trusted.gpg

>sudo apt-get clean

>sudo apt-get update

Acesse http://in.archive.ubuntu.com wily-backports/main Translation-en
Acesse http://in.archive.ubuntu.com wily-backports/universe Translation-en
Obteve 4.789 B em 33s (145 B/s)
W: Falha ao buscar https://apt.dockerproject.org/repo/dists/ubuntu-wily/main/binary-amd64/Packages Hash Sum inmatch
E: Alguns arquivos de índice não foram baixados. Eles foram ignorados, ou os antigos usados ​​em seu lugar.

> apt-get -o Debug::pkgAcquire::Auth=true update

http://in.archive.ubuntu.com/ubuntu/dists/wily-backports/universe/i18n/Translation-en : Computed Hash: SHA256: c03ff8f13394e66ce3b2d4645e779e658df189f96326c6eaa8f137a08eb0df30 Hash esperado: SHA256: c03ff8f13394e66ce3b2d4645e779e658df189f96326c6eaa8f137a08eb0df30
Obteve 737 kB em 28s (26,0 kB/s)
W: Falha ao buscar https://apt.dockerproject.org/repo/dists/ubuntu-wily/main/binary-amd64/Packages Hash Sum inmatch

https://apt.dockerproject.org/repo/dists/ubuntu-wily/main/binary-amd64/
../
InRelease 02-Jun-2016 11:06 2.6K
Pacotes 02-Jun-2016 2:37 28K
Packages.bz2 02-Jun-2016 2:37 4,7K
Packages.gz 02-Jun-2016 2:37 4,5K
Lançamento 02-jun-2016 3:43 1,7K
Release.gpg 02-Jun-2016 3:43 801

Podemos ver que esses arquivos foram regenerados hoje cedo.
As somas de verificação (hashes) para esses arquivos devem corresponder ao que está dentro do arquivo InRelease de somas de verificação assinado.
No InRelease https://apt.dockerproject.org/repo/dists/ubuntu-wily/main/binary-amd64/InRelease diz que este arquivo foi gerado em Date: Thu, 02 Jun 2016 03:43:32 UTC . No entanto, o carimbo de data/hora mostrado pelo servidor Web é 02-Jun-2016 11:06.

Estou chocado que esse processo não seja automatizado com as somas de verificação calculadas independentemente por contêineres separados do Docker e, no caso de um cálculo contestado entre eles, o upload é retido até que um humano possa intervir.

@thaJeztah então existe um repositório diferente para usuários comerciais que não está quebrado?

Aqui está um script para o Ubuntu ser notificado por um carrilhão (reproduz arquivo de áudio) quando as somas de verificação do repositório forem atualizadas,
https://gist.github.com/simos/7ee8258ec17101e44bbfa93606694ede

Acho que não há muito a dizer além de obter uma resposta oficial do Docker sobre isso.

@krak3n sim, existem versões separadas para a versão com suporte comercial.

Para pessoas que usam o Travis, eu poderia corrigi-lo fazendo o seguinte:

before_install:
- sudo apt-get install libsystemd-journal0
- pushd /tmp
- curl -OL https://apt.dockerproject.org/repo/pool/main/d/docker-engine/docker-engine_1.10.2-0~trusty_amd64.deb
- sudo dpkg --force-all -i docker-engine*.deb
- docker -v
- popd

@thaJeztah alterando o repositório "principal" para "teste" do APT ou usando o script de instalação;
curl -fsSL https://test.docker.com | sh não são trabalho.

W: Falha ao buscar https://apt.dockerproject.org/repo/dists/ubuntu-trusty/InRelease Não foi possível encontrar a entrada esperada 'test/binary-amd64/Packages' no arquivo Release (entrada sources.list incorreta ou arquivo malformado )

E: Alguns arquivos de índice não foram baixados. Eles foram ignorados, ou os antigos usados ​​em seu lugar.

@xuedong09 em vez de "teste" use "teste"

Eu twittei @docker @dockerstatus (várias vezes)... este é um grande problema... surpreso que eles tenham ficado tão silenciosos!

Estamos trabalhando nisso, pessoal.

Obrigado @crunis - essa correção de Travis funciona muito bem.

Obrigado por trabalhar para corrigir isso. Seria ótimo se você publicasse os resultados da autópsia depois de corrigidos.

Obrigado @hertzg e @thaJeztah alterando o repositório "principal" para "teste" para o APT funcionar para mim.

@xuedong09 Apenas tenha em mente que é onde publicamos pacotes de pré-lançamento.

Um ponto único de falha tão interessante para o ecossistema docker

@babakgh eu estava pensando isso também. Esperemos que a autópsia possa sugerir uma boa prevenção futura.

Isso também está me afetando.

Ainda recebo: https://apt.dockerproject.org/repo/dists/debian-jessie/main/binary-amd64/Packages Hash Sum mismatch

Me lembra o que aconteceu com npm e NodeJS:

http://www.thejournal.ie/programmer-break-internet-code-2679793-Mar2016/

E outro, eu também

W: Failed to fetch https://apt.dockerproject.org/repo/dists/debian-jessie/main/binary-amd64/Packages Hash Sum mismatch

Mantenedores de repositórios do Docker. Você precisa:

• Testes automáticos de mudanças
• Verificação de integridade do seu repositório
• basicamente monitoramento e alarmes

Espero que isso nunca mais aconteça. O Docker estava causando problemas de teste e implantação de produção aqui (no TravisCI) com isso, embora eu não esteja usando um único contêiner do Docker na produção. 😑

A todos os queixosos e furiosos:

Existe uma versão comercial, paga e bem suportada do Docker.

FYI esta é a versão da comunidade, suportada na base do melhor esforço e NÃO MAIS.

@vadviktor Essa é a posição oficial do Docker, porque gostaria de citar isso?

@therealmarv Esse problema não deve afetar sua produção ou qualquer pipeline de implantação, pois ninguém deve depender de uma conexão com a Internet ou de um repositório externo para criar e implantar software.

@vadviktor Melhor esforço não significa derrubar todo mundo. Isso significa que pequenos bugs e defeitos são analisados ​​eventualmente. Você ainda precisa manter tudo funcionando nos melhores cenários.

Para o Ubuntu Trusty (14.04), mudar do repositório APT "principal" para "teste" funcionou muito bem para mim.

+1

Eu nunca soube que o Docker era uma organização de 2 camadas onde a base de usuários é dividida entre os que têm e os que não têm. A instalação do docker é uma preocupação global para todos que usam o software e, portanto, o suporte que as pessoas "comerciais" recebem também deve se aplicar à comunidade. Um nível pago para uma organização é uma boa maneira de ganhar dinheiro, mas isso deve ir além do básico, como poder instalar seu software.

Acidentes acontecem, é como lidamos com eles e as lições que levamos adiante. A maior parte deste tópico parece ser galopante com especulações. Agradecemos antecipadamente a todos os membros da equipe do Docker que estão trabalhando para corrigir esse problema.

@vadviktor Você trabalha no Docker?

@vadviktor Onde posso encontrar este repositório apt comercial? Qual produto devo comprar para ter acesso a ele?

@vadviktor Não funciona no Docker nem mantém o projeto.

@qzio consulte http://www.docker.com/docker-support-services

Parece estar funcionando para o Ubuntu Xenial agora.

FYI, este problema está em HN https://news.ycombinator.com/item?id=11822562

para todos que estão furiosos com esse tempo de inatividade: aqui está uma foto fofa de veado para se acalmar e passar o tempo enquanto isso:

Trusty parece estar de volta

Olá a todos. Eu trabalho na Docker.

Primeiramente, minhas desculpas pela interrupção. Considero nossa infraestrutura de pacotes como infraestrutura crítica, tanto para as versões gratuitas quanto comerciais do Docker. É verdade que oferecemos um suporte melhor para a versão comercial (é uma se suas características), mas isso não deve se aplicar a coisas fundamentais como poder baixar seus pacotes.

A equipe está trabalhando no problema e continuará dando atualizações aqui. Estamos levando isso a sério.

Alguns de vocês apontaram que o tempo de resposta e o uso dos canais de comunicação parecem inadequados, por exemplo, o bot @dockerststus não mencionou o problema quando foi detectado. Partilho a opinião mas ainda não conheço a história completa; a autópsia nos dirá com certeza o que deu errado. No momento, a equipe está se concentrando em corrigir o problema e não quero distraí-los disso.

Assim que a autópsia identificar o que deu errado, tomaremos as medidas corretivas apropriadas. Suspeito que parte disso será uma melhor coordenação entre os engenheiros principais e os engenheiros de infraestrutura (2 grupos distintos dentro do Docker).

Obrigado e desculpe novamente o transtorno.

heh - recebi o catálogo, mas o pacote está faltando - acho que vou tomar outro café :-)
@shykes Obrigado pela atualização - péssima maneira de começar sua manhã ...
Espero que o dia melhore daqui

Estou triste que minha foto de veado tenha recebido menos +1s do que a resposta oficial.

Já instalei o docker com https://get.docker.com | sh sem nenhum erro.
Parece que os caras do Docker corrigiram o problema,

Localizamos a causa do problema e, se for resolvido agora, tente novamente.

Pode ser necessário limpar o apt-cache;

apt-get clean && apt-get update

Obrigado pela correção @thaJeztah

Bem, isso foi rápido para um problema inesperado, obrigado.

@snario de nada; não posso levar o crédito pela correção, mas feliz em ver que foi resolvido 😅

👍

Infelizmente, com isso no topo das notícias sobre hackers, haverá bilhões de comentários. Muito obrigado pela solução rápida @thaJeztah.

Gostaria de saber se devemos bloquear este tópico antes que eles apareçam.

Até agora havia workarounds (pegue o .deb e instale com o dpkg, mude temporariamente para o repositório testing , etc). Estas não são soluções permanentes.

Um fix significa que a origem deste problema foi resolvida e podemos marcar este problema como Resolvido.

Conforme postado anteriormente, você pode usar um script para obter uma notificação de áudio assim que os principais repositórios do docker forem corrigidos,
https://gist.github.com/simos/7ee8258ec17101e44bbfa93606694ede
Fora isso, não há muito o que fazer.

@simos veja meu comentário anterior; https://github.com/docker/docker/issues/23203#issuecomment -223328829 o problema deve ser resolvido

@thaJeztah Verifiquei que o problema foi resolvido. Testado no Ubuntu 15.10. Obrigado a todas as outras pessoas do Docker que ajudaram a resolver esse problema rapidamente.

Obrigado a todos pelos relatos: sentimos muito por isso. Estamos analisando os detalhes e a linha do tempo dos eventos que levaram a isso e garantiremos que não aconteça novamente.

Estou encerrando o problema, mas, claro, sinta-se à vontade para me informar se encontrar alguma peculiaridade restante.

Ubuntu 14.04 Aqui, problema resolvido!

Provavelmente não deveria se surpreender, mas é chocante quantas pessoas arriscam sua infraestrutura com dependências rígidas de repositórios externos. Eu nem faço isso com meus sistemas domésticos.

E depois reclamar que o Docker tem um único ponto de falha?

@jalawrence Docker é a ponta do iceberg...
Você ouviu sobre os problemas recentes com node.js e um dev retirando um único pacote?
Tenho certeza de que a maioria dos desenvolvedores php que usam o Composer - o gerenciador de pacotes de fato para essa plataforma - também não armazena cópias completas de todas as dependências de seu site, e o fato de não ter ocorrido nenhum contratempo até agora é mais sorte do que qualquer coisa.
O problema é que todos e seus cães agora dependem do $world, e armazenar em cache todas as dependências localmente é uma tarefa sísmica. Devo armazenar em cache todo o debian, todo o packagist, todo o cpan, todo o rubygems, todo o npm dentro de um proxy reverso às minhas próprias custas?
E então: se o github, bitbucket ou travis estiverem inativos, o que meus desenvolvedores poderão fazer de qualquer maneira? Eu quero voltar ao dia em que tive que hospedar tudo isso?