DSBMC/DSBMD

Jetzt musste ich am Ende ein Ctrl+Cmachen, da die letzte Ausgabe mit 188 nicht mehr aufhörte. Die ersten Angaben sind im Terminal nicht mehr vorhanden.

Code:
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In ^Ce-loop

#
 
So, jetzt hat es wohl geklappt:

Code:
# fetch http://freeshell.de/~mk/download/testcd.c
testcd.c                                      100% of 6185  B 2199 kBps 00m00s
# cc -o testcd testcd.c -lgeom -lcam
# ./testcd /dev/cd0
96: Check for media
101: OK
107: Getting sector size
110: OK
111: Reading TOC header
116: OK
119: Reading TOC entry
124: OK
136: seeking
141: OK
146: Reading
151: OK
169: Seeking
174: OK
175: Reading
testcd: pbs == 2048
181: OK
186: Entering while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
188: In while-loop
n == 5
#
 
So, die Spannung steigt:
Code:
# fetch http://freeshell.de/~mk/download/dsbmd-1.2pre.tgz
# tar xf dsbmd-1.2pre.tgz && cd dsbmd-1.2pre && make && make install
# service dsbmd onerestart
 
Damit alles sauber läuft, wollte ich zunächst dsbmd deinstallieren, aber ich brauche zum Testen ja auch dsbmc-cli. Dies ist jedoch eine Abhängigkeit von dsbmd. Wie gehe ich jetzt geanu vor?

Code:
# pkg delete dsbmd
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 3 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
        dsbmd-1.1
        dsbmc-cli-0.1.2
        dsbmc-0.2.2

Number of packages to be removed: 3

Proceed with deinstalling packages? [y/N]: y
[1/3] Deinstalling dsbmc-cli-0.1.2...
[1/3] Deleting files for dsbmc-cli-0.1.2: 100%
[2/3] Deinstalling dsbmc-0.2.2...
[2/3] Deleting files for dsbmc-0.2.2: 100%
[3/3] Deinstalling dsbmd-1.1...
[3/3] Deleting files for dsbmd-1.1: 100%
# pkg install dsbmc
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 2 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        dsbmc: 0.2.2
        dsbmd: 1.1

Number of packages to be installed: 2

64 KiB to be downloaded.

Proceed with this action? [y/N]: n
#
 
Hallo @marcel,

gute Nachrichten, es klappt! Ich habe die CD mehrmals in beiden Laufwerken getestet, sie wurde immer erkannt, konnte wieder entfernt werden und das Symbol in caja verschwand dann auch immer wieder, genau so, wie es zu erwarten ist.
Um noch einen draufzusetzen:
Mir fiel noch eine (weitere) uralte CD ein (damals 1999 schon reduzierte Ware, "Mig Alley" eine Flugsimulation vom Koreakrieg), die damals unter Windows98 uns später XP schon nicht in Laufwerk 1 erkannt wurde und auch auf manchen anderen PC's nicht, die ich jetzt auch noch getestet habe.
Sie wird von keinem der Laufwerke erkannt, aber das Gute ist, dass dsbmd sich selbst dadurch nicht aus der Fassung bringen läßt. Die CD kann manuell aus beiden Laufwerken entfernt werden und die ursprünglich problematische CD wird dann wieder problemlos erkannt, gemountet und kann wieder über caja entfernt werden.

Tolle Leistung!

Die Mig Alley CD wird in Laufwerk 1 selbst unter HAL nicht erkannt, in Laufwerk 2 nach deutlich hörbarem hin und her dann schließlich doch (angeblich haben einige DVD-Brenner auch bessere Leseeigenschaften als so manches DVD-Laufwerk), das muss uns jetzt aber nicht weiter stören.

Ich denke, Du kannst dsbmd-1.2 jetzt comitten und kurz Bescheid sagen. Vielen Dank nochmal für Deine Bemühungen!
 
Da bin ich aber erleichtert! Vielen Dank für Deine Geduld. Dadurch ist DSBMD wieder etwas robuster und zuverlässiger geworden. Ich werde noch eine neue Konfigurationsvariable einführen, mit der man angeben kann, ob und wie, DSBMD nicht zur Bootzeit gemountete Dateisysteme aushängt, wenn er beendet wird. Und keine Sorge, der Code von heute beleibt davon unberührt (immerhin weiss ich jetzt auch, wo es gehakt hat) ;) Sobald die neue Version in den Ports ist, gebe ich noch mal Bescheid.
 
OK, @marcel,

ich freue mich schon drauf! Wenn es soweit ist, werde ich dann wahrscheinlich auf SLIM/MATE umsteigen und so erstmal eine längere Testphase starten, bis ich mich mit der neuen Umgebung anfreunden kann und wenn alles gut geht, von KDE Abschied nehmen. Das Einzige, was ich ein bißchen unschön finde, ist dass "dsbmc-cli -a &" außerhalb der /etc/rc.conf gestartet werden muss. Wie an anderer Stelle bereits erörtert, könnte das mit einer .xinitrc oder .xsession oder einer abhängig vom DE eigenen Autostartfunktion gehen. Denn je nachdem, um welchen DE es sich handelt, macht dieser vielleicht ein Override z.B. von .xinitrc. Das ist eben etwas unschön.

Wäre es denn ohne großen Aufwand möglich, das Programm "dsbmc-cli -a" oder eben genau diese Funktion, die es bewirkt, in Zukunft auch über die /etc/rc.conf zu aktivieren, etwa durch einen zusätzlichen Eintrag wie "dsbmc_enable="YES"?
 
Wie an anderer Stelle bereits erörtert, könnte das mit einer .xinitrc oder .xsession oder einer abhängig vom DE eigenen Autostartfunktion gehen.
Das ist die beste und einfachste Variante. Eine ~/.xinitrc könnte im Fall von MATE so aussehen:
Code:
#!/bin/sh
export PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:${HOME}/bin
dsbmc-cli -a&
exec mate-session
Ich z.B. habe als Openbox-Benutzer in meiner ~/.config/openbox/autostart.sh lediglich stehen:
Code:
sh ~/.config/DSB/autostart.sh&
Die Programme, die ich zum Session-Start gestartet haben möchte, ändere oder (de)aktiviere ich mit Hilfe von dsbautostart.

Wäre es denn ohne großen Aufwand möglich, das Programm "dsbmc-cli -a" oder eben genau diese Funktion, die es bewirkt, in Zukunft auch über die /etc/rc.conf zu aktivieren, etwa durch einen zusätzlichen Eintrag wie "dsbmc_enable="YES"?

Da es bei dsbmc-cli entscheidend ist, unter welchem Benutzer es läuft, ist es nicht gut geeignet, systemweit per /etc/rc.conf gestartet zu werden. Aber man kann natürlich ein rc-Skript schreiben, das dieses "Problem" wie folgt löst, auch wenn ich das nicht sehr ansprechend finde:
Code:
#!/bin/sh

# PROVIDE: dsbmc-cli
# REQUIRE: LOGIN dsbmd
#
# Add these lines to /etc/rc.conf.local or /etc/rc.conf
# to enable this service:
#
# dsbmc_cli_enable (bool):   Set to NO by default.
#                            Set it to YES to enable dsbmc-cli.
# dsbmc_cli_user (string):   Set username you want dsbmc-cli to run as.
#

. /etc/rc.subr

name=dsbmc_cli
start_cmd="start_dsbmc_cli"

rcvar=dsbmc_cli_enable

load_rc_config $name

: ${dsbmc_cli_enable:="NO"}

start_dsbmc_cli()
{
   if [ -z ${dsbmc_cli_user} ]; then
     echo "dsbmc_cli_user undefined";
     exit 1
   fi
   /usr/bin/su -l ${dsbmc_cli_user} -c '/usr/local/bin/dsbmc-cli -a'&
}

run_rc_command "$1"

Das speichert man in der Datei dsbmc-cli, kopiert sie nach /usr/local/etc/rc.d und macht das Skript ausführbar:
Code:
# chmod a+x /usr/local/etc/rc.d/dsbmc-cli
In /etc/rc.conf trägt man ein:
Code:
dsbmc_cli_enable="YES"
dsbmc_cli_user="cabriofahrer" # Oder wie auch immer der Benutzername lautet

Damit wird dsbmc-cli unter dem angegebenen Benutzer beim Booten nach dsbmd gestartet. Um es zu testen kann man auch service dsbmc-cli start ausführen.
 
Vielen Dank, das sieht wirklich sehr gut aus! Das ist auch die beste und sauberste Lösung, wenn man verschiedene DE's auspropieren will. Ich kann's kaum noch erwarten! Aber nein, mein Benutzername lautet nicht "cabriofahrer"...^^. Und wie, wenn man mehrere Benutzer zulassen will? Ich nehme an dsbmc_cli_user="user1, user2,user3" usw? Und gibt es auch eine Option, wenn man alle von vornherein zulassen will, auch die noch nicht geschaffenen, mit z.B. "all"?
 
Aber nein, mein Benutzername lautet nicht "cabriofahrer"...^^.
Dachte ich mir schon ;)
Und wie, wenn man mehrere Benutzer zulassen will? Ich nehme an dsbmc_cli_user="user1, user2,user3" usw? Und gibt es auch eine Option, wenn man alle von vornherein zulassen will, auch die noch nicht geschaffenen, mit z.B. "all"?
Die Variante mit dem rc-Skript bietet sich für ein System mit mehreren Benutzern nicht an. Es geht davon aus, dass es einen Benutzer gibt. Angenommen, das System würde von zwei Benutzern A und B benutzt. Wenn A und B gleichzeitig angemeldet sind, bzw. für jeden der beiden Benutzer dsbmc-cli gestartet wurde, konkurrieren die jeweiligen Instanzen von dsbmc-cli miteinander. Der Datenträger, der durch die dsbmc-cli-Instanz von Benutzer A eingehängt wird, verhindert dann natürlich den Zugriff durch Benutzer B. Dabei weiss man nicht, welche der Instanzen schneller ist. Das rc-Skript weiss nicht, ob überhaupt einer der Benutzer angemeldet ist. Wenn man als A arbeiten möchte, das Skript aber auch die dsbmc-cli-Instanz für B startet, obwohl B nicht angemeldet ist, hat A natürlich ein Problem. Das rc-Skript müsste also im Hintergrund darauf warten, dass sich einer der Benutzer anmeldet, und erst dann für diesen dsbmc-cli starten. Wenn sich jetzt aber der andere Benutzer per ssh anmeldet oder auf einer lokalen Konsole, wird für diesen auch dsbmc-cli gestartet.

Ich würde der .xinitrc-Variante den Vorzug geben. Man muss ja nur den exec ... -Teil entsprechend ändern, wenn man einen anderen WM oder eine andere DE nach dem Anmelden mit Slim oder per startx starten möchte.
 
Eine weitere, etwas flexiblere Variante ist diese:

Lege desktop-Dateien für die DE/WM-Sessions an, die Du benutzt, etwa:

/usr/local/share/xsessions/mate.desktop:
Code:
[Desktop Entry]
Name=MATE
Comment=Start MATE session
Exec=/usr/local/bin/mate-session
Icon=MATE
Type=Application
/usr/local/share/xsessions/openbox.desktop:
Code:
[Desktop Entry]
Name=Openbox
Comment=Log in using the Openbox window manager (without a session manager)
Exec=/usr/local/bin/openbox-session
Icon=openbox
Type=Application
/usr/local/share/xsessions/kde.desktop:
Code:
[Desktop Entry]
Name=KDE
Comment=Start KDE session
Exec=/usr/local/bin/startkde
Icon=KDE
Type=Application
Anschließend erzeuge für jeden Benutzer eine ~/.xinitrc:
Code:
#!/bin/sh
dsbmc-cli -a&
exec "$1"
Jetzt kannst Du in slim mit der Taste F1 zwischen den Session wählen, und bei jeder wird (sofern es nicht schon läuft) dsbmc-cli -a im Hintergrund ausgeführt, und anschließend die DE/WM-Session gestartet.
 
Hallo @marcel,

