Повторная попытка таймаута подключения

Ответ 1

Я решил эту проблему и отвечу, если у кого-то другая проблема.

Что я сделал: я включил GUI виртуального окна, чтобы увидеть, что он ждал ввода при запуске, чтобы выбрать, хочу ли я загружаться непосредственно на ubuntu или safemode и т.д.

Чтобы включить GUI, вы должны поместить это в свою конфигурацию брандмауэра Vagrantfile:

config.vm.provider :virtualbox do |vb|
  vb.gui = true
end

Ответ 2

Когда вы застряли с вашей бродягой машиной, как описано выше, нет необходимости загружаться в режиме gui (и невозможно без X-сервера).

Во время загрузки виртуальной машины в отдельном окне терминала просто найдите идентификатор работающей машины.

vboxmanage list runningvms

Это приведет к чему-то вроде этого:

"projects_1234567890" {5cxxxx-cxxx-4xxx-8xxx-5xxxxxxxxxx}

Довольно часто виртуальная машина просто ждет, когда вы выберете опцию в загрузчике. Вы можете отправить соответствующий код ключа (в случае, Enter) в vm с помощью controlvm:

vboxmanage controlvm projects_1234567890 keyboardputscancode 1c

Что это. Ваша виртуальная машина продолжит процесс загрузки.

Ответ 3

Одна вещь, которую нужно проверить дважды, - это то, что в BIOS вашего компьютера включена функция виртуализации оборудования.

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

Ноутбук, который я только настраивал, все время показывал ту же проблему. После нескольких часов поиска я наконец нашел подсказку, чтобы узнать, включена ли в BIOS аппаратная виртуализация.

Вот содержание сообщения, которое я нашел:

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

• Убедитесь, что ваш брандмауэр или антивирус не блокирует программу (что я сомневаюсь, что это произойдет часто)
• Дайте вашей бродяжнейшей машине время для перерыва. Если у вас нет очень быстрого ПК /Mac, VM займет некоторое время, чтобы загрузиться в состояние готовности к SSH, поэтому тайм-ауты произойдут.
• Поэтому сначала попробуйте дать полный брандмауэр ПОЛНОСТЬЮ, прежде чем заключить, что есть ошибка.
• Если брандмауэры полностью исчерпаны, увеличьте ограничение времени ожидания в бродячем файле на несколько минут и повторите попытку.
• Если это еще не работает, попробуйте очистить загрузочную машину с помощью интерфейса VirtualBox и предварительно включить графический интерфейс машины. Если GUI не показывает ничего происходящего (т.е. Только черный экран, без текста), пока он загружается, тогда ваша машина бродяг имеет проблемы.
• Уничтожьте всю машину через интерфейс VB и переустановите.
• Удалите файлы изображений ubuntu в папке Vagrant Images в папке пользователя и перезагрузите и установите.
• У вас даже есть процессор Intel, поддерживающий 64-битную аппаратную виртуализацию? Погугли это. Если вы это сделаете, убедитесь, что в вашем Bios отключена настройка.
• Отключить функцию hyper-v, если вы используете Windows 7 или 8. Google, как отключить.
• Убедитесь, что вы используете клиент с поддержкой SSH. Используйте Git bash. Скачать: http://git-scm.com/downloads
• Установите 32-разрядную версию ubuntu, например, trusty32 или exact32. Просто измените версию в бродячем файле и переустановите vagrant в новый каталог.
• Убедитесь, что вы используете последние версии бродяг и виртуальных боксов. Последние курорты: отформатируйте свой компьютер, переустановите окна и купите процессор ядра iomething.

Надеюсь, что это поможет.

Ответ 4

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

Ответ 5

У меня была такая же проблема. Я думал, что проблема может быть связана с SSH-ключами (неправильная локализация файла или что-то еще, но я проверил его много раз), но вы всегда можете добавить имя пользователя и пароль в разделе настроек (без использования ssh-ключей) и запустить gui, чтобы код в Vagrantfile должно выглядеть примерно так же, как показано ниже:

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  config.ssh.username = "vagrant"
  config.ssh.password = "vagrant"

   config.vm.provider "virtualbox" do |vb|
     vb.gui = true
   end
end

