DSBMC/DSBMD

Abschließend möchte ich noch an alle die Combo LightDM/MATE
abschließen wollen wir ja noch nicht ;-)
Aber tatsächlich hatte ich den LightDM ja schon mal in Ubuntu genutzt und schätzen gelernt. Ich bin ein wenig froh zu sehen, dass es den nun auch unter FreeBSD gibt, aber mir genügt im Moment auch durchaus der XDM und ich habe auch keine Bedenken, eine ~/.xinitrc zu nutzen, wo die eben erforderlich ist. Ich sehe darin kein Problem.

Du bist echt ein Genie!
@marcel:
So weit würde ich zwar nicht gerade gehen, aber du bist echt der Hammer! Ich genieße jeden Beitrag hier, in dem ich als unbedarfter Endanwender sehen darf, wie sich eine SW entwickelt. Einfach toll!
 
klappt jetzt alles wunderbar, Danke! Der jahrelange Traum nach einem HAL-freien FreeBSD Desktop mit automatischem Mounten sämtlicher Medien (inkl. NTFS und optischer Medien) und der Möglichkeit, Dateien mit nichtenglischen Zeichen (z.B. "Fähre") abzuspeichern, ist endlich in Erfüllung gegangen! Du bist echt ein Genie!
Super, das freut mich!

Ich werde, wenn Du nichts dagegen hast, demnächst anfangen, die frohe Botschaft in der Welt zu verkünden (z.B an das KDE-Team, damit die vielleicht interessiert sind, KDE an dsbmd anzupassen).
Ich würde es begrüßen, und sehe dem, wenn auch etwas verhalten, mit Interesse entgegen.

Abschließend möchte ich noch an alle die Combo LightDM/MATE empfehlen, da erübrigt sich die Notwendigkeit einer .xinitrc wie mit Slim.

LightDM muss ich mir mal anschauen.
 
So weit würde ich zwar nicht gerade gehen, aber du bist echt der Hammer! Ich genieße jeden Beitrag hier, in dem ich als unbedarfter Endanwender sehen darf, wie sich eine SW entwickelt. Einfach toll!
Danke Dir, @pit234a . Die Software wäre ohne die Zusammenarbeit hier nicht mal halb so gut. In der relativ kurzen Zeit, in der ich hier aktiv bin, hat sich durch die tollen Rückmeldungen, durch Fehlerberichte, Anfragen, Kritik und Ideen mehr getan, als in der Zeit davor.
 
Ich nehme an, der Patch, den ich eingespielt habe, fließt bald in den Port ein?
Es ist schon alles bereit, aber ich warte noch etwas. Man weiss ja nie ... ;)

Wäre es möglich, den zu portieren? Im Moment kann man nur durch Editieren der lightdm-gtk-greeter.conf in /usr/local/etc/lightdm den Greeter konfigurieren.
Ich denke, das sollte machbar sein. Habe mal das Paket heruntergeladen, und naiv
Code:
python3.6 bin/lightdm-gtk-greeter-settings
ausgeführt. Er beschwert sich zwar, dass er die Konfigurationsdatei nicht beschreiben darf, aber es scheint zu laufen. Bei LightDM stört mich allerdings schon die Modularität. Das ist mir zu unübersichtlich.
 
Eine weitere Möglichkeit ist pcdm von TrueOS. Das Package ist aber leider noch nicht da und aus irgendeinem Grund ist der Bau des Ports bei mir gescheitert.
 
@cabriofahrer :

könntest Du bitte mal den neuen Port testen? Insbesondere bin ich daran interessiert, ob sich dsbmd zeitnah beim Herunterfahren/Neustarten beendet.

Code:
# fetch https://freeshell.de/~mk/download/dsbmd-1.2.2-port.tgz && tar xf dsbmd-1.2.2-port.tgz && cd dsbmd
# make deinstall
# make install
# service dsbmd restart
 
Hallo @marcel,

nach Ausführen der o.g. Schritte wurde erstmal gar nichts mehr gemountet. Erst nach zweimaligem Neustart wurde wieder gemountet. Verstehe ich nicht...
Und zu der Sache vor ein paar Tagen: Nach dem Einspielen des Patches hing der PC sich beim Herunterfahren nicht mehr bei LightDM auf, nach mehrmaligen Neustarts aber dann doch wieder. Verstehe ich auch nicht...

