Rozwiązywanie „Odpowiedzi RTNETLINK: plik istnieje” podczas uruchamiania ifup

Jeśli rozwiązanie podane przez @ theoB610 nadal nie działa , wtedy może być konieczne opróżnienie urządzenia wlan0 przed ifup i ifdown.

sudo ip addr flush dev wlan0 

Jest to problem niezbyt specyficzny dla Raspberry Pi, podobny problem wystąpił i został rozwiązany w sieciach przewodowych w tutaj (skąd wyprowadziłem rozwiązanie mojego problemu z Pi).

Komentarze

• Miałem ten problem na serwer HP ProLiant (!) i to naprawiło.
• Świetne rozwiązanie. Podstawowym problemem jest to, że niektóre poprzednie konfiguracje, automatyczne lub ręczne (takie jak uruchamianie ifconfig z wiersza cmd) wciąż się utrzymują. Grypa polecenie sh naprawia tę sytuację.
• Miałem ten problem, gdy występują zniekształcone pliki /etc/sysconfig/network-scripts/ifcfg-*, które powodowały, że Menedżer sieci nie lubił niektórych konfiguracji i tworzył plik zastępczy, tworząc w ten sposób wiele dodatkowych plików i powodując błąd RTNETLINK answers: File exists. Usunięcie zepsutych (tych, które nie ' nie są wyświetlane jako profil) wydaje się być rozwiązaniem.
• Nigdy nie kopiuj i wklejaj tego na serwerze produkcyjnym. Zamieniłem wlan0 na eth0 i interfejs natychmiast przestał działać i nie ' nie chcę wracać.
• Ciekawe, że nikt nie zapewnił najprostszej i z zasady najbezpieczniejszej metody : reboot. Na przykład z opróżnianiem interfejsu miałem kłopoty – mój interfejs / adres IP zepsuł się i mogłem połączyć się tylko bezpośrednio z konsoli … więc ponowne uruchomienie jest zawsze najlepszym rozwiązaniem.

Myślę, że rozwiązanie można znaleźć w tym poście na blogu Rozwiązywanie problemu „RTNETLINK odpowiedzi: plik istnieje ”podczas uruchamiania ifup ; to z pewnością naprawiło to dla mnie.

Zasadniczo możesz mieć przypisaną tylko jedną bramę w swoim pliku interfejsów. Usuń wszystkie zduplikowane wiersze określające bramę, aby pojawiała się tylko raz.

Zmodyfikowano / etc / network / interfaces file:

auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.1.2 netmask 255.255.255.0 gateway 192.168.1.1 iface wlan0 inet static address 192.168.1.3 netmask 255.255.255.0 #gateway 192.168.1.1 <= Either comment or remove this line 

Wszystkie zasługi dla Lennart za rozwiązanie tego problemu!

Komentarze

• Natknąłem się na tę odpowiedź za pośrednictwem Google. To właśnie zadziałało dla mnie na maszynie wirtualnej Ubuntu na Hyper-V
• Proszę zaakceptuj własną odpowiedź, klikając znacznik po jej lewej stronie. Tylko to zakończy pytanie i nie będzie pojawiać się ponownie rok za rok.

Rozwiązałem by:

sudo ifup --ignore-errors wlan0 

po tym poleceniu ifdown i ifup zaczęły działać poprawnie.

Komentarze

• Jest to przydatne po " ponownym uruchomieniu sieci usługi ", dziękuję. 🙂

kroki:

1 check-> ip route (jeśli domyślna trasa IP jest inna niż wymagany interfejs, wykonaj 2d & trzeci krok)

2 sudo ip route del default (usuń ten domyślny interfejs)

3 sudo ip route add default via ip_address dev interface_name (dodaj wymagany interfejs w ten sposób)

W moim przypadku nadal działało inne połączenie – kiedy wyłączyłem ten interfejs z ifdown eth0, przyszedł ten, który mnie interesował (wlan0) w porządku.

Nie polecam używania opcji –ignore-errors

Natknąłem się na to podczas zabawy z VMWare vCenter.Jeśli znajdujesz się na tej samej łodzi, przed utworzeniem szablonu / migawki maszyny wirtualnej powinieneś zainstalować narzędzia VMWare, perl i net-tools z menedżerem pakietów.

Używamy ifdown, aby usunąć RTNETLINK i ponownie ifup

ifdown wlan0 ifup wlan0 

Wymuś de / configuration

ifdown --force --verbose ethX && ifup --force --verbose ethX