В моем случае, даже если был отображен GUI, я получил черный экран (никаких ошибок или возможности входа в систему или что-то еще), а в консоли я получил Error: Connection timeout. Retrying... много раз. Я убедился, что в BIOS включен V-x (виртуализация), я проверил множество комбинаций версий как Virtual Box, так и Vagrant вместе и много бранных ящиков (для некоторых из них у меня не было черного экрана в графическом интерфейсе, но у меня все еще есть соединение проблемы). Наконец, я снова обновил VirtualBox и Vagrant до последних версий, и проблема все еще произошла.

Самое главное - посмотреть иконки в VirtualBox после запуска vagrantup (с графическим интерфейсом в Vagrantfile, как я показал выше), как на рисунке ниже.

Хотя у меня не было ошибок в VirtualPC (никаких предупреждений о том, что VT-x не включен), мой значок V был более серым, поэтому означает, что VT-x отключен. Как я уже сказал, он все время включался в мой BIOS.

Наконец, я понял, что проблема может возникнуть при помощи HYPER-V, которую я также установил и включил для тестирования сайтов в более старом Internet Explorer. Я пошел в Windows Control Panel -> Programs and functions / Software и выбираю из меню слева Turn on or Turn off Windows functions (надеюсь, что вы найдете их, я использую польские Windows, так что не знаю точных английских имен). Я отключил Hyper-V, перезапустил ПК и после запуска Virtual Box и vagrant up у меня, наконец, не было ошибок, в GUI у меня есть экран входа, а значок V остановлен как серый.

Я потратил много времени на решение этой проблемы (и многие перезагрузки ПК), поэтому я надеюсь, что это может быть полезно для всех, у кого есть проблемы в Windows, - убедитесь, что в вашей панели управления отключен Hyper-V.

Ответ 6

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

vagrant destroy
vagrant up

и все было хорошо. Моя была очень простой, но я сделал это так, сократив Vagrantfile до всего лишь config.vm.box = "ubuntu/trusty64", и он все еще делал это. Вот почему уничтожение и начало снова казалось лучшим выбором. Учитывая безгражданность этих бродячих образов, я не понимаю, почему это не сработало бы в каждом случае. Я просто вникаю в это, и я могу еще узнать, что это не так.

Ответ 7

У меня возникла такая же проблема на машине Windows 8.1. Тайм-аут соединения и включение gui не был полезен вообще, экран был черным. Исправление в моем случае было отключением "Hyper V"

Цитата из документации Vagrant https://docs.vagrantup.com/v2/hyperv/index.html

Предупреждение. Включение Hyper-V приведет к тому, что VirtualBox, VMware и другие технологии виртуализации перестанут работать. Смотрите этот пост в блоге https://www.hanselman.com/blog/SwitchEasilyBetweenVirtualBoxAndHyperVWithABCDEditBootEntryInWindows81.aspx, чтобы создать простой загрузочный элемент для загрузки Windows без включения Hyper-V, если вам понадобятся другие гипервизоры.

Ответ 8

Если вы работаете с Windows 8 или 10, это то, что сработало для меня:

• Измените настройки BIOS, чтобы разрешить виртуализацию 64-разрядной версии.
• Вот как это сделать:
  • Перезагрузите компьютер с помощью Advanced Startup (перейдите к расширенному запуску - "сейчас перейдите" - "Устранение неполадок" - "расширенный вариант" - "Настройка встроенного ПО UEFI" - "Перезагрузка" )
  • Внутри окна BIOS - перейдите в меню "Дополнительно" /вкладку - Включите "Виртуальная технология Intel".
  • Сохранить и выйти.

Ответ 9

У меня возникла проблема с существующим полем (не знаю, что изменилось), но я мог подключиться через SSH, даже если ящик Vagrant не загрузился. Так как это произошло, мой ключ SSH каким-то образом изменился.

Из корневой папки бродяг я запустил vagrant ssh-config, который рассказал мне, где был ключевой файл. Я открыл это с помощью puttygen, а затем дал мне новый ключ.

В моем гостевом Linux я редактировал ~/.ssh/authorized_keys и удалял там новый открытый ключ.

Все работает снова - пока!

Ответ 10

У меня была такая же проблема после того, как я удалил эту строку из моего Vagrantfile:

config.vm.network "private_network", type: "dhcp"

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

Ответ 11

У меня была такая же проблема, но ни один из других ответов полностью не разрешил мою проблему. Answer by @Kiee было полезно, хотя все, что я мог видеть в графическом интерфейсе, - это черный экран (с подчеркиванием в левом верхнем углу, эта проблема в Virtual Box также была поднята отдельно в переполнении стека, снова ничего помог).

