По-видимому, имеет отношение к #23202.

Та же проблема в 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.

Аналогичная проблема на Travis CI с пакетом Ubuntu. Он работал час назад.

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.

То же самое в Debian Jessie:
W: Failed to fetch https://apt.dockerproject.org/repo/dists/debian-jessie/main/binary-amd64/Packages Hash Sum mismatch

Также можно легко воспроизвести в контейнере:

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

А как насчет apt-get clean ? Это помогает?

@Vanuan Нет, уже пробовал.

_ОПРОС ПОЛЬЗОВАТЕЛЯ_

_Лучший способ получать уведомления об обновлениях — использовать кнопку _Подписаться_ на этой странице._

Пожалуйста, не используйте комментарии «+1» или «У меня тоже есть это» в комментариях к проблемам. Мы автоматически
Соберите эти комментарии, чтобы сделать тему короткой.

Перечисленные ниже люди проголосовали за эту проблему, оставив комментарий +1:

@ViGo5190

То же самое!

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

Вещи, которые мы пробовали до сих пор:

Повторно добавьте ключ GPG
curl -fsSL https://get.docker.com/gpg | sudo apt-key add -

Очистить кеш списков
sudo rm -rf /var/lib/apt/lists/*

Чисто
apt-clean

Ни один из них не решил проблему

Пытался установить через apt. Несовпадение контрольной суммы со следующим файлом:

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

Пробовал следующие процедуры, которые не помогли:

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

Возможно, это поможет apt-get -o Debug::pkgAcquire::Auth=true update разобраться в проблеме.

Релиз содержит:
MD5Сумма:
49df2d605bb5914873fd826f7e7e8c6f 4917 пакетов.bz2

InRelease содержит:
b013253c327e2bc4be87825f02936344 4915 main/binary-amd64/Packages.bz2

последний был обновлен сегодня, Дата: Чт, 02 июня 2016 11:06:54 UTC
в то время как выпуск со вчерашнего дня.

Запуск apt-get -o Debug::pkgAcquire::Auth=true update на Ubuntu 14.04 дает

[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

Соответствующий вывод 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

Я получаю Ubuntu Wily 15.10

E: Не удалось найти пакет docker-engine.

У меня было то же самое раньше на Ubuntu Xenial 16.04. Добавлен ли докер в репозиторий Xenial?

Соответствующий вывод 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

Можем ли мы согласиться с тем фактом, что хеш-суммы неверны / репо требует административных действий?

Я работал над этим, загрузив новый пакет вручную и установив его с помощью 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

К сожалению, установка dpkg не работает на Трэвисе.

Кроме того, вот что происходит со мной при ручной установке Debian Stretch с использованием 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'.

Обновление : как я и ожидал, это была несвязанная проблема. Я исправил это, запустив rm -rf /var/lib/docker/aufs после нахождения этого файла . Так что ручная установка у меня пока работает.

пинг @mlaventure @tiborvass PTAL!

И?

да, нам тоже нужно ETA, это очень срочно - наша полная цепочка сборки travis сейчас мертва -.-

Вот соответствующие файлы для 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

Мы видим, что эти файлы были восстановлены ранее сегодня.
Контрольные суммы (хэши) для этих файлов должны соответствовать тому, что находится внутри подписанного файла контрольных сумм InRelease .

В файле InRelease (https://apt.dockerproject.org/repo/dists/ubuntu-xenial/main/binary-amd64/InRelease) сказано, что этот файл был создан Date: Thu, 02 Jun 2016 03:43:32 UTC . Однако отметка времени, показанная веб-сервером, равна 02-Jun-2016 11:06 .

Среди нескольких причин для Hash Sum Mismatch эта связана с каким-то странным обновлением InRelease с неправильными контрольными суммами. Кроме того, InRelease указывает, что Release имеет длину 0 байт.

@simos Итак, теперь это должно работать на Xenial? Я думал, что докер все еще не работает на Xenial и нам нужно вернуться к Wily. (опять же, я пользователь Ubuntu с сегодняшнего дня, так что я знаю)

@bmoorthamers Вы можете вручную проверить, какие репозитории имеют несовпадающие хэши. Смотрите мой пост выше. По крайней мере, trusty , wily и xenial в настоящее время (вероятно, с утра) затронуты.

Я использую в ожидании исправления основного пакета экспериментальный пакет, который работает. кто-нибудь знает, есть ли какие-то большие различия, о которых мне нужно знать, или есть ли где-нибудь документ, описывающий их?

@theluk Экспериментальная сборка в настоящее время собрана из мастера.

Дать обновление; Я поднял эту проблему внутри компании, но люди, которые должны были решить эту проблему, находятся в часовом поясе Сан-Франциско, поэтому они еще не присутствуют.

В качестве временного обходного пути вы можете установить docker 1.11.2-rc1 из «тестового» репозитория; 1.11.2-rc1 почти такой же, как текущий выпуск, за исключением этих трех изменений;
https://github.com/docker/docker/pull/23164 , https://github.com/docker/docker/pull/23169 и https://github.com/docker/docker/pull/23176.

Эти изменения не должны иметь функционального значения (и последнее изменение влияет только на некоторые крайние случаи).

Вы можете установить RC, либо изменив репозиторий «основной» на «тестовый» для APT, либо используя сценарий установки;

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

Надеюсь исправить это как можно скорее

Чтобы выяснить, исправлена ​​ли эта проблема, вы можете посетить, например, страницу https://apt.dockerproject.org/repo/dists/ubuntu-xenial/main/binary-amd64/ и проверить метку времени для InRelease файл.

В настоящее время он по-прежнему говорит 11:06 (UTC), что является версией файла с неправильными контрольными суммами. Если указано более позднее время, то, вероятно, оно было исправлено.

Сейчас время 13:25 (UTC), и мы все еще ждем.

Спасибо, парни!

спасибо @thaJeztah установка теста сработала нормально!

Та же проблема с Ubuntu Trusty на Travis CI:

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

Дать обновление; Я поднял эту проблему внутри компании, но люди, которые должны были решить эту проблему, находятся в часовом поясе Сан-Франциско, поэтому они еще не присутствуют.

Означает ли это, что у Docker — крупной инфраструктурной компании — нет дежурных инженеров, которые могли бы это исправить?

@mlafeldt думаю, вы не платили за круглосуточную поддержку 7 дней в неделю.

коммерческая поддержка @mlafeldt ; open source — это отдельная инфраструктура

я также сталкиваюсь с той же проблемой на Wily и не могу установить докер:

root@vikram-VirtualBox :/etc/apt/sources.list.d# cat docker.list
deb https://apt.dockerproject.org/repo ubuntu-wily основной

> кот /etc/_release_

DISTRIB_ID=Убунту
DISTRIB_RELEASE=15.10
DISTRIB_CODENAME=хитрый
DISTRIB_DESCRIPTION="Убунту 15.10"
ИМЯ="Убунту"
ВЕРСИЯ = "15.10 (Коварный оборотень)"
ID=убунту
ID_LIKE=дебиан
PRETTY_NAME="Убунту 15.10"
ВЕРСИЯ_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-очиститься

>sudo apt-получить обновление

Нажмите http://in.archive.ubuntu.com wily-backports/main Translation-en
Нажмите http://in.archive.ubuntu.com wily-backports/universe Translation-en
Получено 4789 ББ за 33 с (145 Б/с)
W: Не удалось получить https://apt.dockerproject.org/repo/dists/ubuntu-wily/main/binary-amd64/Packages Несоответствие хеш-суммы
E: Не удалось загрузить некоторые индексные файлы. Их игнорировали или вместо них использовали старые.

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

http://in.archive.ubuntu.com/ubuntu/dists/wily-backports/universe/i18n/Translation-en : хеши: SHA256: c03ff8f13394e66ce3b2d4645e779e658df189f96326c6eaa8f137a08eb0df30 Ожидаемого Hash: SHA256: c03ff8f13394e66ce3b2d4645e779e658df189f96326c6eaa8f137a08eb0df30
Получено 737 КБ за 28 с (26,0 КБ/с)
W: Не удалось получить https://apt.dockerproject.org/repo/dists/ubuntu-wily/main/binary-amd64/Packages Несоответствие хеш-суммы

https://apt.dockerproject.org/repo/dists/ubuntu-wily/main/binary-amd64/
../
InRelease 02 июня 2016 11:06 2.6K
Пакеты 02 июня 2016 2:37 28K
Пакеты.bz2 02 июня 2016 2:37 4.7K
Packages.gz 02 июня 2016 2:37 4.5K
Выпуск 02 июня 2016 3:43 1.7K
Release.gpg 02 июня 2016 3:43 801

Мы видим, что эти файлы были восстановлены ранее сегодня.
Контрольные суммы (хэши) для этих файлов должны соответствовать тому, что находится внутри подписанного файла контрольных сумм InRelease.
В InRelease https://apt.dockerproject.org/repo/dists/ubuntu-wily/main/binary-amd64/InRelease говорится, что этот файл был создан Дата: четверг, 02 июня 2016 г., 03:43:32 UTC. Однако отметка времени, показанная веб-сервером, — 02 июня 2016 г., 11:06.

Я ошеломлен тем, что этот процесс не автоматизирован, а контрольные суммы вычисляются независимо отдельными контейнерами Docker, и в случае спорного расчета между ними загрузка задерживается до тех пор, пока не сможет вмешаться человек.

@thaJeztah , значит, есть другое репо для коммерческих пользователей, которое не сломано?

Вот скрипт для Ubuntu, чтобы получить уведомление звуковым сигналом (воспроизведение аудиофайла) при обновлении контрольных сумм репозитория,
https://gist.github.com/simos/7ee8258ec17101e44bbfa93606694ede

Я думаю, что нечего сказать, кроме как получить официальный ответ от Docker по этому поводу.

@ krak3n да, для коммерчески поддерживаемой версии есть отдельные выпуски.

Для людей, использующих Travis, я могу исправить это следующим образом:

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 либо меняет репозиторий с «основного» на «тестовый» для APT, либо использует сценарий установки;
curl -fsSL https://test.docker.com | ш не работают.

W: Не удалось получить https://apt.dockerproject.org/repo/dists/ubuntu-trusty/InRelease . Не удалось найти ожидаемую запись «test/binary-amd64/Packages» в файле выпуска (неверная запись в sources.list или файл с искаженным форматом). )

E: Не удалось загрузить некоторые индексные файлы. Их игнорировали или вместо них использовали старые.

@xuedong09 вместо «тест» используйте «тестирование».

Я твитнул @docker @dockerstatus (несколько раз)... это серьезная проблема... удивлен, что они так молчат!

Мы работаем над этим, ребята.

Спасибо @crunis - это исправление Трэвиса работает.

Спасибо за работу над исправлением этого. Было бы здорово, если бы вы опубликовали результаты вскрытия после исправления.

Спасибо @hertzg и @thaJeztah, которые меняют репозиторий «main» на «testing» для APT.

@ xuedong09 xuedong09 Просто имейте в виду, что именно здесь мы публикуем предварительные пакеты.

Такая интересная единая точка отказа для экосистемы докеров

@babakgh Я тоже так думал. Надеюсь, вскрытие может предложить хорошую профилактику в будущем.

Это тоже влияет на меня.

Я все еще получаю: https://apt.dockerproject.org/repo/dists/debian-jessie/main/binary-amd64/Packages Hash Sum mismatch

Напоминает мне, что случилось с npm и NodeJS:

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

И еще, я тоже

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

Сопровождающие репозитория Docker. Тебе нужно:

• Автоматическое тестирование изменений
• Проверка работоспособности вашего репо
• в основном мониторинг и сигнализация

Я надеюсь, что это никогда не повторится. Docker вызывал здесь (на TravisCI) проблемы с производственным тестированием и развертыванием, хотя я не использую ни одного контейнера Docker в производстве. 😑

Всем жалобщикам и негодяям:

Существует коммерческая, платная и хорошо поддерживаемая версия Docker.

К вашему сведению, это версия сообщества, поддерживаемая по мере возможности и НЕ БОЛЬШЕ.

@vadviktor Это официальная позиция Докера, потому что я хотел бы ее процитировать?

@therealmarv В любом случае эта проблема не должна влиять на ваше производство или какие-либо конвейеры развертывания, поскольку никто не должен полагаться на подключение к Интернету или внешний репозиторий для создания и развертывания программного обеспечения.

@vadviktor Максимальное усилие не означает, что всех можно победить. Это означает, что мелкие ошибки и дефекты рассматриваются в конце концов. Вам по-прежнему нужно, чтобы все работало в лучшем случае.

Для ubuntu trusty (14.04) переключение с «основного» на «тестовый» репозиторий APT отлично сработало для меня.

+1

Я никогда не знал, что Docker — это двухуровневая организация, в которой пользовательская база разделена на имущих и неимущих. Неуклюжая установка докера является глобальной проблемой для всех, кто использует программное обеспечение, и поэтому поддержка, которую получают «коммерческие» люди, также должна распространяться на сообщество. Платный уровень для организации — это хороший способ заработать деньги, но он должен выходить за рамки основ, таких как возможность установки вашего программного обеспечения.

Несчастные случаи случаются, важно то, как мы с ними справляемся и какие уроки мы извлекаем. Большая часть этой ветки, кажется, кишит спекуляциями. Заранее благодарим всех членов команды Docker, работающих над устранением этой проблемы.

@vadviktor Ты работаешь в Докере?

@vadviktor Где я могу найти этот коммерческий репозиторий apt? Какой продукт я должен купить, чтобы получить к нему доступ?

@vadviktor Не работает в Docker и не поддерживает проект.

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

Похоже, теперь он работает для Ubuntu Xenial.

К вашему сведению, эта проблема находится на HN https://news.ycombinator.com/item?id=11822562 .

для всех, кто злится из-за этого простоя: вот милая картинка с оленем, чтобы успокоиться и скоротать время:

Верный, похоже, вернулся

Всем привет. Я работаю в Докере.

Во-первых, мои извинения за сбой. Я считаю нашу пакетную инфраструктуру критической инфраструктурой как для бесплатной, так и для коммерческой версии Docker. Это правда, что мы предлагаем лучшую поддержку коммерческой версии (это одна из ее функций), но это не должно относиться к фундаментальным вещам, таким как возможность загрузки ваших пакетов.

Команда работает над этой проблемой и будет продолжать предоставлять обновления здесь. Мы относимся к этому серьезно.

Некоторые из вас отметили, что время отклика и использование каналов связи кажутся неадекватными, например, бот @dockerststus не упомянул проблему при ее обнаружении. Я разделяю мнение, но я еще не знаю всей истории; вскрытие точно скажет нам, что пошло не так. На данный момент команда сосредоточена на устранении проблемы, и я не хочу их отвлекать от этого.

Как только вскрытие покажет, что пошло не так, мы предпримем соответствующие корректирующие действия. Я подозреваю, что отчасти это будет связано с лучшей координацией между основными инженерами и инженерами по инфраструктуре (две отдельные группы в Docker).

Спасибо и еще раз извините за неудобства.

хех - каталог есть, а упаковки нет - пожалуй, возьму еще кофе :-)
@shykes Спасибо за обновление - паршивый способ начать утро ...
Надеюсь, что день станет лучше отсюда

Мне грустно, что моя фотография оленя получила меньше +1, чем официальный ответ.

Я уже установил докер с https://get.docker.com | ш без ошибок.
Похоже, ребята из Docker исправили проблему,

Мы локализовали причину проблемы, и если она должна быть решена сейчас, попробуйте еще раз.

Может потребоваться очистка apt-кеша;

apt-get clean && apt-get update

Спасибо за исправление @thaJeztah

Ну, это было быстро для неожиданной проблемы, спасибо.

@snario всегда пожалуйста; не могу взять на себя ответственность за исправление, но рад видеть, что с этим разобрались 😅

👍

К сожалению, из-за этого в топе хакерских новостей появятся миллиарды комментариев. Большое спасибо за быстрое исправление @thaJeztah.

Интересно, стоит ли нам заблокировать эту ветку до того, как они появятся.

До сих пор было workarounds (либо возьмите .deb и установите с помощью dpkg, либо временно переключитесь на репозиторий testing и т. д.). Это не постоянные решения.

fix означает, что источник этой проблемы устранен, и мы можем пометить эту проблему как решенную.

Как сообщалось ранее, вы можете использовать скрипт для получения звукового уведомления, как только основные репозитории докеров будут исправлены,
https://gist.github.com/simos/7ee8258ec17101e44bbfa93606694ede
Кроме этого, делать особо нечего.

@simos см. мой предыдущий комментарий; https://github.com/docker/docker/issues/23203#issuecomment -223328829 проблема должна быть решена

@thaJeztah Я убедился, что проблема решена. Проверено на Ubuntu 15.10. Спасибо всем другим людям из Docker, которые помогли быстро решить эту проблему.

Спасибо всем за отчеты: мы очень сожалеем об этом. Мы изучаем детали и хронологию событий, которые привели к этому, и позаботимся о том, чтобы это больше не повторилось.

Я закрываю тему, но, конечно, не стесняйтесь, дайте мне знать, если вы обнаружите какие-либо оставшиеся причуды.

Ubuntu 14.04 Здесь проблема решена!

Вероятно, не следует удивляться, но шокирует то, как много людей рискуют своей инфраструктурой из-за жесткой зависимости от внешних репозиториев. Я даже не делаю этого со своими домашними системами.

А потом жаловаться на то, что Docker имеет единую точку отказа?

@jalawrence Докер — это верхушка айсберга…
Вы слышали о недавних проблемах с node.js и о том, что один разработчик вытащил один-единственный пакет?
Я почти уверен, что большинство разработчиков php, использующих Composer — де-факто менеджер пакетов для этой платформы — также не хранят полные копии всех зависимостей своего сайта, и тот факт, что до сих пор не было никаких сбоев, — это скорее удача, чем что-либо еще.
Проблема в том, что теперь все и их собаки зависят от $world, а локальное кэширование всех зависимостей — сизифов труд. Должен ли я кэшировать весь debian, весь packagist, весь cpan, весь rubygems, весь npm внутри обратного прокси за свой счет?
И потом: если github, bitbucket или travis не работают, что все равно смогут сделать мои разработчики? Хочу ли я вернуться к тому дню, когда мне приходилось размещать все это?