Błędne przekroczenie limitu czasu połączenia zablokowanego

Mój włóczęga pracował zeszłej nocy idealnie. Właśnie włączyłem komputer, uderzyłem vagrant upi oto co otrzymuję:

==> 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...

Czy ktoś już to miał? Vagrant nie jest jeszcze szeroko omawiany w sieci i nie mogę znaleźć powodu, dla którego tak się dzieje.

Rozwiązałem ten problem i odpowiem na wypadek, gdyby ktoś miał podobny problem.

Zrobiłem to: włączyłem GUI Virtual boxa, aby zobaczyć, że czeka on na dane wejściowe podczas uruchamiania, aby wybrać, czy chcę uruchomić bezpośrednio do trybu Ubuntu lub Safemode itp.

Aby włączyć GUI, musisz umieścić to w swojej błędnej konfiguracji Vagrantfile:

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

Kiedy utkniesz z włóczęgą w sposób opisany powyżej, nie ma potrzeby uruchamiania w trybie GUI (i jest to niemożliwe bez serwera X).

Podczas uruchamiania maszyny wirtualnej w osobnym oknie terminala po prostu znajdź identyfikator uruchomionej maszyny.

vboxmanage list runningvms

Spowoduje to coś takiego:

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

Dość często maszyna wirtualna po prostu czeka, aż wybierzesz opcję w bootloaderze. Możesz wysłać odpowiedni kod klucza (w przypadku, Enter) do vm za pomocą controlvm:

vboxmanage controlvm projects_1234567890 keyboardputscancode 1c

Otóż ​​to. Twoja maszyna wirtualna będzie kontynuować proces uruchamiania.

Jedną rzeczą, którą należy dokładnie sprawdzić, jest to, czy wirtualizacja sprzętu jest włączona w systemie BIOS komputera.

Moim problemem jest ten sam ciąg limitów czasu, ale widziałem tylko czarny ekran w GUI.

Laptop, który właśnie konfigurowałem, ciągle wyświetlał ten sam problem. Po wielu godzinach poszukiwań w końcu znalazłem wskazówkę, czy BIOS ma włączoną wirtualizację sprzętu.

Oto treść znalezionego postu:

Widzę, że niektórzy użytkownicy nadal doświadczają tego problemu. Spróbuję więc podsumować poniższą listę niektórych możliwych rozwiązań problemu przekroczenia limitu czasu SSH:

• Upewnij się, że zapora sieciowa lub program antywirusowy nie blokuje programu (co, jak sądzę, często się zdarza)
• Daj swojej włóczęgi trochę czasu na przekroczenie limitu czasu. Jeśli nie masz bardzo szybkiego komputera PC / Mac, maszyna wirtualna zajmie chwilę, aby uruchomić się w stanie gotowości SSH, więc przekroczą limit czasu.
• Dlatego najpierw spróbuj CAŁKOWICIE przekroczyć limit czasu przed stwierdzeniem, że wystąpiła usterka.
• Jeśli włóczęga przekroczy limit czasu, zwiększ limit czasu w pliku włóczęgi do kilku minut i spróbuj ponownie.
• Jeśli to nadal nie działa, spróbuj wyczyścić bootowalną maszynę za pomocą interfejsu VirtualBox i wcześniej włączyć graficzny interfejs użytkownika maszyny. Jeśli GUI nie pokazuje niczego, co się dzieje (tj. Tylko czarny ekran, bez tekstu) podczas uruchamiania, oznacza to, że na twojej błędnej maszynie występują problemy.
• Zniszcz całą maszynę za pomocą interfejsu VB i zainstaluj ponownie.
• Usuń pliki obrazów ubuntu z folderu Vagrant Images w folderze użytkownika i ponownie pobierz i zainstaluj.
• Czy masz nawet procesor Intel obsługujący 64-bitową wirtualizację sprzętu? Wygoogluj to. Jeśli to zrobisz, upewnij się, że nie ma ustawienia w twoim Bios wyłączającym tę funkcję.
• Wyłącz funkcję hyper-v, jeśli korzystasz z systemu Windows 7 lub 8. Google, jak ją wyłączyć.
• Upewnij się, że korzystasz z klienta obsługującego SSH. Użyj Git Bash. Pobierz: http://git-scm.com/downloads
• Zainstaluj 32-bitową wersję systemu Ubuntu, taką jak trusty32 lub precision32. Wystarczy zmienić wersję w pliku włóczęgi i ponownie zainstalować włóczęgę w nowym katalogu.
• Upewnij się, że korzystasz z najnowszych wersji Vagrant i Virtualbox. Ostateczne rozwiązania: sformatuj komputer, zainstaluj ponownie system Windows i kup procesor isomething Intel Core.

