J'ai une virtualbox Ubuntu. Tout fonctionne bien, sauf qu'au démarrage, il faut environ 5 minutes ou plus après le message
Waiting for machine to boot. This may take a few minutes...
avant de terminer le démarrage:
➜ 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
Auparavant, cette boîte était beaucoup plus rapide (environ 30 secondes pour démarrer). Donc, je pense que c'est une configuration de réseau qui provoque un délai d'attente ou quelque chose comme ça.
Il a essayé les corrections proposées ici: https://github.com/mitchellh/vagrant/wiki/%60vagrant-up%60-hangs-at-%22Waiting-for-VM-to-boot.-This -peut-prendre-quelques-minutes% 22
mais sans succès. (J'ai essayé le correctif Resolve it
et le workaround 2.
).
J'ai également essayé de supprimer les entrées 127.0.0.1 de mes fichiers /etc/hosts
. Sans succès.
Un indice?
OS/Versions:
Host: OSX 10.8.5
Guest: Ubuntu 12.05
Virtualbox: 4.2
Vous utilisez une boîte comportant des ajouts d'invité virtualbox 4.3.x, mais votre hôte exécute 4.2.x
En raison de cette divergence, Virtualbox n'est pas en mesure d'exécuter une commande faisant partie du processus de création.
Obtenir une nouvelle boîte en cours d’ajout d’invités 4.2.x ou mettre à niveau votre virtualbox vers la version 4.3.x résoudra probablement ce problème.
Mettre à jour
Essayez de définir ce qui suit dans votre fichier vagrant
config.vm.boot_timeout = 300
Essayez également d'activer le débogage
vagrant up --debug
Mise à jour 2
Certains vm ne jouent tout simplement pas bien avec les versions incompatibles des ajouts invités. Par exemple, un centos et une boîte debian de la même entreprise. Les centos s’arrêteront pendant que Debian fonctionnera correctement.
http://puppet-vagrant-boxes.puppetlabs.com/centos-64-x64-vbox4210.box
http://puppet-vagrant-boxes.puppetlabs.com/debian-70rc1-x64-vbox4210.box
Cela peut également se produire si vagrant n’est pas en mesure d’établir une connexion SSH.
Il semble ne pas signaler d'erreur pour laquelle il se bloque dans ce cas.
Voir le GUI pour montrer:
# Show GUI or not.
config.vm.provider "virtualbox" do |v|
v.gui = true
end
Vous pouvez voir le "dev login:" ou autre invite comme si tout allait bien.
Ensuite, vous vous souviendrez que vous avez changé le jeu de clés SSH sur l'invité hier soir ...
Solution: Indique à vagrant où se trouve la clé privée sur l'hôte.
# Use a new keyset
config.ssh.private_key_path = "~/.ssh/id_rsa"
Clé publique Doit également être sur l'invité.
Cela ne fonctionnera que si vous avez déjà placé la clé publique correspondante dans le fichier allowed_keys sur l'invité.
Cela varie en fonction du système d'exploitation, mais sur la boîte Precise64 commune, il ressemble à ceci depuis un terminal:
Hôte Linux avec openssh-client
ssh-copy-id -i .ssh/id_rsa.pub [email protected]
Hôte Mac
cat ~/.ssh/id_rsa.pub | ssh [email protected] "mkdir ~/.ssh; cat >> ~/.ssh/authorized_keys"
Il existe également un port de ssh-copy-id pour mac. https://github.com/beautifulcode/ssh-copy-id-for-OSX
Cette publication SO contient un simple approvisionneur en ligne Shell pour échanger les clés authorised_keys lors du provisionnement d'une machine pour la rendre automatique. Vagrant non sécurisé par défaut?
J'ai eu cela parfois: la VM met longtemps à démarrer, et par la suite, il y a un problème avec sa mise en réseau (le site sur lequel je cours d'exécution devient inaccessible).
Pour moi, cela a été corrigé par ce qui suit:
vagrant ssh
dans la machine virtuelleSudo /etc/init.d/networking restart
La suggestion de @ spuder de vagrant up --debug
a corrigé ce problème pour moi. Il semblait que l’interface graphique de VirtualBox fonctionnait de manière plus fluide et ouvrait une fenêtre plus tôt dans le processus. J'avais tourné ça comme d'autres l'avaient suggéré:
config.vm.provider :virtualbox do |vb|
vb.gui = true
end
et avait mis config.vm.boot_timeout = 600
.
C'était en relation avec setup pour le cours Udacity Full Stack Foundations.
Je ne sais pas si vous avez déjà résolu le problème, mais j’ai eu la même erreur et, pour le résoudre, j’ai retiré les baux dhcp émis sur vagrant avant de le redémarrer.
@ votre local, vous pouvez éteindre le VM en utilisant
VBoxManage controlvm <vmname> poweroff
Ensuite, sur VirtualBox, vous devez supprimer le dhcp
Sudo rm -Rf /var/lib/dhcp/*
Vous trouverez des informations supplémentaires pour vous guider
Essayez de générer insecure_private_key
J'ai résolu ce problème en supprimant le insecure_private_key
, situé sous ~/.vagrant.d
peut-être que la raison est insecure_private_key
le fichier est vieux
J'ai résolu ce problème:
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
Certains peuvent aussi faire comme ça:
Warning: Authentication failure. Retrying...
Essayez de décommenter la ligne:
config.vm.network "réseau_privé", ip: "192.168.33.11"
à l'intérieur du fichier Vagrant
Correction du problème. Ce que j'ai fait:
Remarques:
Autres notes:
config.vm.boot_timeout = 300
n'a pas aidéEdit: Essayez également d’exécuter remove /etc/udev/rules.d/70-persistent-net.rules
sur votre ordinateur invité.