[erledigt] VirtualBox und merkwürdige UID:GID in /usr

[TomL]

Moin

Heute morgen hatte ich mal wieder eines der eher seltenen VirtuaBox-Phänomene....der Desktopstarter startet nix. Aus Neugier hab ich es dann mal im Terminal gestartet.... und siehe da, eine zuvor noch nicht dagewesene Fehlermeldung überrascht mich.

$ /usr/bin/VirtualBox

VirtualBox: Error -610 in supR3HardenedMainInitRuntime!
VirtualBox: dlopen("/usr/lib/virtualbox/VBoxRT.so",) failed: <NULL>

VirtualBox: Tip! It may help to reinstall VirtualBox.

Da ich ein gewisses Problem schon länger kenne, und zwar sowohl unter Jessie als auch jetzt unter Stretch, habe ich zuerst einmal nach der mir schon bekannten Ursache für Probleme gesucht. Und die gibts tatsächlich jetzt auch wieder:

find /usr -iname "*" ! -user root -ls | less -S
1831425 4 drwxr-xr-x 10 8070 9999 4096 Jun 3 11:53 /usr
1831426 20 drwxr-xr-x 109 8070 9999 20480 Jul 7 10:11 /usr/lib
1855489 0 lrwxrwxrwx 1 8070 9999 12 Mai 17 2012 /usr/lib/libtiff.so -> libtiff.so.3
1855490 320 -r-xr-xr-x 1 8070 9999 327085 Mai 17 2012 /usr/lib/libtiff.so.3.6.1
1855491 0 lrwxrwxrwx 1 8070 9999 16 Mai 17 2012 /usr/lib/libtiff.so.3 -> libtiff.so.3.6.1

Zunächst habe ich versucht, wieder root als Eigentümer einzusetzen, was nur bei der Lib klappte, aber bei den beiden symlinks nicht möglich war. Es kam keine Fehlermeldung beim Setzen mit chown, aber die Rechte wurden auch nicht gesetzt. Letztendlich habe ich die Symlinks gelöscht und neu angelegt.

Nun läuft VirtualBox wieder gewohnt. Aber das merkwürdige ist, dass ich diese merkwürdigen UID:GID schon öfter gefunden habe, wenn VirtualBox nicht startet. Und zwar über alle Versionen, also mit der Jessie Repo-Version, mit der späteren Oracle-Version, und jetzt auch unter Stretch mit der aktuellen Oracle-Version. Ssowohl auf meinem Desktop als auch auf dem Notebook. Und immer sind diese UID:GID die Ursache.

Die Frage ist: Wer setzt die? Wo kommen die her? Wer hat überhaupt an /usr rumzufummeln?

ps
Sorry wg. quotes... aber code ist wohl noch nicht soweit...

[MSfree]

Auffällig ist, daß libtiff auch diese merkwürdigen UID/GID besitzt. Libtiff ist aber die Zugriffsbibliothek für digitale Bilder im TIFF-Format und hat mit VirtualBox ungefähr so viel zu tun wie ein leerer Benzintank mit Thunfisch.

Ich würde an deiner Stelle mal den Installationsverlauf auf deinem Rechner untersuchen und nach Bildverarbeitungsprogrammen und/oder dist-upgradees untersuchen, die eventuell die libtiff angefaßtt haben könnten.

[TomL]

Die war tatsächlich heute morgen dabei... und ich habe mich oben vertan... ist sogar hier noch der Jessie-Laptop.

