Parece estar relacionado con #23202.

Mismo problema en 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 similar en Travis CI con el paquete Ubuntu. Estaba funcionando hace una 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.

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

Se puede reproducir fácilmente en un contenedor también:

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

¿Qué pasa con apt-get clean ? ¿Ayuda?

@Vanuan No, ya lo intenté.

_ENCUESTA DE USUARIOS_

_La mejor manera de recibir notificaciones de actualizaciones es usar el botón _Suscribirse_ en esta página._

No utilice comentarios "+1" o "Yo también tengo esto" en los problemas. automáticamente
recopile esos comentarios para mantener el hilo corto.

Las personas que se enumeran a continuación han votado a favor de este problema dejando un comentario de +1:

@ViGo5190

¡Aquí igual!

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

Cosas que hemos probado hasta ahora:

Vuelva a agregar la clave GPG
curl -fsSL https://get.docker.com/gpg | sudo apt-key add -

Explotar el caché de listas
sudo rm -rf /var/lib/apt/lists/*

apto limpio
apt-clean

Ninguno de ellos ha resuelto el problema.

Traté de instalar a través de apt. La suma de comprobación no coincide con el siguiente archivo:

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

Intenté los siguientes procedimientos que no ayudaron:

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

Tal vez esto ayudaría a apt-get -o Debug::pkgAcquire::Auth=true update a resolver el problema.

El lanzamiento contiene:
MD5Suma:
49df2d605bb5914873fd826f7e7e8c6f 4917 Paquetes.bz2

InRelease contiene:
b013253c327e2bc4be87825f02936344 4915 principal/binario-amd64/Paquetes.bz2

este último ha sido actualizado hoy, Fecha: Jue, 02 Jun 2016 11:06:54 UTC
mientras que Release es de ayer.

Ejecutar apt-get -o Debug::pkgAcquire::Auth=true update en Ubuntu 14.04 produce

[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

Salida 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

Me pongo en Ubuntu Wily 15.10

E: No se puede ubicar el paquete docker-engine

Obtuve lo mismo antes en Ubuntu Xenial 16.04. ¿Ya se agregó docker al repositorio de Xenial?

Salida 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 estar de acuerdo con el hecho de que las sumas hash son incorrectas/el repositorio necesita una acción administrativa?

Resolví esto descargando el nuevo paquete manualmente e instalándolo 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

Desafortunadamente, la instalación de dpkg no parece funcionar bien en Travis.

Además, esto es lo que me pasa cuando instalo manualmente en 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'.

Actualización : como esperaba de alguna manera, este era un problema no relacionado. Lo arreglé ejecutando rm -rf /var/lib/docker/aufs después de encontrar esto . Así que la instalación manual funciona para mí por el momento.

¡Haga ping a @mlaventure @tiborvass PTAL!

¿Y?

sí, también necesitamos una ETA, es bastante urgente: nuestra cadena completa de construcción de travis está muerta ahora -.-

Aquí están los archivos 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 estos archivos se han regenerado hoy.
Las sumas de verificación (hashes) para estos archivos deben coincidir con lo que hay dentro del archivo de sumas de verificación InRelease firmado.

En el archivo InRelease (https://apt.dockerproject.org/repo/dists/ubuntu-xenial/main/binary-amd64/InRelease), dice que este archivo se generó en Date: Thu, 02 Jun 2016 03:43:32 UTC . Sin embargo, la marca de tiempo que muestra el servidor web es 02-Jun-2016 11:06 .

Entre las diversas causas de Hash Sum Mismatch , esta se trata de una actualización extraña de InRelease con sumas de verificación incorrectas. Además, InRelease enumera Release con una longitud de 0 bytes.

@simos Entonces, ¿esto debería funcionar en Xenial ahora? Pensé que docker todavía no funcionaba en Xenial y que teníamos que volver a Wily. (por otra parte, soy un usuario de Ubuntu desde hoy, entonces, ¿qué sé yo?)

@bmoorthamers Puede verificar manualmente qué repositorios tienen hashes que no coinciden. Mira mi publicación arriba. Al menos trusty , wily y xenial están actualmente (probablemente desde temprano en la mañana) afectados.

Uso, mientras espero la corrección del paquete principal, el paquete experimental, que está funcionando. ¿Alguien sabe si hay algunas grandes diferencias que debo tener en cuenta, o hay algún documento que las describa?

@theluk, la compilación experimental está construida desde el maestro actualmente

Para dar una actualización; Planteé este problema internamente, pero las personas que necesitaban solucionarlo se encuentran en la zona horaria de San Francisco, por lo que aún no están presentes.

Como solución temporal, puede instalar docker 1.11.2-rc1 desde el repositorio de "prueba"; 1.11.2-rc1 es casi igual a la versión actual, aparte de estos tres cambios;
https://github.com/docker/docker/pull/23164 , https://github.com/docker/docker/pull/23169 y https://github.com/docker/docker/pull/23176

Esos cambios no deberían hacer una diferencia funcional (y el último cambio solo afecta algunos casos de esquina)

Puede instalar RC, ya sea cambiando el repositorio "principal" por "de prueba" para APT, o usando el script de instalación;

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

Esperando arreglar esto lo antes posible

Para averiguar si este problema está solucionado, puede visitar, por ejemplo, la página en https://apt.dockerproject.org/repo/dists/ubuntu-xenial/main/binary-amd64/ y verificar la marca de tiempo para el InRelease archivo.

Actualmente todavía dice 11:06 (UTC), que es la versión del archivo que tiene las sumas de verificación incorrectas. Si dice más tarde, probablemente se haya solucionado.

Ahora el tiempo es 13:25 (UTC) y todavía estamos esperando.

¡Gracias chicos!

gracias @thaJeztah ¡la instalación de la prueba funcionó bien!

Mismo problema con Ubuntu Trusty en Travis CI:

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

Para dar una actualización; Planteé este problema internamente, pero las personas que necesitaban solucionarlo se encuentran en la zona horaria de San Francisco, por lo que aún no están presentes.

¿Significa esto que Docker, una importante empresa de infraestructura, no tiene ingenieros de guardia disponibles para solucionar este problema?

@mlafeldt supongo que no pagó por el soporte 24/7.

El soporte comercial de @mlafeldt lo hace; el código abierto es una infraestructura separada

También estoy enfrentando el mismo problema en Wily y no puedo instalar la ventana acoplable:

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

> gato /etc/_release_

DISTRIB_ID=Ubuntu
DISTRIB_LIBERAR=15.10
DISTRIB_CODENAME=astuto
DISTRIB_DESCRIPTION="Ubuntu 15.10"
NOMBRE="Ubuntu"
VERSION="15.10 (Hombre lobo astuto)"
identificación = ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 15.10"
VERSION_ID="15.10"
URL_INICIAL=" http://www.ubuntu.com/ "
SOPORTE_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-limpiar

>Sudo apt-obtener actualización

Pulse http://in.archive.ubuntu.com wily-backports/main Translation-en
Pulse http://in.archive.ubuntu.com wily-backports/universe Translation-en
Obtuvo 4789 B en 33 s (145 B/s)
W: no se pudo obtener https://apt.dockerproject.org/repo/dists/ubuntu-wily/main/binary-amd64/Packages Hash Sum discrepancia
E: Algunos archivos de índice no se pudieron descargar. Se han ignorado o se han utilizado los antiguos en su lugar.

> apt-get -o Debug::pkgAcquire::Auth=actualización verdadera

http://in.archive.ubuntu.com/ubuntu/dists/wily-backports/universe/i18n/Translation-en : computarizada Hash: SHA256: c03ff8f13394e66ce3b2d4645e779e658df189f96326c6eaa8f137a08eb0df30 Hash esperado: SHA256: c03ff8f13394e66ce3b2d4645e779e658df189f96326c6eaa8f137a08eb0df30
Obtuvo 737 kB en 28 s (26,0 kB/s)
W: no se pudo obtener https://apt.dockerproject.org/repo/dists/ubuntu-wily/main/binary-amd64/Packages Hash Sum discrepancia

https://apt.dockerproject.org/repo/dists/ubuntu-wily/main/binary-amd64/
../
InRelease 02-jun-2016 11:06 2.6K
Paquetes 02-jun-2016 2:37 28K
Paquetes.bz2 02-jun-2016 2:37 4.7K
Paquetes.gz 02-jun-2016 2:37 4.5K
Lanzamiento 02-jun-2016 3:43 1.7K
Release.gpg 02-jun-2016 3:43 801

Podemos ver que estos archivos se han regenerado hoy.
Las sumas de verificación (hashes) para estos archivos deben coincidir con lo que está dentro del archivo de sumas de verificación firmado InRelease.
En InRelease https://apt.dockerproject.org/repo/dists/ubuntu-wily/main/binary-amd64/InRelease dice que este archivo se generó el Fecha: jueves, 02 de junio de 2016 03:43:32 UTC. Sin embargo, la marca de tiempo que muestra el servidor web es 02-jun-2016 11:06.

Estoy atónito de que este proceso no esté automatizado con las sumas de verificación calculadas de forma independiente por contenedores Docker separados y, en el caso de un cálculo en disputa entre ellos, la carga se detiene hasta que un ser humano pueda intervenir.

@thaJeztah , ¿entonces hay un repositorio diferente para usuarios comerciales que no está roto?

Aquí hay una secuencia de comandos para que Ubuntu sea notificado por un timbre (reproduce un archivo de audio) cuando se actualizan las sumas de verificación del repositorio,
https://gist.github.com/simos/7ee8258ec17101e44bbfa93606694ede

Creo que no hay mucho que decir aparte de obtener una respuesta oficial de Docker al respecto.

@krak3n sí, hay lanzamientos separados para la versión con soporte comercial.

Para las personas que usan Travis, podría solucionarlo haciendo lo siguiente:

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 cambiando el repositorio "principal" por "de prueba" para APT, o usando el script de instalación;
curl -fsSL https://test.docker.com | sh no son trabajo.

W: No se pudo obtener https://apt.dockerproject.org/repo/dists/ubuntu-trusty/InRelease No se pudo encontrar la entrada esperada 'test/binary-amd64/Packages' en el archivo de versión (entrada de source.list incorrecta o archivo con formato incorrecto) )

E: Algunos archivos de índice no se pudieron descargar. Se han ignorado o se han utilizado los antiguos en su lugar.

@xuedong09 en lugar de "prueba" use "prueba"

He tuiteado a @docker @dockerstatus (varias veces)... este es un problema importante... ¡sorprendido de que hayan estado tan callados!

Estamos trabajando en ello, amigos.

Gracias @crunis : esa solución de Travis funciona de maravilla.

Gracias por trabajar en arreglar esto. Sería genial si publicaras los resultados de la autopsia una vez arreglados.

Gracias @hertzg y @thaJeztah cambiando el repositorio "principal" a "de prueba" para que APT funcione para mí.

@ xuedong09 Solo tenga en cuenta que ahí es donde publicamos los paquetes de prelanzamiento.

Un punto único de falla tan interesante para el ecosistema docker

@babakgh Yo también estaba pensando eso. Esperemos que la autopsia pueda sugerir una buena prevención futura.

Esto también me está afectando.

Todavía obtengo: https://apt.dockerproject.org/repo/dists/debian-jessie/main/binary-amd64/Packages Hash Sum mismatch

Me recuerda a lo que pasó con npm y NodeJS:

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

Y otro, yo también

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

Mantenedores de repositorios de Docker. Necesitas:

• Pruebas automáticas sobre cambios.
• Control de salud de su repositorio
• básicamente monitoreo y alarmas

Espero que esto nunca vuelva a suceder. Docker estaba causando problemas de implementación y prueba de producción aquí (en TravisCI) con esto, aunque no estoy usando un solo contenedor de Docker en producción. 😑

A todos los quejosos y furiosos:

Existe una versión comercial, de pago y con buen soporte de Docker.

Para su información, esta es la versión comunitaria, compatible con el mejor esfuerzo y NO MÁS.

@vadviktor ¿Es esa la posición oficial de Docker, porque me gustaría citar eso?

@therealmarv Este problema no debería afectar su producción ni ninguna tubería de implementación de todos modos, ya que nadie debe depender de una conexión a Internet o un repositorio externo para crear e implementar software.

@vadviktor El mejor esfuerzo no significa derribar a todos. Significa que los pequeños errores y defectos se analizan eventualmente. Todavía necesita mantener todo funcionando en el mejor de los casos.

Para ubuntu trusty (14.04), cambiar del repositorio APT "principal" al de "prueba" funcionó muy bien para mí.

+1

Nunca supe que Docker era una organización de 2 niveles donde la base de usuarios se divide entre los que tienen y los que no. Surly instalar docker es una preocupación global para todos los que usan el software y, por lo tanto, el apoyo que reciben las personas "comerciales" también debería aplicarse a la comunidad. Un nivel pago para una organización es una buena manera de ganar dinero, pero eso debería ir más allá de lo básico, como poder instalar su software.

Los accidentes ocurren, es cómo los tratamos y las lecciones que sacamos lo que importa. La mayor parte de este hilo parece estar lleno de especulaciones. Gracias de antemano a todos los miembros del equipo de Docker que trabajan para solucionar este problema.

@vadviktor ¿Trabajas en Docker?

@vadviktor ¿Dónde puedo encontrar este repositorio apto comercial? ¿Qué producto debo comprar para tener acceso a él?

@vadviktor No trabaja en Docker ni mantiene el proyecto.

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

Parece estar funcionando para Ubuntu Xenial ahora.

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

para todos los que están furiosos por este tiempo de inactividad: aquí hay una linda foto de un ciervo para calmarse y pasar el tiempo mientras tanto:

Trusty parece estar de vuelta

Hola a todos. Trabajo en Docker.

Primero, mis disculpas por la interrupción. Considero nuestra infraestructura de paquetes como infraestructura crítica, tanto para las versiones gratuitas como comerciales de Docker. Es cierto que ofrecemos mejor soporte para la versión comercial (es una de sus características), pero eso no debería aplicarse a cosas fundamentales como poder descargar tus paquetes.

El equipo está trabajando en el problema y continuará brindando actualizaciones aquí. Nos estamos tomando esto en serio.

Algunos de ustedes señalaron que el tiempo de respuesta y el uso de los canales de comunicación parecen inadecuados, por ejemplo, el bot @dockerststus no mencionó el problema cuando se detectó. Comparto la opinión pero aún no sé la historia completa; la autopsia nos dirá con certeza qué salió mal. Por el momento, el equipo se está enfocando en solucionar el problema y no quiero distraerlos de eso.

Una vez que la autopsia identifique qué salió mal, tomaremos las medidas correctivas apropiadas. Sospecho que parte de esto será una mejor coordinación entre los ingenieros centrales y los ingenieros de infraestructura (2 grupos distintos dentro de Docker).

Gracias y disculpa de nuevo las molestias.

heh - tengo el catálogo pero falta el paquete - supongo que tomaré otro café :-)
@shykes Gracias por la actualización, pésima forma de empezar la mañana...
Espero que el día mejore desde aquí.

Me entristece que mi imagen de venado haya obtenido menos +1 que la respuesta oficial.

Ya instalé docker con https://get.docker.com | sh sin ningún error.
Parece que los chicos de Docker solucionaron el problema,

Localizamos la causa del problema y, si debe resolverse ahora, inténtelo de nuevo.

Puede ser necesario borrar el apt-cache;

apt-get clean && apt-get update

Gracias por la solución @thaJeztah

Bueno, eso fue rápido por un problema inesperado, gracias.

@snario de nada ; no puedo atribuirme el mérito de la solución, pero estoy feliz de ver que se ha solucionado 😅

👍

Lamentablemente, con esto en la parte superior de las noticias de piratas informáticos, habrá miles de millones de comentarios. Muchas gracias por la solución rápida @thaJeztah.

Me pregunto si deberíamos cerrar este hilo antes de que aparezcan.

Hasta ahora ha habido workarounds (o toma el .deb e instálalo con dpkg, cambia temporalmente al repositorio testing , etc.). Estas no son soluciones permanentes.

Un fix significa que la fuente de este problema está resuelta y podemos marcar este problema como Resuelto.

Como se publicó anteriormente, puede usar un script para recibir una notificación de audio tan pronto como se reparen los repositorios principales de la ventana acoplable.
https://gist.github.com/simos/7ee8258ec17101e44bbfa93606694ede
Aparte de eso, no hay mucho que hacer.

@simos mira mi comentario anterior; https://github.com/docker/docker/issues/23203#issuecomment -223328829 el problema debe resolverse

@thaJeztah Verifiqué que el problema se resolvió. Probado en Ubuntu 15.10. Gracias a todas las demás personas de Docker que ayudaron a resolver este problema rápidamente.

Gracias a todos por los informes: lo sentimos mucho. Estamos investigando los detalles y la línea de tiempo de los eventos que llevaron a esto, y nos aseguraremos de que no vuelva a suceder.

Estoy cerrando el problema, pero por supuesto, siéntete libre de avisarme si ves alguna peculiaridad restante.

Ubuntu 14.04 Aquí, ¡problema resuelto!

Probablemente no debería sorprenderse, pero es impactante cuántas personas arriesgan su infraestructura con fuertes dependencias en repositorios externos. Ni siquiera hago eso con mis sistemas domésticos.

¿Y luego quejarse de que Docker tiene un único punto de falla?

@jalawrence Docker es la punta del iceberg...
¿Escuchó sobre los problemas recientes con node.js y un desarrollador sacando un solo paquete?
Estoy bastante seguro de que la mayoría de los desarrolladores de php que usan Composer, el administrador de paquetes de facto para esa plataforma, tampoco almacenan copias completas de todas las dependencias de su sitio, y el hecho de que no haya habido contratiempos hasta ahora es más suerte que nada.
El problema es que todos y su perro ahora dependen de $world, y almacenar en caché todas las dependencias localmente es una tarea de sísifo. ¿Debería almacenar en caché todo debian, todo packagist, todo cpan, todo rubygems, todo npm dentro de un proxy inverso a mi cargo?
Y luego: si github, bitbucket o travis no funcionan, ¿qué podrán hacer mis desarrolladores de todos modos? ¿Quiero volver al día en que tuve que alojar todo eso?