Netzlaufwerkmount funktioniert nicht beim Start des Raspberry

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Habe die Mount Definition mit folgendem Aufbau ausgeführt.
    fstab wird bei aktuellem Jessie lite nicht ausgeführt

    Beim Testsystem mit dem Pi3 funktioniert der Mount.
    Bei allen anderen Systemen funktioniert der Mount beim Start des Raspberry nicht.
    Starte ich nach dem Hochfahren den Mount Befehl wird des Freigegebene Verzeichnis eingebunden.

    Code
    sudo systemctl start media-hdd.mount


    uname -a

    Code
    Linux ccs-ht-rasp02 4.9.13-v7+ #974 SMP Wed Mar 1 20:09:48 GMT 2017 armv7l GNU/Linux

    Leider finde ich keine Lösung hierfür damit der Mount wieder automatisch abläuft.

    Anbei noch die Startreihenfolge.
    sudo systemd-analyze plot >/media/hdd/$HOSTNAME.svg

  • Netzlaufwerkmount funktioniert nicht beim Start des Raspberry? Schau mal ob du hier fündig wirst!

  • Moin Burny,

    sagst du mir woher du den Kernel 4.9.13-v7+ #974 SMP Wed Mar 1 20:09:48 GMT 2017 armv7l GNU/Linux hast?

    Durch ein rpi-update?

    Aktuell ist ein 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l GNU/Linux.

    Wenn du das obige Kommando genutzt hast, dann kann es sein das dein System etwas durcheinander ist.

    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.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • So wie es aussieht, wird (wieder mal) versucht, die Verbindung zur Netzwerkfreigabe zu erreichen, bevor das Netzwerk oben ist.

    In die Unit eintragen, dass das Netz oben sein muss, dann sollte es funktionieren.

    Computer ..... grrrrrr

  • @DG8BR
    Diese Version

    Code
    uname -a
    Linux ccs-ht-rasp07 4.9.13-v7+ #974 SMP Wed Mar 1 20:09:48 GMT 2017 armv7l GNU/Linux

    wurde durch eine Neuinstallation und anschließendem Update errreicht.

    @Rasp-Berlin

    Zitat

    In die Unit eintragen, dass das Netz oben sein muss, dann sollte es funktionieren.


    In welcher Datei muss ich was eintragen bzw. umdrehen?

    Lg

    Chris

    Raspberry Pi 2/2+/3/3+

    Stretch|Buster Lite, FHEM
    RFXtrx433E, SIGNALduino, nanoCUL433MHz & 868MHz, HomeMatic

    FS20, IT, HomeMatic, WMR200, TEK603, YouLess, APC, SUSV, Resol VBUS, Fronius DataloggerWeb2

    Einmal editiert, zuletzt von Burny (15. März 2017 um 09:00)


  • ... und anschließendem Update errreicht.

    Ja, aber als Update solltest Du (bei raspbian) kein "sudo rpi-update" ausführen, sondern lediglich:

    Code
    sudo apt-get update
    sudo apt-get dist-upgrade

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

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • OK das wusste ich auch nicht.

    Muss ich die Raspberry's jetzt wieder neu aufstetzen?

    Lg

    Chris

    Raspberry Pi 2/2+/3/3+

    Stretch|Buster Lite, FHEM
    RFXtrx433E, SIGNALduino, nanoCUL433MHz & 868MHz, HomeMatic

    FS20, IT, HomeMatic, WMR200, TEK603, YouLess, APC, SUSV, Resol VBUS, Fronius DataloggerWeb2


  • Muss ich die Raspberry's jetzt wieder neu aufstetzen?

    Das kommt drauf an. Hast Du schon zwei Verzeichnisse "/lib/modules/4.4.50*" auf deinem PI? Wenn nicht, dann:

    Code
    sudo apt-get update
    sudo apt-get dist-upgrade


    ausführen und rebooten.

    EDIT:

    Poste auch die Ausgabe von:

    Code
    ls -la / | grep bak

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

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (13. März 2017 um 13:44)


  • Habe die Mount Definition mit folgendem Aufbau ausgeführt.
    fstab wird bei aktuellem Jessie lite nicht ausgeführt


    Genau das ist die Ursache Deines Problems. Und leider holen mich hier meine alten Sünden wieder ein. In Deinem angehängten Bootlog kannst Du genau sehen, dass der Mount-Versuch passiert, bevor das Netz fertig ist, siehe network-online.target, obwohl das Netz noch weitere 8 Sekunden benötigt. Die Lösung in dem genannten Thread ist übernommen von einem älteren Thread von mir, aber heute weiss ich, dass der Ansatz falsch ist... wie gesagt, sieh Dir Dein Bootlog an. Der Anbindung an "network-online.target" ist an dieser Stelle schlichtweg falsch und überflüssig.

    Ich habe diesen älteren Thread auf einen aktuellen Stand gebracht. Du solltest diese neue Lösung übernehmen.

    Siehe #24 und #26

    Hth

    Einmal editiert, zuletzt von WinterUnit16246 (13. März 2017 um 21:36)

  • @ThomasL
    Danke für Deinen Hinweis.
    Diese Systemänderung funktioniert jetzt jedenfalls bei dem Testsystem wo es vorher nicht zum Erfolg führte.
    Werde diese Änderung gleich bei allen anderen Systemen nachziehen.
    Aktuelle Konfiguration für die Verbindung zum Netzwerkverzeichnis auf einen Windows 2008R2 Server

    rpi444
    Ich hatte gelegentlich die RPI Updates durchgeführt.

    Code
    sudo apt-get install rpi-update
    sudo rpi-update

    Folgende Verzeichnisse sind /lib/modules vorhanden.

    Code
    pi@ccs-ht-rasp02:/lib/modules $ dir
    4.4.23+     4.4.34+     4.4.36+     4.4.46+     4.9.11+     4.9.14+
    4.4.23-v7+  4.4.34-v7+  4.4.36-v7+  4.4.46-v7+  4.9.11-v7+  4.9.14-v7+
    4.4.30+     4.4.35+     4.4.44+     4.4.50+     4.9.13+
    4.4.30-v7+  4.4.35-v7+  4.4.44-v7+  4.4.50-v7+  4.9.13-v7+
    Code
    pi@ccs-ht-rasp02:~ $ ls -la / | grep bak
    drwxr-xr-x   3 root root  4096 Okt 10 12:00 boot.bak

    Lg

    Chris

    Raspberry Pi 2/2+/3/3+

    Stretch|Buster Lite, FHEM
    RFXtrx433E, SIGNALduino, nanoCUL433MHz & 868MHz, HomeMatic

    FS20, IT, HomeMatic, WMR200, TEK603, YouLess, APC, SUSV, Resol VBUS, Fronius DataloggerWeb2

    Einmal editiert, zuletzt von Burny (14. März 2017 um 13:01)

  • @ThomasL
    Bis auf ein System funktionieren alle.
    Es startet bei diesem System zwar der Mount für die Verbindung zum Netzlaufwerk, aber FHEM wurde schon vorher gestartet und hat noch keinen Zugriff auf das Netzlaufwerk.
    sudo systemd-analyze plot >/media/hdd/$HOSTNAME.svg

  • Bis auf ein System funktionieren alle.
    Es startet bei diesem System zwar der Mount für die Verbindung zum Netzlaufwerk, aber FHEM wurde schon vorher gestartet und hat noch keinen Zugriff auf das Netzlaufwerk.

    Wie ist denn fhem.service konfiguriert?

    Code
    systemctl cat fhem.service

    Was spricht dagegen, die Abhängigkeit zum Netzwerk und "drauf warten" in fhem.service konkret vorzugeben?

    Code
    After=network_wait_online.service

    Gegebenenfalls sogar:

    Code
    After=network_wait_online.service
    Requires=network_wait_online.service

    Einmal editiert, zuletzt von WinterUnit16246 (15. März 2017 um 10:48)

  • @ThomesL

    Zitat

    Was spricht dagegen, die Abhängigkeit zum Netzwerk und "drauf warten" in fhem.service konkret vorzugeben?


    Eigentlich nichts. Ich müsste nur wissen wo genau ich die Definition für FHEM abändern muss.
    Linux bin ich noch nicht so richtig Fitt.

    Die fhem.service sieht bei mir so aus:

    Lg

    Chris

    Raspberry Pi 2/2+/3/3+

    Stretch|Buster Lite, FHEM
    RFXtrx433E, SIGNALduino, nanoCUL433MHz & 868MHz, HomeMatic

    FS20, IT, HomeMatic, WMR200, TEK603, YouLess, APC, SUSV, Resol VBUS, Fronius DataloggerWeb2


  • Eigentlich nichts. Ich müsste nur wissen wo genau ich die Definition für FHEM abändern muss.
    Linux bin ich noch nicht so richtig Fitt.

    An der Stelle gibt es ein kleines Problem... und zwar durch den Umstand, dass fhem durch ein Startscript in den Runlevels gestartet wird, wobei diese Technik bereits Anfang 2015 durch systemd abgelöst wurde. Die von Dir gepostete Service-Unit ist eine autogenerierte Unit durch systemd, mit der systemd in gewisser Weise eine Abwärtskompatibilität zu "vergangenen Zeiten" herzustellen versucht. Das Problem dabei ist, dass die runlevels für systemd zu unpräzise sind und insofern nur annäherungsweise interpretiert werden können, also kann es eben bei Parallelstarts von Services zu diesem Effekt kommen, dass das Netzwerk beim fhem-Start noch nicht bereit ist.

    Ich würde jetzt folgendes machen. Als erstes diese vorhandene Unit außer Betrieb nehmen:

    Code
    systemctl disable fhem.service
    systemctl stop fhem.service

    Als nächstes würde ich dann eine eigene neue Unit einrichten und in Bertrieb nehmen und schauen, ob es damit so läuft, wie gewünscht. Der Vorteil ist, bei Problemen kann man ganz einfach wieder alles zurücknehmen und einfach die alte Service-Unit wieder einsetzen. Achtung: Die neue Unit bekommt die Rechte root:root:644.

    Code
    nano /etc/systemd/system/fhem-neu.service

    Dann starten und auf Fehler kontrollieren, und wenn keine Fehler sind für den Boot-Vorgang einrichten. Wenn Fehler auftauchen, abbrechen und erst die Fehler beheben:

    Code
    cd /etc/systemd/system
    systemctl start fhem-neu.service
    systemctl status fhem-neu.service
    
    
    systemctl enable fhem-neu.service

    Einmal editiert, zuletzt von WinterUnit16246 (15. März 2017 um 15:57)


  • Die fhem.service sieht bei mir so aus:

    Ergänze mal in der /etc/init.d/fhem, die Zeilen:

    Code
    # Required-Start:    $local_fs $remote_fs
    # Required-Stop:     $local_fs $remote_fs


    wie folgt:

    Code
    # Required-Start:    $network $local_fs $remote_fs
    # Required-Stop:     $network $local_fs $remote_fs


    restarte "fhem.service" und siehe danach die Ausgabe von:

    Code
    systemctl cat fhem.service

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

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Änderungen ausgeführt.
    Nur was soll das bringen wenn die Zeile mit # beginnt?

    Lg

    Chris

    Raspberry Pi 2/2+/3/3+

    Stretch|Buster Lite, FHEM
    RFXtrx433E, SIGNALduino, nanoCUL433MHz & 868MHz, HomeMatic

    FS20, IT, HomeMatic, WMR200, TEK603, YouLess, APC, SUSV, Resol VBUS, Fronius DataloggerWeb2


  • Änderungen ausgeführt. Nur was soll das bringen wenn die Zeile mit # beginnt?


    Ich vermute, die würden von sysvinit resp. von update-rd.d geparsed werden, um entsprechende Run-Level-Links zu erzeugen. Du kannst das hier mal nachlesen:
    https://wiki.debian.org/LSBInitScripts
    Vermutlich reicht dafür aber nicht allein die Änderung und ein Disable plus hinterher Enable. Wahrscheinlich brauchts dafür auch ein 'update-rd.d {name} remove' plus anschließendem 'update-rd.d {name} default' oder so ähnlich.... das musst Du mal nachlesen bzw. überprüfen.

    Du solltest nur abwägen, ob Energie und Arbeit in vage Annäherungslösungen reinzustecken, deren Systematik eigentlich schon tot ist und die nur noch an der Beatmungsmaschine hängen, überhaupt noch sinnvoll sind. Zumal das sowieso nur eine Lösung auf Zeit ist.... vermutlich nur noch für die Laufzeit von "Stretch". Meine Empfehlung ist da etwas radikaler.... und zwar grundsätzlich jedes Runlevel-Script entsorgen, sofern es sich ohne Aufwand entsorgen lässt, und es durch eigene Service-Units ersetzen. Das wäre dann der zukunftsorientierte Weg. Aber die Entscheidung muss Du selber treffen.

    Einmal editiert, zuletzt von WinterUnit16246 (15. März 2017 um 21:07)

  • Einfacher gesagt als getan.
    Wenn ich mich mit Service-Units auskennen würde, wäre das sicher eine Lösung.

    Lg

    Chris

    Raspberry Pi 2/2+/3/3+

    Stretch|Buster Lite, FHEM
    RFXtrx433E, SIGNALduino, nanoCUL433MHz & 868MHz, HomeMatic

    FS20, IT, HomeMatic, WMR200, TEK603, YouLess, APC, SUSV, Resol VBUS, Fronius DataloggerWeb2


  • Einfacher gesagt als getan.
    Wenn ich mich mit Service-Units auskennen würde, wäre das sicher eine Lösung.


    Ich habe Dir doch eine geänderte Service-Unit gepostet..... funktioniert es nicht, die originale einfach zu ersetzen.... also die alte ausplanen und die neue einplanen?


  • Änderungen ausgeführt.

    Code
    systemctl cat fhem.service
    Unit file of fhem.service changed on disk. Run 'systemctl daemon-reload'.

    Deine Änderungen/Ergänzungen sind noch nicht wirksam. Versuch mal:

    Code
    sudo systemctl daemon-reload
    sudo systemctl restart fhem.service
    systemctl cat fhem.service
    head -n 20 /etc/init.d/fhem

    EDIT:

    BTW: In jessie (systemd) kann man z. B. mit:

    Code
    head -n 20 /etc/init.d/* | grep -i provide


    sehen bzw. anzeigen lassen, für welche Dienste die maintainer z. Zt. noch die Verwendung von Runlevel-Scripts vorgesehen haben (... d. h. noch keine service-unit erstellt).

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

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (15. März 2017 um 22:36)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!