В конце концов, решение оказалось очень простым: проверить версию вашей виртуальной машины.

Точнее, у меня была коробка от кого-то другого с 64-разрядным Debian, но Virtual Box настаивала на том, чтобы рассматривать ее как 32-битную, чего я не заметил. Чтобы изменить его, откройте Virtual Box, затем откройте терминал и запустите

vagrant up

ждать строки

default: SSH auth method: private key

теперь вы можете нажать ctrl + C (или дождаться таймаута) и запустить

vagrant halt

ваша виртуальная машина не будет уничтожена, поэтому вы можете увидеть ее в меню Virtual Box, но ее можно отключить, чтобы вы могли изменять настройки. Выберите свой аппарат в меню, нажмите "Настройки" → "Общие" и выберите "Версия", для меня это "Debian (64-бит)". После этого типа vagrant up снова.

Если это случай для вас (или различные изменения в "Настройках" решили вашу проблему), вы можете создать новое окно из исправленного ввода

vagrant package --output mynew.box

Дополнительная информация: хост 32-разрядный Ubuntu 12.04, гостевой 64-разрядный Debian 8.1, Virtual Box 5.0.14, Vagrant 1.8.1

Ответ 12

Я тестировал смонтированную папку в моей бродящей виртуальной машине, добавив новую запись в /etc/fstab. Позже я вышел из системы, побежал на бродячую остановку, но когда я побежал vagrant up, я получил:

SSH auth method: private key
Warning: Remote connection disconnect. Retrying...

Я прочитал все эти сообщения и пробовал все те, которые казались мне важными для моего дела (за исключением бродячего уничтожения, который наверняка устранил бы мою проблему, но был последним средством в моем случае). Сообщение от @Kiee дало мне идею попытаться загрузить мою виртуальную машину непосредственно из графического интерфейса VirtualBox. Во время процесса загрузки VM остановилась и спросила меня, хочу ли я пропустить установку тестовой папки, которую я добавил ранее, в /etc/fstab. (Почему вагрант не смог загрузить виртуальную машину.) После ответа "НЕТ" VM не загрузила никаких проблем. Я вошел в систему, удалил непослушную строку из моей fstab и остановил виртуальную машину.

После этого бродяга смог нормально загрузиться.

Вынос? Если внезапный бродяга не может вернуться в вашу виртуальную машину, попробуйте загрузить непосредственно у поставщика (VirtualBox в моем случае). Скорее всего, ваш ботинок висит за что-то совершенно не связанное с SSH.

Ответ 13

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

• vagrant up не смог найти мой ssh ​​' id_rsa' (потому что в то время у меня его еще не было): Я побежал ssh-keygen -t rsa -b 4096 -C "[email protected]", основываясь на этой статье GitHub, и вошел в это,

• Затем у меня возникла такая же проблема с этим вопросом: Предупреждение: время ожидания подключения. Повторная попытка... ", вечно...: Итак, после многого чтения, я перезапустил свою систему и посмотрел на свой BIOS (F2, чтобы попасть туда, на ПК), и было отключено виртуализация. Я включил это, сохранил и снова запустил систему, чтобы проверить, не изменилось ли что-либо.

После этого vagrant up работал как шарм! Это 4 утра, но он работает! Как здорово, ха?: D Как я знаю, таких мазохистских разработчиков, как я, очень мало, что бы попробовать это в Windows, особенно в Windows 10, я просто не мог не забыть приходить сюда и оставил свое слово... Другая важная информация: я пытаюсь настроить Laravel 5, используя Homestead, VirtualBox, composer и т.д. Он сработал. Поэтому, надеюсь, этот ответ помогает, как этот вопрос, и ответы помогли мне. Мои наилучшие пожелания. G-прощай!

Ответ 14

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

• проверьте, включена ли виртуализация в BIOS (согласно comment),
• система ожидает взаимодействия пользователя (например, раздел разделов не готов),
• несоответствие вашего закрытого ключа (проверьте конфигурацию через vagrant ssh-config),
• Процесс загрузки занимает гораздо больше времени (попробуйте увеличить config.vm.boot_timeout),
• загрузка с неправильного диска (например, из ISO установщика),
• неправильная конфигурация брандмауэра VM (например iptables настройка),
• правила локального брандмауэра, конфликт портов или конфликт с программным обеспечением VPN,
• sshd неправильная конфигурация.

