[BrickV] Kein Anzeige der Bricks in VM LinuxMint16

[Nic]

Hallo,

ich habe mir auf dem Host-PC (Win7x64) eine VMWare mit der aktuellen Linux Mint 16 XFCE eingerichtet. Installation von BrickD und Viewer war ohne Probleme. Im Host werden die Bricks im Viewer einwandfrei dargestellt, nicht aber im Linux System. Obwohl der Master-Brick vom Host an die VM erfolgreich durchgereicht wird, gibt es im Viewer keine Anzeige von Bricks und Bricklets. Allerdings auch keine Fehlermeldungen.

 

Any ideas ?

Gruß,

Nic

[photron]

Hast du den Brick in die VM durchgereicht bevor oder nachdem du in brickv in der VM auf Connect geklickt hast? Falls du den Brick danach durchgereicht hast, dann muss du einmal in brickv Disconnect und dann wieder Connect klicken, um ein Enumerate auszulösen. Wenn du den Brick per USB ansteckst sendet er von sich aus ein Enumerate. Wenn du ihn aber durchreichst ist das zwar für die VM das anstecken eines neuen USB Gerätes, aber nicht für den Brick. Daher hat bei dieser Abfolge brickv den Brick einfach noch nicht gesehen.

 

Falls es dass nicht ist, kann du dir verschiedene Dinge ansehen (alles in einem Terminal):

 

Das brickd Log:

 

less /var/log/brickd.log

 

Möglicherweise ist hier ein Hinweis auf das Problem zu finden.

 

Als nächstes die Liste der USB Geräte:

 

lsusb

 

Hier tauchen Bricks unter der ID 16d0:063d auf. Abhängig davon wie neu deine usb.ids Liste ist wird GrauTech oder MCS als Vendor angegeben. Wenn hier kein solcher Eintrag vorhanden ist, dann hat der Kernel den Brick nicht erkannt.

 

Dann ist da noch das Kernel Log:

 

dmesg

 

Hier solltest du im Normalfall beim Durchreichen am Ende des Logs Meldungen wie diese sehen:

 

[204458.156050] usb 6-3: new full-speed USB device number 28 using ohci_hcd

 

Oder aber Fehlermeldungen des Kernels die dann auch mit "usb" beginnen.

[Nic]

Die TF Software (BrickD bzw. -Viewer) wurden komplett installiert. Anschl. die VM restartet, Master-Brick durchgereicht (Disconnect from Host), letzteres wurde im Host System überprüft. Dort wurden keine Bricks mehr dargestellt.

 

Auch mehrmaliges Einbinden, Connect und Disconnect, Restart der VM haben keine Änderung gebracht. Ich hatte testweise alle Schritte auf einem 2.PC durchgeführt aber auch dort alles ok bis auf das kein Brick angezeigt wurde. In beiden VMs wird ein MCS-Master-Brick durchgereicht.

 

Verbinde ich beide PC (A+B) über WLAN-Router, kann ich einen Brick-Stapel von (A) wenigstens via IP-Angabe im Viewer von (B) sehen und benutzen.

 

Ich bin kein Linux-Experte, kann es an speziellen, lokalen Rechten für USB-Devices in Linux liegen ?

[photron]

Ich bin kein Linux-Experte, kann es an speziellen, lokalen Rechten für USB-Devices in Linux liegen ?

 

Normalerweise nicht. Ich nehme an du hast brickd über das .deb Packet installiert, dann läuft der als root und sollte keine Probleme haben auf die USB Geräte zuzugreifen.

 

Auch mehrmaliges Einbinden, Connect und Disconnect, Restart der VM haben keine Änderung gebracht. Ich hatte testweise alle Schritte auf einem 2.PC durchgeführt aber auch dort alles ok bis auf das kein Brick angezeigt wurde.

 

Dass heißt, du hast dabei auch folgende Reihenfolge getestet: VM starten, Brick durchreichen, brickv starten und Connect klicken?

 

In beiden VMs wird ein MCS-Master-Brick durchgereicht.

 

Sagt dir das VMware oder hast du das mit lsubs in der VM nachgesehen?

[Nic]

    Ich bin kein Linux-Experte, kann es an speziellen, lokalen Rechten für USB-Devices in Linux liegen ?

