web-dev-qa-db-fra.com

Nouvelle installation du serveur Ubuntu 14.04 Slow Boot en raison d’un échec de connexion 169.254.169.254

Je viens d'installer Ubuntu Server 14.04 et aucune instance VM n'est opérationnelle. Le temps de démarrage prend une éternité et en appuyant sur la touche F1 pendant le chargement, voici ce que je vois. Les tentatives de connexion continues et les échecs sont infinis. Des corrections simples seraient appréciées (Remarque ont remplacé http par LINK dans les mentions du journal pour activer cette publication): -

 Cloud-init v. 0.7.5 exécutant 'init-local' le mar, 06 mai 2014 19:42:27 +0000. Jusqu'à 359,24 secondes. 
 Cloud-init v. 0.7.5 exécutant 'init' le mar, 06 mai 2014 19:42:31 +0000. Jusqu'à 363,43 secondes. 
 Ci-info: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++. ------- + ------- + ----------- + ----------- + ---------- --------- + 
 ci-info: | Appareil | Up | Adresse | Masque | Hw-Address | 
 Ci-info: + -------- + ------- + ----------- + ------- ---- + ------------------- + 
 ci-info: | lo | Vrai | 127.0.0.1 | 255.0.0.0 | . | 
 ci-info: | em1 | Faux | . | . | 9c: b6: 54: 02: 0d: ab | 
 Ci-info: + -------- + ------- + ----------- + ----------- + ------------------- + 
 ci-info: !!!!!!!! Les informations sur la route ont échoué !!!!!!!!!!!!!!!!!!!!!!! !!!!!!!! 
 2014-05-06 20: 42: 33,252 - url_helper.py [AVERTISSEMENT]: Appel de 'LINK: //169.254.169.254/2009-04-04/meta-data/instance-id 'a échoué [0/120s]: erreur de demande [HTTPConnectionPool (Host =' 169.254.169.254 ', port = 80): Nombre maximal de tentatives dépassé avec l'url:/2009-04-04/meta-data/instance-id (Causée par: [Errno 101] Le réseau est inaccessible)] 
 2014-05-06 20: 42: 34,255 - url_helper.py [AVERTISSEMENT]: Appel de 'LINK: //169.254.169.254/2009-04- 04/meta-data/instance-id 'a échoué [1/120s]: erreur de demande [HTTPConnectionPool (Host =' 169.254.169.254 ', port = 80): Nombre maximal de nouvelles tentatives dépassé avec l'URL:/2009-04-04/meta- data/instance-id (Causée par: [Errno 101] le réseau est inaccessible)] 
 2014-05-06 20: 42: 35,259 - url_helper.py [AVERTISSEMENT]: Appel de 'LINK: //169.254.169.254/2009-04-04/meta-data/instance-id 'en échec [2/120s]: erreur de requête [HTT PConnectionPool (Host = '169.254.169.254', port = 80): Nombre maximal de tentatives dépassé avec l'url:/2009-04-04/meta-data/instance-id (Causé par: [Errno 101], le réseau est inaccessible)] 
4
Jlee

Vous devez exécuter la version cloud du serveur Ubuntu. cloud-init tente de contacter 169.254.169.254, une adresse IP de lien local que les fournisseurs de services cloud écoutent pour fournir des métadonnées sur la VM en cours d'initialisation.

Vous pouvez empêcher cloud-init d'interroger des serveurs distants en définissant le paramètre datasources_list sur None.

En pratique, cela signifie changer le fichier /etc/cloud/cloud.cfg.d/90_dpkg.cfg de:

# to update this file, run dpkg-reconfigure cloud-init
datasource_list: [ NoCloud, ConfigDrive, OpenNebula, Azure, AltCloud, OVF, MAAS, GCE, OpenStack, CloudSigma, Ec2, CloudStack, None ]

à:

# to update this file, run dpkg-reconfigure cloud-init
datasource_list: [ None ]

Si possible, vous voudrez exécuter dpkg-reconfigure cloud-init pour effectuer le changement.

5
Michael Kropat

Dans mon cas (nouvelle installation avec Ubuntu Juju), le problème était que neutron était mal configuré avec la mauvaise adresse IP pour le serveur de métadonnées.

C'est bien: http://techbackground.blogspot.ie/2013/06/metadata-via-dhcp-namespace.html

Cela m'a dirigé vers: root @ neutron:/etc/neutron # cat metadata_agent.ini

    ...
  nova_metadata_ip = 192.168.100.151
  nova_metadata_port = 8775
    ...

J'ai corrigé le nova_metadata_ip et redémarré le service de métadonnées sur les neutrons et cela a résolu le problème.

0
bladedoyle

Oui, et dans notre cas, nous avons dû utiliser [ OpenStack ] par opposition à [ None ] dans le fichier /etc/cloud/cloud.cfg.d/90_dpkg.cfg de notre image dans le cloud, car il s'agissait du type de source de données acceptable pour notre système d'exploitation dans le cloud. Ce problème s’est manifesté lorsque nous avons commencé à utiliser nos images conviviales existantes dans la glacière dans un nuage Juno. Aucun autre système d'exploitation n'avait ce problème, à l'exception de notre image 14.04.
Nous avons également basé notre image 14.04 sur la version Canonical Cloud.

0
Sean Beeg