Deaktivieren von NetworkManager unter RHEL 7

9

Ich habe einen RHEL7-Server in VMware vSphere eingerichtet und habe Probleme, ihn ohne NetworkManager in das Netzwerk zu bringen. Ich habe den Server so konfiguriert, dass er während des Installationsvorgangs eine statische IP-Adresse hat, und er hat alles mit NetworkManager eingerichtet. Während dies funktioniert, verwenden wir NetworkManager in meinem Büro nicht. Deshalb habe ich die Konfigurationsdatei eingegeben, um RHEL6-Server ohne NetworkManager online zu schalten.

/ etc / sysconfig / network-scripts / ifcfg-ens192 lautet wie folgt:

NAME = ens192
TYP = Ethernet
ONBOOT = ja
NM_CONTROLLED = nein
BOOTPROTO = statisch
IPADDR = 10.0.2.15
PREFIX = 24
GATEWAY = 10.0.2.2

Wenn ich NetworkManager deaktiviere, startet der Netzwerkdienst jedoch nicht mit dem folgenden Fehler

#Service Netzwerk Neustart

Neustart des Netzwerks (über systemctl): Job für network.service fehlgeschlagen. Weitere Informationen finden Sie unter 'systemctl status network.service' und 'journalctl -xn'.

Und beide Befehle geben Folgendes aus:

Netzwerk [1838]: RTNETLINK-Antworten: Datei existiert
Netzwerk [1838]: RTNETLINK-Antworten: Datei existiert
Netzwerk [1838]: RTNETLINK-Antworten: Datei existiert
Netzwerk [1838]: RTNETLINK-Antworten: Datei existiert
Netzwerk [1838]: RTNETLINK-Antworten: Datei existiert
Netzwerk [1838]: RTNETLINK-Antworten: Datei existiert
Netzwerk [1838]: RTNETLINK-Antworten: Datei existiert
systemd [1]: network.service: Steuerungsprozess beendet, Code = beendet Status = 1
systemd [1]: LSB konnte nicht gestartet werden: Bring Up / Down-Vernetzung

Außerdem gibt der Befehl 'ip addr' Folgendes aus:

1: lo: mtu 65536 qdisc noqueue state UNBEKANNTER
     Link / Loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
     inet 127.0.0.1/8 Bereich Host lo
       valid_lft für immer bevorzugt_lft für immer
     inet6 :: 1/128 Gültigkeitsbereich Host
       valid_lft für immer bevorzugt_lft für immer
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

— Andrew
quelle

RTNETLINK answers: File existsbedeutet, dass alles, was network.serviceversucht wurde hinzuzufügen (wahrscheinlich IP-Adressen), bereits vorhanden war. Führen ip addrSie die Ergebnisse aus und fügen Sie sie Ihrer Frage hinzu.

— BenjiWiebe

Ich habe kürzlich ein Problem mit behoben network.serviceund der beste Weg, um die IP-Befehle zu verfolgen, war strace. Sie sollten diese Art von Fehler im Allgemeinen nicht erhalten. Es könnte sich lohnen, darüber zu berichten (idealerweise über den Support).

— Pavel Šimerda

2

Überprüfen Sie Ihre MAC-Adresse für die VM. Es sollte 08: 00: 27: 98: 8e: df sein, da dies gezeigt wird, dass Sie ip addr ausgeführt haben. Wenn es etwas anderes ist, müssen Sie es in Ihrer ifcfg-ens192-Datei wie folgt festlegen, aber die Adresse durch die tatsächliche ersetzen.

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

Ich hatte das gleiche Problem und dies löste es für mich.

— Nickg
quelle

Die Konfigurationsdatei in der Frage basiert anscheinend auf NAME = ens192, ohne dass eine MAC-Adresse übereinstimmt.

— Pavel Šimerda

1

Alles, was ich gefunden habe, um dies zu beheben, ist der MAC in der Konfiguration

 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

Wenn Sie sich der Hardwareadresse nicht sicher sind, finden Sie sie in.

 cat /sys/class/net/ens192/address

— 0ldd0g
quelle

1

Versuchen Sie, zu den Netzwerkeinstellungen der virtuellen Maschine zu wechseln, stellen Sie sicher, dass das Netzwerkkabel angeschlossen ist, und überprüfen Sie, ob Sie dies mit einer Firewall blockiert haben.

— Belal Mohammed
quelle

0

Sie sollten diese Informationen (GATEWAY = 10.0.2.2) in / etc / sysconfig / network ablegen, sobald dies abgeschlossen ist. Der Neustart des Dienstes sollte erfolgreich sein

— Adrien Lm
quelle

0

Auch ich bin auf den Fehler "LSB konnte nicht gestartet werden: Netzwerk hoch- / runterfahren" gestoßen, da NetworkManager deaktiviert wurde. Es dauerte zwei Minuten, bis die Schnittstellen nach dem Booten aufgerufen wurden. Die Ursache der Verwirrung war "... LSB". Es stellte sich heraus, dass die Nachricht nur aus dem traditionellen Skript /etc/rc.d/init.d/network stammt. In meinem Fall löste das Folgende das Problem;

Zu Netzwerkskripten / ifcfg-eth0 hinzugefügt

NMCONTROLLED=no

Unnötige ifcfg- * -Dateien wurden entfernt, die NetworkManager zurückgelassen hat

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

— Ntats
quelle

0

Dies wird das Problem lösen!

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

# reboot

Bearbeiten Sie nun / etc / sysconfig / network-scripts / ifcfg-eth0,
Fügen Sie neu generiertes HWADDR hinzu oder entfernen Sie es
UUID-Leitung entfernen

-Starten Sie den Netzwerkdienst neu

 #systemctl restart network.service

JETZT! Arbeiten.

— Abdullah
quelle

0

NetworkManager bestimmt die Standardroute (IP-Route), obwohl Ihre Schnittstelle nm deaktiviert hat. Es ist nur diese Schnittstelle, nicht das gesamte System.

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

— rjt
quelle

1

systemctl disablestoppt keinen Dienst und wird auch nicht chkconfig ... offin den gleichen Befehl übersetzt.

— Pavel Šimerda

-1

Ich hatte das gleiche Problem. Also habe ich die Backup - Dateien nur löschen habe ich in /etc/sysconfig/network-scripts, wie ifcfg-Bridge_connection_1.homeund ifcfg-Bridge_connection_1.officewo ich für die Sicherung Nutzung erstellt. Sie sollten dort nicht erstellt werden. Das /etc/init.d/network restartkönnte gut funktionieren, nachdem diese nutzlosen ifcfg- * gelöscht wurden.

— Rubin
quelle