Volltreffer! Sogar die wird jetzt erkannt! Ich habe jetzt MATE mit LightDM installiert, dann habe ich in Control Center - Startup Applications - Add "dsbmc-cli -a &" eingetragen und es funktioniert alles wunderbar! Es erscheinen auf dem Desktop jetzt auch Symbole (CD's/Festplatten), wie es sich für MATE gehört. Sehr erfreulich ist auch, dass nun endlich meine externe NTFS-Platte automatisch gemountet wird. Dieses Feature war leider ab FreeBSD 10.0 im Zusammenhang mit HAL verloren gegangen.

Ich finde, dass das jetzt ins WIKI gehört, vor allem auch mit dem in #288 und #291 gesagtem.

Also Desktop Feeling und Funktionalität mit dsbmd/dsbmc pur! KDE aber leider erstmal ade!

Ich weiss noch, wie hier am Anfang gesagt wurde, so etwas könnte dsbmc gar nicht leisten, ich würde zu viel verlangen, etc...
(Ich muss mich jetzt leider noch mit LightDM weiter beschäftigen, damit ich ein Hintergrundbild kriege, automatisch einloggen kann, usw.)

Was dsbmd bei mir allerdings im Hintergrund und sichtbar durch dmesg hervorruft ist folgendes:

Code:
ata0: FAILURE - zero length DMA transfer attempted
ata0: setting up DMA failed
ata0: FAILURE - zero length DMA transfer attempted
ata0: setting up DMA failed
ata0: FAILURE - zero length DMA transfer attempted
ata0: setting up DMA failed
ata0: FAILURE - zero length DMA transfer attempted
ata0: setting up DMA failed

...

Ich weiß nicht, ob mich das jetzt weiter stören muss?
 
Hallo @marcel,

ich muss leider nachtragen: Die Fehlermeldung, die ich oben angegeben habe, stört doch, und zwar nicht geringfügig:
  1. Wenn ich mich in der Konsole befinde, erscheint diese Fehlermeldung immer wieder und nimmt mir den Prompt weg.
  2. Das Herunterfahren des Systems verzögert sich um mindestens eine Minute. Wenn man in MATE auf System -> Shutdown geht, erscheint LightDM erstmal wieder und da bleibt es für eben diese Zeit hängen. Wenn ich aber vorher im Terminal dsbmd deaktiviere (#service dsbmd stop), fährt das System schnell runter.
Gibt es hier einen einfachen Workaround, oder musst Du da wieder was ändern?
 
Hallo @cabriofahrer ,

danke für die Rückmeldung! Es klingt ja bis auf diese garstige Meldung sehr erfreulich. Zu Letzterer: Die Meldung ist nicht schlimm. Beheben kannst Du das Problem, indem Du dsbmd-1.2 über die Ports baust.

Zu dem Hänger beim Shutdown weiss ich leider im Moment keinen Rat. Werde mich darum kümmern.
 
Das Herunterfahren des Systems verzögert sich um mindestens eine Minute. Wenn man in MATE auf System -> Shutdown geht, erscheint LightDM erstmal wieder und da bleibt es für eben diese Zeit hängen. Wenn ich aber vorher im Terminal dsbmd deaktiviere (#service dsbmd stop), fährt das System schnell runter.
Entferne bitte mal die Zeile # KEYWORD: shutdown aus /usr/local/etc/rc.d/dsbmd
Vielleicht hilft das.
 
Entferne bitte mal die Zeile # KEYWORD: shutdown aus /usr/local/etc/rc.d/dsbmd
Vielleicht hilft das.

Tatsache, der PC fährt jetzt ordnungsgemäß runter! Verstehen tue ich es allerdings nicht: Sind Zeilen, die mit # beginnen nicht sowieso wirkungslos?

Zu Letzterer: Die Meldung ist nicht schlimm. Beheben kannst Du das Problem, indem Du dsbmd-1.2 über die Ports baust.

Die Meldung ist aber sehr lästig, denn wenn ich ein dmesg mache, habe ich in meinem Terminal nichts anderes. Und wie gesagt, in der Konsole wird mir dadurch der Prompt immer wieder weggenommen.

Und aus den Ports gebaut hatte ich. Vorher war dsbmd-1.1 schon aus den Ports installiert. Nach einem "portsnap fetch update" wollte ich dann ein "portupgrade dsbmd machen, was aber leider nicht funktionierte (Fehlermeldung weiß ich leider nicht mehr).
Danach wechselte ich in das Verzeichnis /usr/ports/sysutils/dsbmd und machte zuerst ein "make deinstall" und anschließend ein "make reinstall".
 
Verstehen tue ich es allerdings nicht: Sind Zeilen, die mit # beginnen nicht sowieso wirkungslos?
Nein. Bei rc-Skripten wird durch diese Schlüsselwörter u.a. die Reihenfolge der Ausführung bestimmt. Wenn es Dich interessiert: man rc

Kopieren bitte die angefügte Datei ohne .txt nach /usr/ports/sysutils/dsbmd/files/
Anschließend:
Code:
# cd /usr/ports/sysutils/dsbmd && make clean && make extract && make patch && make deinstall && make install
# service dsbmd restart

Ich hoffe, das behebt das Spam-Problem.
 

Anhänge

  • patch-dsbmd.txt
    426 Bytes · Aufrufe: 264
Und wie gesagt, in der Konsole wird mir dadurch der Prompt immer wieder weggenommen.
du bist dann auf der virtuellen Konsole No 1 (also Null) und die wird halt für Fehlerausgaben genutzt. Wenn du nichts umgestellt hast, solltest du einige weitere Konsolen haben (F2 ... F7? ich weiß nicht genau, weil ich immer auf vier begrenze). Sobald du nicht auf der ersten bist, sollte keine Fehlermeldung dich stören.
dmesg sieht man allgemein ja eh mittels grep an, also nicht so dramatisch.
 
Hallo @marcel,

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!

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).

Auch noch Danke an @pit234a für den letzten kleinen Hinweis, war mich nicht bewußt, dass es nur auf der ersten Konsole passiert.

Abschließend möchte ich noch an alle die Combo LightDM/MATE empfehlen, da erübrigt sich die Notwendigkeit einer .xinitrc wie mit Slim.
 
  • Like
Reaktionen: lme
Zurück
Oben