it-swarm.dev

Po przejściu „Oczekiwanie na uruchomienie komputera może potrwać kilka minut ...”

Mam wirtualną skrzynkę ubuntu. Wszystko działa dobrze, z wyjątkiem tego, że po uruchomieniu zajmuje około 5 lub więcej minut po wiadomości 

Waiting for machine to boot. This may take a few minutes...

przed zakończeniem uruchamiania:

➜  my_box  vagrant reload
/Users/pinouchon/.vagrant.d/boxes/my_box/virtualbox/include/_Vagrantfile:5: warning: already initialized constant VAGRANTFILE_API_VERSION
[default] Attempting graceful shutdown of VM...
[default] Clearing any previously set forwarded ports...
[default] Creating shared folders metadata...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
# More port forwards 
[default] Booting VM...
[default] Waiting for machine to boot. This may take a few minutes...
# waits about 5 minutes at this point, then:

[default] Machine booted and ready!
[default] The guest additions on this VM do not match the installed version of
VirtualBox! In most cases this is fine, but in rare cases it can
cause things such as shared folders to not work properly. If you see
shared folder errors, please update the guest additions within the
virtual machine and reload your VM.

Guest Additions Version: 4.3.0
VirtualBox Version: 4.2
[default] Configuring and enabling network interfaces...
[default] Mounting shared folders...
[default] -- /vagrant

To pudełko było znacznie szybsze (około 30 sekund na rozruch). Myślę, że jest to konfiguracja sieci, która powoduje przekroczenie limitu czasu lub coś takiego.

Próbował poprawek zaproponowanych tutaj: https://github.com/mitchellh/vagrant/wiki/%60vagrant-up%60-hangs-at-%22Waiting-for-VM-to-boot. -To-może-wziąć-kilka minut% 22

ale bez powodzenia. (Próbowałem poprawki Resolve it i workaround 2.).

Próbowałem także usunąć wszystkie wpisy 127.0.0.1 w moich plikach /etc/hosts. Bezskutecznie.

Jakaś podpowiedź?

OS/Wersje:

Host: OSX 10.8.5
Guest: Ubuntu 12.05
Virtualbox: 4.2
12

Używasz pudełka, które ma dodatki gości wirtualnych 4.3.x, ale Twój Host działa 4.2.x

Z powodu tej rozbieżności Virtualbox nie może wykonać polecenia, które jest częścią procesu tworzenia. 

Albo zdobycie nowego pudełka z dodatkami dla gości 4.2.x, albo uaktualnienie wirtualnej skrzynki do 4.3.x prawdopodobnie rozwiąże ten problem. 

Aktualizacja  

Spróbuj ustawić następujące elementy w pliku włóczęgi

config.vm.boot_timeout = 300

Spróbuj także włączyć debugowanie

vagrant up --debug

Aktualizacja 2

Niektóre vm po prostu nie grają dobrze z niezgodnymi wersjami dodatków dla gości. Na przykład skrzynka centos i debian tej samej firmy. Centos wygaśnie, podczas gdy debian będzie działał poprawnie. 

http://puppet-vagrant-boxes.puppetlabs.com/centos-64-x64-vbox4210.box
http://puppet-vagrant-boxes.puppetlabs.com/debian-70rc1-x64-vbox4210.box

13
spuder

Może również wystąpić, jeśli włóczęga nie jest w stanie nawiązać połączenia SSH.  

Wydaje się, że nie zgłasza żadnego błędu z powodu zawieszenia w tym przypadku.

Gdy GUI pokaże:

 # Show GUI or not.
config.vm.provider "virtualbox" do |v|
  v.gui = true
end

Możesz zobaczyć „login dev:” lub inny monit, jak wszystko jest w porządku.

Może pamiętasz, że zmieniłeś klucz SSH u gościa ostatniej nocy ... 

Rozwiązanie: Powiedz vagrantowi, gdzie jest klucz prywatny na hoście.  

 # Use a new keyset
config.ssh.private_key_path = "~/.ssh/id_rsa"

Klucz publiczny musi być również dostępny dla gościa.

Będzie to działać tylko wtedy, gdy umieściłeś pasujący klucz publiczny w pliku authorized_keys gościa.