Mam nadzieję, że to pomaga.

Rozwiązaniem, które znalazłem, jest sprawdzenie opcji podłączenia kabla w adapterze 1, który jest podłączony do NAT. Naprawdę nie wiem, to jest moje czwarte pudełko włóczęgi, ale jest to jedyne z niezaznaczoną opcją połączenia kablowego, a po sprawdzeniu działa.

Miałem dokładnie ten sam problem. Myślałem, że problem może być z kluczami SSH (zła lokalizacja pliku lub coś innego, ale sprawdziłem to wiele razy), ale zawsze możesz dodać w sekcji konfiguracji nazwę użytkownika i hasło (bez użycia kluczy ssh) i uruchomić GUI, więc kod Vagrantfilepowinien wyglądać mniej więcej jak poniżej:

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

W moim przypadku, nawet jeśli GUI był wyświetlany, dostałem czarny ekran (brak błędów, możliwość logowania lub cokolwiek innego), aw konsoli dostałem Error: Connection timeout. Retrying... wiele razy. Upewniłem się, że mam włączony VT-x (wirtualizacja) w BIOS-ie, sprawdziłem wiele kombinacji wersji Virtual Box i Vagrant razem i wiele Vagrant (dla niektórych z nich nie miałem czarnego ekranu w GUI, ale nadal mam połączenie problemy). Wreszcie zaktualizowałem VirtualBox i Vagrant ponownie do ostatnich wersji i problem nadal występował.

Najważniejsze było spojrzenie na ikony w VirtualBox po uruchomieniu vagrantup (z GUI w, Vagrantfilejak pokazano powyżej), jak na poniższym obrazku

Chociaż nie miałem żadnych błędów w VirtualPC (brak ostrzeżeń, że VT-x nie jest włączony) mój V ikona była wcześniej szara, co oznacza, że ​​VT-x został wyłączony. Jak powiedziałem, miałem włączony przez cały czas w BIOS-ie.

W końcu zdałem sobie sprawę z problemu, przez HYPER-Vktóry również zainstalowałem i umożliwiłem testowanie witryn na starszym Internet Explorerze. Poszedłem do systemu Windows Control Panel -> Programs and functions / Softwarei wybrałem z menu po lewej stronie Turn on or Turn off Windows functions(mam nadzieję, że je znajdziesz, używam polskiego systemu Windows, więc nie znam dokładnych angielskich nazw). Wyłączyłem Hyper-V, zrestartowałem komputer i po uruchomieniu Virtual Boxa vagrant upwreszcie nie miałem błędów, w GUI mam ekran logowania i moja Vikona przestała być szara.

Zmarnowałem dużo czasu na rozwiązanie tego problemu (i wiele restartów komputera), więc mam nadzieję, że może to być pomocne dla każdego, kto ma problem w systemie Windows - upewnij się, że masz wyłączoną funkcję Hyper-V w Panelu sterowania.

Mój działał dobrze, a potem to „Ostrzeżenie: połączenie zdalne rozłączone. Ponawianie ...” w kółko - może 20 razy - aż do połączenia. Na podstawie powyższych odpowiedzi właśnie

vagrant destroy
vagrant up

i wszystko było dobrze. Mój był bardzo prosty, ale zrobiłem to w ten sposób, zmniejszając plik Vagrantfile do samego końca config.vm.box = "ubuntu/trusty64"i nadal to robiłem. Dlatego właśnie niszczenie i rozpoczynanie od nowa wydawało się najlepszym wyborem. Biorąc pod uwagę bezpaństwowość tych włóczęgów, nie rozumiem, dlaczego to nie zadziałałoby w każdym przypadku. Wchodzę w to i mogę jeszcze dowiedzieć się, że to nieprawda.

Ten sam problem wystąpił na komputerze z systemem Windows 8.1. Przekroczono limit czasu połączenia i włączenie GUI, ekran był czarny. Rozwiązaniem w moim przypadku było wyłączenie „Hyper V”

