NomadBSD - ein LiveUSB-System basierend auf FreeBSD 11.1

Kann mir bitte jemand der NomadBSD nutzt, die Ausgabe von:
Code:
cat /etc/group | grep -i nomad
hier posten? ... wenn diese Datei noch im original Zustand ist. Danke.

Code:
wheel:*:0:root,nomad
operator:*:5:root,nomad
video:*:44:nomad
nomad:*:1001:
cups:*:193:root,nomad
webcamd:*:145:root,nomad
 
komme mir ziemlich blöd vor: kann NomadBSD 1.2 vom Stick problemlos starten und konfigurieren, allerdings werde ich schon bei der wifi Konfiguration nach dem root Password gefragt: alles mögliche probiert: root, nomad, Nomad, ... Mit google auch nichts gefunden.
 
Ich versuche gerade verzweifelt mit Thunar auf mein NAS zu gucken (mit smb://silo01/ in der Adreszeile). Bekomme aber nur eine obscure
" "/ auf " konnte nicht geöffnet werden. Vorgang wird nicht unterstützt. " -Meldung.
Thunar sagt mir außerdem, daß ihm gvfs fehlt.
Ich bin mir sicher, daß es schon mal geklappt hat.
2 Fragen:
wo loggt Thunar normalerweise seine Probleme?
/var/log/messages ist fast leer. Ist das heutzutage normal?
 
Ich versuche gerade verzweifelt mit Thunar auf mein NAS zu gucken (mit smb://silo01/ in der Adreszeile). Bekomme aber nur eine obscure
" "/ auf " konnte nicht geöffnet werden. Vorgang wird nicht unterstützt. " -Meldung.
Thunar sagt mir außerdem, daß ihm gvfs fehlt.
Ich bin mir sicher, daß es schon mal geklappt hat.
2 Fragen:
wo loggt Thunar normalerweise seine Probleme?
/var/log/messages ist fast leer. Ist das heutzutage normal?
Vorweg: ich habe kein NomadBSD. Da es aber auf FreeBSD basiert, sollte es einigermaßen ähnlich sein. gvfs ist auf meinem System als Abhängigkeit von thunar installiert worden. Im Thunar selbst habe ich Links auch die Möglichkeit das Netzwerk zu durchsuchen.

Um etwas konkreter auf deine Frage zu antworten: Starte thunar mal aus zB xterm heraus. Solche Fehler werden meist in der Konsole ausgegeben und nicht geloggt.

HTH
 
Ich versuche gerade verzweifelt mit Thunar auf mein NAS zu gucken (mit smb://silo01/ in der Adreszeile). Bekomme aber nur eine obscure
" "/ auf " konnte nicht geöffnet werden. Vorgang wird nicht unterstützt. " -Meldung.
Thunar sagt mir außerdem, daß ihm gvfs fehlt.
Ich bin mir sicher, daß es schon mal geklappt hat.
2 Fragen:
wo loggt Thunar normalerweise seine Probleme?
/var/log/messages ist fast leer. Ist das heutzutage normal?

Hi,

offenbar wurden Umgebungsvariablen, die dbus betreffen, nicht so gesetzt, dass sie jeder Komponente zur Verfügung standen. Du kannst die .xinitrc von hier einfach nach ~/.xinitrc kopieren, oder die entsprechenden Änderungen manuell vornehmen.
 
  • Like
Reaktionen: lme
kaum macht mans richtig, schon funktionierts!

aber warum funktionierte es vorher nicht? Ein frisch erstellter Stick (um ein mlx4en_load="YES" in der /boot/loader.conf erweitert)
produziert folgendes diff der .xinitrc:
2d1
< export EDITOR=ee
31a31,35
> #FIRSTRUN_START
> # Put everything to be run only on the first login here
> cat ${HOME}/.config/plank.ini | dconf load /net/launchpad/plank/docks/
> sed -i '' '/^#FIRSTRUN_START/,/^#FIRSTRUN_END/d' $0
> #FIRSTRUN_END
40a45
> eval $(dbus-launch --sh-syntax)
55c60
< # exec ck-launch-session dbus-launch --exit-with-session mate-session
---
> # exec ck-launch-session mate-session
62c67
< exec ck-launch-session dbus-launch --exit-with-session openbox-session
---
> exec ck-launch-session openbox-session
 
aber warum funktionierte es vorher nicht?

Genau genommen funktionierte es vorher nicht, wenn man Thunar per plank startete. Denn letzteres wird/wurde vor Openbox und der DBus-Session gestartet. Somit stand weder plank noch allen von plank aus gestarteten Anwendungen, die ihre Umgebung von ihrem Elternprozess übernehmen, die Umgebungsvariable DBUS_SESSION_BUS_ADDRESS zur verfügung. Und ohne diese können die von Thunar gestarteten gvfs-Dienste keine DBus-Verbindung herstellen.

um ein mlx4en_load="YES" in der /boot/loader.conf erweitert
Danke für den Hinweis.
 
Zurück
Oben