Normalerweise nicht. Ich nehme an du hast brickd über das .deb Packet installiert, dann läuft der als root und sollte keine Probleme haben auf die USB Geräte zuzugreifen.

Ich meinte, ob zur Laufzeit dem Linux-System über Rechtevergabe an den BrickV der direkte Zugriff an ein bestimmtes USB-Device erlaubt wird.

 

Ich nehme an du hast brickd über das .deb Packet installiert

Ich hoffe Du meinst das Download-Paket von TF, dann ja, es mussten aber noch einige Dependencies für den BrickV via Internet während der Install. nachgeladen werden. Mit den Linux eigenen Begrifflichkeiten bin ich nicht bewandert, ich bin schon froh, dass ich soweit gekommen bin

Dass heißt, du hast dabei auch folgende Reihenfolge getestet: VM starten, Brick durchreichen, brickv starten und Connect klicken?

Ja.

Sagt dir das VMware ...

Ja, also zumindest über die Toolbar-Leiste des VMWare Players, rechts oben. Dort werden alle relevante HW des Host eingeblendet und lassen sich connecten.

[photron]

    Ich bin kein Linux-Experte, kann es an speziellen, lokalen Rechten für USB-Devices in Linux liegen ?

Normalerweise nicht. Ich nehme an du hast brickd über das .deb Packet installiert, dann läuft der als root und sollte keine Probleme haben auf die USB Geräte zuzugreifen.

Ich meinte, ob zur Laufzeit dem Linux-System über Rechtevergabe an den BrickV der direkte Zugriff an ein bestimmtes USB-Device erlaubt wird.

 

Nein, brickv braucht keine root Rechte. Das läuft anders. Typischerweise hat nur root Zugriff auf die USB Geräte. Daher läuft brickd als root und kann daher auf die USB Geräte zugreifen. brickv kann sich dann zu brickd verbinden und mit den Bricks kommunizieren ohne selbst root Rechte zu brauchen.

 

Sprich, du hast da keine Rechteproblem mit brickv.

 

Ich nehme an du hast brickd über das .deb Packet installiert

Ich hoffe Du meinst das Download-Paket von TF, dann ja, es mussten aber noch einige Dependencies für den BrickV via Internet während der Install. nachgeladen werden. Mit den Linux eigenen Begrifflichkeiten bin ich nicht bewandert, ich bin schon froh, dass ich soweit gekommen bin

 

Ja, dass meinte ich. Unser .deb Packet von der Downloadseite installiert brickd und richtet ihn als Service ein, damit er automatisch im Hintergrund mit root Rechten läuft.

 

Dass heißt, du hast dabei auch folgende Reihenfolge getestet: VM starten, Brick durchreichen, brickv starten und Connect klicken?

Ja.

 

Sagt dir das VMware ...

Ja, also zumindest über die Toolbar-Leiste des VMWare Players, rechts oben. Dort werden alle relevante HW des Host eingeblendet und lassen sich connecten.

 

Okay, dann ist der Brick nach VMwares Meinung wohl durchgereicht. Dann ist jetzt der nächste Schritt sich anzusehen wie Linux das sieht. Dazu einen Terminal in der VM öffnen und

 

lsusb

 

eingeben und Enter drücken. Das sollte sowas in der Art hier ausgeben:

 

Bus 006 Device 030: ID 16d0:063d GrauTec 
Bus 006 Device 029: ID 16d0:063d GrauTec 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 003: ID 045e:078c Microsoft Corp. 
Bus 004 Device 004: ID 046d:c05b Logitech, Inc. M-U0004 810-001317 [b110 Optical USB Mouse]
Bus 003 Device 006: ID 16d0:063d GrauTec

 

Die ersten beiden Zeilen sind Bricks, zu erkennen an 16d0:063d. Ob da bei dir dann GrauTec oder MCS steht hängt davon ab wie aktuell, die usb.ids Datei des Linux ist.

 

Wenn bei durchgereichtem Brick lsusb keine Zeile mit 16d0:063d ausgibt, dann erkennt Linux den Brick nicht.

[borg]

