Nach Upgrade auf 12.2: Problem mit dsbmc einerseits und mit eingebauter zweiter Festplatte in /etc/fstab

cabriofahrer

Well-Known Member
Ich habe gerade das System auf 12.2 gebracht und mit einem pkg upgrade -f auch das Userland aktualisiert. Doch jetzt habe ich auf einmal zwei Probleme:

1. Wenn ich einen USB-Stick einführe, wird dieser zwar gemountet (aber mit anderem Namen als früher, was schon mal verdächtig ist) aber wenn ich dann auf das Symbol zum Auswerfen in caja klicke, wird er nicht mehr ausgeworfen und es erscheinen plötzlich eine Vielzahl von Icons von anderen Laufwerken und ich bekomme die Fehlermeldung, wie sie im Screenshot zu sehen ist. Dabei stimmt die Fehlermeldung "not mounted" gar nicht, denn wenn ich auf das 1 GB-Symbol klicke, kann ich auf den Stick zugreifen. Ich habe als User immer "dsbmc-cli -a" geladen, damit der Filemanager diese Funktion anbietet. Das hatte über diverse Upgrades immer funktioniert.

2. Meine zweite, fest eingebaute Festplatte (ada1) erscheint nicht mehr, sie erschien im Filemanager immer als Symbol "Disk2". Hier meine /etc/fstab:

Code:
$ more /etc/fstab
# Device        Mountpoint      FStype  Options Dump    Pass#
/dev/ada0s1b    none            swap    sw      0       0
/dev/ada0s1a    /               ufs     rw      1       1
proc    /proc           procfs  rw      0       0
linprocfs       /compat/linux/proc linprocfs    rw      0       0
linsysfs    /compat/linux/sys   linsysfs        rw      0       0
tmpfs    /compat/linux/dev/shm  tmpfs   rw,mode=1777    0       0
/dev/ada1p1     /Disk2          ufs     rw      2       2
fdesc   /dev/fd         fdescfs         rw      0       0
$

Nachtrag: Ich habe soeben festgestellt, dass die zweite Festplatte wohl unter /Disk2 gemountet ist, sie erscheint aber nicht mehr automatisch im Filemanager oder auf dem Desktop wie früher. Könnte der Fehler vielleicht in "pkg upgrade -f" anstatt von "pkg upgrade" liegen?. Ich hatte ein "pkg upgrade -f" bei einem Wechsel von 12.1 auf 12.2 für besser empfunden...
 

Anhänge

  • dsbmc.png
    dsbmc.png
    960 KB · Aufrufe: 237
Zuletzt bearbeitet:
Mach mal ein:

Code:
pkg version -vRL=

um zu sehen, ob noch Pakete "nacheilen" und hernach ggf einmal:

Code:
pkg autoremove -y
pkg update -f
pkg upgrade -f
reboot

Das hatte bei mir geholfen, als ich von 12.1 auf 12.2 aktualisierte und das System hernach etwas spassig war (die Probleme mit dsbmc hatte ich jedoch nicht, bzw fiel mir da nichts bezüglich dazu auf, ich konnte mich z.B. nicht mehr am MATE einloggen, und wenn, dann nur einmal, hernach nie wieder und noch ein paar andere kleinere Sachen).
 
Hm, das war es leider nicht, aber ich habe eine neue Erkenntnis erlangt: Das Problem tritt nur in einer Xfce oder Mate-Umgebung auf. Wenn ich hingegen Fluxbox starte und in Fluxbox caja oder Thunar, dann verhält es sich normal, wie der Screenshot zeigt. Disk2 erscheint und auch der Stick, und dieser lässt sich auch unmounten.
 

Anhänge

  • fluxbox.png
    fluxbox.png
    51,2 KB · Aufrufe: 228
WTF???!!!??? Ich habe letztendlich ein pkg delete -a gemacht und sämtliche (noch nichtmal die Hälfte wie ich vorher hatte) Packages neu installiert, und das Problem ist immernoch da, es sei denn, ich starte in eine Fluxbox-Umgebung. Auch bei einem völlig neu eingerichteten Benutzerkonto mittels adduser tritt das Problem auf, so dass man einen Fehler in den Userkonfigurationsdateien ausschließen kann.

Meine Vermutung: Irgendein Package von xfce oder auch MATE ist faul und müsste neu kompiliert werden, nur welches?
Was kann dafür verantwortlich sein, dass Thunar oder caja unter Fluxbox richtig funktionieren, aber nicht in xfce?
 