Чтобы отладить проблему, запустите ее как опцию --debug или как:

VAGRANT_LOG=debug vagrant up

Если нет ничего очевидного, попробуйте подключиться к нему с другого терминала, нажав vagrant ssh или:

vagrant ssh-config > vagrant-ssh; ssh -F vagrant-ssh default

Если SSH все еще не работает, попробуйте запустить его с графическим интерфейсом (например, config.gui = true).

Если это не так, проверьте выполняемые процессы (например: by: vagrant ssh -c 'pstree -a') или подтвердите свой sshd_config.

Если это одноразовая виртуальная машина, вы всегда можете попробовать ее destroy и up снова.

Вы также должны рассмотреть возможность обновления вашего Vagrant и Virtualbox.

Для получения дополнительной информации посетите страницу Отладка и устранение неполадок.

Ответ 15

У меня была такая же проблема, когда я использовал поле x64 (chef/ubuntu-14.04).

Я изменил на x32 и работал (hashicorp/exact32).

Ответ 16

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

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

Ответ 17

Я получил это при запуске vagrant/VirtualBox внутри VirtualBox. Я решил это, запустив машину бродяг в главной машине.

Ответ 18

Установка битов ubuntu32 на бит AMD64 сделала трюк. У меня нет доступа к BIO с его ограниченной средой, но я все еще мог заставить его работать с ubuntu/trusty32 вместо ubuntu/trusty64

Использование Vagrant 1.6.3 с VirtualBox 4.3.15 в Windows 7 SP1

надеюсь, что это поможет.

Ответ 19

Для меня это была совместимость между бродягой и виртуальной коробкой.

Я на окнах 10, и что я сделал, я удалил бродягу и виртуальную коробку

Затем установите старую версию виртуального окна специально для версии 4.3.38 (установите для этого пакета обновления также)

Затем была установлена ​​последняя копия бродяг (1.8.5 на данный момент)

После этого он работал.

Ответ 20

Я узнал, что на MacOS с VirtualBox добавление этого параметра в Vagrantfile позволит вам продолжить:

config.vm.provider 'virtualbox' do |vb|
  vb.customize ['modifyvm', :id, '--cableconnected1', 'on']
end

Ответ 21

Если вы не хотите включать графический интерфейс, а затем отключить его позже, вы также можете установить пакет расширения из Oracle:

http://www.oracle.com/technetwork/server-storage/virtualbox/downloads/index.html#extpack

Затем поместите это в свой Vagrantfile, чтобы включить VRDP:

vb.customize ["modifyvm", :id, "--vrde", "on"]

Теперь вы можете использовать RDP для подключения к вашему ящику по требованию без необходимости запуска SSH или GUI, который открыт все время.

Ответ 22

Для меня работала 64-битная виртуализация 64-разрядной ОС (Ubuntu 13.10) из BIOS.

Ответ 23

Еще одно возможное решение для пользователей поставщика VMware: Для меня проблема была решена после удаления параллельной установки VirtualBox на том же хост-компьютере. Сетевые интерфейсы между VMware и VirtualBox, по-видимому, противоречивы.

Ответ 24

Я столкнулся с той же проблемой. Я исправил это, включив настройку Virtualization из BIOS.

Ответ 25

Удалить файл:

C:\Users\UserName\\.vagrant.d\insecure_private_key

Затем запустите:

vagrant up

Ответ 26

Проверьте, включена ли виртуализация вашего процессора в настройках BIOS.

Ответ 27

FWIW-- Моя проблема связана с использованием действительно старого файла конфигурации вместо более нового. Использование нового файла конфигурации (и, таким образом, измененного/измененного DSL) немедленно устранило мои проблемы.

Ответ 28

Что помогло мне, так это включение виртуализации в BIOS, потому что машина не загрузилась.

Ответ 29

Вместо того, чтобы ctrl-d-ing из виртуального окна, как я привык делать всякий раз, когда я ssh во что-либо, я считаю, что бродяга предпочтет, чтобы вы вошли в другой терминал и сделали:

vagrant halt

чтобы остановить окно. Тогда проблем с возвратом в VB не будет.

Ответ 30

Я столкнулся с одной и той же проблемой, однако не для меня эти решения работали! Я решил это, понизив Vagrant до 1.6.2, и теперь он работает!