Expiration du délai de connexion bloqué

Mon vagrant fonctionnait parfaitement bien la nuit dernière. Je viens de mettre le PC sous vagrant up , de bash le vagrant up , et vagrant up ce que j’ai:

 ==> 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 at-il déjà eu ça? Le vagrant n’est pas encore largement couvert sur le Web et je ne trouve aucune raison pour laquelle cela se produit.

J’ai résolu ce problème et répondrai au cas où quelqu’un d’autre aurait un problème similaire.

Ce que j’ai fait, c’est: j’ai activé l’interface graphique de la boîte virtuelle pour voir qu’elle attendait une entrée au démarrage pour déterminer si je voulais démarrer directement sur ubuntu ou safemode, etc.

Pour activer l’interface graphique, vous devez la placer dans votre Vagrantfile :

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

Lorsque vous êtes bloqué avec votre machine vagrante de la manière décrite ci-dessus, il n’est pas nécessaire de démarrer en mode interface graphique (et est impossible sans un serveur X).

Pendant le démarrage de votre machine virtuelle, dans une fenêtre de terminal distincte, recherchez simplement l’identifiant de la machine en cours d’exécution.

 vboxmanage list runningvms 

Cela se traduira par quelque chose comme ceci:

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

Assez souvent, la VM attend simplement que vous sélectionniez une option dans le chargeur de démarrage. Vous pouvez envoyer le keycode approprié (dans le cas, Enter ) à la vm avec controlvm :

 vboxmanage controlvm projects_1234567890 keyboardputscancode 1c 

C’est tout. Votre machine virtuelle continuera le processus de démarrage.

Une chose à vérifier est si la virtualisation du matériel est activée dans le BIOS de votre machine.

Mon problème est la même chaîne de délais, mais je ne pouvais voir qu’un écran noir dans l’interface graphique.

Un ordinateur portable que je venais juste d’installer montrait toujours le même problème. Après des heures de recherche, j’ai finalement trouvé un conseil pour voir si la virtualisation matérielle du BIOS était activée.

Voici le contenu du post que j’ai trouvé:

Je vois qu’il y a encore des utilisateurs qui rencontrent ce problème. Donc, je vais essayer de résumer une liste ci-dessous de certaines solutions possibles au problème de délai d’attente SSH:

  • Assurez-vous que votre pare-feu ou votre antivirus ne bloque pas le programme (ce dont je doute que cela se produise souvent)
  • Donnez à votre machine vagrant un certain temps pour que les temps morts se produisent. Si vous ne disposez pas d’un PC / Mac très rapide, la VM mettra du temps à démarrer dans un état prêt pour SSH, de sorte que des dépassements de délai se produiront.
  • Par conséquent, essayez d’abord de laisser la temporisation intempestive COMPLETEMENT avant de conclure à une erreur.
  • Si le temps passe trop vite, augmentez le délai d’expiration du fichier vagrant à quelques minutes et réessayez.
  • Si cela ne fonctionne toujours pas, essayez de démarrer votre machine vagrant à l’aide de l’interface VirtualBox et activez au préalable l’interface graphique de la machine. Si l’interface graphique n’affiche rien (c.-à-d. Juste un écran noir, pas de texte) pendant le démarrage, votre machine vagrante a des problèmes.
  • Détruisez la machine entière via l’interface VB et réinstallez-la.
  • Supprimez les fichiers d’image Ubuntu dans le dossier Vagrant Images du dossier utilisateur et téléchargez à nouveau et installez-les.
  • Avez-vous même un processeur Intel prenant en charge la virtualisation matérielle 64 bits? Recherche le sur Google. Si vous le faites, assurez-vous qu’il n’y a pas de paramètre dans votre Bios désactivant cette fonctionnalité.
  • Désactivez la fonctionnalité hyper-v si vous utilisez Windows 7 ou 8. Google comment désactiver.
  • Assurez-vous que vous utilisez un client compatible SSH. Utilisez Git Bash. Télécharger: http://git-scm.com/downloads
  • Installez une version 32 bits d’ubuntu comme trusty32 ou precise32. Changez simplement la version dans le fichier errant et réinstallez vagrant dans le nouveau répertoire.
  • Assurez-vous que vous utilisez les dernières versions de vagrant et de virtualbox. Derniers complexes: Formatez votre ordinateur, réinstallez Windows et achetez un processeur Intel Core isomething.