Was habe ich jetzt eigentlich nach der o.g. Prozedur nun fest installiert, dsbmd-1.2.2 oder 1.2?

xdm, was spricht gegen den guten alten xdm? Der macht doch, was er soll.

Der ist doch total spartanisch, oder? Also ein bißchen hübsch soll es schon sein, und wie schon gesagt, ich mag keine zusätzlichen Konfigurationsdateien, die man sich erst selbst erstellen muss. Deswegen war ich von KDE so angetan, weil man mit drei Einträgen in der rc.conf einen voll funktionierenden Desktop hat, mit Loginmanager und allem drum und dran.
 
Danke für die Rückmeldung, @cabriofahrer !

Verstehe ich nicht...
Ich auch nicht. Bei so etwas müsstest Du mal in das Log von dsbmd schauen, oder ob auf der Konsole etwas steht, das auf ein Problem hindeuten könnte.

Und zu der Sache vor ein paar Tagen: Nach dem Einspielen des Patches hing der PC sich beim Herunterfahren nicht mehr bei LightDM auf, nach mehrmaligen Neustarts aber dann doch wieder. Verstehe ich auch nicht...
Ja, das ist so ein Mysterium mit dem rc-System. Es könnte sein, dass es manchmal hängt, weil dsbmd seine PID-Datei nach Beendigung nicht löscht. Das habe ich jetzt eingebaut. Sollte noch mal etwas komisch sein, lass es mich bitte wissen.

Was habe ich jetzt eigentlich nach der o.g. Prozedur nun fest installiert, dsbmd-1.2.2 oder 1.2?
Es sollte jetzt 1.2.2 drauf sein:
Code:
pkg info| grep dsbmd
 
Also ein bißchen hübsch soll es schon sein
ich will das nicht ins OT treiben, zumal es ja auf Geschmackssache hinausläuft und ich habe nichts dagegen, wenn dieser Beitrag deshalb gelöscht wird. Aber ich kann es mir auch nicht verkneifen: für die fünf Sekunden, wo der Login-Screen sichtbar ist, genügt doch eine Box vor einem Hintergrund(Bild) meiner Wahl? Das geht mit XDM in zwei Schritten, oder so. Maximal fünfzehn Minuten lesen und einrichten. Ich wette, du hast nun schon mehr Zeit verbracht.
 
Nun, @pit234a,

zwischen xdm ohne gar nichts und gdm, das sogar Pulseaudio braucht, wird es wohl für jeden Geschmach etwas geben...

Und auch, wenn es jetzt mit dsbmd nicht direkt etwas zu tun hat, interessiert Euch vielleicht mein neuer Thread zu den URL's unter KDE, da habe ich gerade nicht schlecht gestaunt...
 
Hallo @marcel,

Vorsicht, denn mit dsbmd-1.2.2 stimmt vielleicht etwas nicht. Ich wollte ein pkg upgrade machen, und um nicht auf Version 1.2 zurückzufallen, die schon in den Packages ist, hatte ich ein pkg lock dsbmd gemacht. Mir ist jetzt gerade aufgefallen, dass danach das Mounten von USB-Sticks ging, aber das von CD's wieder nicht (ich habe nur eine ausprobiert, und zwar die ursprünglich problematische), auch nicht nach einem Neustart.

Ich habe daraufhin

Code:
#pkg unlock dsbmd
#pkg delete dsbmd
#pkg install dsbmd dsbmc dcbmc-cli
#service dsbmd restart
$dsbmc-cli -a &

gemacht und jetzt funktioniert es wieder.
 
Hallo @cabriofahrer ,

die jüngsten Änderungen sollten eigentlich nicht zu diesem Verhalten führen. Es ist, was CDs betrifft, nur der Patch eingeflossen, der ja bei Dir funktionierte, aber schauen wir mal:
Code:
# fetch https://codeload.github.com/mrclksr/DSBMD/zip/1.2.2-debug
# unzip 1.2.2-debug
# cd DSBMD-1.2.2-debug
# make
# service dsbmd stop
# sh -c './dsbmd -f > dsbmd.log 2>&1'
Poste dann bitte das Log hier.
 