Start-Date: 2017-07-07 10:10:29
Commandline: apt-get dist-upgrade -y
Upgrade: multiarch-support:amd64 (2.19-18+deb8u9, 2.19-18+deb8u10), linux-image-3.16.0-4-amd64:amd64 (3.16.43-2, 3.16.43-2+deb8u2), libgraphite2-3:amd64 (1.3.6-1~deb8u1, 1.3.10-1~deb8u1), vlc-plugin-notify:amd64 (2.2.5-1~deb8u1, 2.2.6-1~deb8u1), libvlccore8:amd64 (2.2.5-1~deb8u1, 2.2.6-1~deb8u1), openvpn:amd64 (2.4.0-6~bpo8+1, 2.4.0-6+deb9u1~bpo8+1), vlc-nox:amd64 (2.2.5-1~deb8u1, 2.2.6-1~deb8u1), vlc-plugin-samba:amd64 (2.2.5-1~deb8u1, 2.2.6-1~deb8u1), libtiff5:amd64 (4.0.3-12.3+deb8u3, 4.0.3-12.3+deb8u4), libc-dev-bin:amd64 (2.19-18+deb8u9, 2.19-18+deb8u10), libc-bin:amd64 (2.19-18+deb8u9, 2.19-18+deb8u10), libc6:amd64 (2.19-18+deb8u9, 2.19-18+deb8u10), vlc-data:amd64 (2.2.5-1~deb8u1, 2.2.6-1~deb8u1), linux-headers-3.16.0-4-amd64:amd64 (3.16.43-2, 3.16.43-2+deb8u2), linux-compiler-gcc-4.8-x86:amd64 (3.16.43-2, 3.16.43-2+deb8u2), vlc:amd64 (2.2.5-1~deb8u1, 2.2.6-1~deb8u1), libvlc5:amd64 (2.2.5-1~deb8u1, 2.2.6-1~deb8u1), libexpat1:amd64 (2.1.0-6+deb8u3, 2.1.0-6+deb8u4), linux-libc-dev:amd64 (3.16.43-2, 3.16.43-2+deb8u2), linux-headers-3.16.0-4-common:amd64 (3.16.43-2, 3.16.43-2+deb8u2), locales:amd64 (2.19-18+deb8u9, 2.19-18+deb8u10), vlc-plugin-pulse:amd64 (2.2.5-1~deb8u1, 2.2.6-1~deb8u1), libc6-dev:amd64 (2.19-18+deb8u9, 2.19-18+deb8u10), libgcrypt20:amd64 (1.6.3-2+deb8u3, 1.6.3-2+deb8u4), libffi6:amd64 (3.1-2+b2, 3.1-2+deb8u1)
End-Date: 2017-07-07 10:11:53

Ich weiss jetzt nur nicht so recht, irgendwelche Erkenntnisse daraus abzuleiten. Allenfalls nach dem Upgrade vielleicht ein reboot, wegen möglicherweise geänderter Kernel-Header.... und vielleicht auch noch weil dkms auf dem Rechner hier fehlte.

[TomL]

Wegen der neuen Linux-Header und dem vergessenen und bisher fehlenden dkms habe ich jetzt einfach mal ein

Code: Alles auswählen

dpkg-reconfigure virtualbox-5.1

hinterhergeschickt. Tja, es hat ne Zeitlang was gemacht, nur habe ich leider zu spät geschaltet und nicht nachgesehen, ob tatsächlich gcc läuft und die Kernelmodule möglicherweise neu erstellt werden. Insofern bin ich jetzt hinsichtlich der Sinnhaftigkeit meiner Aktion nun etwas unsicher. Aber es läuft scheinbar alles.

[owl102]

Die Frage ist: Wer setzt die? Wo kommen die her? Wer hat überhaupt an /usr rumzufummeln?

Ich tippe darauf, daß der Übeltäter derjenige ist, der /usr/lib/libtiff.so.3.6.1 installiert hat, und dabei dann auch alle Pfade auf dem Weg dorthin verhunzt hat.

Die Frage ist: Wo kommt die her? Die kommt nicht aus dem Debian Jessie Repository:

https://packages.debian.org/search?sear ... e&arch=any

Was meint

Code: Alles auswählen

dpkg --search /usr/lib/libtiff.so.3.6.1

Code: Alles auswählen

apt-file search /usr/lib/libtiff.so.3.6.1