Różni się to w zależności od systemu operacyjnego, ale na wspólnym polu Precise64 wygląda to mniej więcej tak:

Host Linuksa z openssh-client

ssh-copy-id -i .ssh/id_rsa.pub [email protected]

Host Mac

cat ~/.ssh/id_rsa.pub | ssh [email protected] "mkdir ~/.ssh; cat >> ~/.ssh/authorized_keys"

Istnieje również port ssh-copy-id dla mac. https://github.com/beautifulcode/ssh-copy-id-for-OSX

Ten post SO ma prosty wbudowany moduł Shell, który umożliwia zamianę autoryzowanych kluczy podczas udostępniania maszyny w celu automatycznego jej uruchomienia. Domyślnie niezabezpieczony włóczęgą?

7
shanemgrey

Od czasu do czasu miałem to: uruchamianie VM zajmuje dużo czasu, a następnie coś jest nie tak z jego siecią (strona, na której się uruchomiłem, staje się niedostępna).

Dla mnie to zostało naprawione przez:

  1. vagrant ssh do maszyny wirtualnej
  2. W maszynie wirtualnej uruchom Sudo /etc/init.d/networking restart
2
Nick F

Sugestia @ spuder z vagrant up --debug naprawiła ten problem dla mnie. Wyglądało na to, że GUI VirtualBox działa bardziej płynnie i pojawiło się okno wcześniej w tym procesie. Odwróciłem to w sposób, w jaki inni sugerowali:

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

i ustawiłem kod config.vm.boot_timeout = 600

Było to w odniesieniu do setup dla kursu Udacity Full Stack Foundations.

1
Noumenon

Nie jestem pewien, czy już to rozwiązałeś, ale miałem ten sam błąd i naprawiłem go, usunąłem wydane dzierżawy dhcp na włóczęgę przed ponownym uruchomieniem.

@ Twój lokalny użytkownik może wyłączyć VM za pomocą

VBoxManage controlvm <vmname> poweroff

Następnie na VirtualBox musisz usunąć dhcp

Sudo rm -Rf /var/lib/dhcp/*

Znajdziesz dodatkowe informacje, które poprowadzą Cię

https://github.com/mitchellh/vagrant/wiki/%60vagrant-up%60-hangs-at-%22Waiting-for-VM-to-boot.-This-can-take-a-few-minutes % 22

1
Hal

Spróbuj wygenerować insecure_private_key

Rozwiązałem to, usuwając insecure_private_key, znajdujący się pod ~/.vagrant.d

może powodem jest to, że plik insecure_private_key jest stary

0
javinc

Rozwiązałem ten problem:

wget https://raw.githubusercontent.com/mitchellh/vagrant/master/keys/vagrant.pub -O .ssh/authorized_keys
chmod 700 .ssh
chmod 600 .ssh/authorized_keys
chown -R vagrant:vagrant .ssh

Niektórzy mogą tak zrobić:

Warning: Authentication failure. Retrying...
0
Barry

Spróbuj odkomentować linię:

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

wewnątrz pliku VagrantFile 

0
Gil Margolin

Naprawiono problem. Co ja zrobiłem:

  • zaktualizowany virtualbox do 4.3.0
  • zaktualizował Vagrant do 1.4.2 (myślę, że 1.4.3 zadziałałoby tak samo)
  • po tej poprawce (do aktualizacji vBoxAdditions): https://Gist.github.com/zbal/7800423

Uwagi: 

  • Aktualizacja wirtualnej skrzynki jest konieczna, ponieważ virtualbox i vboxGuestAdditions są kompatybilne. (mój vBoxGuestAdditions był za niedawny)
  • Aktualizacja vagranta jest konieczna, ponieważ vagrant 1.3 nie działa z virtualbox 4.3 (vagrant 1.4).
  • Naprawiłem to zaktualizowaną wersję tego: https://Gist.github.com/fernandoaleman/5083680

Inne notatki:

  • Zmiana config.vm.boot_timeout = 300 nie pomogła

Edytuj: Spróbuj także uruchomić remove /etc/udev/rules.d/70-persistent-net.rules na komputerze-gościu.

0