Vagrant coincé délai d'attente de connexion de réessayer
Mon vagabond a été fonctionne parfaitement bien la nuit dernière. J'ai juste tourné le PC, cliquez sur vagrant up
, et c'est ce que j'obtiens:
==> 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...
Quelqu'un a eu cela avant? l'errance n'est pas largement couvert sur le web encore et je ne peux pas trouver une raison pour laquelle cela se produit.
- La situation pourrait être à cause de VirtualBox pas réussi à rediriger les ports, malgré disant: "==> valeur par défaut: Redirection de ports... par défaut: 22 => 2222 (carte 1)' Vous pouvez avoir un coup d'oeil à la description complète dans ma question ici link. Je n'ai toujours aucune idée de la façon de fixer redirection de l'échec( Vous pouvez avoir un coup d'oeil dans VirtualBox journal.
- J'ai le même problème. Le problème est que le serveur ssh n'a pas été installé et activé sur l'ordinateur invité.
- J'ai eu la même erreur lors de l'installation d'ubuntu 16.04 - le problème a été résolu par la mise à niveau de virtual box à 5.1.x - voir askubuntu.com/a/822974/151137
- Veuillez vérifier les antivirus et pare-feu, stop à la fois pour le moment et puis u go 🙂
Vous devez vous connecter pour publier un commentaire.
J'ai résolu ce problème, et la réponse au cas où quelqu'un d'autre a un problème similaire.
Ce que j'ai fait: j'ai activé l'interface graphique de virtualbox pour voir qu'il était en attente d'entrée au démarrage de choisir si je voulais boot directement sur ubuntu ou mode sans échec etc.
Pour activer l'interface graphique, vous devez mettre ceci dans votre vagrant config
Vagrantfile
:hashicorp/precise32
. J'ai commencé à la machine avec une interface graphique, puis a courusudo grub-mkconfig
réinitialiser les/boot/grub/grub.cfg
fichier, et que je ne puis commenter revenir levb.gui=true
ligne.vagrant up
vagrant
vagrant ssh-config
et manuellement l'exécution de plusieurs commandes ssh, l'ajout de différents ssh flags/options à chaque fois. Finalement, j'ai découvert la racine de la cause: un de mes .ssh/config entrées accidentellement n'ont pasHost
ensemble, appliquant ainsi que la config de la règle pour toutes les commandes ssh. Solution: assurez-vous que tous les .ssh/config entrée aHost
ensemble.Lorsque vous êtes coincé avec votre vagabond de la machine de la manière décrite ci-dessus il n'est pas nécessaire de démarrer en mode graphique (et qui est impossible sans un serveur X).
Alors que votre VM est le démarrage, dans une fenêtre de terminal séparée, il suffit de trouver l'id de la machine en cours.
Le résultat sera quelque chose comme ceci:
Assez souvent, la machine virtuelle est simplement en attente pour vous de sélectionner une option dans le bootloader. Vous pouvez envoyer le mot de code approprié (dans le cas, Entrée) à la vm avec
controlvm
:Que c'est. Votre machine virtuelle va continuer le processus de démarrage.
vboxmanage
lequel l'interface de ligne de commande pour VirtualBox. Donc, vous êtes le "contrôle" de la VM et l'envoi d'un "scan code" pour la touche d'Entrée (1C) en utilisant le paramètrekeyboardputscancode
.Warning: Connection timeout. Retrying...
àdefault: Warning: Remote connection disconnect. Retrying...
après l'exécution devboxmanage controlvm dst_default_1407935479617_2464 keyboardputscancode 1c
. Vais essayer de lavb.gui = true
à la place.C:\Progra~1\Oracle\VirtualBox\VBoxManage.exe
cela dit, les changements dans le BIOS ci-dessous ont permis de résoudre ce problème pour moiUne chose à vérifier est de savoir si le Matériel de la Virtualisation est activée dans votre BIOS des machines.
Mon problème, c'est la même chaîne de délais d'attente, mais je ne pouvais voir que l'écran est noir dans l'interface graphique.
Un ordinateur portable dont j'ai été un peu mise en place ne cessaient de le même problème. Après des heures de recherche j'ai enfin trouvé une astuce pour voir si le BIOS a du Matériel de la Virtualisation est activée.
Voici le contenu du post que j'ai trouvé:
Je vois il y a encore des utilisateurs qui sont confrontés à ce problème. Donc, je vais tenter de résumer ci-dessous une liste de certaines des solutions possibles pour le SSH problème de délai d'attente:
http://git-scm.com/downloads
Espère que ça aide.
La solution que j'ai trouvé est de vérifier la connexion du câble en option dans la carte 1, qui est attaché à NAT. Je ne sais vraiment pas, c'est mon 4ème vagrant box, mais c'est le seul avec câble de raccordement de l'option n'est pas sélectionnée, et lors de la vérification, il fonctionne.
J'ai eu exactement le même problème. J'ai pensé que peut être le problème avec les clés SSH (problème de localisation d'un fichier ou d'autre chose, mais je l'ai vérifié plusieurs fois), mais vous pouvez toujours ajouter dans la section configurer nom d'utilisateur et le mot de passe (sans l'aide de clés ssh) et en cours d'exécution graphique, donc le code dans
Vagrantfile
devrait ressembler plus ou moins comme ci-dessous:Dans mon cas, même si l'interface graphique est affiché j'ai eu un écran noir (pas d'erreurs ou de possibilité de connexion ou quoi que ce soit d'autre) et dans la console j'ai eu le
Error: Connection timeout. Retrying...
de nombreuses fois. J'ai fait en sorte que j'avais VT-x (virtualisation) activé dans le BIOS, j'ai vérifié de nombreuses combinaisons de versions de Virtual Box et Vagrant ensemble et beaucoup Vagrant boîtes (pour certains d'entre eux, je n'ai pas eu d'écran noir en interface graphique, mais toujours des problèmes de connexion). Enfin j'ai mis à jour VirtualBox et Vagabonde de nouveau aux dernières versions et le problème n'est toujours pas eu lieu.L'essentiel était à la recherche à des icônes dans VirtualBox après l'exécution de vagrantup (avec une interface graphique en
Vagrantfile
comme je l'ai montré ci-dessus) comme sur l'image ci-dessousBien que je n'avais pas d'erreurs dans VirtualPC (pas de mises en garde que VT-x n'est pas activé) mon
V
icône a été précédemment gris donc, cela signifie que le VT-x a été désactivé. Comme je l'ai dit je l'avais activé dans mon BIOS de tous les temps.Finalement, j'ai réalisé que le problème pourrait par
HYPER-V
que j'ai également installé et activé pour tester les sites sur les plus anciennes d'Internet Explorer. Je suis allé à WindowsControl Panel -> Programs and functions /Software
et choisissez dans le menu sur la gaucheTurn on or Turn off Windows functions
(espérons que vous trouverez ces, j'utilise le Windows polonais afin de ne pas connaître exactement les noms anglais). J'ai éteint la technologie Hyper-V, redémarré le PC et après l'exécution de Virtual Box etvagrant up
j'ai enfin eu aucune erreur, dans le GUI, j'ai l'écran de connexion et monV
icône cessé d'être gris.J'ai perdu beaucoup de temps à résoudre ce problème (et de nombreux PC redémarre) donc j'espère que cela peut être utile à toute personne qui ont des problème sur Windows, assurez-vous d'avoir Hyper-V est désactivé dans votre Panneau de Contrôle.
De la Mine a été en cours d'exécution fine, puis "Avertissement: la connexion à Distance de déconnexion. Réessayer..." et plus - peut-être 20 fois jusqu'à ce qu'il connecté. Basé sur les réponses ci-dessus, je viens de
et c'était tout bon. Le mien était très simple, mais je l'ai fait de cette façon par la coupe de la Vagrantfile juste le
config.vm.box = "ubuntu/trusty64"
et il était encore le faire. C'est pourquoi la détruire et recommencer semblait le meilleur choix. Compte tenu de l'apatride, de la nature de ces Vagabonds des images que je ne vois pas pourquoi ça ne marcherait pas dans tous les cas. Je suis juste à entrer dans ce et j'ai peut encore apprendre que ce n'est pas vrai.vragant halt
mais cela fonctionne parfaitement!J'ai connu le même problème sur un Windows 8.1 machine. Le délai d'attente de connexion et l'activation de l'interface graphique n'était pas utile à tous, l'écran était noir. La solution dans mon cas était la désactivation de "Hyper V"
Citation de Vagrant documentation https://docs.vagrantup.com/v2/hyperv/index.html
Si vous travaillez sur Windows 8 ou 10, c'est ce qui a fonctionné pour moi:
J'ai eu un problème avec ce avec une boîte existante (pas sûr de ce qui a changé), mais je pourrait connecter via SSH, même si le Vagrant box échec de démarrage du système. Comme il arrive ma clé SSH avait changé en quelque sorte.
De l'errance dossier racine, j'ai couru
vagrant ssh-config
qui m'a dit où le fichier de clé a été. J'ai ouvert ce avec puttygen et puis il m'a donné une nouvelle clé.Sur mon Linux, j'ai édité
~/.ssh/authorized_keys
et abandonné la nouvelle clé publique là.Tout fonctionne à nouveau - pour l'instant!
J'ai eu le même problème après j'ai supprimé cette ligne de mon Vagrantfile:
VM bien chargé après que j'ai mis cette ligne de retour.
config.vm.network
et il a résolu le problème.La connexion SSH délai d'attente pendant le premier démarrage peut être liée à une variété de raisons telles que:
vagrant ssh-config
),config.vm.boot_timeout
),iptables
configuration),sshd
mauvaise configuration.À déboguer le problème, s'il vous plaît exécuter un
--debug
option ou comme:Si il n'y a rien d'évident, puis essayez de vous connecter à partir d'un autre terminal, par
vagrant ssh
ou par:Si le SSH ne fonctionne toujours pas, essayez de le faire fonctionner avec une interface graphique (par exemple
config.gui = true
).Si elle ne l'est pas, vérifier les processus en cours d'exécution (par exemple:
vagrant ssh -c 'pstree -a'
) ou de vérifier votresshd_config
.Si c'est à usage unique machine virtuelle, vous pouvez toujours essayer de
destroy
etup
de nouveau.Vous devriez également envisager de mettre à niveau votre Vagrant et Virtualbox.
Pour plus d'informations, consultez la Débogage et Dépannage page.
J'ai eu le même problème, mais aucune des autres réponses entièrement résolu mon problème. Réponse par @Kiee a été utile, bien que tout ce que je pouvais voir dans l'interface graphique a été un écran noir (avec un trait de soulignement en haut à gauche, ce problème dans Virtual Box a également été élevés séparément dans le débordement de la pile, encore une fois rien n'y fait).
Finalement, une solution s'est avérée être très simple: vérifier la version de votre machine virtuelle.
Plus précisément, j'ai eu une boîte de quelqu'un d'autre avec la version 64 bits Debian, mais Virtual Box a insisté à la traiter en 32 bits, ce que je n'ai pas d'avis. Pour le modifier, ouvrez Virtual Box, puis ouvrir un terminal et exécuter
attendre pour la ligne
maintenant, vous pouvez appuyez sur ctrl+C (ou attendre le délai d'attente) et d'exécuter
votre machine virtuelle ne sera pas détruit, de sorte que vous pouvez voir dans le menu de Virtual Box, mais éteint, de sorte que vous pouvez modifier les paramètres. Choisissez votre machine dans le menu, cliquez sur 'Paramètres'-> "Général" et a choisi la bonne "Version", pour moi c'était " Debian (64-bit)'. Après ce type
vagrant up
de nouveau.Si c'est le cas pour vous (ou à différents changements dans les 'Paramètres' résolu votre problème), vous pouvez créer une nouvelle zone de l'réparé un en tapant
Un peu plus de détails: hôte 32 bits Ubuntu 12.04, invité 64 bits Debian 8.1, Virtual Box 5.0.14, Vagrant 1.8.1
Il y a beaucoup de bonnes réponses ici, et je ne pouvais pas tout lu, mais je viens par donné ma petite contribution aussi. J'ai eu 2 problèmes différents:
vagrant up
n'était pas en mesure de trouver mon ssh 'id_rsa' (parce que je ne l'ai pas encore, à l'époque):J'ai couru
ssh-keygen -t rsa -b 4096 -C "[email protected]"
, basé sur cette GitHub de l'article, et voilá, steped par qui;Ensuite, j'ai eu le même problème de cette question "Avertissement: Connection timed out. Réessayer...", éternellement...:
Donc, après avoir lu beaucoup, j'ai redémarré mon système et a regardé mon BIOS (touche F2 pour y arriver, sur PC), et il y avait Virtualisation désactivé. J'ai activé que, enregistré, et a commencé à le système une fois de plus, pour vérifier si elle a quelque chose de changé.
Après,
vagrant up
a fonctionné comme un charme! Il est 4h du matin, mais il est en marche! Comment cool, hã? 😀 Comme je sais qu'il y a très peu masochiste développeurs comme moi, ce serait d'essayer ce à Windows, spécialement à Windows 10, je ne pouvais pas ne pas oublier de venir ici et de gauche ma parole... une autre information importante, c'est que, j'ai essayé de set-up Laravel 5, à l'aide de Homestead, VirtualBox, du compositeur etc. Il a travaillé. Donc, espère que cette réponse l'aide de cette question et les réponses m'ont aidé. Mes vœux les meilleurs. G-bye!J'ai été le tester un dossier monté dans mon errance des VM par l'ajout d'une nouvelle entrée dans le
/etc/fstab
. Plus tard, je me suis déconnecté, couru les arrêter, mais quand j'ai couruvagrant up
j'ai eu:J'ai lu tous ces messages et essayé tous ceux qui semblaient pertinents pour mon cas (sauf pour les détruire, ce qui aurait certainement corrigé mon problème, mais c'était un dernier recours dans mon cas). Le post de @Kiee m'a donné l'idée d'essayer de démarrer ma VM directement à partir de l'interface graphique de VirtualBox. Pendant le processus de démarrage de la VM arrêté lui-même et a été de me demander si je voulais ignorer le montage du dossier de test que j'avais ajouté précédemment pour
/etc/fstab
. (C'est pourquoi l'errance ne pouvais pas le démarrage de la VM.) Après avoir répondu " NON " de la VM démarré sans problème. Je me suis connecté, enlevé la coquine en ligne à partir de mon fstab, et de l'arrêt de la VM.Après que le vagabond a été en mesure de démarrer l'amende juste.
À emporter? Si tout d'un coup, vagabond ne peut pas démarrer votre machine virtuelle, essayez de démarrer directement à partir du fournisseur (VirtualBox dans mon cas). Les Chances sont de votre démarrage est suspendu pour quelque chose de totalement sans rapport avec SSH.
J'ai eu le même problème lorsque j'ai été en utilisant x64 boîte(chef/ubuntu-14.04).
J'ai changé pour x32 et cela a fonctionné(hashicorp/precise32).
C'est peut-être trop simple une réponse pour aider beaucoup de gens, mais la peine d'essayer si vous ne l'avez pas: Faire un "vagabond s'arrêter" au lieu de "vagabond suspendre" puis redémarrez la machine virtuelle avec "vagrant up".
Je pense que mon problème était dû à quelques "kworker" processus de prise en buggy et en constante timing dans la machine virtuelle et donc en faisant un hard reboot semblait recharger correctement le processus alors qu'une sauvegarde et de restauration était juste de la restauration de l'cassé processus dans son état rompu.
J'ai obtenu ce lors de l'exécution de vagrant/VirtualBox à l'intérieur de VirtualBox. J'ai résolu ce problème en exécutant le vagabond de la machine dans la machine hôte.
L'installation d'un ubuntu32 bits sur un AMD64 bits a fait le tour. Je n'ai pas accès au BIOs depuis sa un environnement restreint, mais j'étais encore capable de le faire fonctionner avec ubuntu/trusty32 au lieu de ubuntu/trusty64
Utilisation de Vagrant 1.6.3 avec VirtualBox 4.3.15 sur Windows 7 SP1
espère que ça aide.
Pour moi, c'était la compatibilité entre l'errance et virtual box.
Je suis sur windows 10 et de ce que j'ai fait, j'ai désinstallé l'errance et virtual box
Puis installer une ancienne version de virtual box spécifiquement version 4.3.38 ( Installez le pack d'extension de trop pour cette version )
Puis installé la dernière copie de vagrant ( 1.8.5 pour le moment )
Après qu'il a travaillé.
J'ai découvert que sur MacOS avec VirtualBox en ajoutant ceci à Vagrantfile vous permettra d'aller plus loin:
Si vous ne souhaitez pas activer l'interface graphique, puis de le désactiver plus tard, vous pouvez également installer le pack d'extension à partir d'Oracle:
http://www.oracle.com/technetwork/server-storage/virtualbox/downloads/index.html#extpack
Puis mettez ceci dans votre Vagrantfile pour permettre VRDP:
Maintenant, vous pouvez utiliser le protocole RDP pour vous connecter à votre boîte sur demande sans SSH besoin d'être en cours d'exécution ou l'interface graphique de l'ouvrir tout le temps.
Encore une solution possible pour les utilisateurs de VMware fournisseur de:
Pour moi, le problème a été résolu après la suppression d'un parallèle de l'installation de VirtualBox sur la même machine. Les interfaces réseau entre VMware et VirtualBox étaient apparemment contradictoires
Que j'ai rencontré le même problème. J'ai corrigé cela en permettant à
Virtualization
deBIOS
de l'installation.Supprimer le fichier:
Puis exécutez:
Ce qui a fonctionné pour moi a été de permettre 64 bits de la virtualisation sur une version 64 bits du système d'exploitation (Ubuntu 13.10) à partir du BIOS.
Vérifiez votre PROCESSEUR de virtualisation dans le BIOS est activé.
FWIW-- Mon problème était dû à l'utilisation d'un très ancien fichier de config à la place d'un autre plus récent. En utilisant le nouveau fichier de configuration (et ainsi modifié/changé DSL) fixe mes problèmes instantanément.
Ce qui a aidé pour moi était de l'activation de la virtualisation dans le BIOS, car la machine ne démarre pas.
Plutôt que ctrl-d-ing hors de la boîte virtuelle que je suis l'habitude de le faire chaque fois que j'en ssh en quoi que ce soit, je crois que vagrant vous préférez entrer dans un autre terminal et faites un:
vagrant halt
pour arrêter la boîte. Alors il n'y aura pas de problèmes à obtenir retour dans le VB.
ctrl+d
se déconnecte. Rien de mal à le faire, et qu'il n'a rien d'une machine en fonctionnement.vagrant halt
arrêts de la machine virtuelle.J'ai fait face à la même question, mais non de les solutions mentionnées fonctionné pour moi!
Je l'ai résolu par la dégradation de l'Errance en 1.6.2 et maintenant ça fonctionne!
J'ai eu le même problème avec Vagrant 1.6.5 et Virtual Box 4.3.16.
La solution décrite à https://github.com/mitchellh/vagrant/issues/4470 a bien fonctionné pour moi, j'ai juste eu à enlever VirtualBox 4.3.16 et installer l'ancienne version 4.3.12.
Il a utilisé pour aider à passer à trusty32, mais la situation était pire encore:
J'ai essayé d'utiliser Homestead 2.0 et maintenant que j'ai la Connexion problème de Délai d'attente de nouveau,
qui serait habituellement pas être un problème, parce que la commutation à 32 bits aidé auparavant.
Mais maintenant, je ne peux pas simplement d'ajouter une ligne comme
config.vm.boîte="ubuntu/trusty32"
parce que nous n'avons pas un classique de la Maison.fichier yaml plus,
les valeurs dans le nouveau 2.0 Homestead.fichier yaml semblent juste être inséré dans
le vrai dans le fond et il n'y aucune ist Vagrantfile que je
pourrait modifier manuellement ...
Espère que quelqu'un peut aider ...
À partir de l'interface de virtualbox, j'ai démarré sur un "CD" tout d'abord, et désactivé le démarrage sur un disque dur. Par conséquent, il était en cours de démarrage à partir d'un CD iso, et évidemment pas sur la machine... j'espère que cela aide. Et j'espère que ça fait sourire à quelqu'un de trop... PEBCAK.
Désactivé pare-feu iptables à l'intérieur de la VM
C'est comment je l'ai résolu:
Vagrantfile
(c'est le fichier de config)Cela a résolu mon problème, j'ai découvert que le pare-feu a bloqué toutes les IPs de réseaux locaux comme 192.168.x.x et 10.x.x.x
L'ajout d'une règle dans
/etc/iptables.d/199-allow-wan
à autoriser toutes les connexions de réseau étendu:(ip46tables est un alias) voir ce commit dans mon Errance exemple Freifunk de la communauté
Personnellement, pour moi, Tunnelblick VPN logiciel a été le blocage de la connexion. Maintenant, quand je suis le démarrage de nouvelles VMs-je désactiver temporairement Tunnelblick.
J'ai résolu simplement en tapant
ˆC
(ouctrl+C
sur Windows) deux fois et la fermeture de l'échec de la connexion de l'écran.Ensuite, je pourrais connecter via SSH (
vagrant ssh
) et de voir l'erreur par ma propre.Dans mon cas, c'était un chemin fait une faute de frappe.
La façon dont j'ai eu à résoudre ce n'était pas mentionné dans ce fil, donc je poste ici au cas où il permet à quiconque d'autre.
Quelles sont les causes de cette est que vagrant ne peut pas faire un ssh sur la machine une fois qu'il démarre. Il y a plusieurs raisons à cela, comme mentionné dans ce fil, tels que la machine ne démarre pas tout le chemin, ou pare-feu iptables blocage SSH.
Dans mon cas, le problème est que j'ai, par inadvertance, l'installation d'un "private_network" avec une adresse IP dans le même sous-réseau que le haut-VirtualBox NAT réseau (dans mon cas 10.0.2.0/24). Cette foiré le NAT du réseau pour la machine (mais pas d'erreurs qui s'affichent n'importe où), et depuis vagabond se connecte via le réseau NAT, il n'était pas en mesure de se connecter même si la machine était en marche et qu'aucun pare-feu ont été activés.
La solution était de mettre à jour mon VagrantFile et l'utilisation d'un "private_network" IP qui n'a pas de conflit avec VirtualBox NAT réseau.
Cherchez cette ligne dans votre
Homestead.yaml
:et changement:
puis dans
Homestead
répertoire, exécutez:Voir si cela fonctionne.
Si vous utilisez une enveloppe de couche (comme la Cuisine CI) et que vous exécutez un 32b de l'hôte, vous aurez à anticiper l'installation de l'Errance des boîtes. Leur fournisseur par défaut est le opscode "famille" des binaires.
Donc, avant de
kitchen create default-ubuntu-1204
assurez-vous que vous utilisez:pour l'utilisation de la 32b image si votre hôte ne prend pas en charge la taille de mot de virtualisation
Je l'ai résolu quand j'ai tué le mastic processus. Parce que j'ai git-ssh et putty à la fois en cours d'exécution. Ils apparaissaient à se battre les uns les autres pour l'accès ssh. Un seul suffit.
Comme certaines personnes ici l'a déjà souligné, l'erreur apparaît - entre autres choses - si l'image VirtualBox ne pas démarrer correctement. Pour moi, en utilisant le mode GUI sur Vagrant n'aide pas beaucoup, car il ne montre qu'une fenêtre noire. Dans le VirutalBox GUI j'ai vérifié les paramètres sur ma VM et compris que d'une certaine façon le système d'exploitation était mal réglé (Debian 32 au lieu de 64 Bits).
Donc je ne peux que recommander la vérification de la VirtualBox paramètres de la machine virtuelle manuellement et l'obtention de la VM à démarrer sans l'aide de l'Errance à la première place.
Ma solution à ce problème était que mon vieux portable a été prise wayyyyyyyyyyy trop long à démarrer. J'ai ouvert Virtual Box, connecté à la box et attendu que l'écran de chargement. A pris environ 8 minutes.
Alors il connecté et monté mes dossiers et allé de l'avant.
juste être patient parfois!
Ma solution est avéré être rien de ce qui précède exactement. Je suis sur Ubuntu 14 en tant qu'invité à l'intérieur d'un Windows 7 ordinateur hôte. J'avais été l'exécution de cette vagrant box bien, mais j'ai commencé à nouveau après de ne pas l'utiliser pour un couple de mois, et il a cessé de venir avec le SSH délai d'attente de connexion. Il s'est avéré qu'en quelque sorte, la paire de clés n'a pas de travail donc j'ai copié le Vagrant clé publique dans Ubuntu en suivant les instructions sur cette page. Mais ce n'était pas tout. J'ai alors découvert que la clé privée dans ma zone de base est différente de la clé privée ici. Mettre cette clé privée dans le vagrant_private_key fichier dans C:\Users\your-user.vagrant.d\boxes\vagrant-box-name\nnnnnnnn\virtualbox après le placement de la clé publique dans Ubuntu résolu le problème.
Ici est de savoir comment cela a fonctionné pour moi:
Dans mon cas, de donner une adresse IP fixe, il suffit de résoudre le problème:
config.vm.network "private_network", ip: "192.168.50.50"
Eu ce problème pendant plus d'une semaine, Essayé toutes les solutions,
Rien n'a fonctionné.
Finalement obtenu la solution de ce lien
Ajouter le
Google public DNS IP
à votreWifi Settings
under Network Preferences > Wifi > Advanced > DNS
ajouter Adresse IP 8.8.8.8A parfaitement fonctionné. Peut-être cela aide à toute personne qui ont des problèmes sous Mac.
Grâce Skovmand
network preference
, je l'ai mentionné dans ma réponseC'est une nouvelle "fonctionnalité" de l'errance. Jetez un oeil ici:
https://github.com/mitchellh/vagrant/issues/3329
Ils vont changer la "Erreur" d'un "Avertissement". C'est juste vous dire que la machine n'est pas démarré, et il essaie de se connecter...