J’espère que cela pourra aider.

La solution que j’ai trouvée consiste à vérifier l’option de connexion par câble dans la carte 1 connectée à NAT. Je ne sais vraiment pas, c’est ma 4ème boîte vagrante mais c’est la seule avec l’option de connexion par câble non vérifiée, et en la vérifiant, cela fonctionne. Connexion par câble NAT

J’ai eu exactement le même problème. Je pensais que le problème pourrait être avec les clés SSH (mauvaise localisation du fichier ou autre chose mais je l’ai vérifié plusieurs fois) mais vous pouvez toujours append le nom d’utilisateur et le mot de passe configure (sans utiliser les clés ssh) et Vagrantfile gui pour que le code de Vagrantfile ressemble plus ou moins comme ci-dessous:

 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 

Dans mon cas, même si l’interface graphique était affichée, j’ai un écran noir (pas d’erreurs ou de possibilité de connexion ou autre) et dans la console, j’ai eu l’ Error: Connection timeout. Retrying... Error: Connection timeout. Retrying... plusieurs fois. Je me suis assuré que VT-x (virtualisation) était activé dans le BIOS, j’ai vérifié plusieurs combinaisons de versions de Virtual Box et de Vagrant ensemble et de nombreuses boîtes Vagrant (pour certains, je n’avais pas d’écran noir dans l’interface graphique problèmes). Enfin, j’ai mis à jour VirtualBox et Vagrant dans les dernières versions et le problème est toujours survenu.

La chose cruciale était de regarder les icons dans VirtualBox après avoir exécuté vagrantup (avec l’interface graphique dans Vagrantfile comme je l’ai montré ci-dessus) comme sur l’image ci-dessous

entrer la description de l'image ici

Même si je n’avais aucune erreur dans VirtualPC (aucun avertissement indiquant que VT-x n’est pas activé), mon icône V était grise, ce qui signifie que le VT-x était désactivé. Comme je l’ai dit, je l’avais toujours activé dans mon BIOS.

Enfin, je me suis rendu compte du problème que pourrait poser HYPER-V que j’ai également installé et activé pour tester des sites sur Internet Explorer plus ancien. Je suis allé dans le Control Panel -> Programs and functions / Software Windows Control Panel -> Programs and functions / Software et choisissez dans le menu de gauche Turn on or Turn off Windows functions (j’espère que vous trouverez ceux-ci, j’utilise Windows polonais, donc je ne connais pas les noms anglais exacts). J’ai éteint Hyper-V, redémarré le PC et après avoir exécuté Virtual Box et vagrant up je n’ai finalement eu aucune erreur, dans l’interface graphique j’ai un écran de connexion et mon icône V cessé d’être grise.

J’ai perdu beaucoup de temps à résoudre ce problème (et de nombreux redémarrages de PC), alors j’espère que cela pourrait être utile à toute personne ayant des problèmes sous Windows – assurez-vous que Hyper-V est désactivé dans votre Panneau de configuration.

Le mien fonctionnait bien et puis cet “Avertissement: Déconnexion de la connexion à distance. Réessayer …” encore et encore – peut-être 20 fois – jusqu’à ce qu’il soit connecté. Basé sur les réponses ci-dessus je viens

 vagrant destroy vagrant up 

et tout était bon. Le mien était très simple mais je l’ai fait en réduisant le fichier Vagrant à seulement config.vm.box = "ubuntu/trusty64" et il le faisait toujours. C’est pourquoi détruire et recommencer semblait être le meilleur choix. Étant donné la nature sans état de ces images vagrantes, je ne vois pas pourquoi cela ne fonctionnerait pas dans tous les cas. Je ne fais que commencer et je peux encore apprendre que ce n’est pas vrai.

