Posts by baertiger

    Zumindest sah es am Anfang gut aus....aber nach einer Weile kommt dann

    N: Für das Depot »http://raspbian.raspberrypi.org/raspbian buster InRelease« wurde der »Suite«-Wert von »stable« in »oldstable« geändert.

    Das ist noch nachvollziehbar, aber dann:

    W: Fehlschlag beim Holen von http://raspbian.raspberrypi.org/raspbian/dists/buster/main/binary-armhf/Packages Fehler beim Schreiben der Ausgabedatei - write (28: Auf dem Gerät ist kein Speicherplatz mehr verfügbar) [IP: 93.93.128.193 80]

    W: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder alte an ihrer Stelle benutzt.

    Welches Gerät ist hier gemeint? Die IP-Adresse 93.93.128.193 ist in London....

    Hallo,


    Sudo apt-get update gibt mir die folgende Meldung aus:


    sudo apt-get update

    Holen:1 http://raspbian.raspberrypi.org/raspbian buster InRelease [15,0 kB]

    Holen:2 http://archive.raspberrypi.org/debian buster InRelease [32,6 kB]

    Paketlisten werden gelesen... Fertig

    E: Für das Depot »http://raspbian.raspberrypi.org/raspbian buster InRelease« wur de der »Suite«-Wert von »stable« in »oldstable« geändert.

    N: Sie müssen dies explizit bestätigen, bevor Aktualisierungen von diesem Depot angewendet werden können. Lesen Sie die apt-secure(8)-Handbuchseite, wenn Sie we itere Informationen benötigen.

    E: Für das Depot »http://archive.raspberrypi.org/debian buster InRelease« wurde der »Suite«-Wert von »testing« in »oldstable« geändert.

    N: Sie müssen dies explizit bestätigen, bevor Aktualisierungen von diesem Depot angewendet werden können. Lesen Sie die apt-secure(8)-Handbuchseite, wenn Sie we itere Informationen benötigen.


    das apt-secure-Handbuch war für mich nicht hilfreich. Wie bestätigt man das explizit?

    und eigentlich will ich ja keine oldstable version, sondern die aktuelle stable... Wie komme ich da hin?


    Liebe Grüße

    Michael

    Wo habe ich denn geschrieben, das der cron job minütlich laufen soll :conf: ?

    Hast du gar nicht, das ist von mir, aber deshalb muss ich es doch nicht verschweigen. Dein Beitrag war auf jeden Fall eine gute Anregung für mich, etwas über cron zu lernen. Danke für den Hinweis.


    Muss ich zwar selbst nochmals testen, aber ich dachte die wird von alleine wieder hergestellt. Ich hatte zumindest noch nie Probleme diesbezüglich.

    Ich hatte festgestellt, daß meine Verbindung abgebrochen war und habe es darauf zurückgeführt, daß ich zwischendurch den Server rebootet hatte. Deine Antwort hat mich angeregt, das noch einmal genau zu überprüfen.

    Ergebnis: Du hast recht. Nach Reboot des Servers wird die Verbindung wieder hergestellt.

    Mein Thema hat sich damit erübrigt und mein Problem ist ein anderes.

    Danke für Deine Reaktion.

    Ich habe mir cron mal angesehen. Ich denke, das sollte man nicht nutzen. Ein einmaliger Skript ist wahrscheinlich besser. Ich möchte die Überwachung engmaschig realisieren und wenn ich jede Minute einen Prozess mit cron starte, könnte es passieren, daß bei Wiederverfügbarkeit der Verbindung 2 Instanzen des Skripts sich gegenseitig stören.


    Worum es mir geht, ist die Verfahrensweise, den mount-Prozess manuell anzustoßen. Du hast geschrieben, die systemctl aufzurufen. In dem Beitrag sind aber nur eine serverctl.service bzw. serverctl erwähnt.

    Ich habe hier mal - mein erster bash skript überhaupt - einen Versuch unternommen. Bis dahin auch getestet.

    Aber wie stelle ich es richtig an, dann neu zu mounten? Und wie kann ich den Skript nach dem erstmaligen mounten während des Bootprozesses anstoßen?

    Hallo,

    ich habe Deine Anleitung mit Erfolg dazu benutzt, 2 RaspberryPi miteinander zu koppeln und einem den Zugriff auf die Festplatte des zweiten zu ermöglichen.
    Im Gegensatz zum Zugriff auf einen Server kommt es hierbei eher vor, daß der 2. Raspi neu gestartet wird und die Verbindung dabei verloren geht.
    Sinnvoll wäre nun eine Überwachung der Verbindung, indem man zyklisch prüft, ob ein Verzeichnis auf der Festplatte des zweiten Raspi vom Raspi 1 aus zu sehen ist.

    Ist das nicht der Fall, muß die Prüfung wie bei Dir beschrieben, neu angestoßen werden.

    Deine Skripte basieren offenbar auf dem Startprozess des Betriebssystems und wie es genau abläuft, kann ich nur teilweise nachvollziehen. Wie könnte man den Mount-Prozess nach Trennung der Verbindung neu anstoßen, um die Verbindung robuster zu machen?

    Ich habe einen rpi4b mit Raspberry pi OS mit grafischem Interface, welches ich jedoch nur gelegentlich nutze.

    Normalerweise starte ich in die Kommandozeile und von dort aus Kodi.

    Eine angeschlossene USB-Festplatte wird nach Neustart immer wieder unter /media/pi/ eingehängt, auch wenn ich sie in der /etc/fstab woanders einhängen möchte, selbst wenn in der /etc/fstab überhaupt nicht eintrage.

    Kann das am installierten grafischen Interface liegen, auch wenn es nicht gestartet wird?

    Oder hat jemand eine Idee, was der Grund sein könnte?


    sudo blkid -o list -w /dev/null:

    Code
    device     fs_type label    mount point    UUID
    -------------------------------------------------------------------------------
    /dev/mmcblk0p1
    vfat    boot     /boot          04A5-3FE5
    /dev/mmcblk0p2
    ext4    rootfs   /              c1578b06-85c2-4327-9c65-4c474a8f23f9
    /dev/sda1  ntfs    TOSHIBA  /media/pi/TOSHIBA 083C36F93C36E0FC
    /dev/mmcblk0
    (in use)



    /etc/fstab:

    Code
    proc            /proc           proc    defaults          0       0
    PARTUUID=81498d8b-01  /boot           vfat    defaults          0       2
    PARTUUID=81498d8b-02  /               ext4    defaults,noatime  0       1
    # a swapfile is not a swap partition, no line here
    #   use  dphys-swapfile swap[on|off]  for that
    
    #UUID=083C36F93C36E0FC /home/hts/ ntfs-3g nofail,rw,auto,nls=utf8,gid=hts,uid=hts 0 0
    #UUID=083C36F93C36E0FC /mnt/usbstorage/ ntfs-3g defaults,auto,permissions,users,rw,nofail,umask=000 0 0
    /dev/sda1/ /mnt/usbstorage/ ntfs-3g defaults,auto,permissions,users,rw,nofail,umask=000 0 0

    ich habe den Fehler eben gefunden.

    Bei der Verifikation des client wurde dieser im eth0-Protokoll abgewiesen. Der Grund war, daß bei der Installation von Tvheadend der Client-Zugriff auf den Adressbereich 192.168.178.0/24 eingeschränkt wurde. Das war mir aktuell nicht mehr so bewußt, aber das Auseinanderlaufen der beiden Protokolle an dieser Stelle hat mich veranlaßt, bei Tvheadend noch einmal nachzusehen und da hat es geklingelt.


    Also vielen Dank an dieser Stelle nochmal, ich habe wieder etwas dazu gelernt. :danke_ATDE:

    es geht schon wieder, ich habe tcpdump inzwischen installiert und versuche mich in die Ausgaben einzulesen.

    Hier schon mal 2 Mitschnitte:




    läßt sich erst einmal schwer lesen, ich habe vor, noch je einen Mitschnitt von beiden Verbindungen aufzunehmen, als Rohdaten und mir diese mit Wireshark anzusehen. Bin mit TCP-Protokollen nicht vertraut.

    Der 2. Mitschnitt ist gekürzt, sonst Nachricht zu lang... max. 50.000 Zeichen

    ich glaube, da muß ich erst mal warten, bis ich tcpdump installieren kann

    Code
    pi@Raspi3:~ $ sudo apt-get update
    Fehl:1 http://raspbian.raspberrypi.org/raspbian buster InRelease
    Verbindung mit raspbian.raspberrypi.org:80 kann nicht aufgebaut werden

    Server

    Code
    pi@Medienserver:~ $ sudo netstat -tulpena | grep -i 998
    tcp        0      0 0.0.0.0:9981            0.0.0.0:*               LISTEN      0          17334      640/tvheadend
    tcp        0      0 0.0.0.0:9982            0.0.0.0:*               LISTEN      0          17337      640/tvheadend
    tcp        0      0 192.168.0.1:9982        192.168.0.2:56684       VERBUNDEN   115        23141      640/tvheadend


    Client

    Code
    pi@Raspi3:~ $ nc -zv 192.168.0.1 9981
    Connection to 192.168.0.1 9981 port [tcp/*] succeeded!
    pi@Raspi3:~ $ nc -zv 192.168.0.1 9982
    Connection to 192.168.0.1 9982 port [tcp/*] succeeded!

    Im Tvheadend-Addon von Kodi ist die IP-Adresse des Gerätes anzugeben, auf dem der Tvheadend-Server läuft (rot umrandet):

    Steht hier die wlan-Adresse des Servers (192.168.178.43), funktioniert es grundsätzlich, mit der eth0-Adresse (192.168.0.1) nicht. Das ist die einzige mir bekannte Stelle, wo ich definieren kann, wie die Verbindung hergestellt werden soll.

    Um das Resultat gem. #10 zu erreichen bräuchte ich doch lediglich den ersten Eintrag meiner Tabelle

    zu löschen:

    Code
    sudo route del -net 0.0.0.0 netmask 0.0.0.0  dev eth0


    Das Ergebnis

    Code
    pi@Raspi3:~ $ route -n
    Kernel-IP-Routentabelle
    Ziel            Router          Genmask         Flags Metric Ref    Use Iface
    0.0.0.0         192.168.178.1   0.0.0.0         UG    303    0        0 wlan0
    192.168.0.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0
    192.168.178.0   0.0.0.0         255.255.255.0   U     303    0        0 wlan0

    paßt zu #10, führt aber nicht zum gewünschten Ergebnis bei kodi.

    FSC830 : OK, es war gestern offenbar schon etwas spät für mich, habe es korrigiert


    Ich werde mich jetzt mit den Möglichkeiten des route-Befehls beschäftigen, vielleicht hat jemand noch einen guten Literatur-Tip.

    Überdauert so ein route-Befehl einen Neustart, und falls nicht, wie kann man ihn beim Start automatisch ausführen lassen?

    Ausgabe mit LAN-Verbindung:

    Ausgabe ohne LAN-Verbindung, Kabel entfernt: