Vertauschte USB Einbindung verhindert Shutdown

  • Hallo an die Runde,


    je nach Einbindung von zwei USB Geräten (aktiver USB Hub, an diesem hängt ein EnOcean USB 300 Stick) habe ich Probleme, meinen Raspi herunterzufahren. Ist der USB Hub auf /dev/ttyUSB0 und der Enocean Stick auf /dev/ttyUSB1 eingebunden, läuft alles problemlos. Mache ich einen Reboot, wird der Enocean Stick auf /dev/ttyUSB0 eingebunden und der USB Hub auf /dev/ttyUSB1. Möchte ich dann den Raspi mittels shutdown -h now herunterfahren, bleibt der Befehl hängen. Dann hilft nur noch den Enocean Stick abziehen, Stecker ziehen und den Enocean Stick nach dem Booten wieder anzustöpseln, damit erst der USB Hub auf /dev/ttyUSB0 zugewiesen wird.


    Nach Lesen diverser Threads habe ich versucht, den beiden Geräten mittels udev Rule eine neue Belegeung zuzuweisen; leider ohne Erfolg. Nach weiterer Recherche bin ich nun der Meinung, dass dies mein Problem auch nicht lösen wird, da die udev-Rule verwendet werden kann, um aus Anwendungen immer das jeweils gewünschte USB-Device anzusprechen, ohne deren interne /tty Belegung zu wissen, also Pointer-Logik, die nach Vendor/Product-ID sucht. Allerdings spreche ich ja nie direkt den USB Hub an und ist es wohl das Problem, dass der Hub intern, warum auch immer, auf dev/ttyUSB0 hängen muss?! Sehr seltsam finde ich es auch, dass erst der Enocean USB Stick, der ja am USB Hub hängt, zugewiesen wird und dann erst der USB Hub :denker:


    Fällt Euch eine Lösung ein, entweder immer erst den USB Hub immer auf /dev/ttyUSB0 zuzuweisen oder eine Lösung, wie letztlich der shutdown des Raspi wieder einwandfrei funktionieren sollte, auch wenn der Hub auf /dev/ttyUSB1 hängt?


    Zur Info noch Details zu meiner Hardware-Konfuguration:

    Raspi 4B in DeskPi verbaut. An den 2 internen USB 3.0 Anschlüssen hängen eine Touch-Bedienung und Datenübertragung zur SSD, die im DeskPi verbaut ist. An den beiden USB 2.0 Anschlüssen hängt eine USV (Raspi dient als nut-server) und der Anker 60W USB 3.0 Hub. An diesem hängen ein deConz Phoscon Zigbee Stick, ein HMIP RF-USB Stick, ein Aeotec z-Wave Stick und der EnOcean USB300 Stick.


    Danke Euch!



    Grüße

    neuling10

  • Danke für die ersten Hinweise!


    reboot -f macht erfolgreich einen Reboot


    poweroff -f fährt den Raspi herunter, USB Anschlüsse sind stromlos, allerdings bleibt der DeskPi an und auch ein an der GPIO-Leiste angeschlossenes Display bleibt mit Spannung versorgt

  • der Anker 60W USB 3.0 Hub.

    Ist das dieser 7-Port ?

    Bus 002 Device 003: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge

    Ich habe zufällig den gleichen, der hat bei meinem Windowsrechner immer Probleme gemacht, also konnte keine "Hardware sicher entfernen".

    Jetzt habe ich den auch an einem Pi hängen, macht dort aber keine Probleme, weil nichts zum entfernen dran ist.

    Hast du denn einen Monitor dran, an dem man ablesen könnte, woran es hängt, z.B. waiting for job o.ä. ?

    P.S. Laut man poweroff:

  • Nein es ist der Bus 001 Device 004: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub bzw. Bus 001 Device 010: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub. Der Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge ist die M.2 SSD im DeskPi (Anschluss via USB3.0)

    Ich habe den Anker 7-Port USB 3.0 Datenhub mit 3 PowerIO Ladeports angeschlossen.


    Hast du denn einen Monitor dran, an dem man ablesen könnte, woran es hängt, z.B. waiting for job o.ä. ?

    Ja hab ich. Hab es nun wieder mit shutdown -h now versucht. Am Bildschirm erscheint plymouth-poweroff.service in der linken unteren Ecke, ansonsten black screen. Das steht nun schon ein paar Minuten...

  • Jedenfalls sehr seltsam... Hab noch etwas herumgetestet. Die 3 weiteren am Hub angeschlossenen USB-Sticks machen keine Probleme. Wahrscheinlich liegt dies jedoch daran, dass der deConz Zigbee Stick vom Raspi an ttyACM0, der Aeotec z-Wave Stick an ttyACM1 zugewiesen werden und der Homematic RFUSB via separatem Bus kommuniziert. Vermutlich kommt sich dann wohl irgendwas in die Quere bei den beiden Schnittstellenzuweisungen ttyUSB0 und ttyUSB1, was dann irgendeinen Service blockiert...


    Gibt es eine Möglichkeit, die Einbindung des Enocean USB Sticks z.B. um 1 Sekunde zu verzögern, damit er auf ttyUSB1 und nicht auf ttyUSB0 zugewiesen wird?

  • Fehler sucht man eigentlich zuerst in den Logfiles und meine Glaskugel sagt mir, dass dort wahrscheinlich auch "run fsck manually" steht.


    Wenn Du bei < sudo dumpe2fs -h /dev/mmcblk0p2 | grep orphan > schon einen ersten verwaisten Inode angezeigt erhältst, solltest Du erstmal das root Filesystem reparieren, oder die letzte funktionierende Datensicherung verwenden.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Hi RTFM, danke für die Tipps :)


    Hab nun meine Log-Files nach "run fsck manually" durchsucht aber nichts gefunden. In der syslog konnte ich Einträge zu "fsck" finden, allerdings nur unter anderem mit "systemd[1]: systemd-fsckd.service: Succeeded."


    sudo dumpe2fs -h /dev/mmcblk0p2 | grep orphan gibt aus, dass die dumpe2fs Datei nicht gefunden werden kann. Für mein bescheidenes Wissen wohl kein verwaister Inode? :conf:


    Hab noch mal herumprobiert und kann den USB-Hub mittlerweile als Fehler ausschließen. Das Problem dürfte am DeskPi liegen. Dieser ist wohl hart auf ttyUSB0 gecodet. Da allerdings beim Booten erst der am USB Hub hängende Enocean USB Stick auf ttyUSB0 eingehängt wird und anschließend der Deskpi mit Lüfter und Front-USB Hub auf ttyUSB1, muckt er wohl herum und übernimmt beispielsweise die Shutdown Befehle nicht korrekt.

    Meine Theorie möchte ich nun noch mit einem frisch aufgesetzten System ohne Deskpi testen => wenn es ohne Deskpi keine Probleme gibt, liegts wohl tatsächlich daran


    Hat jemand vielleicht eine Lösungsidee für das Problem, sollte sich die Theorie mit dem Deskpi bewahrheiten?

  • Hi,


    Problem ist nun gelöst. Ich habe sämtliche DeskPi-Treiber auf einen neuen Pfad mit udev-Rule umgeleitet


    Grüße

    neuling10