J’ai rencontré le même problème sur un ordinateur Windows 8.1. Le délai de connexion et l’activation de l’interface graphique n’étaient pas du tout utiles, l’écran était noir. Le correctif dans mon cas désactivait “Hyper V”

Citation de la documentation Vagrant https://docs.vagrantup.com/v2/hyperv/index.html

Avertissement: si vous activez Hyper-V, VirtualBox, VMware et toute autre technologie de virtualisation ne fonctionneront plus. Consultez cet article sur le blog https://www.hanselman.com/blog/SwitchEasilyBetweenVirtualBoxAndHyperVWithABCDEditBootEntryInWindows81.aspx pour créer facilement une entrée de démarrage pour démarrer Windows sans que Hyper-V ne soit activé.

Si vous travaillez sur Windows 8 ou 10, voici ce qui a fonctionné pour moi:

  1. Modifier les parameters du BIOS pour permettre la virtualisation du 64 bits.
  2. Voici comment:
    • Redémarrez le PC en utilisant Advanced Startup (Allez au démarrage avancé – redémarrer maintenant – “résoudre les problèmes” – “option avancée” – “UEFI Firmware Setting” – “Restart”)
    • Dans la fenêtre du BIOS – Allez dans l’onglet / menu “Avancé” – Activez “Technologie virtuelle Intel”
    • Enregistrer et quitter

J’ai eu un problème avec cela avec une boîte existante (pas sûr de ce qui a changé), mais je pouvais me connecter via SSH, même si la boîte Vagrant ne parvenait pas à démarrer. Comme il arrive, ma clé SSH a changé.

A partir du dossier racine vagrant, j’ai couru vagrant ssh-config qui m’a dit où se trouvait le fichier de clés. Je l’ai ouvert avec puttygen et puis il m’a donné une nouvelle clé.

Sur mon invité Linux, j’ai édité ~/.ssh/authorized_keys et y ai déposé la nouvelle clé publique.

Tout fonctionne à nouveau – pour l’instant!

J’ai eu le même problème après avoir supprimé cette ligne de mon fichier Vagrant:

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

VM chargée bien après avoir remis cette ligne.

J’ai eu le même problème, mais aucune des autres réponses n’a complètement résolu mon problème. La réponse de @Kiee a été utile, même si tout ce que je pouvais voir dans l’interface graphique était un écran noir (avec le soulignement en haut à gauche, ce problème dans Virtual Box a également été soulevé séparément dans le cas d’un débordement de stack, encore une fois rien).

À terme, une solution s’est avérée très simple: vérifiez la version de votre machine virtuelle.

Plus précisément, j’avais une boîte avec quelqu’un d’autre avec Debian 64 bits, mais Virtual Box a insisté pour le traiter comme 32 bits, ce que je n’ai pas remarqué. Pour le changer, ouvrez Virtual Box, puis ouvrez le terminal et lancez

 vagrant up 

attendre la ligne

 default: SSH auth method: private key 

maintenant vous pouvez appuyer sur Ctrl + C (ou attendre le délai d’expiration) et exécuter

 vagrant halt 

votre machine virtuelle ne sera pas détruite, vous pouvez donc la voir dans le menu de Virtual Box, mais elle sera désactivée pour que vous puissiez modifier les parameters. Choisissez votre machine dans le menu, cliquez sur “Paramètres” -> “Général” et choisissez la “Version” appropriée, pour moi c’était “Debian (64 bits)”. Après ce type vagrant up nouveau.

Si c’est le cas pour vous (ou si différentes modifications apscopes à «Paramètres» ont résolu votre problème), vous pouvez créer une nouvelle boîte à partir de la frappe réparée.

 vagrant package --output mynew.box 

Quelques détails supplémentaires: Ubuntu 12.04 hôte 32 bits, invité Debian 8.1 64 bits, Virtual Box 5.0.14, Vagrant 1.8.1