Das VMWare Thema gab es hier schonmal im Forum: http://www.tinkerunity.org/forum/index.php?topic=1972.0

[Nic]

Mit dem Acer Notebook bekomme ich von der VM und lsusb

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 004: ID 16d0:063d MCS 
Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

 

less /var/log/brickd.log liefert

2014-01-24 20:58:21.357996 <I> <other|main_linux.c:392> Brick Daemon 2.0.10 started (daemonized)
2014-01-24 20:58:37.087027 <I> <event|event_posix.c:56> Received SIGTERM
2014-01-24 20:58:37.087337 <I> <other|main_linux.c:454> Brick Daemon 2.0.10 stopped
2014-01-24 20:58:37.205487 <I> <other|main_linux.c:392> Brick Daemon 2.0.10 started (daemonized)
2014-01-24 20:58:46.524644 <I> <event|event_posix.c:56> Received SIGTERM
2014-01-24 20:58:46.524952 <I> <other|main_linux.c:454> Brick Daemon 2.0.10 stopped
2014-01-24 20:58:46.642851 <I> <other|main_linux.c:392> Brick Daemon 2.0.10 started (daemonized)
2014-01-24 21:07:29.623794 <I> <event|event_posix.c:56> Received SIGTERM
2014-01-24 21:07:29.624567 <I> <other|main_linux.c:454> Brick Daemon 2.0.10 stopped
2014-01-24 21:51:28.316948 <I> <other|main_linux.c:392> Brick Daemon 2.0.10 started (daemonized)
2014-01-25 17:21:50.310211 <I> <other|main_linux.c:392> Brick Daemon 2.0.10 started (daemonized)
2014-01-25 17:24:26.523655 <E> <usb|usb_stack.c:278> Could not reset USB device (bus: 2, device: 4): LIBUSB_ERROR_NOT_FOUND (-5)
2014-01-25 17:24:26.523787 <W> <usb|usb.c:134> Ignoring USB device (bus: 2, device: 4) due to an error
2014-01-25 17:24:53.016590 <I> <event|event_posix.c:56> Received SIGTERM
2014-01-25 17:24:53.016820 <I> <other|main_linux.c:454> Brick Daemon 2.0.10 stopped
2014-01-26 12:46:47.685704 <I> <other|main_linux.c:392> Brick Daemon 2.0.10 started (daemonized)
2014-01-26 12:46:49.676619 <E> <usb|usb.c:462> Could not get product string descriptor for USB device (bus: 2, device: 4): LIBUSB_ERROR_TIMEOUT (-7)
2014-01-26 12:46:49.676716 <W> <usb|usb.c:134> Ignoring USB device (bus: 2, device: 4) due to an error
2014-01-26 11:58:19.597320 <I> <network|network.c:94> Added new client (socket: 16, peer: 127.0.0.1)
2014-01-26 11:58:24.559746 <I> <network|client.c:74> Client (socket: 16, peer: 127.0.0.1) disconnected by peer
2014-01-26 11:58:25.217027 <I> <network|network.c:94> Added new client (socket: 16, peer: 127.0.0.1)
2014-01-26 12:00:18.249378 <I> <network|client.c:74> Client (socket: 16, peer: 127.0.0.1) disconnected by peer
2014-01-26 12:04:13.392488 <I> <event|event_posix.c:56> Received SIGTERM
2014-01-26 12:04:13.397809 <I> <other|main_linux.c:454> Brick Daemon 2.0.10 stopped
2014-01-26 12:07:16.359836 <I> <other|main_linux.c:392> Brick Daemon 2.0.10 started (daemonized)

[photron]

Okay, laut lsusb ist der Brick da. Allerdings bekommt brickd Fehler bei der Interaktion mit dem Brick.

 

Bevor brickd irgendetwas mit dem Brick tut resettet es die USB Kommunikation. Das schlägt fehl:

 

2014-01-25 17:24:26.523655 <E> <usb|usb_stack.c:278> Could not reset USB device (bus: 2, device: 4): LIBUSB_ERROR_NOT_FOUND (-5)

 

Bei einem späten Versuch scheint der Reset zu funktionieren, aber das Auslesen des USB Config Descriptors schlägt fehl.

 