Hallo @marcel,

ich nehme an, Du hattest noch den Schritt "§dsbmc-cli -a &" vergessen? Habe ich aber gemacht und es funktioniert mit der Debug-Version wieder korrekt.
Kann es sein, dass wenn ich einfach nach dem pkg unlock den Schritt oben in #308 wieder ausgeführt hätte, es dann auch funktioniert hätte? Soll ich das auch mal probieren?
 
So @marcel,

habe soeben die Neuinstallation von #308 ausgeführt und alles funktioniert wieder. Das Hängen beim Herunterfahren bleibt allerdings bestehen, das wollte ich Dir auch nochmal bestätigen. Warum eine Neuinstallation von 1.2.2 nach einem pkg lock und einem pkg upgrade nötig war, bleibt jetzt wohl ein Rätsel.
Falls es Dich interessiert, füge ich jetzt noch die Log-Datei bei, die ich vorhin vergessen hatte.
 

Anhänge

  • dsbmd.txt
    5,5 KB · Aufrufe: 261
habe soeben die Neuinstallation von #308 ausgeführt und alles funktioniert wieder.
Sehr gut.
Das Hängen beim Herunterfahren bleibt allerdings bestehen, das wollte ich Dir auch nochmal bestätigen.
Zum wahnsinnig werden. Ich weiss da im Moment auch nicht weiter. Egal wie ich dsbmd beende, ich habe es noch nie geschafft, dass er nicht gleich auf ein Signal reagiert und sich nicht gleich beendet.
Warum eine Neuinstallation von 1.2.2 nach einem pkg lock und einem pkg upgrade nötig war, bleibt jetzt wohl ein Rätsel.
Kann ich auch nicht nachvollziehen.
Falls es Dich interessiert, füge ich jetzt noch die Log-Datei bei, die ich vorhin vergessen hatte.
Danke. Laut Log ist alles so, wie es soll.
 
Eigentlich ist das unnötig, aber das angefügte rc-Skript killt dsbmd jetzt explizit. Versuche das mal. Sollte er immer noch beim Shutdown/Reboot hängen, lass es mich wissen.
Code:
# cp dsbmd.txt /usr/local/etc/rc.d/dsbmd
# chmod a+x /usr/local/etc/rc.d/dsbmd
 

Anhänge

  • dsbmd.txt
    513 Bytes · Aufrufe: 392
Eigentlich ist das unnötig, aber das angefügte rc-Skript killt dsbmd jetzt explizit.

Unnötig wohl keineswegs, denn es klappt jetzt ausgezeichnet! Einmal direkt nach dem Anwenden (shutdown) und ein zeites Mal nach nochmaligem Starten des Rechners (restart).

Noch eine kleine Frage dazu: Wenn man beim Herunterfahren Speichermedien stecken lässt, werden die dann auch ordnungsmemäß geunmountet?

Zum wahnsinnig werden. Ich weiss da im Moment auch nicht weiter. Egal wie ich dsbmd beende, ich habe es noch nie geschafft, dass er nicht gleich auf ein Signal reagiert und sich nicht gleich beendet.

Kann es vielleicht an meiner alten Hardware liegen? Vielleicht sind gewisse Umstände bei moderner Hardware einfach nicht (mehr?) gegeben und werden folglicherweise von Programmierern erst gar nicht in Betracht gezogen?

Oder andere Theorie: Vielleicht etwas im Zusammenhang mit dem Nvidia-Treiber? Ich kann nur sagen, wie die Sache sprichwörtlich "ausgesehen" hat:

Nach Ausschalten des Rechners verschwindet MATE ziemlich prompt, und der Bildschirm zeigt sich für einen kurzen Moment schwarz, was alles auf ein normales Herunterfahren hindeutet. Doch plötzlich erscheint doch wieder das Bild von LightDM, als würde es, oder X allgemein sich wieder durchsetzen wollen und dann bleibt es noch sichtbar für ungefähr eine Minute.

Ich füge Dir auch noch ein dmidecode bei, falls es Dich interessiert.
 