Il y a beaucoup de bonnes réponses ici, et je ne pouvais pas tout lire, mais je viens juste de donner ma petite consortingbution. J’ai eu 2 problèmes différents:

  1. vagrant up n’a pas pu trouver mon ssh ‘ id_rsa ‘ (car je ne l’avais pas encore, à ce moment-là): j’ai lancé ssh-keygen -t rsa -b 4096 -C "myemailaddress@mydomain.com" , basé sur sur cet article de GitHub , et voilá, franchi le pas;

  2. Ensuite, j’ai le même problème de cette question ” Attention: la connexion a expiré. Réessayer … “, éternellement …: Après avoir beaucoup lu, j’ai redémarré mon système et regardé mon BIOS (F2 pour obtenir là, sur PC), et la virtualisation était désactivée . Je l’ai activé, sauvegardé et redémarré le système pour vérifier s’il a bien changé.

Après ça, vagrant up fonctionné comme un charme! Il est 4h du matin mais ça marche! Comment cool, hã? : D Comme je sais qu’il y a très peu de développeurs masochistes comme moi qui essaieraient ça chez Windows, spécialement chez Windows 10 , je ne peux pas ne pas oublier de venir ici et de laisser mon mot… une autre information importante est que, J’essayais de mettre en place Laravel 5 , en utilisant Homestead, VirtualBox, compositeur, etc. Cela a fonctionné. Alors, j’espère que cette réponse vous aidera comme cette question et les réponses m’ont aidé. Mes meilleurs voeux. Au revoir!

Le délai d’expiration de la connexion SSH lors du démarrage initial peut être lié à diverses raisons, telles que:

  • vérifier si la virtualisation est activée dans le BIOS (selon les commentaires ),
  • le système attend l’interaction de l’utilisateur (par exemple, la partition de partage n’est pas prête ),
  • non concordance de votre clé privée (vérifiez la configuration via vagrant ssh-config ),
  • le processus de démarrage prend beaucoup plus de temps (essayez d’augmenter config.vm.boot_timeout ),
  • il démarre à partir du mauvais lecteur (par exemple, de l’installateur ISO),
  • Mauvaise configuration du pare-feu VM (par exemple, configuration iptables ),
  • règles de pare-feu locales, conflit de port ou conflit avec un logiciel VPN,
  • sshd mauvaise configuration.

Pour déboguer le problème, exécutez-le avec une option --debug ou:

 VAGRANT_LOG=debug vagrant up 

S’il n’y a rien d’évident, alors essayez de vous y connecter depuis un autre terminal, par vagrant ssh ou par:

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

Si le SSH échoue toujours, essayez de l’exécuter avec une interface graphique (par exemple, config.gui = true ).

Si ce n’est pas le cas, vérifiez les processus en cours (par exemple: vagrant ssh -c 'pstree -a' ) ou vérifiez votre sshd_config .


S’il s’agit d’une VM jetable, vous pouvez toujours essayer de la destroy et de la up .

Vous devriez également envisager de mettre à niveau votre Vagrant et Virtualbox.


Pour plus d’informations, consultez la page Débogage et dépannage .

Je testais un dossier monté dans ma machine virtuelle vagrant en ajoutant une nouvelle entrée dans /etc/fstab . Plus tard, je me suis déconnecté, j’ai couru s’arrêter vagrant, mais quand j’ai couru vagrant up j’ai eu:

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

