DSBMC/DSBMD

Was genau ist unter "robusten Dateiensystemen" zu verstehen? NTFS gehört also offensichtlich nicht dazu?
Also ZFS, UFS und Ext* würde ich als robust betrachten. Zu NTFS kann ich nichts sagen. Dein Szenario war jetzt auch eher ein Spezialfall, da das Problem eher auf die Partitionierung zurückging. Der beschriebene Schaden wäre mit GPT (ich setze mal voraus, dass die Platte MBR-partitioniert war/ist) aufgrund des GPT-Backup-Eintrags am Ende des Speichermediums deutlich weniger wahrscheinlich passiert wäre.
 
Hallo @marcel,

sei so gut und poste für einen älteren Herrn noch mal, wie ich die letzte funktionierende Version installiere und wie ich an sie komme, ohne gleich die Ports neu zu installieren. Ich möchte es jetzt, wo es wohl auf der Zielgeraden ist, unter FreeBSD 11.1 mit dem XFCE4 Desktop testen. Natürlich bekommst Du als Danke shcön ein zeitnahes Feedback. Danke für Deine Bemühungen.
 
Hallo @marcel,

sei so gut und poste für einen älteren Herrn noch mal, wie ich die letzte funktionierende Version installiere und wie ich an sie komme, ohne gleich die Ports neu zu installieren.
Hallo @ralli ,

sehr gerne :)

Code:
# fetch https://codeload.github.com/mrclksr/DSBMD/tar.gz/1.2.3
# tar xf 1.2.3
# cd DSBMD-1.2.3 && make install
# cp dsbmd.conf /usr/local/etc
# sysrc dsbmd_enable=YES
# service dsbmd restart
 
Danke!:) Leider funktioniert es bei mir nicht. Ich habe alles nach Deinen Anweisungen installiert. Das manuelle mounten auch als normaler User funktioniert einwandfrei. Wenn ich allerdings eine CD einlege, wird zwar das Symbol auf dem Desktop angezeigt, aber es kommt die Fehlermeldung:

An operation is already pending.

Bei dem Einstecken meines USB Stick das gleiche Spiel mit der gleichen Fehlermeldung:

Im Dateimanager Thunar ist unter EInstellungen - Fortgeschrittene die Datenträgerverwaltung aktiviert.

Manuell mounte ich die CD mit:

mount -t cd9660 /dev/cd0 /usr/home/ralph/mnt

und den USB Stick mit:

mount -t msdosfs /dev/da0s1 /usr/home/ralph/mnt

Den Mountpoint habe ich natürlich vorher erstellt. Das funktioniert ordnungsgemäß und einwandfrei.
 
Hast du hald aktiviert?
Wenn Du bei laufendem dsbmc-cli -a (im Vordergrund) einen Stick einsteckst, erscheint dann eine Fehlermeldung? Wenn nicht, zeigt denn mount an, dass der Stick eingehängt wurde?
 
Wo kommt denn dsbmc-cli her, wird dsbmc-cli automatisch mitinstalliert? Das ist wohl die Command-Line-Interface Version was?
Ja, genau. Du brauchst einen Client, der mit DSBMD spricht. Du kannst den grafischen sysutils/dsbmc nehmen und/oder wenn Du Automount möchtest, sysutils/dsbmc-cli nehmen. Beide müsse separat installiert werden, entweder per pkg oder die Ports. Mit (als User ausgeführt)
Code:
% dsbmc-cli -a
veranlasst Du DSBMD alle bereits vorhandenen und für DSBMD sichtbaren, sowie alle später hinzugefügten Speichermedien einzuhängen. Den Befehl kannst Du z.B. einfach dem exec startxfce4 in der ~/.xinitrc voranstellen:
Code:
#!/bin/sh
dsbmc-cli -a&
exec startxfce4
oder wenn Du dsbmc automatisch starten willst:
Code:
#!/bin/sh
(sleep 3; dsbmc -i&)&
exec startxfce4
 
Ja, muß hald deaktiviert werden ?
Es wurde hier berichtet, dass es wohl Probleme gab, wenn dsbmd und hald zusammen laufen. Da hald nur noch die Funktion eines Mounters übernimmt, ist er überflüssig:
Code:
# service hald stop
# sysrc hald_enable=NO

Schau auch mal hier. Ich muss den Artikel wohl mal hier ins deutsche BSD-Wiki bringen.
 
@marcel, danke hervorragende Arbeit.:) Alles funktioniert einwandfrei so, wie es soll.:) Hald habe ich deaktiviert. Alle devices CD USB Stick werden im Thunar angezeigt und deren Inhalt nach einem Klick sichtbar gemacht. Auch das Aushängen erfolgt einwandfrei. Ich bin begeistert! Danke! Suuuuuuper....
 
Code:
# fetch https://codeload.github.com/mrclksr/DSBMD/tar.gz/1.2.3
# tar xf 1.2.3
# cd DSBMD-1.2.3 && make install
# cp dsbmd.conf /usr/local/etc
# sysrc dsbmd_enable=YES
# service dsbmd restart