Cytat z dokumentacji Vagrant https://docs.vagrantup.com/v2/hyperv/index.html

Ostrzeżenie: włączenie funkcji Hyper-V spowoduje, że VirtualBox, VMware i wszelkie inne technologie wirtualizacji przestaną działać. Zobacz ten post na blogu https://www.hanselman.com/blog/SwitchEasilyBetweenVirtualBoxAndHyperVWithABCDEditBootEntryInWindows81.aspx, aby w łatwy sposób utworzyć pozycję rozruchową w celu uruchomienia systemu Windows bez włączonej funkcji Hyper-V, jeśli będą potrzebne inne hiperwizory.

Jeśli pracujesz w systemie Windows 8 lub 10, to działało dla mnie:

1. Zmień ustawienia BIOS, aby umożliwić wirtualizację 64-bitową.
2. Oto jak:
   • Uruchom ponownie komputer za pomocą funkcji Advanced Startup (przejdź do opcji Advanced Startup -'restart now '-' Rozwiązywanie problemów '-'Avanced Option'-'UEFI Firmware Setting' - 'Restart')
   • W oknie BIOS - przejdź do menu / karty „Zaawansowane” - Włącz „Intel Virtual Technology”
   • Wyjście bezpieczeństwa.

Miałem z tym problem z istniejącym pudełkiem (nie jestem pewien, co się zmieniło), ale mogłem połączyć się przez SSH, mimo że nie udało się uruchomić Vagrant. Tak się składa, że ​​mój klucz SSH jakoś się zmienił.

Z błędnego folderu głównego, vagrant ssh-configktóry uruchomiłem, który powiedział mi, gdzie jest plik klucza. Otworzyłem to za pomocą puttygena a następnie dał mi nowy klucz.

Na moim gościu Linuksa dokonałem edycji ~/.ssh/authorized_keysi upuściłem tam nowy klucz publiczny.

Wszystko znów działa - na razie!

Miałem ten sam problem po usunięciu tego wiersza z mojego pliku Vagrantfile:

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

Maszyna wirtualna ładuje się dobrze po ponownym umieszczeniu tej linii.

Limit czasu połączenia SSH podczas pierwszego uruchamiania może być związany z różnymi przyczynami, takimi jak:

• sprawdź, czy w BIOSie jest włączona wirtualizacja (zgodnie z komentarzem ),
• system czeka na interakcję użytkownika (np. partycja udostępniania nie jest gotowa ),
• niedopasowanie twojego klucza prywatnego (sprawdź konfigurację przez vagrant ssh-config),
• proces uruchamiania trwa znacznie dłużej (spróbuj zwiększyć config.vm.boot_timeout),
• uruchamia się z niewłaściwego napędu (np. z ISO instalatora),
• Błędna konfiguracja zapory VM (np. iptablesKonfiguracja ),
• lokalne reguły zapory, konflikt portów lub konflikt z oprogramowaniem VPN,
• sshd błędna konfiguracja.

Aby debugować problem, uruchom go --debuglub skorzystaj z opcji:

VAGRANT_LOG=debug vagrant up

Jeśli nie ma nic oczywistego, spróbuj połączyć się z nim z innego terminala vagrant sshprzez:

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

Jeśli SSH nadal nie działa, spróbuj uruchomić go z GUI (np config.gui = true.).

Jeśli nie, sprawdź uruchomione procesy (np. Przez vagrant ssh -c 'pstree -a':) lub zweryfikuj swoje sshd_config.

Jeśli jest to maszyna wirtualna jednorazowego użytku, zawsze możesz spróbować destroyi upponownie.

Powinieneś także rozważyć aktualizację Vagrant i Virtualbox.

Aby uzyskać więcej informacji, sprawdź stronę Debugowanie i rozwiązywanie problemów .

Miałem ten sam problem, ale żadna inna odpowiedź nie rozwiązała w pełni mojego problemu. Odpowiedź @Kiee była pomocna, chociaż wszystko, co widziałem w GUI, to czarny ekran (z podkreśleniem w lewym górnym rogu, ten problem w Virtual Box został również podniesiony osobno w przepełnieniu stosu, znowu nic nie pomogło).