J’ai lu tous ces articles et essayé tous ceux qui semblaient pertinents pour mon cas (sauf pour détruire vagrant, qui aurait certainement corrigé mon problème, mais é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 depuis l’interface graphique de VirtualBox. Au cours du processus de démarrage, la VM s’est arrêtée et m’a demandé si je voulais ignorer le assembly du dossier de test que j’avais ajouté précédemment à /etc/fstab . (C’est pourquoi vagrant n’a pas pu démarrer la machine virtuelle.) Après avoir répondu «NON», la machine virtuelle n’a pas rencontré de problème. Je me suis connecté, j’ai retiré la vilaine ligne de mon fstab et j’ai arrêté la machine virtuelle.

Après ce vagrant a pu démarrer très bien.

À emporter? Si un vagrant soudain ne peut pas redémarrer dans votre machine virtuelle, essayez de démarrer directement depuis le fournisseur (VirtualBox dans mon cas). Les chances sont que votre démarrage est suspendu pour quelque chose de totalement indépendant de SSH.

J’ai eu le même problème lorsque j’utilisais la boîte x64 (chef / ubuntu-14.04).

J’ai changé pour x32 et ça a fonctionné (hashicorp / precise32).

Peut-être est-ce une réponse trop simple pour aider beaucoup de gens, mais cela vaut la peine d’essayer si vous ne le faites pas: Faites un «arrêt vagrant» au lieu d’une «suspension errante», puis redémarrez la VM avec «vagrant».

Je pense que mon problème était dû à un processus de “kworker” devenant bogué et à un chronométrage constant sur la machine virtuelle. Le redémarrage semblait donc relancer correctement le processus alors qu’une sauvegarde et une restauration ne faisaient que restaurer le processus interrompu.

J’ai eu ceci en exécutant vagrant / VirtualBox dans VirtualBox. J’ai résolu ce problème en exécutant la machine vagrante dans la machine hôte.

L’installation d’un bit ubuntu32 sur un bit AMD64 a fait l’affaire. Je n’ai pas access aux BIO car c’est un environnement restreint, mais je pouvais toujours le faire fonctionner avec Ubuntu / Trusty32 au lieu de Ubuntu / Trusty64

Utiliser Vagrant 1.6.3 avec VirtualBox 4.3.15 sur Windows 7 SP1

J’espère que cela pourra aider.

Pour moi, c’était la compatibilité entre vagrant et boîte virtuelle.

Je suis sur Windows 10 et ce que j’ai fait j’ai désinstallé vagrant et boîte virtuelle

Ensuite, installez une ancienne version de la boîte virtuelle en particulier la version 4.3.38 (Installez également le pack d’extension pour cette version)

Puis installé la dernière copie de vagrant (1.8.5 pour le moment)

Après ça a fonctionné.

J’ai découvert que sur MacOS avec VirtualBox, l’ajout de ceci à Vagrantfile vous permettra d’aller plus loin:

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

Si vous ne souhaitez pas activer l’interface graphique et que vous devez ensuite la désactiver ultérieurement, vous pouvez également installer le pack d’extension à partir d’Oracle:

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

Ensuite, mettez ceci dans votre fichier Vagrant pour activer VRDP:

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

Maintenant, vous pouvez utiliser RDP pour vous connecter à votre boîte à la demande sans avoir à exécuter SSH ou à ouvrir l’interface graphique à tout moment.

Une autre solution possible pour les utilisateurs du fournisseur VMware: pour moi, le problème a été résolu après la suppression d’une installation parallèle de VirtualBox sur la même machine hôte. Les interfaces réseau entre VMware et VirtualBox étaient apparemment contradictoires

J’ai rencontré le même problème. J’ai résolu ce Virtualization activant la Virtualization partir de la configuration du BIOS .

Supprimer le fichier:

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

Puis lancez:

 vagrant up 

Ce qui a fonctionné pour moi était la virtualisation 64 bits sur un OS 64 bits (Ubuntu 13.10) à partir du BIOS.

Vérifiez que la virtualisation de votre CPU dans la configuration du BIOS est activée.

FWIW– Mon problème était dû à l’utilisation d’un fichier de configuration vraiment ancien au lieu d’un fichier plus récent. L’utilisation du nouveau fichier de configuration (et donc du DSL modifié / modifié) a résolu mes problèmes instantanément.

Ce qui m’a aidé, c’est de permettre la virtualisation dans le BIOS, car la machine n’a pas démarré.

Plutôt que de faire un ctrl-d-out de la boîte virtuelle comme je le ferais chaque fois que je me pencherai sur quelque chose, je pense que vagrant préférerait que vous passiez dans un autre terminal et que vous fassiez:

vagrant halt

pour arrêter la boîte. Ensuite, il n’y aura plus de problèmes pour revenir dans le VB.

J’ai rencontré le même problème, mais aucune des solutions mentionnées n’a fonctionné pour moi! Je l’ai résolu en rétrogradant Vagrant à 1.6.2 et maintenant ça marche!