?

[MSfree]

Die war tatsächlich heute morgen dabei... und ich habe mich oben vertan... ist sogar hier noch der Jessie-Laptop.

Ich habe gerade auch mal ein apt-get update auf meinem Jessie-Rechner gemacht und auch eine neue libtiff bekommen. Allerdings gehört libtiff.so.5.2.0 root:root und auch der link von libtiff.so.5 auf libtiff.so.5.2.0 wurde von root angelegt.

Allenfalls nach dem Upgrade vielleicht ein reboot, wegen möglicherweise geänderter Kernel-Header.... und vielleicht auch noch weil dkms auf dem Rechner hier fehlte.

Das Reboot nach der Installation von Softwarepaketen ändert keineswegs etwas an den UID/GUID von gerade installierten Dateien. Das Reboot ist eigentlich nur bei Kernelupdates nötig, um den gerade laufenden Kernel durch den frisch installierten zu ersetzten.

Eigentlich sollte DKMS auch schon durch den update-Prozeß anspringen, wenn ich das noch richtig in Erinenrung habe, sonst können die proprietären Graphiktreiber ja nicht geladen werden.

[TomL]

Moin

Ich glaube,
1. die libtiff-Rechte der Symlinks haben nix mit VirtualBox-Problem zu tun
2. das es wahrscheinlich allein an den falschen Rechten für /usr lag
3. hier liegt für die symlinks nur eine kollaterale Beteiligung vor

Ich habe aber keine Idee, wo ich diese Datei her habe, ob die überhaupt auf regulärem Weg dahingekommen ist oder ob ich da vielleicht irgendwas getrickst habe. Und in den Apt-Logs ist 1 1/2 Jahr zurück nicht passendes finden. Ich vermute, dass ich die Ursache des Problems war, wer weiss wie lange zurück .... erinnern kann ich mich nicht mehr daran.

Ich habe die jetzt einfach mal rausgemoved und warte mal ab, ob was passiert.

[owl102]

Ich habe aber keine Idee, wo ich diese Datei her habe, ob die überhaupt auf regulärem Weg dahingekommen ist oder ob ich da vielleicht irgendwas getrickst habe.

Was sagt denn

Code: Alles auswählen

dpkg --search /usr/lib/libtiff.so.3.6.1

Code: Alles auswählen

apt-file search /usr/lib/libtiff.so.3.6.1

?

Dann würde man doch sehen, von welchem Paket die herkommt...

[TomL]

Oh sorry.... ich hatte das vorhin schon probiert, aber weil nix dabei rausgekommen ist, vergessen das zu posten.

root@dell-e6320
# dpkg --search /usr/lib/libtiff.so.3.6.1
dpkg-query: Kein Pfad gefunden, der auf Muster /usr/lib/libtiff.so.3.6.1 passt

# apt-file search /usr/lib/libtiff. so.3.6.1
root@dell-e6320:~
#

Ich habe die natürlich jetzt wieder zurückkopiert. Ich glaube, ich habe irgendwann mal da irgendwas gefummelt und geschraubt und hinterher einfach nicht aufgeräumt. Meiner Meinung nach sind das Leichen.

[owl102]

Oh sorry.... ich hatte das vorhin schon probiert, aber weil nix dabei rausgekommen ist, vergessen das zu posten.

"Nix dabei rausgekommen" bedeutet ja immerhin schon einmal, daß es nicht via dpkg bzw. apt installiert wurde, sondern entweder manuell oder per Script.

Manuell denke ich nicht, denn dabei vergibt man ja nicht so blöde IDs.

Irgendeine Druckertreiberinstallation? (Samsung, Dell, Brother, Canon, ...)

Hier hatte übrigens jemand vor ca. 3 Jahren das selbe Problem: https://thinkpad-forum.de/threads/12496 ... KA)/page87 Leider wurde auch dort nicht die Ursache herausgefunden.