ich mutmaße mal ins Blaue, dass es eigene Konfigurationen mit XFCE und/oder MATE gibt.
Die allermeisten Programme können mit einer Option aufgerufen werden, die auf die zu benutzende Konfig-Datei zeigt. Ohne eine solche Option, wird ein Default genutzt.
Da könnten dann XFCE oder MATE jeweils eigene "Versionen" von Programmen starten.
Keine Ahnung, ob das wirklich so ist. In manchen Zusammenhängen habe ich so etwas schon gesehen, etwa in einem Lubuntu, wo dann mit LXDE OpenBox als Windows-Manager mit einer anderen rc-xml (der Konfiguration-Datei) gestartet wird, als wenn man OpenBox direkt aufruft und wieder eine andere Konfig wird bei Aufruf von Lubuntu (LXDE im Ubuntu-Design) verwendet.
Oft werden Konfig-Dateien benutzt, die ähnliche Namen haben und manchmal liegen die in den gleichen Verzeichnissen, manchmal haben sie sogar die gleichen Namen und liegen an anderen Plätzen.
Eigentlich müsste hierüber die Dokumentation des DEs Aufschluss geben, aber ich würde es einfach mal mit einem find versuchen, um im Beispiel von oben zu bleiben etwa: find ./ -iname "*rc.xml*" und das vielleicht auch noch in /usr/local.
 
@cabriofahrer :
Das Problem ist, dass Thunar jetzt sysutils/bsdisks benutzt, um Datenträger einzuhängen. Es scheint allerdings noch etwas unflexibel zu sein, denn wenn ein Gerät nicht unter dem erwarteten Pfad, der aus dem Gerätenamen (nicht Label) gebildet wird, gemountet wurde, wird es nicht als eingehängt betrachtet. Um das alte Verhalten wieder herzustellen, kannst Du die Exec-Zeile in /usr/local/share/dbus-1/system-services/org.freedesktop.UDisks2.service auskommentieren.
 
Nachtrag: Genauer gesagt, benutzt gvfs sysutils/bsdisks (gvfs ist eine Abhängigkeit von Thunar). Caja selbst hat keine gvfs-Abhängigkeit, aber Mate, das die gvfsd-Services startet, die dann auch von Caja benutzt werden. Dies könnte das umgebungsabhängige Verhalten von Caja erklären. Laut der Manpage von gvfs, lässt sich das alte Verhalten durch das Setzen der Umgebungsvariable GIO_USE_VOLUME_MONITOR auf "unix" einstellen. Einfach in der ~/.xinitrc (~/.xsession) vor dem Start von mate-session die Zeile

export GIO_USE_VOLUME_MONITOR=unix

eintragen.
 
@marcel , vielen herzlichen Dank!

Durch das Auskommentieren in /usr/local/share/dbus-1/system-services/org.freedesktop.UDisks2.service ist das Problem mit Thunar und caja in einer xfce-Umgebung behoben worden.

Allerdings taucht die "Disk2" aus der /etc/fstab immernoch nicht auf wie früher (siehe nochmal die Screenshots). (Zur Klarstellung: Ich nutze zwar xfce, aber als Dateimanager caja. Ich habe weder .xinitrc noch .xsession)

Und jetzt noch weitere Fragen: Und wie kommt man darauf? Sowohl ich als auch andere hier tappten da völlig im Dunkeln, es wurde ein Fehler im Upgrade der Packages vermutet, ich habe eine Menge Zeit verloren, indem ich alle Packages gelöscht und nochmal aufgespielt habe...

Und zu sysutils/bsdisks, da habe ich heute mal auf einem anderen Rechner kde5 installiert, um es auszuprobieren, und bsdisks mountete zwar einen Stick zufällig, aber andere Sticks nicht, es scheint wohl so zu sein, wie Du oben gesagt hast. Und die externe NTFS-Festplatte wurde auch nicht erkannt, so wie mit dsbmd/dsbmc. Dieses bsdisks scheint also noch in den Kinderschuhen zu stecken?
 
@marcel , vielen herzlichen Dank!

Durch das Auskommentieren in /usr/local/share/dbus-1/system-services/org.freedesktop.UDisks2.service ist das Problem mit Thunar und caja in einer xfce-Umgebung behoben worden.

Allerdings taucht die "Disk2" aus der /etc/fstab immernoch nicht auf wie früher (siehe nochmal die Screenshots). (Zur Klarstellung: Ich nutze zwar xfce, aber als Dateimanager caja. Ich habe weder .xinitrc noch .xsession)

Versuche erst mal folgendes:

Du könntest ein Wrapper-Skript unter /usr/local/bin/xfce4-session-wrapper anlegen, das XFCE mit der entsprechenden Umgebungsvariable gesetzt, startet:
Code:
#!/bin/sh

export GIO_USE_VOLUME_MONITOR=unix
exec xfce4-session

Dann legst Du unter /usr/local/share/xsessions/xfce4-without-bsdisks.desktop eine Desktopdatei an, sodass Du in Deinem Display manager die neue Session auswählen kannst:

Code:
[Desktop Entry]
Version=1.0
Name=Xfce Session ohne bsdisks
Comment=Startet eine XFCE-Session ohne bsdisks
Exec=/usr/local/bin/bin/xfce4-session-wrapper
Type=Application
DesktopNames=XFCE

Und jetzt noch weitere Fragen: Und wie kommt man darauf? Sowohl ich als auch andere hier tappten da völlig im Dunkeln, es wurde ein Fehler im Upgrade der Packages vermutet, ich habe eine Menge Zeit verloren, indem ich alle Packages gelöscht und nochmal aufgespielt habe...

Ich bemerkte auch, dass sich, in meinem Fall, Thunar hinsichtlich der Datenträger-Verwaltung anders verhielt. Da ich aber auch sah, dass bei einem pkg upgrade bsdisks als Abhängigkeit installiert worden war, lag die Vermutung nahe, dass es da einen Zusammenhang gibt. Über man bsdisks -> Udisk2 -> dbus -> dbus-Service files kam ich dann auf die Lösung.

Aber das sollte auch nicht Aufgabe des Benutzers sein. Ich werde das in Kürze in die Dokumentation von DSBM* aufnehmen, damit die anderen User nicht im Dunklen tappen.

Und zu sysutils/bsdisks, da habe ich heute mal auf einem anderen Rechner kde5 installiert, um es auszuprobieren, und bsdisks mountete zwar einen Stick zufällig, aber andere Sticks nicht, es scheint wohl so zu sein, wie Du oben gesagt hast. Und die externe NTFS-Festplatte wurde auch nicht erkannt, so wie mit dsbmd/dsbmc. Dieses bsdisks scheint also noch in den Kinderschuhen zu stecken?

Also ich kann über bsdisks nicht mehr sagen, als ich aus kurzer Beobachtung seines Verhalten gemutmaßt habe. Ich weiss zu wenig darüber.
 
Hallo @marcel,

ich habe die von Dir vorgeschlagenen Dateien angelegt und den Code jeweils einfach kopiert, doch nach einem Ausloggen und anschließendem Wiedereinloggen falle ich sofort in den lightdm zurück. Ich habe in der .desktop-Datei zwar einen Fehler gefunden (Exec=/usr/local/bin/bin/xfce4-session-wrapper), da ist wohl ein "bin" im Pfad zuviel, aber auch nach dem Korrigieren wieder das Gleiche.
 
Hallo @marcel,

ich habe die von Dir vorgeschlagenen Dateien angelegt und den Code jeweils einfach kopiert, doch nach einem Ausloggen und anschließendem Wiedereinloggen falle ich sofort in den lightdm zurück. Ich habe in der .desktop-Datei zwar einen Fehler gefunden (Exec=/usr/local/bin/bin/xfce4-session-wrapper), da ist wohl ein "bin" im Pfad zuviel, aber auch nach dem Korrigieren wieder das Gleiche.
so ein Verhalten hatte ich schonmal, als ich irrtümlich eine leere ~/.xinitrc-Datei angelegt hatte (zum erstellen geöffnet, nix reingeschrieben und dann VI mit :wq verlassen - Aaargh!). Beim Einlog-Versuch von xdm oder lightdm landete ich sofort wieder genau da - ohne Fehlermeldungen (klar, es passierte genau, was gesagt nämlich nix und das ohne Fehler :p ). Fehlerbehebung: als root "rm ~user/.xinitrc".

Ciao,
Photor
 
Hi @cabriofahrer ,

ich vergaß zu erwähnen, dass das Skript ausführbar gemacht werden muss:

Code:
# chmod a+x /usr/local/bin/xfce4-session-wrapper

Genau das wars! So, nun zum Ergebnis: Die 2. Festplatte wird so wieder angezeigt, sowohl auf dem Desktop als auch im Dateimanager, wie der erste Screenshot zeigt. Wie lautet jetzt die genaue Erklärung dafür?


Was ich aber bei der Gelegenheit schon immer fragen wollte:

- XFCE zeigt von dsbmc-cli -a gemountete externe Medien zwar im Dateimanager an, nicht aber auf dem Desktop, so wie die interne Festplatte aus der /etc/fstab. (Das war übrigens schon immer so, nicht erst seit der Umstellung jetzt auf bsdisks.)

- MATE aber schon, wie der zweite Screenshot zeigt. Die interne Festplatte übrigens auch nicht mehr, so wie es früher der Fall war. Ich nehme an, da müsste man den gleichen Trick anwenden wie bei xfce?
 

Anhänge

  • xfce.png
    xfce.png
    186,2 KB · Aufrufe: 208
  • mate.png
    mate.png
    112,6 KB · Aufrufe: 213
Zurück
Oben