2014-01-26 12:46:49.676619 <E> <usb|usb.c:462> Could not get product string descriptor for USB device (bus: 2, device: 4): LIBUSB_ERROR_TIMEOUT (-7)

 

Das ist komisch, ist mir beides noch nicht untergekommen. Ich habe gerade auch noch mal Mint 16 32bit in einer VirtualBox VM getestet und keine Probleme mit durchgereichten Bricks. Ich habe gerade kein VMware zur Hand zum Testen.

 

Wie dem auch sei, hier mal eine brickd Version die keinen initialen Reset durchführt.

 

brickd-2.0.10-d1_amd64.deb

brickd-2.0.10-d1_i386.deb

[Nic]

Ok hab die 386er installiert, macht aber leider keinen Unterschied:

2014-01-28 17:21:41.252338 <I> <other|main_linux.c:392> Brick Daemon 2.0.10 started (daemonized)
2014-01-28 17:24:56.840644 <I> <event|event_posix.c:56> Received SIGTERM
2014-01-28 17:24:56.843266 <I> <other|main_linux.c:454> Brick Daemon 2.0.10 stopped
2014-01-28 17:24:57.666483 <I> <other|main_linux.c:392> Brick Daemon 2.0.10 d1 started (daemonized)
2014-01-28 17:25:43.714787 <I> <event|event_posix.c:56> Received SIGTERM
2014-01-28 17:25:43.715163 <I> <other|main_linux.c:454> Brick Daemon 2.0.10 stopped
2014-01-28 17:26:10.046376 <I> <other|main_linux.c:392> Brick Daemon 2.0.10 d1 started (daemonized)
2014-01-28 17:27:22.907076 <E> <usb|usb.c:462> Could not get product string descriptor for USB device (bus: 2, device: 5): LIBUSB_ERROR_TIMEOUT (-7)
2014-01-28 17:27:22.907484 <W> <usb|usb.c:134> Ignoring USB device (bus: 2, device: 5) due to an error
2014-01-28 17:27:47.786948 <I> <network|network.c:94> Added new client (socket: 16, peer: 127.0.0.1)
2014-01-28 17:27:49.827485 <I> <network|client.c:77> Client (socket: 16, peer: 127.0.0.1) disconnected by peer
2014-01-28 17:27:50.493746 <I> <network|network.c:94> Added new client (socket: 16, peer: 127.0.0.1)
2014-01-28 17:27:51.809221 <I> <network|client.c:77> Client (socket: 16, peer: 127.0.0.1) disconnected by peer
2014-01-28 17:27:52.512658 <I> <network|network.c:94> Added new client (socket: 16, peer: 127.0.0.1)
2014-01-28 17:27:53.368523 <I> <network|client.c:77> Client (socket: 16, peer: 127.0.0.1) disconnected by peer
2014-01-28 17:27:54.033496 <I> <network|network.c:94> Added new client (socket: 16, peer: 127.0.0.1)
2014-01-28 17:27:54.684388 <I> <network|client.c:77> Client (socket: 16, peer: 127.0.0.1) disconnected by peer
2014-01-28 17:27:55.302781 <I> <network|network.c:94> Added new client (socket: 16, peer: 127.0.0.1)
2014-01-28 17:27:55.996481 <I> <network|client.c:77> Client (socket: 16, peer: 127.0.0.1) disconnected by peer
2014-01-28 17:27:59.343869 <I> <network|network.c:94> Added new client (socket: 16, peer: 127.0.0.1)
2014-01-28 17:28:01.270628 <I> <network|client.c:77> Client (socket: 16, peer: 127.0.0.1) disconnected by peer

 

Wenn ich den BrickD Win-Service im Host alternativ ansprechen würde, was müsste ich im Linux-BrickV (bei Host) innerhalb der VM einstellen ?

[Nic]

Achso, ich gebe die IP des Ethernet-Adapters ein, dann geht es, prima. So kann ich auch leben Besten Dank für den Support, macht einen ordentlichen Eindruck das Linux Mint.

[Nic]

Noch eine kleine Randnotiz: VirtualBox kann sogar ein VMDK-Image aus VMWare ausführen, das o.g. Localhost Problem der Bricks tritt dabei nicht mehr auf .