Question Désactivation de NetworkManager sur RHEL 7


Je mettais en place un serveur RHEL7 dans vmware vSphere et je ne parviens pas à l'obtenir sur le réseau sans NetworkManager. J'ai configuré le serveur pour qu'il ait une adresse IP statique pendant le processus d'installation et il a tout configuré avec NetworkManager. Bien que cela fonctionne, nous n'utilisons pas NetworkManager dans mon bureau, alors je suis allé et j'ai entré ce que nous mettons habituellement le fichier de configuration pour obtenir les serveurs RHEL6 en ligne sans NetworkManager.

/ etc / sysconfig / network-scripts / ifcfg-ens192 est le suivant:

NOM = ens192
 TYPE = Ethernet
 ONBOOT = oui
  NM_CONTROLLED = non
 BOOTPROTO = statique
 IPADDR = 10.0.2.15
  PREFIXE = 24
 PASSERELLE = 10.0.2.2

Cependant, lorsque je désactive NetworkManager, le service réseau ne parvient pas à démarrer avec l'erreur suivante

# redémarrage du réseau de service

Redémarrage du réseau (via systemctl): le job pour network.service a échoué.   Voir 'systemctl status network.service' et 'journalctl -xn' pour   détails.

Et les deux commandes affichent les informations suivantes:

network [1838]: RTNETLINK répond: Le fichier existe
 réseau [1838]:   RTNETLINK répond: Le fichier existe
 network [1838]: RTNETLINK répond:   le fichier existe
 network [1838]: RTNETLINK répond: Le fichier existe
  network [1838]: RTNETLINK répond: Le fichier existe
 réseau [1838]:   RTNETLINK répond: Le fichier existe
 network [1838]: RTNETLINK répond:   le fichier existe
 systemd [1]: network.service: processus de contrôle terminé,   code = état de sortie = 1
 systemd [1]: impossible de démarrer LSB: monter / descendre   la mise en réseau

Aussi, voici ce que la commande 'ip addr' affiche:

1: lo: mtu 65536 qdisc noqueue state INCONNU   
 link / loopback 00: 00: 00: 00: 00: 00 brd   00: 00: 00: 00: 00: 00
 inet 127.0.0.1/8 portée   hôte lo
 valid_lft   pour toujours preferé
 inet6   :: Hôte de portée 1/128
  valid_lft pour toujours   preferred_lft pour toujours
 2: ens192: mtu 1500   qdisc noop state DOWN qlen 1000
  link / ether 08: 00: 27: 98: 8e: df brd   ff: ff: ff: ff: ff: ff


9
2017-07-11 22:19


origine


RTNETLINK answers: File exists signifie que peu importe network.service essayé d'ajouter (probablement des adresses IP) étaient déjà là. Courir ip addr et ajoutez les résultats à votre question. - BenjiWiebe
J'ai récemment débogué un problème avec network.service et le meilleur moyen de suivre les commandes ip était strace. Vous ne devriez généralement pas avoir ce type d'erreur. Cela pourrait valoir la peine d'être signalé (idéalement via un support). - Pavel Šimerda


Réponses:


Vérifiez votre adresse MAC pour la VM. Il devrait être 08: 00: 27: 98: 8e: df puisque c'est ce qui est montré, vous avez couru ip addr. Si c'est autre chose, vous devrez le définir dans votre fichier ifcfg-ens192 avec les éléments suivants, mais remplacer l'adresse par le réel.

HWADDR="08:00:27:98:8e:df"

J'ai eu le même problème et cela l'a résolu pour moi.


2
2017-10-25 16:46



Le fichier de configuration dans la question repose apparemment sur NAME = ens192 sans correspondance d'adresse MAC. - Pavel Šimerda


Tout ce que j'ai trouvé qu'il faut pour résoudre ce problème est que MAC dans la configuration

 NAME=ens192
 TYPE=Ethernet
 ONBOOT=yes
 HWADDR="08:00:27:98:8e:df"
 NM_CONTROLLED=no
 BOOTPROTO=static
 IPADDR=10.0.2.15
 PREFIX=24
 GATEWAY=10.0.2.2

Si vous n'êtes pas sûr de l'adresse matérielle, vous pouvez la trouver.

 cat /sys/class/net/ens192/address

2
2017-12-30 14:46





Essayez d'accéder aux paramètres réseau de la machine virtuelle et assurez-vous que le câble réseau est connecté et vérifiez si vous l'avez bloqué avec un pare-feu.


1
2018-02-19 14:11





vous devriez mettre cette information (GATEWAY = 10.0.2.2) dans / etc / sysconfig / network une fois cela fait, le redémarrage du service devrait réussir


0
2017-08-20 10:54





J'ai également rencontré l'erreur "Impossible de démarrer LSB: Bring up / down networking", depuis la désactivation de NetworkManager. Il a fallu deux minutes pour que les interfaces soient activées après le démarrage. La cause de la confusion était "... LSB". Il s'est avéré que le message provient uniquement du script traditionnel /etc/rc.d/init.d/network. Dans mon cas, le problème suivant a été résolu;

À scripts de réseau / ifcfg-eth0 ajoutée

NMCONTROLLED=no

Suppression des fichiers ifcfg- * inutiles laissés par NetworkManager

# rm /etc/sysconfig/network-scripts/ifcfg-Wired_connection_?

0
2018-06-26 00:10





Cela résoudra le problème!

# rm /etc/udev/rules.d/70-persistent-ipoib.rules 

# reboot
  • Maintenant, éditez / etc / sysconfig / network-scripts / ifcfg-eth0,
  • Ajouter un nouveau fichier HWADDR généré ou le supprimer
  • Supprimer la ligne UUID

-Redémarrer le service réseau

 #systemctl restart network.service

À PRÉSENT! Travail.


0
2018-05-11 10:26





NetworkManager dicte la route par défaut (ip route) même si votre interface a nm désactivée, il ne s'agit que de cette interface et non de l'ensemble du système.

ps aux | grep -I net   # will probably find NetworkManager still running.
chkconfig network on
systemctl disable NetworkManager.service
systemctl stop NetworkManager.service

0
2017-07-12 04:49



systemctl disable n'arrête pas un service, pas plus chkconfig ... off ce qui se traduit essentiellement par la même commande de toute façon. - Pavel Šimerda


J'avais le même problème. Donc, je supprime simplement les fichiers de sauvegarde que j'ai faits dans /etc/sysconfig/network-scripts, tel que ifcfg-Bridge_connection_1.home et ifcfg-Bridge_connection_1.office que j'ai créé pour une utilisation de sauvegarde. Ils ne devraient pas être créés là. le /etc/init.d/network restart pourrait fonctionner bien après avoir supprimé ces ifcfg- * inutiles.


-1
2017-07-20 04:48