Posts by satsatt

    Danke framp,


    Du hast natürlich recht , ich war zu ungeduldig beim Restore. Da ich nun nicht noch einen dritten USB Port zum Restore belegen wollte hab ichs mal mit dem freien onboard sd port versucht und nach dem Restore hat er gleich neu gebootet bis zum MM und die sd genommen.


    Aber mal ehrlich jetzt brauch ich ein backup dieses Kommandos


    sudo raspiBackup.sh -d /dev/mmcblk0 /media/pi/USB-STICK/raspberrypi/raspberrypi-rsync-backup-20200505-211801


    :conf:

    Also als Linux noob hoffe dass ich es mit der Zeit noch hinkriege meine MagicMirror sd/USB Installation zu sichern ohne die Probleme mit den DD images.


    1. nach dem schönen Installer von raspiBackup hoffte ich auch auf einen Menuepunkt RESTORE last backup? nach xxx - hmm

    2. was mich pested - im Raspian GUI werden USB Geräte automatisch gemounted und auch noch mit blöden Namen ( na gut kann man umbenennen) aber Rechtsclick umount oder format ist erstmal nicht wegen fehlenden root Rechten.

    3. Ich weiß nicht welche Dienste da laufen die gestoppt und gestarted werden sollen ( cron, pm2 ? )

    4. zeitgesteuertes rsync Backup auf USB Stick ist gelaufen vorher hab ich MM gestoppt denn der started sonst immer wieder.

    5 restore auf neuen USB Stick ( woran sieht man eigendlich dass der Restore fertig ist - kommt der Prompt wieder?) kam nur 2 partionen angelegt und beschrieben aber kein prompt, hab noch ne Weile gewarted und dann mit ctl C weitergemacht

    6. bootet durch bis zur GUI von Raspian aber MM lässt sich nicht starten - Fehlermeldung für mich kryptisch


    Im MM-Forum hatte jemand auf raspiBackup hingewiesen aber die Meisten da sind der Meinung sie können jede Installation innerhalb von 15min wieder neu herstellen - ich gehöre nicht dazu ;-))

    Da es beim RPBi3+ gegenüber dem Z0 ( beide mit stretch ) funktioniert, vergleiche ich mal beide lsusb Hubs und Ports.


    lsusb -s 001:001 -v (HUB)


    Z0 bcdDevice 4.14

    B3 bcdDevice 4.19 ansonsten alles identisch


    Ports

    Z0

    $ lsusb -s 001:002 -v

    Bus 001 Device 002: ID 1130:6801 Tenx Technology, Inc.

    bcdDevice 3.01


    B3

    $ lsusb -s 001:007 -v

    Bus 001 Device 007: ID 1130:6801 Tenx Technology, Inc.

    bcdDevice 3.02 ansonsten alles identisch

    Entschuldigung - mein Typo nur hier im Forum.

    Richtig

    ATTRS{idVendor}=="1130", ATTRS{idProduct}=="6801", MODE="0660", GROUP="plugdev", RUN="/bin/sh -c 'echo -n $id:1.0 > /sys/bus/usb/drivers/usbhid/unbind'"


    scheint auch zu funktionieren denn es wird kein HID Driver gemeldet.


    /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M

    |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=, 1.5M

    @Rasp-Berlin


    meine Versuche mit journalctl -xe

    Ich finde nur
    interface 0 claimed by usbfs while 'te923con' sets config #1


    Zu diesem Fehler gibt es massig Fundstellen im Netz zu allen möglichen Geräten (Scanner, Drucker usw.) mit der gleichen Symptomatic ( es funktioniert ein paarmal und dann nicht mehr ). Eine Lösung konnte ich bisher nicht finden.

    Der Zustand des USB ports/Schnittstelle ist offensichtlich nach dem kill nicht der gleiche wie nach einem reboot, obwohl ja kein Prozeß mehr darauf zugreift , denn es kommt sofort "Error while setting configuration (-16)" beim Zugriffsversuch.


    Mir scheint es so, als ob vorhergehenden usb configuration Aufrufe irgendwo gespeichert werden und dann beim 7.-8. mal kein Platz mehr im Speicher ist oder wahrscheinlicher der/die vorhergehende/n Zugriff/e nicht korrekt beendet wurde/n "Device or resource busy" .


    Code
    open("/dev/bus/usb/001/002", O_RDWR)    = 3
    ioctl(3, USBDEVFS_GETDRIVER, 0xbe81cff8) = 0
    ioctl(3, USBDEVFS_IOCTL, 0xbe81d0e8)    = 0
    ioctl(3, USBDEVFS_SETCONFIGURATION, 0xbe81d0fc) = -1 EBUSY (Device or resource busy)
    write(2, "Error while setting configuratio"..., 41Error while setting configuration (-16).
    ) = 41
    exit_group(1)                           = ?
    +++ exited with 1 +++

    Manul du hast vollkommen Recht.


    Nach dem kill sieht es so aus als wäre Alles ok ( Der hängende Prozeß wurde beendet - und der Pi Prompt ist wieder verfügbar - fuser Aufruf liefert keine Ausgabe ! )


    Beim nächsten Aufruf von te923con oder te923con -D ( liefert nur [DEBUG] VER 0.6.1 ) hängt es wieder, nur mit anderer PID.


    Wenn es zu Anfang funktioniert, gibt es dann ohne Parameter ( Hänger beim 7. ) oder mit -s ( Hänger beim 7. ) oder strace -f ( Endlosschleife beim 8. Auruf) das Problem.


    Ich kann auch mit -d den ganzen internen Speicher mit über 200 Zeilen ausgeben lassen ( hab ich bisher nicht siebenmal probiert weil dauert sehr lange )

    hier die Fortsetzung

    strace -f te923con # Das ist jetzt der 7. Durchlauf


    nein der verhält sich nicht wie ein Durchlauf, der zählt nicht aber wenn ich ihn nochmal eingebe rennt das Fenster durch.

    i@pizero1:~ $ sudo fuser -v /dev/bus/usb/001/002

    BEN. PID ZUGR. BEFEHL

    /dev/bus/usb/001/002:

    pi 870 F.... te923con


    kill 870


    Fenster eins "killed by sigterm"

    Prompt wieder da

    ok sechster Aufruf- sorry


    sudo fuser -v /dev/bus/usb/001/002 keine Ausgabe

    sudo fuser -v /dev/bus/usb/001/002 keine Ausgabe