W końcu rozwiązanie okazało się bardzo proste: sprawdź wersję swojej maszyny wirtualnej.

Dokładniej, miałem pudełko od kogoś innego z 64-bitowym Debianem, ale Virtual Box nalegał, aby traktować go jako 32-bitowy, czego nie zauważyłem. Aby to zmienić, otwórz Virtual Box, a następnie otwórz terminal i uruchom

vagrant up

czekać na linię

default: SSH auth method: private key

teraz możesz nacisnąć Ctrl + C (lub poczekać na limit czasu) i uruchomić

vagrant halt

twoja maszyna wirtualna nie zostanie zniszczona, więc możesz ją zobaczyć w menu Virtual Box, ale zostanie wyłączona, więc możesz zmienić ustawienia. Wybierz swój komputer w menu, kliknij „Ustawienia” -> „Ogólne” i wybierz odpowiednią „Wersję”, dla mnie była to „Debian (64-bit)”. Po tym typie vagrant upjeszcze raz.

Jeśli tak jest w Twoim przypadku (lub różne zmiany w „Ustawieniach” rozwiązały Twój problem), możesz utworzyć nowe pole z naprawionego jednego wpisu

vagrant package --output mynew.box

Więcej informacji: host 32-bitowy Ubuntu 12.04, gość 64-bitowy Debian 8.1, Virtual Box 5.0.14, Vagrant 1.8.1

Jest tu wiele dobrych odpowiedzi i nie mogłem przeczytać wszystkiego, ale właśnie przyszedłem, aby dać swój mały wkład. Miałem 2 różne problemy:

1. vagrant upnie mogłem znaleźć mojego ssh „ id_rsa ” (bo wtedy jeszcze go nie miałem): pobiegłem ssh-keygen -t rsa -b 4096 -C "[email protected]"na podstawie artykułu z GitHub i voilá, przeszedłem przez to;

2. Potem mam ten sam problem z pytaniem „ Ostrzeżenie: Przekroczono limit czasu połączenia. Ponawiam próbę ... ”, wiecznie…: Po przeczytaniu dużo, ponownie uruchomiłem system i spojrzałem na BIOS (F2, aby uzyskać tam, na PC), a wirtualizacja została wyłączona . Włączyłem to, zapisałem i ponownie uruchomiłem system, aby sprawdzić, czy coś zmieniło.

Potem vagrant updziałało jak urok! Jest 4 rano, ale już działa! Jak fajnie, hã? : D Jak wiem, jest bardzo niewielu masochistycznych programistów takich jak ja, którzy wypróbowaliby to w Windowsie, szczególnie w Windowsie 10 , po prostu nie mogłem nie zapomnieć o przybyciu tutaj i zostawieniu słowa… kolejna ważna informacja, że: Próbowałem skonfigurować Laravela 5 , używając Homestead, VirtualBox, kompozytora itp. Udało się. Mam nadzieję, że ta odpowiedź pomoże polubić to pytanie, a odpowiedzi pomogły mi. Najlepsze życzenia. Cześć!

Testowałem zamontowany folder na mojej wirtualnej maszynie wirtualnej, dodając nowy wpis do /etc/fstab. Później wylogowałem się, zatrzymałem włóczęgę, ale kiedy uciekłem vagrant up, dostałem:

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

Przeczytałem wszystkie te posty i wypróbowałem wszystkie, które wydawały się odpowiednie dla mojej sprawy (z wyjątkiem włóczęgi niszczącej, co z pewnością rozwiązałoby mój problem, ale w moim przypadku było ostatecznością). Post autorstwa @Kiee podsunął mi pomysł, aby spróbować uruchomić moją maszynę wirtualną bezpośrednio z interfejsu GUI VirtualBox. Podczas rozruchu maszyna wirtualna zatrzymała się i zapytała, czy chcę pominąć montowanie folderu testowego, do którego wcześniej dodałem /etc/fstab. (Dlatego włóczęga nie mógł uruchomić maszyny wirtualnej.) Po odpowiedzi „NIE” maszyna wirtualna nie uruchomiła się. Zalogowałem się, usunąłem niegrzeczną linię z mojego fstab i zamknąłem maszynę wirtualną.

Po tym włóczęga był w stanie uruchomić się dobrze.

Na wynos? Jeśli nagle włóczęga nie może ponownie uruchomić się na maszynie wirtualnej, spróbuj uruchomić komputer bezpośrednio od dostawcy (w moim przypadku VirtualBox). Możliwe, że Twój but wisi na czymś zupełnie niezwiązanym z SSH.

Miałem ten sam problem, gdy korzystałem z urządzenia x64 (chef / ubuntu-14.04).

Zmieniłem na x32 i zadziałało (hashicorp / precision32).

Być może jest to zbyt prosta odpowiedź, aby pomóc wielu ludziom, ale warto spróbować, jeśli nie: Wykonaj „włóczęgowskie zatrzymanie” zamiast „włóczęgowskie zawieszenie”, a następnie uruchom ponownie maszynę wirtualną z „włóczęgą w górę”.

Myślę, że mój problem był spowodowany błędnym procesem „kworker” i ciągłym przekraczaniem limitu czasu na maszynie wirtualnej, więc wykonanie twardego restartu wydawało się poprawnie ładować proces ponownie, podczas gdy zapisywanie i przywracanie przywracało uszkodzony proces w stanie zepsutym.

Mam to podczas uruchamiania vagrant / VirtualBox w VirtualBox. Rozwiązałem ten problem, uruchamiając błędną maszynę na maszynie hosta.

Dowiedziałem się, że w MacOS z VirtualBox dodanie tego do Vagrantfile pozwoli ci pójść dalej:

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

Instalacja bitów ubuntu32 na bitach AMD64 załatwiła sprawę. Nie mam dostępu do BIO, ponieważ jest to ograniczone środowisko, ale nadal byłem w stanie zmusić go do pracy z ubuntu / trusty32 zamiast ubuntu / trusty64

Korzystanie z Vagrant 1.6.3 z VirtualBox 4.3.15 w Windows 7 SP1

mam nadzieję, że to pomaga.

Dla mnie była to zgodność między wirtualnym a wirtualnym pudełkiem.

Jestem na Windowsie 10 i co zrobiłem odinstalowałem Vagrant i Virtual Box

Następnie zainstaluj starą wersję wirtualnego urządzenia, a konkretnie wersję 4.3.38 (Zainstaluj także rozszerzenie dla tej wersji)

Następnie zainstalowałem najnowszą kopię włóczęgi (obecnie 1.8.5)

Potem zadziałało.

Jeśli nie chcesz włączać GUI, a następnie musisz go wyłączyć później, możesz również zainstalować pakiet rozszerzeń z Oracle:

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

Następnie włóż to do pliku Vagrantfile, aby włączyć VRDP:

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

Teraz możesz używać protokołu RDP do łączenia się z urządzeniem na żądanie, bez konieczności uruchamiania SSH lub GUI otwartego przez cały czas.

Jeszcze jedno możliwe rozwiązanie dla użytkowników dostawcy VMware: Dla mnie problem został rozwiązany po usunięciu równoległej instalacji VirtualBox na tym samym komputerze hosta. Interfejsy sieciowe między VMware i VirtualBox najwyraźniej były w konflikcie

Napotkałem ten sam problem. Naprawiłem to, włączając Virtualizationod BIOSkonfiguracji.

Usuń plik:

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

Następnie uruchomić:

vagrant up

Dla mnie zadziałało zezwolenie na 64-bitową wirtualizację w 64-bitowym systemie operacyjnym (Ubuntu 13.10) z BIOS-u.

Sprawdź, czy wirtualizacja procesora w konfiguracji BIOS jest włączona.

W moim przypadku nadanie statycznego adresu IP rozwiązało problem:

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

FWIW-- Mój problem wynikał z użycia naprawdę starego pliku konfiguracyjnego zamiast nowszego. Użycie nowego pliku konfiguracyjnego (a tym samym poprawionego / zmienionego DSL) natychmiast rozwiązało moje problemy.

Pomogło mi włączenie wirtualizacji w systemie BIOS, ponieważ maszyna nie uruchomiła się.

Zamiast ctrl-d-out z wirtualnego pudełka, bo nie będę tego robić za każdym razem, gdy ssh do czegoś, wierzę, że włóczęga wolałby dostać się do innego terminalu i zrobić:

vagrant halt

zatrzymać skrzynkę. Wtedy nie będzie problemów z powrotem do VB.