Plötzlich kein SSH mehr => Neuinstallation, was nun?!

  • Hallo,


    mein Pi läuft mit fester IP (zugewiesen per Router) im lokalen Netzwerk. Über den entsprechend eingerichteten SSH Zugriff war er auch immer erreichbar.


    Nun habe ich ein paar Programme installiert und die fstab geändert; nach dem folgenden Reboot war der Pi nicht mehr per SSH zu erreichen. Das Problem hatte ich schon einmal, damals leider nicht gelöst (und, nachdem der Pi neu aufgesetzt war vergessen). Soweit ich mich erinnern kann, war der Pi noch erreichbar, indem man Tastatur und Bildschirm angeschlossen hat - dies kann ich jetzt nicht testen, weil beides nicht zur Verfügung steht.


    Der Pi enthielt vorher nur Apache, MySql und Php. Zusätzlich installiert hatte ich nzbget, couchpotato und sonarr. In der fstab habe ich nur einen NAS Ordner eingebunden, der sich auch auch erfolgreich mounten lies.


    Jetzt setze ich den Pi gerade neu auf und möchte vermeiden, _wieder_ einen Fehler zu begehen. Meine History des frischen Pi sieht noch folgendermaßen aus:
    sudo raspi-config
    (Dateisystem erweitert, SSH aktiviert, Boot zur Konsole ohne Login, Boot ohne auf das Netzwerk zu warten)
    sudo apt-get update -y
    sudo reboot now
    sudo apt-get upgrade -y


    Mehr habe ich noch nicht gemacht. Nun möchte ich die fstab wieder entsprechend ändern und die o.g. Programme (nzbget, CouchPotato, Sonarr) installieren. Ggf. auch einen kleinen Git-Server. Für Apache, MySql etc. besteht aktuell _kein_ Bedarf auf dem Pi.


    Da der Pi sich vorher immer problemlos rebooten lies, gehe ich davon aus, dass bei der Installation irgend etwas schief gelaufen sein muss. Leider kann ich aber nicht nachvollziehen, was.


    Das Upgrade ist jetzt gerade durch. Ich werde nun noch einmal rebooten und dann ggf. schon mal ein Backup der SD Karte erstellen; dies nach jedem Schritt (nach fstab, nach Installation von nzbget, nach Installation von CouchPotato etc. etc.) zu wiederholen, bis irgendwann ein Fehler auftritt, nur um dann von dem vorherigen Backup von vorne zu beginnen, ist mir allerdings etwas zu umständlich.


    Wie würdet Ihr vorgehen? Kann ich nach dem Mount des NAS Ordners manuell vollständige Backups des Pi, die ich dann im Notfall wieder (von Hand) auf die SD Karte aufspielen kann? Komischerweise liefen die o.g. Programme in der Konstellation schon mehrmals scheinbar ohne Probleme, nach Reboots war aber immer der SSH Zugang weg.


    Danke im Voraus für Eure Hilfe :)


  • Hallo,


    mein Pi läuft mit fester IP (zugewiesen per Router) im lokalen Netzwerk. Über den entsprechend eingerichteten SSH Zugriff war er auch immer erreichbar.


    mehrmals scheinbar ohne Probleme, nach Reboots war aber immer der SSH Zugang weg.


    nach fester ip hört sich das aber nicht an, es sei dann du hast dem router gesagt das der raspi mit der mac-adr die ip bekommen soll.


    ich wuerd nee 2.sd karte mit boot faehigen linux bereit halten und im notfall mit dem starten und damit auf die andere sd-karte schaun warum die ploetzlich nicht funktioniert (log etc.)


  • nach fester ip hört sich das aber nicht an, es sei dann du hast dem router gesagt das der raspi mit der mac-adr die ip bekommen soll.


    Der DHCP Server im Router weist DIESEM Pi anhand seiner Mac Adresse immer die IP zu. So ist dieser IP seit mindestens einem Jahr immer über ein und dieselbe Adresse erreichbar (auch noch Neueinrichtung etc.)


    Quote


    FAQ => Nützliche Links / Linksammlung => Wenn das root Password vergessen wurde => Methode 4


    Die Zugang per SSH ist überhaupt nicht mehr möglich. Es liegt nicht an einem falschen PW oder so. Auch das Anpingen des Geräts funktioniert nicht mehr nach einem Reboot...

  • Moin,


    ... Der DHCP Server im ...
    ...


    hast Du jessie drauf? Evtl. direkt als neues Image?
    Ich hatte das Phänomen, dass die MAC <-> IP Zuweisung im Router bei mir plötzlich nicht funktionierte ( -> click <- ).


    Grund: jessie bringt einen eigenen dhcpd mit, der dann die zugewiesene Adresse ändert.


    cu,
    -ds-

  • Moin,
    hast du keinen Fernseher mit HDMI?? Da würdest du den Hochlauf sehen.


    Mein erster Impuls war, das NAS kann nicht gemountet werden, darum hängt der Hochlauf.


    Irgend sowas hatte ich auch mal..


    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"

    Vielleicht trifft man sich in der RPi-Plauderecke.

  • Quote

    hast du keinen Fernseher mit HDMI?? Da würdest du den Hochlauf sehen.


    Doch, den habe ich schon. Der Pi hat aber kein WLAN und daher würde ich den Hochlauf nicht originalgetreu nachvollziehen können. Grundsätzlich ist das aber eine Möglichkeit.


    Quote

    Mein erster Impuls war, das NAS kann nicht gemountet werden, darum hängt der Hochlauf.


    Wie hattest Du das Problem gelöst? Also gemountet wird unter

    Code
    /mnt/$dirname

    und das NAS ist immer verfügbar. Die Einträge in der fstab stimmen -denke ich jedenfalls-, der Ordner konnte per

    Code
    sudo mount -a

    ja auch gemountet werden.


    Probleme mit den Rechten dürfte es auch nicht geben. Die fstab kann ich ja sowieso nur als su editieren...?


    Quote

    Setz dich an die Pi mit Tastatur und Bildschirm, und schau dir mal die Logs an.


    Wie gesagt: Tastatur und Bildschirm sind in der Form nicht verfügbar. Sonst hätte ich das schon getan.


    Quote

    hast Du jessie drauf? Evtl. direkt als neues Image?
    Ich hatte das Phänomen, dass die MAC <-> IP Zuweisung im Router bei mir plötzlich nicht funktionierte


    Es läuft 2016-03-18-raspbian-jessie-lite. Das Problem dürfte aber wirklich beim Mounten oder den anderen Programmen liegen. Ich kann den Pi aktuell immer wieder neu starten. Die über den Router festgelegte IP ist erreichbar und anpingbar. Nach Update und Upgrade. Nach jedem Neustart funktioniert SSH. Gerade deshalb glaube ich auch nicht, dass der Fehler bei jessie und/oder dem eigenen DHCP liegt. Sonst wäre ja bereits jetzt kein Reboot mehr möglich.


    Wenn der Pi eine neue IP vergeben würde, sollte diese doch auch über den Router sichtbar sein. Aber dort sehe ich nirgends eine alternative IP (bzw. jetzt funktioniert ja noch alles und ich kann es nicht testen; hatte es beim letzten Auftreten des Problems aber getestet)


    Quote

    ..dann probiers mit dem ersten link und sag dem Kernel direkt welche Netzwerkdaten er nutzen soll..


    Ich mache jetzt ein manuelles Backup der SD und probiere das dann mal.


    Grundsätzlich dürfte es doch nicht an den "paar" Instanzen (nzbget, CouchPotato, sonarr) liegen, oder? Beim Unraren von Dateien und dem Scannen meiner Mediathek durch CP und Sonarr (passiert nur während der Einrichtigung) kommt der Pi zwar ins Schwitzen..... aber er läuft und läuft und läuft, bis ich halt reboote.


  • Wenn der Pi eine neue IP vergeben würde, sollte diese doch auch über den Router sichtbar sein. Aber dort sehe ich nirgends eine alternative IP (bzw. jetzt funktioniert ja noch alles und ich kann es nicht testen; ...


    Wie sind jetzt auf deinem PI, die Ausgabe von:

    Code
    ip a
    ps aux | grep -i [d]hc


    ?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

  • Wie sind jetzt auf deinem PI, die Ausgabe von:

    Code
    ip a
    ps aux | grep -i [d]hc


    ?


    Das sind folgende:



    ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
    valid_lft forever preferred_lft forever
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b.....0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.143/24 brd 192.168.1.255 scope global eth0
    valid_lft forever preferred_lft forever
    inet6 fd7....6/128 scope global noprefixroute
    valid_lft forever preferred_lft forever
    inet6 fd....4ac/64 scope global noprefixroute dynamic
    valid_lft 6908sec preferred_lft 1508sec
    inet6 fe......52/64 scope link
    valid_lft forever preferred_lft forever


    pi@raspberrypi:/mnt $ ps aux | grep -i [d]hc
    root 283 0.0 0.1 2564 1796 ? Ss 13:20 0:03 /sbin/dhcpcd -q -b