No ping after reboot by terminal

    Bonjour to the comunity

    I am on a new fresh KVM root server "RS 1000 G11 iv" and I've modified my /etc/hosts and /etc/hostname.

    I make a simple "reboot" in my terminal, not in the NetcupPanel, the server is in started status in the panel but don't responds to my pings anymore.

    What I've changed :

    127.0.0.1 localhost

    127.0.1.1 srv-b.democrasite.com srvb

    152.53.180.152 srv-b.democrasite.com srvb

    # The following lines are desirable for IPv6 capable hosts

    ::1 localhost ip6-localhost ip6-loopback

    ff02::1 ip6-allnodes

    ff02::2 ip6-allrouters

    That's all, and server respond nothing :

    ssh % ping 152.53.180.152

    PING 152.53.180.152 (152.53.180.152): 56 data bytes

    Request timeout for icmp_seq 0

    Request timeout for icmp_seq 1

    Request timeout for icmp_seq 2

    Request timeout for icmp_seq 3

    Request timeout for icmp_seq 4

    Request timeout for icmp_seq 5

    any Idea ?

    Thanks.

    ------ translation ------

    Bonjour an die Gemeinschaft

    Ich habe einen neuen, frischen KVM-Root-Server "RS 1000 G11 iv" und habe meine /etc/hosts und /etc/hostname geändert.

    Wenn ich einen einfachen "Neustart" in meinem Terminal, nicht im NetcupPanel, durchführe, ist der Server im Panel zwar gestartet, reagiert aber nicht mehr auf meine Pings.

    Was ich geändert habe:


    127.0.0.1 localhost

    127.0.1.1 srv-b.democrasite.com srvb

    152.53.180.152 srv-b.democrasite.com srvb

    # Die folgenden Zeilen sind für IPv6-fähige Hosts erwünscht

    ::1 localhost ip6-localhost ip6-loopback

    ff02::1 ip6-allnodes

    ff02::2 ip6-allrouters

    Das ist alles, und der Server antwortet nicht:

    ssh % ping 152.53.180.152

    PING 152.53.180.152 (152.53.180.152): 56 Datenbytes

    Anfrage-Timeout für icmp_seq 0

    Anfragezeitüberschreitung für icmp_seq 1

    Zeitüberschreitung bei der Anfrage für icmp_seq 2

    Zeitüberschreitung bei der Anfrage für icmp_seq 3

    Zeitüberschreitung bei der Anfrage für icmp_seq 4

    Anfrage-Timeout für icmp_seq 5

    irgendeine Idee?

    Danke.

    Du kannst die VNC-Konsole benutzen, um den Server auch ohne Netzwerkzugriff zu bedienen. Eine andere Möglichkeit ist das Rettungssystem. Wenn es sich nur um ein Netzwerkproblem handelt, sollte der Server noch normal aus dem ServerControlPanel herunterzufahren sein, um ihn im Rettungssystem neuzustarten. Im Rettungssystem könntest du dann die Netzwerkkonfiguration (oder die Firewall, den SSH-Server, etc.) korrigieren.

    Angesichts von 45 Netzwerkdevices denke ich, dass du vielleicht etwas mehr als nur /etc/hosts and /etc/hostname geändert hast. Docker ist offenbar installiert. Das verwendet netfilter für seine Zwecke. Wenn dir nichts anderes einfällt, was du gemacht hast, hilft wahrscheinlich nur eine systematische Fehlersuche. Prüfe, ob eth0 die richtige(n) Adresse(n) hat: ip address show dev eth0. Du kannst mit tcpdump untersuchen, ob die SSH Pakete deinen Server erreichen (tcpdump -i eth0 port 22). Wenn die ufw Firewall installiert ist, lass dir die Konfiguration davon anzeigen: ufw status verbose. Logfiles anschauen ist auch nützlich.

    Ich habe tatsächlich Docker auf dieser Maschine installiert, was auch der Grund für meine Bestellung war. Ich wusste nicht, dass Docker-Netzwerke die Erreichbarkeit der Maschine im Netzwerk zum Absturz bringen können...

    Ich dachte gerade, dass es isoliert ist.

    Mein Fehler... Jetzt sitze ich hier fest:

    sudo systemctl stop docker

    sudo systemctl stop docker.socket

    sudo systemctl stop containerd

    ping -c 4 152.53.180.152 = 100% data lost...

    Was für ein schlechter Tag nicht wahr? :)

    NaN  MichaelOF Command not found, I'm connected via VNC … I've disactivated Docker

    sudo systemctl disable docker

    sudo systemctl disable docker.socket

    sudo systemctl disable containerd


    root@srv-b:~# ip r

    default via 152.53.180.1 dev eth0 onlink

    152.53.180.0/22 dev eth0 proto kernel scope link src 152.53.100.152

    Chain INPUT (policy DROP... with no accepting rules in the chain means that your server throws away everything inbound, so no communication is possible. It's a firewall issue. It may be a result of not finishing the network configuration. Look for hints why the network service fails.

    Einmal editiert, zuletzt von NaN (26. Juni 2025 um 01:22)

    NaN @MickaelOF @Virium

    Hi NaN, I can see that the server is refusing all connections.

    The inability to ping the gateway (152.53.180.1), even though the eth0 interface is configured correctly and the OUTPUT string in iptables is set to ACCEPT, indicates a deeper problem. The RTNETLINK answers: File exists error when starting the network service is the key here. It suggests that the network interface cannot be fully initialized by the kernel.

    This is way beyond my skills, I'm sending a verification request to Netcup, something has a problem above my instance.

    Thanks for your help :)

    ------ Translation -------

    Hallo NaN, ich sehe, dass der Server alle Verbindungen ablehnt.

    Die Unfähigkeit, das Gateway (152.53.180.1) anzupingen, obwohl die eth0-Schnittstelle korrekt konfiguriert ist und die OUTPUT-Kette von iptables auf ACCEPT steht, deutet auf ein tiefer liegendes Problem hin. Der Fehler RTNETLINK answers: File exists beim Start des Netzwerkdienstes ist hier der Schlüssel. Er deutet darauf hin, dass die Netzwerkschnittstelle nicht vollständig vom Kernel initialisiert werden kann.

    Das übersteigt meine Fähigkeiten bei weitem, ich sende eine Überprüfungsanfrage an Netcup, da etwas über meiner Instanz nicht stimmt.

    Vielen Dank für Ihre Hilfe an alle :)

    Zitat von kameleon1er

    I'm sending a verification request to Netcup, something has a problem above my instance.

    Highly unlikely. The interface is configured and up, you're just throwing away all inbound packets. You send the pings but throw away the responses. This is a configuration problem on your end. Reinstall the server with a fresh OS image and take small steps when you configure your services. Reboot in-between steps and verify that everything still comes up again. When something doesn't, don't proceed. Fix the problem first.

    @MickaelOF

    Yes, that's what I decided to do, having received no reply from Netcup all day :)

    What was bothering me was that I'd installed a number of docker applications, one in particular: docker::docmost, and that I already had quite a few articles written in there that I didn't want to lose.

    It took me a long time to configure all that.

    But thanks to Gemini, I went into rescue mode, backed up my entire docker installation + apps + docker volumes => scp -rp ... => one of my other vps and restarted a fresh install.

    Now I'll remember to reboot after each step and check that the network hasn't jumped.

    So, another day lost, but not totally, because I learned a lot in the end.

    Thanks for the help.

    Oh, I've been a bad boy, but I did receive a reply half an hour ago from Support, asking me to run more tests from mode-rescue...

    Too bad, it's now obsolete, we'll never know :)

    But they replied, after 10 hours, but they replied, I have to be fair. :saint: