plasma5 und Mounten von ntfs-Devices - per plasma5-Bordmitteln

holgerw schrieb:
Nun ja, was dieses ntfs-Mounten mit dem plasma5-device-Manager unter FreeBSD angeht, ist mir bisher nicht klar, ob es überhaupt einzurichten geht.
Zum Vergrößern anklicken....
Ich selbst wäre gar nicht so bestrebt, unbedingt ne Desktop-spezifische Lösung zu basteln. Ich denke auch, dass solche Aufgaben nicht unbedingt vom Desktop direkt übernommen gehören.
Vermutlich würde ich mir eher irgendeine desktop-independed-App (von mir aus noch unterr Ausnutzung von Sachen die freedesktop.org spezifiziert) schreiben die das dann übernimmt.

Das lässt sich ja dann durchaus in die eigenen Desktop-Umgebung integrieren, ist aber nicht davon abhängig.
Ich hatte auch schon mal ein paar Ideen dazu für solche und ähnliche Aufgaben (möglichst dann auch noch unabhängig vom System; zumindest Linux und FreeBSD soll reibungslos funktionieren).

Zur Zeit herrscht aber bei mir ein gewisser Zeitmangel, weshalb zur Zeit bei mir so Einiges liegenbleibt. Ich hoffe, dass entspannt sich irgendwann die nächsten Monate mal wieder.
 
Andy_m4 schrieb:
Ich selbst wäre gar nicht so bestrebt, unbedingt ne Desktop-spezifische Lösung zu basteln. Ich denke auch, dass solche Aufgaben nicht unbedingt vom Desktop direkt übernommen gehören.
Zum Vergrößern anklicken....
Hallo Andy,
interessanter Aspekt - aber: In diesem Fall greift plasma5 ja auch auf einen Mechanismus (hal / polkit) zurück, der gar nicht zum Desktop gehört. Ich finde Deinen Einwand zwar durchaus berechtigt - und Ansprüche der Plasma5-Entwickler "alles unter einer Haube" zu haben, müssen einem vom Konzept auch überhaupt nicht zusagen. Man kann sich auch per tint2 und openbox einen Desktop basteln und mit deutlich systemnäheren Mountlösungen arbeiten (auch das finde ich für mich spannend, es macht mir Spaß, so etwas aufzusetzen und damit zu arbeiten).

Der Status Quo bei KDE ist aber nun einmal ein anderer, und ich möchte schon aus verschiedenen Gründen damit als Hauptsystem arbeiten.
Andy_m4 schrieb:
Vermutlich würde ich mir eher irgendeine desktop-independed-App (von mir aus noch unterr Ausnutzung von Sachen die freedesktop.org spezifiziert) schreiben die das dann übernimmt.
Das lässt sich ja dann durchaus in die eigenen Desktop-Umgebung integrieren, ist aber nicht davon abhängig.
Ich hatte auch schon mal ein paar Ideen dazu für solche und ähnliche Aufgaben (möglichst dann auch noch unabhängig vom System; zumindest Linux und FreeBSD soll reibungslos funktionieren).
Zum Vergrößern anklicken....

Ja, aber das gibt es mit dsbmd / dsbmc von @marcel doch schon. Und das lässt sich auch hervorragend bei meinem tint2-openbox-Desktop einsetzen. Aber bei KDE hängen bestimmte Sachen, die auch das Management externer Devices angeht, zusammen (ohne hald z.B. nach wie vor kein Erkennen von optischen Medien durch k3b, soundkonverter und ähnlicher K-Anwendungen). Und ob sich dann ein zusätzlicher systemnäherer Mountmechanismus parallel dazu verträgt?

KDE hat alles an Bord bzw. greift auf Mechanismen zurück, die unter Linux zum Laufen zu bringen sind. Die Frage ist nun, ob der Status Quo so ist, dass es konfigurationstechnisch ebenso unter FreeBSD möglich ist (programmiertechnisch kann es natürlich möglich gemacht werden, aber das ist ja eine ganz andere Frage, die eher Relevanz für KDE-Entwickler hat und die müßig ist, sofern es jetzt auch schon per Konfiguration durch Anwender hinzubekommen ist). Und ich gehe davon aus, dass es geht, denn sonst wäre die Arbeit des Committers für den polkit-Kram unter FreeBSD ein wenig befremdlich :)
 
Für mich waren Desktop Systeme nur deshalb interessant, weil sie gesamtheitliche Software zur Verfügung stellten und für die Grundbedürfnisse wie Mailen, Surfen, Brennen, Drucken Video und Audio sorgten. Alles aus einem Guß gefiel mir schon immer. Wenn aber ein wichtiges Glied in der Kette nicht zu gebrauchen ist, dann ist der Desktop für mich keine erste Wahl mehr und ich kann mir gleich einen Windowmanager nehmen und mir ein Minimalsystem aufsetzen mit meinen bevorzugten Lieblingsprogrammen. Warum das noch unter KDE4 (mit hal) einwandfrei funktionierte und jetzt unter KDE5 nicht mehr, können doch nur die Entwickler beantworten oder der zuständige und verantwortliche Committer. Die Erwartung, das hier ein Communitymitglied für Abhilfe sorgen kann, ist einfach zu hoch gesteckt. Gäbe es eine praktikable Lösung, wäre sie gewiss bekannt und bereits an irgendeiner Stelle veröffentlicht oder gepostet worden. Da ich zum Pefektionismus neige, muß ich Abstriche machen, denn wir sind ja hier nicht bei Wünsch Dir was...

Muß ich unbedingt brennen? NEIN! Muß ich drucken. Ebenfalls ein klares NEIN! Ich bevorzuge ehe ein papierloses Büro.

Und es geht hier doch ums automatische Mounten. Das manuelle mounten funktioniert doch, oder auch nicht?

Wenn es "nur" eine Sache der Rechtevergabe oder Konfiguration wäre, dann gäbe es sicherlich schon eine Lösung.

Da aber keine Lösung in Sicht ist, wird es keine einfache und banale Angelegenheit sein.

Ob es funktioniert oder nicht ist für mich nicht allein ausschlaggebend.

Wenn aber ein kompetenter Zuständiger mal eine Aussage treffen würde und uns wissen ließe, ob es überhaupt geht oder ob an einer Lösung gearbeitet würde, dann würde ich das begrüßen.

Und ob man überhaupt bereit ist, viel Manpower in eine Insellösung für KDE zu stecken, kann ich höchstens erahnen aber nicht wirklich wissen.
 
Um dem geballten Halbwissen hier mal ein Ende zu setzen ;-) ...

Für Plasam5 braucht man eigentlich kein hal -- sysutils/bsdisks ist ein udisks2 Implementation für FreeBSD, und sollte OOB mit USB Sticks umgehen können. Dafür muss devel/kf5-solid mit BSDDISKS option gebaut werden -- als ich das lezte mal einen USB Stick zur Hand hatte funktionierte es zumindest :)



mfg Tobias
 
tcberner schrieb:
Um dem geballten Halbwissen hier mal ein Ende zu setzen ;-) ...

Für Plasam5 braucht man eigentlich kein hal -- sysutils/bsdisks ist ein udisks2 Implementation für FreeBSD, und sollte OOB mit USB Sticks umgehen können. Dafür muss devel/kf5-solid mit BSDDISKS option gebaut werden -- als ich das lezte mal einen USB Stick zur Hand hatte funktionierte es zumindest :)



mfg Tobias
Zum Vergrößern anklicken....

Hallo Tobias,

das werde ich heute noch testen, danke.

Und es geht auch mit ntfs-Devices? Klar, dafür muss fuse samt ntfs-fuse-Modul installiert sein und die Rechte auf die Devices müssen passen.

Ich bin gespannt.

Viele Grüße
Holger
 
holgerw schrieb:
Ich finde Deinen Einwand zwar durchaus berechtigt - und Ansprüche der Plasma5-Entwickler "alles unter einer Haube" zu haben, müssen einem vom Konzept auch überhaupt nicht zusagen.
Zum Vergrößern anklicken....
Ist ebenso nachvollziehbar. Es gibt da keine "richtige" oder "falsche" Position.

holgerw schrieb:
Ja, aber das gibt es mit dsbmd / dsbmc von @marcel doch schon.
Zum Vergrößern anklicken....
Stimmt.

holgerw schrieb:
Und ob sich dann ein zusätzlicher systemnäherer Mountmechanismus parallel dazu verträgt?
Zum Vergrößern anklicken....
Gute Frage.

tcberner schrieb:
Dafür muss devel/kf5-solid mit BSDDISKS option gebaut werden -- als ich das lezte mal einen USB Stick zur Hand hatte funktionierte es zumindest :)
Zum Vergrößern anklicken....
Guter Hinweis!
 
Hallo @holgerw,

zerbrich Dir nicht weiter den Kopf darüber, Ntfs-Platten mounten unter HAL/KDE funktioniert seit 10.0 einfach nicht mehr. Damals unter 9.x ging es noch. Ich hatte damals sogar die Entwickler angeschrieben, die wussten auch keine Antwort und verwiesen mich auf autofs, das ntfs angeblich mounten könnte. Also einfach vom Thema abgewichen.
Als ich mich damals hier an der Testerei von dsbmd/dsbmc beteiligte, wies ich ausdrücklich darauf hin, dass man unbedingt die KDE-Entwickler über dsbmd/dsbmc informieren müsste, damit KDE/Dolphin/k3b vielleicht in Zukunft damit funktionieren.

Ich selbst verwende seit dem lightdm/xfce4 mit dsbmd/dsbmc weil ich diese Funktionalität mit NTFS einfach nicht missen möchte. Darüber hinaus werden auch Handys automatisch gemountet, dsbmd/dsbmc finde ich deshalb einfach super!

KDE5 wäre mir wahrscheinlich auch lieber als xfce, aber es funktioniert einfach nicht mit dsbmd/dsbmc.


tcberner schrieb:
Um dem geballten Halbwissen hier mal ein Ende zu setzen ;-) ...

Für Plasam5 braucht man eigentlich kein hal -- sysutils/bsdisks ist ein udisks2 Implementation für FreeBSD, und sollte OOB mit USB Sticks umgehen können. Dafür muss devel/kf5-solid mit BSDDISKS option gebaut werden -- als ich das lezte mal einen USB Stick zur Hand hatte funktionierte es zumindest :)
Zum Vergrößern anklicken....


Also das würde mich auch interessieren. Könnt Ihr bitte weiter darüber berichten?
 
Hallo @cabriofahrer

Du kannst das einfach ausprobieren, folgende Anleitung wird Dir teilweise aus dem nvidia-Thread bekannt sein, plasma5 muss dafür zuerst installiert werden und dann:
Code: 
portsnap auto
pkg install portmaster
portmaster -d --force-config devel/kf5-solid
Da wählst Du bsdisks aus.
portmaster ersetzt Dir automatisch das kf5-solid Binary durch Dein selbst gebautes.
Ich komme heute erst spät abends oder ggf. morgen Abend dazu, bin noch unterwegs.
Werde dann aber berichten.
 
holgerw schrieb:
Hallo,

der Tipp von @Lance funktioniert offenbar mit plasma5 nicht mehr, nach wie vor:

Sie haben keine Berechtigung ...

Wo kann ich da weiter ansetzen? Es beginnt schon mit der Frage, ob PolicyKit oder polkit-1. Es ist allmählich nervig, vor allem, weil ntfs-Mount externer USB-Devices keine exotischen Dinge sind.
Zum Vergrößern anklicken....

@holgerw
Moin, hattest du in der org.freedesktop.hal.storage.policy nachgesehen, dort ist bei KDE5 der Eintrag wo du yes und no vertauschen musst. Ich kann es leider nicht testen da ich bei mir trotz meines kleinen Tutorials, was ich mir mal angelegt hatte KDE5 nichtmal zum starten bringe.
 
Hallo,

danke für die weiteren Kommentare, aber der Hinweis von @tcberner ist ein Volltreffer :)

Ich habe devel/kf5-solid mit der Oprtion bsdisks gebaut.

Wenn ich nun unter plasma5 eine ntfs-formatierte externe Festplatte anstöpsele, erscheint in dolphin unter "Orte" diese Platte und lässt sich als User per Mausklick rw einbinden.

a) Folgendes muss installiert sein:
fuse fusefs-ntfs

b) fuse muss in die kld_list der /etc/rc.conf

c) In der /etc/sysctl.conf muss Usermount möglich gemacht werden.

d) User müssen in den Gruppen wheel und operator sein.

e) Der Ordner /media muss in die Gruppe wheel, /dev/fuse muss in die Gruppe operator. Sollte eigentlich schon passen.

f) In der /etc/devfs.conf müssen die Rechte der Devices da0 da1 u.s.f. auf 0666 gesetzt werden und die Devices gehören in die Gruppe operator.

Ein großes Dankeschön, auch an alle hier Beteiligten.

Viele Grüße
Holger
 
Und CD's/DVD's funktionieren so auch? Wie sieht es mit k3b aus? Ist das Ganze noch in einer Testphase und ist das der offiziel für KDE5 geplante Automount-Mechanismus für FreeBSD?
 
tcberner schrieb:
Was genau ist das Problem bei k3b?

mfg Tobias
Zum Vergrößern anklicken....
Hallo Tobias,

mir ist etwas aufgefallen, was ich aber noch genauer untersuchen möchte: Nach dem Bau von kf5-solid erkennt k3b bei mir keine optischen Laufwerke mehr, ob mit oder ohne aktiviertem hald.
Nun werde ich mal mit poudriere aus dem head branch ein eigenes Repo mit plasma5 bauen, und dann noch Mal testen.

Da mir das Mounten von externen Devices wichtig ist und es einige andere Programme gibt, die k3b gut ersetzen können, könnte ich damit gut klar kommen, wobei es natürlich wünschenswert wäre, wenn k3b unter FreeBSD ohne diesen hald-Kram klar käme.
 
cabriofahrer schrieb:
Das ist ja echt Panne... Das wird wohl nicht Sinn der Sache sein bei bsdisk?
Zum Vergrößern anklicken....
Abwarten :) erstmal testen, vielleicht läuft es mit einem eigenen Repo, wo beim Bau hal von vorne herein ausgeschlossen wird. Die Sache mit bsdisks ist relativ neu, da muss vielleicht noch einiges an Sachen bereinigt werden, damit alles reibungslos läuft.
 
Ich finde diesen Thread sehr spannend.
Allein wenn ich sehe, was die Leute alles machen, patchen, biegen, compilieren und diskutieren - damit irgend ein komplett undurchsichtiges und fehlerträchtiges DE irgendwas macht, was der Eine als "toll" - aber der Andere als "lästig" empfindet;-)
 
Es gibt immer Leute, die besser durch blicken, als Andere. Hier hatte @tcberner eindeutig das nötige Wissen. Vielleicht könnte jeder das finden, wenn er ausreichend Energie investiert und sich womöglich mit den Quellcodes vertraut macht. Irgendwie liegt ja tatsächlich alles offen.
Ich konnte das nie und werde es immer weniger wollen.
Dass keine Zeit bleibt, die grundlegenden Mechanismen in einem großen DE ausreichend für Unbedarfte Anwender zu beschreiben, kann ich verstehen, finde es aber doch schade.
Immerhin: die allermeisten Endanwender bekommen ja eine funktionierende Lösung vorgesetzt und brauchen sich keine Gedanken darum zu machen, wie das nun überhaupt funktioniert, dass irgendwelche Datenträger automatisch eingebunden werden. Ich denke, dass das die Entwicklung ist, die in der IT die Zukunft bestimmt. Da wird es auf Endanwender-Ebene nichts mehr zu Basteln geben. Alles ist gut, wie es kommt und einem vorgesetzt wird. Was wir hier aber nicht diskutieren wollen.