Ah, ist das jetzt 1.2.2 mit dem Shutdown-Skript vor ein paar Tagen?

Und @ralli, dass man HAL deaktivieren muss und dsbmd/dsbmc gerade deswegen der neue Hoffnungsträger für ein HAL-freies FreeBSD ist, darum ging es hier eigentlich die ganze Zeit...^^

Im Übrigen kann ich bestätigen, dass dsbmd/dsbmc wunderbar mit XFCE zusammenarbeitet.
 
Hallo @marcel

mal eine Frage, die indirekt nur mit dsbmd aber dem offenbar damit nicht harmonisierenden hald zu tun hat:
Ich betreibe ein FreeBSD-Notebook mit der Kombi openbox und tint2, angereichert mit weiteren Programmen, auch aus kde4 (ich mag nun einmal dolphin, ark und okular sehr gerne). Zum Mounten nehme ich natürlich Deine dsbmd/dsbmc Kombination.
Der Großteil aus kdebase-apps braucht auch kein hald, allerdings gehört zu meinen weiteren Favoriten auch k3b, es erkennt keine Laufwerke, wenn hald nicht aktiviert ist. Ich brauche k3b zum bequemen Auslesen von CDs, man kann bequem cdparanoia zuschalten, abwählen, bequem Auslesemuster beim Tagging wählen, alle Tracks in ein Audio-File rippen u.v.m. ein typisches K-Programm eben :D

Ich sehe jetzt für mich mehrere Möglichkeiten:
a) die k3b Laufwerkserkennung von hald entkoppeln und k3b stattdessen auf dsbmd lauschen lassen (wenn ich wüsste, ob und wie?)
b) ein ähnlicher anderer komfortabler CD-Ausleser, der ohne hald auskommt

Falls Dich dieser Sub-Thread hier stört, einfach sagen, dann mache ich einen ganz neuen Thread auf.

Viele Grüße
Holger
 
Hallo @holgerw,
a) die k3b Laufwerkserkennung von hald entkoppeln und k3b stattdessen auf dsbmd lauschen lassen (wenn ich wüsste, ob und wie?)
Das ist nicht (ohne Weiteres) möglich, da k3b von der Existenz dsbmds wissen und dessen Protokoll sprechen müsste.
b) ein ähnlicher anderer komfortabler CD-Ausleser, der ohne hald auskommt
Da kann ich Dir asunder empfehlen, oder für die Kommando-Zeile mein cdda2x ;).

Du kannst natürlich auch mal versuchen, ob sich dsbmd und hald auf Deinem System vertragen. Aber es ist schon putzig, dass man zur Erkennung, ob ein Laufwerk vorhanden ist, einen Dienst wie hald benötigt.
Ich hoffe, ich konnte Dir helfen.
 
Ich brauche k3b zum bequemen Auslesen von CDs
ich brauche es zwar nicht unbedingt (brennen geht auch gut mit xfburn), aber ich will k3b gelegentlich auch nutzen und dann starte ich einfach manuell vorher den hald und beende ihn nachher wieder. Auf meinem System sehe ich da keine Kollision mit dsbmd, man könnte sich aber sogar vorstellen, in der Zeit auf dsbmd zu verzichten und keine USB-Sticks oder so einzulegen und automatisch mounten zu lassen.
 
Hallo @marcel hallo @pit234a

dasnke für Eure Vorschläge, ich werde asunder, cdda2x und auch die Methode mit k3b und dem dazu manuell gestarteten hald audsprobieren.

Mal schauen, womit ich am meisten warm werde :)
 
Hallo @holgerw, @pit234a und @marcel,

das mit k3b ist ein ganz wichtiger Punkt, den Ihr hier ansprecht, den ich noch gar nicht bemerkt habe da ich in der letzten Zeit keine CD mehr gebrannt hatte.
Das ist mit ein Grund, warum man jetzt auf die KDE-Entwickler zugehen müsste, um auf dsbmd aufmerksam zu machen. Ehrlich gesagt werde ich mit MATE nicht so ganz glücklich und jetzt auch noch diese Sache mit k3b. Es kann doch nicht angehen, dass KDE und seine Programme für immer von diesem HAL abhängen sollen...
 
Es kann doch nicht angehen, dass KDE und seine Programme für immer von diesem HAL abhängen sollen...

Wie macht es denn z. B. TrueOS? Ich habe es seit Ewigkeiten nicht mehr getestet. Dahinter steckt doch mehr als ein Entwickler oder irre ich mich?

TrueOS, ein System ganz ohne "Automagie"? Ich kann es mir nicht vorstellen.
 
In Wirklichkeit kann ich das Gelingen oder Versagen von HAL nicht mehr nachvollziehen, mutmaße aber, wenn ein Device nicht ordnungsgemäß gemounted wird, liegt das nicht an HAL, sondern an dem jeweiligen Dateimanager. Wie ist es denn sonst zu erklären, das unter FreeBSD 11.1 und dem Gnome Desktop alles ordnungsgemäß mit Nautilus gemountet wird und unter KDE eben mit Dolphin nicht? Und zwar, und das erscheint mir auch erwähnenswert, ohne jegliche zusätzliche Konfiguration der Rechte und in den Konfigurationsdateien devfs.conf, devfs.rules sowie sysctl.conf. Merkwürdig ist das schon, oder? Und zwar alles als ganz normaler User und ohne Root Rechte.
 