Anhänge

  • dmidecode.txt
    18,7 KB · Aufrufe: 242
Unnötig wohl keineswegs, denn es klappt jetzt ausgezeichnet! Einmal direkt nach dem Anwenden (shutdown) und ein zeites Mal nach nochmaligem Starten des Rechners (restart).
Ok. Immerhin. Dann übernehme ich dieses rc-Skript jetzt.

Noch eine kleine Frage dazu: Wenn man beim Herunterfahren Speichermedien stecken lässt, werden die dann auch ordnungsmemäß geunmountet?
Setzte dazu unmount_on_exit = yes in der dsbmd.conf.
Oder andere Theorie: Vielleicht etwas im Zusammenhang mit dem Nvidia-Treiber?
Denke ich nicht. Aber danke für den Hinweis.
 
Noch eine kleine Frage dazu: Wenn man beim Herunterfahren Speichermedien stecken lässt, werden die dann auch ordnungsmemäß geunmountet?
Nachtrag: Normalerweise werden alle Dateisystem von FreeBSD beim Herunterfahren ausgehängt, aber bei FUSE ist das nicht unbedingt so. Hier macht es Sinn, dass sich dsbmd darum kümmert. @bluescreen hatte ein Problem mit einem per FUSE eingehängten Ext4, das vor dem Shutdown nicht ausgehängt worden ist, und anschließend ein fsck brauchte. Deswegen hatte ich diese Funktion eingebaut. Funktioniert allerdings nur, wenn das Dateisystem auch von dsbmd eingehängt worden ist. Das ist bewusst so gehalten, damit sich dsbmd nicht in fremde Angelegenheiten einmischt. Man könnte allerdings auch noch eine Variable einführen, mit der man festlegen kann, dass alle für dsbmd sichtbaren Dateisysteme beim Beenden ausgehängt werden.
 
Diesen Punkt im Zusammenhang mit FUSE halte ich aber für besonders wichtig. Jetzt, wo Du es erwähnst, kommt mir wieder in Erinnerung, dass ich, als ich damals hier anfing, mitzutesten, mein NTFS-Laufwerk anschloss. Aus irgendeinem Grund stürzte der Rechner ab (hatte glaube ich aber nicht direkt was mit dsbmd zu tun) und die Daten auf dem NTFS-Laufwerk schienen auf den ersten Blick futsch zu sein. Mit einem ntfsfix konnte nichts erreicht werden. Jemand, der mir zum Glück helfen konnte, stellte fest, dass sogar die Partitionstabelle zerschossen war und konnte diese wiederherstellen und die Daten anschließend auf einem Windows-Rechner nochmal checken. Das war alles gar nicht lustig...
 
Diesen Punkt im Zusammenhang mit FUSE halte ich aber für besonders wichtig. Jetzt, wo Du es erwähnst, kommt mir wieder in Erinnerung, dass ich, als ich damals hier anfing, mitzutesten, mein NTFS-Laufwerk anschloss. Aus irgendeinem Grund stürzte der Rechner ab (hatte glaube ich aber nicht direkt was mit dsbmd zu tun) und die Daten auf dem NTFS-Laufwerk schienen auf den ersten Blick futsch zu sein. Mit einem ntfsfix konnte nichts erreicht werden. Jemand, der mir zum Glück helfen konnte, stellte fest, dass sogar die Partitionstabelle zerschossen war und konnte diese wiederherstellen und die Daten anschließend auf einem Windows-Rechner nochmal checken. Das war alles gar nicht lustig...
Bei einem Absturz kann man da leider nichts machen, außer eben robuste Dateisysteme zu benutzen. Zumindest sollte dsbmd beim ordnungsgemäßen Beenden dafür sorgen, dass per FUSE gemountete Dateisysteme ausgehängt werden.
 
Das wegen dem Absturz hatte ich mir gedacht, das Aushängen beim ordnungsgemäßen Beenden schien mir aber sehr wichtig, als Du den Fall mit dem Ext4-Laufwerk erwähnt hattest.

Was genau ist unter "robusten Dateiensystemen" zu verstehen? NTFS gehört also offensichtlich nicht dazu?
 
Zurück
Oben