Час очікування з’єднання застряг, намагаючись повторити спробу

Мій бродяг минулої ночі працював чудово. Я щойно увімкнув ПК, натисніть vagrant up, і ось що я отримую:

==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...

Хтось мав це раніше? vagrant ще не широко висвітлений в Інтернеті, і я не можу знайти причину, чому це відбувається.

Я вирішив цю проблему і відповім у випадку, якщо хтось інший має подібне питання.

Що я зробив: я включив графічний інтерфейс віртуального вікна, щоб побачити, що він чекає на введення при запуску, щоб вибрати, чи хочу я завантажуватися безпосередньо на ubuntu або safemode тощо.

Щоб увімкнути графічний інтерфейс, ви повинні помістити це у свій бродячий конфігурацію Vagrantfile:

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

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

Поки ваш VM завантажується, в окремому вікні терміналу просто з’ясуйте ідентифікатор запущеної машини.

vboxmanage list runningvms

У результаті вийде щось подібне:

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

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

vboxmanage controlvm projects_1234567890 keyboardputscancode 1c

Це воно. Ваша віртуальна машина продовжить процес завантаження.

Потрібно ще раз перевірити, чи ввімкнено апаратну віртуалізацію в BIOS вашого пристрою.

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

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

Ось зміст публікації, яку я знайшов:

Я бачу, що все ще є деякі користувачі, які відчувають цю проблему. Отже, я спробую узагальнити список нижче можливих рішень проблеми із тимчасовим очікуванням SSH:

• Переконайтесь, що ваш брандмауер чи антивірус не блокують програму (що, мабуть, часто трапляється)
• Дайте вашій бродяжній машині деякий час, щоб відбулися очікування. Якщо у вас не дуже швидкий ПК / Mac, то для завантаження в стан готового SSH потрібно буде час роботи віртуального комп'ютера.
• Тому спершу спробуйте дозволити повноцінний тайм-аут, перш ніж дійти висновку про помилку.
• Якщо час бродячого закінчився повністю, то збільште обмеження часу очікування у файлі бродяг до декількох хвилин та повторіть спробу.
• Якщо це все-таки не працює, спробуйте очистити завантажувальну машину через інтерфейс VirtualBox і заздалегідь увімкніть GUI машини. Якщо GUI не показує нічого, що відбувається (наприклад, чорний екран, немає тексту) під час завантаження, то у вашої бродячої машини виникли проблеми.
• Знищіть всю машину через інтерфейс VB та перевстановіть.
• Видаліть файли зображень ubuntu з папки Vagrant Images в папці користувача та перезавантажте та встановіть.
• У вас навіть є процесор Intel, який підтримує 64-бітну апаратну віртуалізацію? Google це. Якщо ви зробите це, переконайтеся, що у вашому біографії немає налаштувань, які відключають цю функцію.
• Вимкніть функцію гіпер-v, якщо ви використовуєте Windows 7 або 8. Google як відключити.
• Переконайтеся, що ви працюєте через клієнт із підтримкою SSH. Використовуйте Git bash. Завантажте: http://git-scm.com/downloads
• Встановіть 32-бітну версію ubuntu, як trusty32 або preci32. Просто змініть версію у файлі бродяги та перевстановіть бродягу у новий каталог.
• Переконайтеся, що ви використовуєте найновіші версії бродячих та віртуальних скриньок. Останні можливості: відформатуйте свій комп’ютер, перевстановіть вікна та придбайте процесор Intel Core - це щось.

Сподіваюся, що це допомагає.

Я знайшов рішення - перевірити варіант підключення кабелю в адаптері 1, який приєднаний до NAT. Я справді не знаю, це моя четверта коробка для бродяг, але це єдиний варіант з кабельним підключенням, який не перевіряється, і після перевірки він працює.

У мене була точно така ж проблема. Я думав, що проблема може бути з ключами 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

У моєму випадку, навіть якщо відображався графічний інтерфейс, у мене з'явився чорний екран (відсутність помилок чи можливість входу або щось інше), а в консолі я отримував Error: Connection timeout. Retrying...багато разів. Я переконався, що у BIOS увімкнено VT-x (віртуалізацію), я перевірив багато комбінацій версій як Virtual Box, так і Vagrant разом і безліч короб 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нарешті, помилок не було, у графічному інтерфейсі у мене є екран входу, і моя Vпіктограма перестала бути сірою.

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

Моя помилка працює, і тоді це "Попередження: Відключення віддаленого з'єднання. Повторна спроба ..." знову і знову - можливо, 20 разів - поки він не підключився. На основі відповідей вище я просто

vagrant destroy
vagrant up

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

У мене виникла та ж проблема на машині 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, якщо вам буде потрібен інший гіперспонсор.

Якщо ви працюєте в Windows 8 або 10, для мене це працювало:

1. Змініть налаштування BIOS, щоб дозволити віртуалізацію 64 біт.
2. Ось як:
   • Перезавантажте ПК за допомогою розширеного запуску (перейдіть до розширеного запуску - зараз запустіть '-' усунення несправностей '-досконалена опція'-' налаштування прошивки UEFI '-' перезапуск ')
   • Всередині вікна BIOS - перейдіть до меню / вкладці "Додатково" - Увімкніть "Віртуальну технологію Intel"
   • Зберегти та вийти.

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

З корінної папки бродячого я побіг, vagrant ssh-configякий сказав мені, де знаходиться ключ-файл. Я відкрив це за допомогою puttygen і тоді це дало мені новий ключ.

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

Все знову працює - поки що!

У мене виникла та сама проблема, коли я видалив цей рядок зі свого Vagrantfile:

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

Після того, як я повернув цю лінію, VM чудово завантажив

Час очікування з'єднання SSH під час початкового завантаження може бути пов'язано з різними причинами, такими як:

• перевірити, чи включена віртуалізація в BIOS (відповідно до коментаря ),
• система очікує взаємодії з користувачем (наприклад, розділ для спільного доступу не готовий ),
• невідповідність вашого приватного ключа (перевірте конфігурацію через 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).

Якщо ні, перевірте запущені процеси (наприклад, за vagrant ssh -c 'pstree -a':) або перевірте свої sshd_config.

Якщо це одноразовий VM, ви завжди можете спробувати destroyйого та upще раз.

Також слід розглянути можливість оновлення Vagrant та Virtualbox.

Для отримання додаткової інформації перевірте сторінку налагодження та усунення несправностей .

У мене було те саме питання, але жодна з інших відповідей повністю не вирішила мою проблему. Відповідь від @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

Тут є багато хороших відповідей, і я не зміг все прочитати, але, я просто прийшов, щоб також дати свій невеликий внесок. У мене було 2 різні проблеми:

1. vagrant upне зміг знайти свій ssh ​​' id_rsa ' (тому що я його ще не мав на той час): я побіг ssh-keygen -t rsa -b 4096 -C "myemailaddress@mydomain.com", спираючись на цю статтю GitHub , і voilá, проступив через це;

2. Потім у мене виникла та сама проблема з цим питанням " Попередження: Час з'єднання вичерпано. Повторне намагання ... ", вічно ...: Отже, прочитавши багато, я перезапустив свою систему і подивився на свій BIOS (F2, щоб отримати там, на ПК), і там відключена віртуалізація . Я ввімкнув це, зберег і запустив систему ще раз, щоб перевірити, чи вона щось змінила.

Після цього vagrant upпрацював як шарм! Це 4 ранку, але він працює! Як круто, так? : D Як я знаю, є дуже мало мазохістських розробників, як я, які спробували б це в Windows, особливо в Windows 10 , я просто не міг не забути приїхати сюди і залишив своє слово ... Ще одна важлива інформація, це те, Я намагався налаштувати Laravel 5 , використовуючи Homestead, VirtualBox, композитора тощо. Це спрацювало. Тож сподіваюся, що ця відповідь допомагає, як це питання, і відповіді мені допомогли. Мої найкращі побажання. До побачення!

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

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

Я прочитав усі ці пости і спробував усі ті, що здалися актуальними для моєї справи (за винятком бродячих руйнувань, які, безумовно, вирішили б мою проблему, але в моєму випадку були крайнім засобом). Допис від @Kiee дав мені ідею спробувати завантажувати свій VM безпосередньо з GUI VirtualBox. Під час завантаження VM зупинився і запитав мене, чи хочу я пропустити монтаж тестової папки, до якої я додав раніше /etc/fstab. (Ось чому бродяг не міг завантажувати VM.) Після відповіді "НІ" VM завантажився без проблем. Я ввійшов у систему, вийняв неслухняний рядок зі свого fstab та вимкнув VM.

Після цього бродяг зміг завантажитися просто чудово.

Винос? Якщо раптом бродяг не може завантажитися назад у вашу машину управління, спробуйте завантажитися безпосередньо у провайдера (у моєму випадку VirtualBox). Цілком ймовірно, що ваш завантажувач висить на щось абсолютно не пов’язане з SSH.

У мене була така ж проблема, коли я використовував x64 box (chef / ubuntu-14.04).

Я змінив на x32, і він працював (hashicorp / preci32).

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

Я думаю, що моя проблема була пов’язана з тим, що якийсь процес "kworker" отримував помилку і постійно виходив з часу у ВМ, і тому важке перезавантаження, здавалося, перезавантажило процес правильно, тоді як збереження та відновлення просто відновило порушений процес у його зламаному стані.

Я отримав це під час запуску бродяги / VirtualBox всередині VirtualBox. Я вирішив це, запустивши бродячу машину в хост-машині.

Я з’ясував, що на MacOS з VirtualBox додавання цього до Vagrantfile дозволить вам піти далі:

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

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

Використання Vagrant 1.6.3 з VirtualBox 4.3.15 для Windows 7 SP1

сподівання, що допомагає.

Для мене це була сумісність між бродячим та віртуальним ящиком.

Я на Windows 10, і що я зробив, я видалив бродячу та віртуальну скриньку

Потім встановіть стару версію віртуальної коробки, спеціально версію 4.3.38 (Встановіть розширення також для цієї версії)

Потім встановлено останню копію бродячого (1.8.5 на даний момент)

Після цього це спрацювало.

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

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

Потім поставте це у свій Vagrantfile, щоб увімкнути VRDP:

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

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

Ще одне можливе рішення для користувачів постачальника VMware: для мене проблема була вирішена після видалення паралельної установки VirtualBox на тій самій хост-машині. Мережеві інтерфейси між VMware та VirtualBox були, мабуть, суперечливими

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

Видаліть файл:

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

Потім запустіть:

vagrant up

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

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

У моєму випадку, надавши йому статичну IP-адресу, просто вирішено проблему:

config.vm.network "private_network", ip: "192.168.50.50"

FWIW-- Моя проблема була через використання дійсно старого конфігураційного файла замість більш нового. Використання нового файлу конфігурації (і, отже, перероблений / змінений DSL) миттєво усунуло мої проблеми.

Що мені допомогло - це включення віртуалізації в BIOS, оскільки машина не завантажувалася.

Замість того, щоб ctrl-d-ing виходив з віртуальної скриньки, як я не хочу робити кожного разу, коли я врізаюсь у що-небудь, я вважаю, що бродячий вважав за краще, щоб ви потрапили в інший термінал і зробили:

vagrant halt

щоб зупинити коробку. Тоді не буде жодних проблем із поверненням до VB.