IWie ist es denn sonst zu erklären, das unter FreeBSD 11.1 und dem Gnome Desktop alles ordnungsgemäß mit Nautilus gemountet wird und unter KDE eben mit Dolphin nicht? Und zwar, und das erscheint mir auch erwähnenswert, ohne jegliche zusätzliche Konfiguration der Rechte und in den Konfigurationsdateien devfs.conf, devfs.rules sowie sysctl.conf. Merkwürdig ist das schon, oder?

Das ist bei k3b übrigens auch ein wenig aufwändig :D
Code:
 pkg info -D k3b
k3b-2.0.3_5:
Always:
Notes for FreeBSD 7.x and onwards users:
1. The FreeBSD k3b port supports SCSI drives only. If you have IDE CD or DVD
   drives, use them through the cam system. See Chapter 18.6.9 of the handbook
   (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/creating-cds.html#ATAPICAM)
2. k3b has to be started from a root console, which is not recommended.
   Alternatively, do ALL of the following:
   a. Set the suid flag on cdrecord and cdrdao. The 'Notes' chapter of
      'man cdrecord' discusses this.
   b. Set the vfs.usermount sysctl variable to 1.
        # sysctl vfs.usermount=1
      Add the line vfs.usermount=1 to /etc/sysctl.conf
      Note that this has negative security implications
   c. Every user must have read and write access to /dev/cdX:
      - add to your /etc/devfs.rules under '[system=10]':
          add path 'cd*' mode 666
      - or if you prefer allow access for a group XXX only add instead:
          add path 'cd*' mode 660 group XXX
      - to enable it, add to your /etc/rc.conf a
          devfs_system_ruleset="system"
   d. Every user who should be able to use k3b must have read and write access
      to all pass through devices connected with CD and DVD drives and to the
      /dev/xpt0 device. Run 'camcontrol devlist' to identify those devices (seek
      string 'passX' at the end of each line). Note, that this is a security
      leak as well but that there is no alternative!
      - add to your /etc/devfs.rules under '[system=10]':
          add path 'pass*' mode 666
          add path 'xpt0' mode 666
      - or if you prefer allow access for a group XXX only add instead:
          add path 'pass*' mode 660 group XXX
          add path 'xpt0' mode 660 group XXX
      - to enable it, add to your /etc/rc.conf
          devfs_system_ruleset="system"
      - to apply these changes without reboot, run as root:
          /etc/rc.d/devfs restart
3. Check, that DMA is activated for atapi devices: 'sysctl hw.ata.atapi_dma'
   If not, set it to 1 and put 'hw.ata.atapi_dma=1' into /boot/loader.conf.
4. Create a directory on a partition, which has enough disk space to hold a CDs
   or DVDs content (usually below /usr). Enter this directory in Settings->
   Configure K3b...->Misc.

Bei anderen Rippern / Brennprogrammen reicht ein Zugriff auf das Device in der devfs.conf und ein Usermount in der sysctl.conf
 
Wie macht es denn z. B. TrueOS? Ich habe es seit Ewigkeiten nicht mehr getestet. Dahinter steckt doch mehr als ein Entwickler oder irre ich mich?

TrueOS, ein System ganz ohne "Automagie"? Ich kann es mir nicht vorstellen.

TrueOS hatte eine zeitlang pc-mounttray, haben den aber wieder verworfen. Der hatte seinerzeit auch nicht richtig mit KDE zusammengearbeitet (nur ein extra Tool in der Taskleiste, aber keine Integration mit dolphin). Nun arbeiten die mit autofs und wollen Lumina darauf anpassen, so dass auch ein Symbol für optische Medien zur Verfügung steht.
Das ist aber ein schlechter Weg, denn autofs mountet wie damals amd erst, wenn man auf das Verzeichnis /media zugreift. Damit können die Dateimanager aber erst etwas anfangen, wenn man vorher manuell in das Verzeichnis zugreift. Das hatte ich damals mit nautilus un caja getestet.

Ich habe letztens auch mal dsbmd/dsbmc mit Lumina getestet:

Wenn man einen Stick einführt, erscheint ein USB-Symbol auf dem Desktop. Wenn man eine CD einführt, erscheint ebenfalls ein USB-Symbol. Klar, weil die eben noch kein CD-Symbol entwickelt haben. Jetzt kommt aber das Handycap von Lumina: Unmountet man (mit dsbmd), bleiben die Symbole auf dem Desktop etwas ausgegraut bestehen, sogar nach einem Neustart der Maschine. Auch klar, denn die sollen bestehen bleiben, damit man wieder im Zusammenhang mit autofs zugreifen kann, der ja erst mountet, wenn man vorher zugreift (also in diesem Fall durch Doppelklick auf das Symbol auf dem Desktop).

TrueOS macht es also ziemlich blöd, finde ich.
 
Zurück
Oben