In diesem Thread fühlte ich voll mit @holgerw und freue mich, dass es eine wirklich brauchbare Antwort gab. Damit hatte ich nicht gerechnet!
 
Hallo @pit234a

und das mit k3b möchte ich auch noch lösen.

Ich bleibe dran, bsdisks für das Mounten von externen Devices und k3b sollte weiterhin optische Laufwerke erkennen können, ob mit oder ohne hald.
 
Finde ich gut @holgerw , ich werde das mit Aufmerksamkeit verfolgen. Auch wenn plasma5 möglicherweise der beste DE ist, könntest Du Dich vielleicht alternativ mit Gnome3 oder Cinnamon anfreunden? Dort funktioniert dsbmc m.E., natürlich auch mit Automount von NTFS.
 
cabriofahrer schrieb:
Finde ich gut @holgerw , ich werde das mit Aufmerksamkeit verfolgen. Auch wenn plasma5 möglicherweise der beste DE ist, könntest Du Dich vielleicht alternativ mit Gnome3 oder Cinnamon anfreunden? Dort funktioniert dsbmc m.E., natürlich auch mit Automount von NTFS.
Zum Vergrößern anklicken....
Hallo,

mit Gnome konnte ich mich schon zu Linux Zeiten nicht anfreunden.
Und ich mag keine gtk-Dateidialoge zum Öffnen und Speichern .... aber das wird OffTopic.
 
Hallo,

ein selbst gebautes Repo ohne hal, mit der Option bsdisks beim Port devel/kf5-solid, hier die Liste der Ports:
Code: 
emulators/fuse
shells/bash
sysutils/fusefs-ntfs
sysutils/htop
sysutils/devcpu-data
sysutils/k3b
x11/xorg
x11/plasma5-plasma-desktop
x11/kde-baseapps
x11/sddm
x11/nvidia-driver
x11/nvidia-settings
x11-fm/konqueror

Bisheriges Resümee: k3b findet keine Laufwerke, konqueror friert ständig beim Schreiben von Beiträgen auf bsdforen ein. Ich werde für das Testsystem noch den Firefox bauen.

Aber nun mal zu k3b: Auf Linux ist hal seit Jahren(!) obsolet, da tut k3b, unter FreeBSD wird also für k3b mit hal ein unter Linux seit Jahren obsoleter Mechanismus verlangt, der meiner bisherigen Erfahrung nach händisch einfach nur ekelhaft zu konfigurieren ist.
kf5-solid mit dem bsd-eigenen Mechanismus bsdisks ist gut (ein Linuxismus weniger), nur wenn dann eines der KDE-nahen Referenzprogramme wie k3b nicht mehr brauchbar ist, dann ist das meines Erachtens suboptimal.

So wie ich das sehe setzt k3b auch auf kf5-solid, braucht aber ein kf5-solid mit hal, sonst unbrauchbar. Und kf5-solid mit hal ist unbrauchbar für das bequeme Mounten externer ntfs-Devices.

@tcberner Was braucht ihr für Info / Tests von mir, die Euch helfen, das zu fixen? :)

Man kann sich in der Zwischenzeit z.B. mit asunder (zum Auslesen) und xfburn als Alternativen behelfen, nur passt k3b natürlich besser in die plasma5-Umgebung und kann auslesen, brennen u.w.m.

Viele Grüße
Holger
 
Hallo Holger

k3b, da muss ich einfach mal mein CD Laufwerk finden und kucken was da läuft. hal sollte dazu aber garantiert nicht nötig sein.
[Mit dem anschalten von BSDISKS deaktivierst du auch gleichzeitig den Support von hal in kf5/plasma5 -- da kann nur einer von aktiv sein].

Was wir brauchen sind detailierte PRs, was wo fehl schlägt, dann fällt das reproduzieren einfacher.


mfg Tobias
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben