• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Nach Upgrade von 11.2 auf 11.3: Kein DE außer Fluxbox funktioniert mehr?

cabriofahrer

Well-Known Member
Themenstarter #1
Habe heute die alte Mühle von meiner Freundin auf den neuesten Stand gebracht, vorher war 11.2 amd64 drauf, mit nvidia-driver-304 (Geforce GT6600) mit sddm und xfce. Zunächst machte ich "freebsd-update fetch install", "freebsd-update upgrade -r 11.3-RELEASE" und "pkg upgrade" (verkürzt dargestellt). Funktionierte alles wunderbar, nach einem Reboot erschien wieder sddm wie immer, aber beim Auswählen von xfce blieb der Bildschirm schwarz und man sah nur den Mauszeiger. Ich versuchte daraufhin ein "service sddm stop" ein "rm -rf xfce4" und xfce-session in .config, startete sddm und xfce neu und es klappte. Doch nach einem Logout aus xfce oder einem Neustart des Rechners ging es wieder nicht. Ich versuchte ein "pkg delete xfce" und "pkg autoremove" und installierte xfce neu, aber wieder das Gleiche. Ich haute dann sogar alle Pakete runter ("pkg delete -a") und installierte alles wieder neu, xorg, fluxbox, xfce, nvidia-driver-304 und immernoch das gleiche Problem. Ich versuchte mal "pkg install gnome3-lite" und wollte das über sddm starten, aber auch schwarzer Bildschirm wenn ich es über sddm auswähle. Das gleiche mit pcdm. Nur Fluxbox funktioniert, man kann sich beliebig ein- und ausloggen.
Was ist hier los? Das habe ich noch nie erlebt, dass die Grafik an sich funktioniert (sddm oder pcdm laufen ja), aber dann die DE's nicht? Leider bin ich jetzt wieder bei mir zuhause und habe jetzt keinen Zugriff auf den Rechner meiner Freundin.
 

cabriofahrer

Well-Known Member
Themenstarter #5
Wie oben bereits erwähnt, bin ich wieder bei mir zuhause und kann im Moment nicht auf den Rechner meiner Freundin zugreifen. Wäre denn ein Remote-Zugriff möglich, wenn ich ihre public IP, die IP des Rechners hinter dem NAT im Router und das root-Passwort des Rechners (habe ich ja selbst eingerichtet) herausfinde?
 

mr44er

moderater Moderator
Mitarbeiter
#6
Wenn auf ihrem Rechner der sshd läuft und der Port 22 im Router geforwarded wird, dann sollte der Login mit ihrem user klappen. Wenn der in wheel ist, kannst du su werden.

ssh freundinusername@publicip
 
#7
Wie oben bereits erwähnt, bin ich wieder bei mir zuhause und kann im Moment nicht auf den Rechner meiner Freundin zugreifen. Wäre denn ein Remote-Zugriff möglich, wenn ich ihre public IP, die IP des Rechners hinter dem NAT im Router und das root-Passwort des Rechners (habe ich ja selbst eingerichtet) herausfinde?
Vermutlich ist ein Remote-Zugriff nur moeglich, wenn der Router ein port forwarding zum Rechner deiner Freundin hat. Bei einer Fritzbox koennte man auch noch per VPN ins Netz, wenn dieses auf der Fritzbox eingerichtet ist. Ansonsten koennte deine Freundin evtl. einen Reverse-SSH-Tunnel einrichten, ueber den Du dann auf ihren Rechner kommst. Ob sie das hinbekommt, kann ich allerdings nicht beurteilen. ;-)
 

pit234a

Well-Known Member
#8
ich würde trotzdem mit X anfangen. Also nicht in SDDM oder sonst etwas booten, sondern nur von Konsole aus X starten und nachsehen, was in Xorg.0.log steht. Vor allem, welcher Treiber geladen ist und mit welcher Auflösung er funktioniert.
Erst danach, also wenn das sicher ist, dass hier alles passt und meinen Wünschen entspricht, würde ich weiter suchen.

Nur mal dieses Szenario: dein Treiber funktioniert plötzlich gar nicht mehr (wurde ja upgedatet) oder funktioniert nicht korrekt und kann nicht mehr die gleichen Auflösungen fahren, wie zuvor. Oder es vielleicht VESA genommen und du merkst davon nichts, außer, dass womöglich manche DEs damit nicht klarkommen.
Ist vielleicht nicht so wahrscheinlich, aber es hat sich tausende Male gezeigt, dass die Basis zuverlässig stimmen muss, bevor man weiter aufbaut.
 

cabriofahrer

Well-Known Member
Themenstarter #9
Zu @pit234a und X/Xorg.0.log allgemein: Ich kann von sddm aus Fluxbox auswählen, und wenn ich in Fluxbox bin, merke ich sofort, dass das Bild die maximale Auflösung des Monitors hat, was schon mal korrekt ist. Da ich immer mesa-demos installiert habe, zeigt mir ein "glxinfo" bzw. ein "glxgears" an, ob die 3D-Beschleunigung korrekt ist, da die Ausgabe ziemlich lang ist, mit sämtlichen OpenGL-Extensions, "direct rendering:yes", usw. Es schint also alles OK zu sein, also definitiv kein VESA. Wenn die Ausgabe von "glxinfo" hingegen extrem kurz ist und etwas mit einem "glx error" oder so ähnlich anzeigt, was ich in der Vergangenheit auch schon mal gesehen habe, weiß ich, dass definitiv etwas nicht stimmt. Aber selbst in einem solchen Fall, denn ich auf meiner und anderen Maschinen schon mal hatte, läuft xfce dann, weill er nicht 3D-Beschleunigung voraussetzt, wie andere DE's.

Jetzt will ich in dem Zusammenhang mal fragen: Was/bis wann dokumentiert Xorg.0.log denn rein theoretisch, wenn sddm und damit X erfolgreich startet, aber der DE dann nicht? Und nochmal: Wenn ich in .config den Ordner "xfce4" lösche, dann klappt es, ebenso, wenn ich ein neues Userkonto erstelle, weil die Konfigurationsdatei beim ersten Mal ja noch nicht geschrieben ist. Aber beim zweiten Mal dann eben nicht mehr. Das ist total eigenartig und riecht nicht nach Problem mit X.

Wenn auf ihrem Rechner der sshd läuft und der Port 22 im Router geforwarded wird, dann sollte der Login mit ihrem user klappen. Wenn der in wheel ist, kannst du su werden.
Vermutlich ist ein Remote-Zugriff nur moeglich, wenn der Router ein port forwarding zum Rechner deiner Freundin hat.
Wenn ein Portforwarding eines Ports (und warum 22, ist das nicht für ftp?) bei einem Router nicht Standard ist, was ich nicht glaube, sehe ich da schwarz. Könnte ich denn mit nmap einen Portscan durchführen, wenn ich die public IP kenne, um herauszufinden, ob überhaupt ein Port offen ist? Wie würde dann der Befehl lauten?

Und auf dem Remote PC muss sshd laufen, damit man mit ssh von außen zugreifen kann?

Ansonsten koennte deine Freundin evtl. einen Reverse-SSH-Tunnel einrichten, ueber den Du dann auf ihren Rechner kommst. Ob sie das hinbekommt, kann ich allerdings nicht beurteilen. ;-)
Das kann man vergessen...^^.
 

pit234a

Well-Known Member
#10
Das ist total eigenartig und riecht nicht nach Problem mit X.
Jetzt will ich in dem Zusammenhang mal fragen: Was/bis wann dokumentiert Xorg.0.log denn rein theoretisch, wenn sddm und damit X erfolgreich startet, aber der DE dann nicht?
ganz sicher hört sich das so an. Trotzdem hätte ich es mir angesehen.
Der Start von X wird in der Xorg.0.log dokumentiert.
X hat zunächst mal nichts mit Clienten zu tun, die ihn dann nutzen möchten, wie etwa SDDM oder ein DE.
Also, wie soll ich sagen: pures X ohne weitere Programme, die darauf zugreifen. Und eben dieses X muss ja schon mal eindeutig richtig laufen, wenn denn andere es nutzen möchten.
Das sieht bei dir so aus. Dein Problem kann anderer Natur sein. Es ist aber merkwürdig, dass man bisher davon noch nicht wirklich etwas gehört hat. Dass Treiber sich ändern, kommt aber dauernd vor und eben gerade läuft hier ein passender Thread zu Treibern für Nvidia-GraKa.

Die Xorg.0.log ist die Basis-Information zu allem, was beim Start von X passiert. Deshalb scheint sie einen auf den ersten Blick zu erschlagen und wenig zu taugen. Bleibt man davon erst mal unbeeindruckt und liest sich ein wenig ein, sieht man sie plötzlich mit ganz anderen Augen und kann sie als ziemlich verlässliches Instrument gut nutzen.
 

mr44er

moderater Moderator
Mitarbeiter
#11
Wenn ein Portforwarding eines Ports (und warum 22, ist das nicht für ftp?) bei einem Router nicht Standard ist, was ich nicht glaube, sehe ich da schwarz.
ftp ist 21. Ich sähe eher schwarz, wenn ein Router nicht ab Werk völlig abgeschirmt wäre. ;)

Und auf dem Remote PC muss sshd laufen, damit man mit ssh von außen zugreifen kann?
Jep. Essen muß da sein, um es essen zu können. ;)

Zu dem Rest mit scannen etc. sag ich mal nix, weil die Wahrscheinlichkeit auf Erfolg zu gering ist.
Es ist auch insgesamt problematisch, weil dir die Kiste nicht gehört. Könnte sein, dass sie sich dann überwacht vorkommt etc.
 

cabriofahrer

Well-Known Member
Themenstarter #12
OK, habe sie mal gescannt, nachdem ich sie ihre Public IP selbst herausfinden ließ. Hier ist wohl kein einziger Port offen, alle sind "gefiltert":

zenmap2.png


Ich denke mal, bevor ich nicht vor Ort wieder Hand an den PC legen kann, werde ich nicht an die Xorg.0.log kommen.
 

CommanderZed

OpenBSD User
Mitarbeiter
#13
Ist villeicht bei dir und bei ihr ein Windows- oder Linux o.ä. PC vorort? Dann könntest du auf beiden Teamviewer o.ä. starten und dann vom Linux oder Windows per SSH weiterverzweigen.
 

cabriofahrer

Well-Known Member
Themenstarter #14
Nein. Ich werde mal versuchen, es mit ihr telefonisch hinzukriegen, dass sie mir eine Kopie der Xorg.0.log zukommen lässt. Ansonsten muss ich sonst wirklich mal selbst wieder vor Ort sein. Aber Frage zu Teamviewer: Was macht dieses Programm technisch gesehen, damit ein Zugriff von außen damit möglich wäre? Mit dem Scan mit nmap scannt man doch eigentlich den Router, der ja, wie in diesem Fall und auch allgemein offensichtlich undurchlässig ist, es sei denn, man würde im Router einen Port forwarden, oder?
 

CommanderZed

OpenBSD User
Mitarbeiter
#15
Die und ähnliche Anbieter nutzen einen Server "In der Mitte" um die NAT-Einschränkungen zu umgehen.

Dein PC verbindet sich mit einem "Teamviewer" Server und der andere PC auch, es sind somit, vom nat/router aus gesehen, nur verbindungen von "innen" nach "aussen" und nicht umgekehrt.

Standardmäßig blocken ja alle gängigen "einfachen" router ala Fritzbox und Co zugriffe von aussen auf das interne Netz, erlauben aber alle verbindung von "innen" nach "außen".
(Nicht zuletzt da der Router ja garnicht wissen kann was intern das "ziel" ist)
((Allerdings wird das ganze durch upnp & co das ja meist standardmäßig "an" ist wieder etwas aufgeweicht, was aber etwas am Thema vorbei führt))
 
Themenstarter #16
ich würde trotzdem mit X anfangen. Also nicht in SDDM oder sonst etwas booten, sondern nur von Konsole aus X starten und nachsehen, was in Xorg.0.log steht.
OK, gleicher Mist auf meinem Laptop mit 12.0 i386: Nach einem pkg upgrade funktioniert auch hier xfce nicht mehr, ich bekomme auch hier nach einloggen im sddm einen schwarzen Bildschirm. Da es sich nun um meinen Rechner handelt, kann ich natürlich mehr Info liefern.

Was ich bereits asuprobiert habe und hoffentlich nun weiterhilft auch in den anderen Thread von @Morfio https://www.bsdforen.de/threads/nach-updates-sddm-startet-kde-nicht-mehr.35266/

Ich habe ohne sddm direkt in der Konsole ein "xinit startxfce4" gemacht, hier sehe ich auf einem dann schwarzen Bildschirm ein Terminal oben rechts, das folgende Meldung ausgibt:

Code:
/usr/local/bib/startxfce4: X server already running on display :0
xfce4-session: No GPG agent found
XFCE und auch andere Desktops scheinen beim Starten also zu glauben, dass X schon läuft, irgendwo hier liegt also der Fehler.

Denn: "xinit fluxbox" funktioniert weiterhin nach dem pkg upgrade (wie bei meiner Freundin), wenn ich X kille und außerdem, auf meinem Hauptrechner, den ich noch nicht upgedatet habe, funktioniert aus der Konsole heraus (also ohne sddm) ein "xinit startxfce4".

Ich habe jetzt den Laptop neu gestartet, wieder "xinit startxfce4", in eine Konsole gewechselt und die Xorg.0.log in mein Benutzerkonto kopert:

Code:
$ more Xorg.0.log
[    51.172]
X.Org X Server 1.18.4
Release Date: 2016-07-19
[    51.172] X Protocol Version 11, Revision 0
[    51.172] Build Operating System: FreeBSD 12.0-RELEASE-p10 i386
[    51.172] Current Operating System: FreeBSD elvis69.local 12.1-RELEASE FreeBSD 12.1-RELEASE r354233 GENERIC i386
[    51.173] Build Date: 06 October 2019  01:42:20AM
[    51.173] 
[    51.173] Current version of pixman: 0.38.4
[    51.173]    Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
[    51.173] Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    51.173] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Nov 14 13:26:12 2019
[    51.176] (==) Using config file: "/etc/X11/xorg.conf"
[    51.178] (==) ServerLayout "Layout0"
[    51.178] (**) |-->Screen "Screen0" (0)
[    51.178] (**) |   |-->Monitor "Monitor0"
[    51.179] (**) |   |-->Device "Device0"
[    51.179] (**) |-->Input Device "Keyboard0"
[    51.179] (**) |-->Input Device "Mouse0"
[    51.179] (==) Automatically adding devices
[    51.180] (==) Automatically enabling devices
[    51.180] (==) Not automatically adding GPU devices
[    51.180] (==) Max clients allowed: 256, resource mask: 0x1fffff
[    51.191] (==) FontPath set to:
        /usr/local/share/fonts/misc/,
        /usr/local/share/fonts/TTF/,
        /usr/local/share/fonts/OTF/,
        /usr/local/share/fonts/Type1/,
        /usr/local/share/fonts/100dpi/,
        /usr/local/share/fonts/75dpi/
[    51.191] (==) ModulePath set to "/usr/local/lib/xorg/modules"
[    51.191] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[    51.191] (WW) Disabling Keyboard0
[    51.191] (WW) Disabling Mouse0
[    51.192] (II) Loader magic: 0x824a120
[    51.192] (II) Module ABI versions:
[    51.192]    X.Org ANSI C Emulation: 0.4
[    51.192]    X.Org Video Driver: 20.0
[    51.192]    X.Org XInput driver : 22.1
[    51.192]    X.Org Server Extension : 9.0
[    51.193] (--) PCI:*(0:1:0:0) 10de:01d7:1025:0090 rev 161, Mem @ 0xd1000000/16777216, 0xc0000000/268435456, 0xd0000000/16777216, BIOS @ 0x????????/65536
[    51.193] (II) LoadModule: "glx"
[    51.196] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so
[    51.761] (II) Module glx: vendor="NVIDIA Corporation"
[    51.761]    compiled for 4.0.2, module version = 1.0.0
[    51.761]    Module class: X.Org Server Extension
[    51.763] (II) NVIDIA GLX Module  304.137  Thu Sep 14 13:54:16 PDT 2017
[    51.763] (II) LoadModule: "nvidia"
[    51.763] (II) Loading /usr/local/lib/xorg/modules/drivers/nvidia_drv.so
[    51.777] (II) Module nvidia: vendor="NVIDIA Corporation"
[    51.777]    compiled for 4.0.2, module version = 1.0.0
[    51.777]    Module class: X.Org Video Driver
[    51.780] (II) NVIDIA dlloader X Driver  304.137  Thu Sep 14 13:35:03 PDT 2017
[    51.780] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
[    51.781] (--) Using syscons driver with X support (version 2.0)
[    51.781] (--) using VT number 9

[    51.792] (II) Loading sub module "fb"
[    51.792] (II) LoadModule: "fb"
[    51.792] (II) Loading /usr/local/lib/xorg/modules/libfb.so
[    51.794] (II) Module fb: vendor="X.Org Foundation"
[    51.794]    compiled for 1.18.4, module version = 1.0.0
[    51.794]    ABI class: X.Org ANSI C Emulation, version 0.4
[    51.794] (II) Loading sub module "wfb"
[    51.794] (II) LoadModule: "wfb"
[    51.795] (II) Loading /usr/local/lib/xorg/modules/libwfb.so
[    51.797] (II) Module wfb: vendor="X.Org Foundation"
[    51.797]    compiled for 1.18.4, module version = 1.0.0
[    51.797]    ABI class: X.Org ANSI C Emulation, version 0.4
[    51.798] (II) Loading sub module "ramdac"
[    51.798] (II) LoadModule: "ramdac"
[    51.798] (II) Module "ramdac" already built-in
[    51.801] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[    51.801] (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32
[    51.801] (==) NVIDIA(0): RGB weight 888
[    51.801] (==) NVIDIA(0): Default visual is TrueColor
[    51.802] (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0)
[    51.806] (**) NVIDIA(0): Enabling 2D acceleration
[    53.119] (II) NVIDIA(0): NVIDIA GPU GeForce Go 7300 (G72) at PCI:1:0:0 (GPU-0)
[    53.119] (--) NVIDIA(0): Memory: 262144 kBytes
[    53.119] (--) NVIDIA(0): VideoBIOS: 05.72.22.58.30
[    53.119] (II) NVIDIA(0): Detected PCI Express Link width: 16X
[    53.119] (--) NVIDIA(0): Interlaced video modes are supported on this GPU
[    53.119] (--) NVIDIA(0): Valid display device(s) on GeForce Go 7300 at PCI:1:0:0
[    53.119] (--) NVIDIA(0):     CRT-0
[    53.119] (--) NVIDIA(0):     TV-0
[    53.119] (--) NVIDIA(0):     AU Optronics Corporation (DFP-0) (connected)
[    53.119] (--) NVIDIA(0):     DFP-1
[    53.119] (--) NVIDIA(0): CRT-0: 400.0 MHz maximum pixel clock
[    53.119] (--) NVIDIA(0): TV-0: 400.0 MHz maximum pixel clock
[    53.119] (--) NVIDIA(0): TV encoder: Unknown
[    53.119] (--) NVIDIA(0): AU Optronics Corporation (DFP-0): 330.0 MHz maximum pixel clock
[    53.119] (--) NVIDIA(0): AU Optronics Corporation (DFP-0): Internal Dual Link LVDS
[    53.119] (--) NVIDIA(0): DFP-1: 165.0 MHz maximum pixel clock
[    53.119] (--) NVIDIA(0): DFP-1: Internal Single Link TMDS
[    53.119] (**) NVIDIA(0): Using HorizSync/VertRefresh ranges from the EDID for display
[    53.119] (**) NVIDIA(0):     device AU Optronics Corporation (DFP-0) (Using EDID
[    53.119] (**) NVIDIA(0):     frequencies has been enabled on all display devices.)
[    53.120] (==) NVIDIA(0):
[    53.120] (==) NVIDIA(0): No modes were requested; the default mode "nvidia-auto-select"
[    53.120] (==) NVIDIA(0):     will be used as the requested mode.
[    53.120] (==) NVIDIA(0):
[    53.120] (II) NVIDIA(0): Validated MetaModes:
[    53.120] (II) NVIDIA(0):     "DFP-0:nvidia-auto-select"
[    53.120] (II) NVIDIA(0): Virtual screen size determined to be 1280 x 800
[    53.120] (WW) NVIDIA(0): Unable to support custom viewPortOut 1280 x 720 +0 +40
[    53.121] (WW) NVIDIA(0): Unable to support custom viewPortOut 1066 x 800 +107 +0
[    53.121] (WW) NVIDIA(0): Unable to support custom viewPortOut 1066 x 800 +107 +0
[    53.122] (WW) NVIDIA(0): Unable to support custom viewPortOut 1066 x 800 +107 +0
[    53.122] (--) NVIDIA(0): DPI set to (98, 96); computed from "UseEdidDpi" X config
[    53.122] (--) NVIDIA(0):     option
[    53.122] (--) Depth 24 pixmap format is 32 bpp
[    53.135] (II) NVIDIA(0): Setting mode "DFP-0:nvidia-auto-select"
[    54.390] (==) NVIDIA(0): Disabling shared memory pixmaps
[    54.390] (==) NVIDIA(0): Backing store enabled
[    54.390] (==) NVIDIA(0): Silken mouse enabled
[    54.393] (**) NVIDIA(0): DPMS enabled
[    54.395] (II) Loading sub module "dri2"
[    54.395] (II) LoadModule: "dri2"
[    54.395] (II) Module "dri2" already built-in
[    54.396] (II) NVIDIA(0): [DRI2] Setup complete
[    54.396] (II) NVIDIA(0): [DRI2]   VDPAU driver: nvidia
[    54.397] (--) RandR disabled
[    54.416] (II) Initializing extension GLX
[    54.416] (II) Indirect GLX disabled.(II) config/devd: probing input devices...
[    54.680] (II) config/devd: adding input device (null) (/dev/kbdmux)
[    54.680] (II) LoadModule: "kbd"
[    54.683] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so
[    54.683] (II) Module kbd: vendor="X.Org Foundation"
[    54.683]    compiled for 1.18.4, module version = 1.9.0
[    54.683]    Module class: X.Org XInput Driver
[    54.683]    ABI class: X.Org XInput driver, version 22.1
[    54.683] (II) Using input driver 'kbd' for 'kbdmux'
[    54.684] (**) kbdmux: always reports core events
[    54.684] (**) kbdmux: always reports core events
[    54.684] (**) Option "Protocol" "standard"
[    54.684] (**) Option "XkbRules" "base"
[    54.684] (**) Option "XkbModel" "pc105"
[    54.684] (**) Option "XkbLayout" "us"
[    54.684] (**) Option "config_info" "devd:kbdmux"
[    54.684] (II) XINPUT: Adding extended input device "kbdmux" (type: KEYBOARD, id 6)
[    54.687] (II) config/devd: kbdmux is enabled, ignoring device ukbd0
[    54.687] (II) config/devd: kbdmux is enabled, ignoring device atkbd0
[    54.687] (II) config/devd: adding input device (null) (/dev/sysmouse)
[    54.687] (II) LoadModule: "mouse"
[    54.688] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so
[    54.689] (II) Module mouse: vendor="X.Org Foundation"
[    54.689]    compiled for 1.18.4, module version = 1.9.3
[    54.689]    Module class: X.Org XInput Driver
[    54.689]    ABI class: X.Org XInput driver, version 22.1
[    54.689] (II) Using input driver 'mouse' for 'sysmouse'
[    54.689] (**) sysmouse: always reports core events
[    54.689] (**) Option "Device" "/dev/sysmouse"
[    54.690] (==) sysmouse: Protocol: "Auto"
[    54.690] (**) sysmouse: always reports core events
[    54.690] (==) sysmouse: Emulate3Buttons, Emulate3Timeout: 50
[    54.690] (**) sysmouse: ZAxisMapping: buttons 4 and 5
[    54.690] (**) sysmouse: Buttons: 5
[    54.690] (**) Option "config_info" "devd:sysmouse"
[    54.690] (II) XINPUT: Adding extended input device "sysmouse" (type: MOUSE, id 7)
[    54.690] (**) sysmouse: (accel) keeping acceleration scheme 1
[    54.690] (**) sysmouse: (accel) acceleration profile 0
[    54.690] (**) sysmouse: (accel) acceleration factor: 2.000
[    54.690] (**) sysmouse: (accel) acceleration threshold: 4
[    54.690] (II) sysmouse: SetupAuto: hw.iftype is 4, hw.model is 0
[    54.690] (II) sysmouse: SetupAuto: protocol is SysMouse
[    54.690] (II) config/devd: device /dev/ums0 already opened
[    54.737] (II) config/devd: adding input device Mouse (/dev/psm0)
[    54.737] (II) Using input driver 'mouse' for 'Mouse'
[    54.737] (**) Mouse: always reports core events
[    54.737] (**) Option "Device" "/dev/psm0"
[    54.737] (==) Mouse: Protocol: "Auto"
[    54.737] (**) Mouse: always reports core events
[    54.784] (==) Mouse: Emulate3Buttons, Emulate3Timeout: 50
[    54.784] (**) Mouse: ZAxisMapping: buttons 4 and 5
[    54.784] (**) Mouse: Buttons: 5
[    54.784] (**) Option "config_info" "devd:psm0"
[    54.784] (II) XINPUT: Adding extended input device "Mouse" (type: MOUSE, id 8)
[    54.784] (**) Mouse: (accel) keeping acceleration scheme 1
[    54.784] (**) Mouse: (accel) acceleration profile 0
[    54.785] (**) Mouse: (accel) acceleration factor: 2.000
[    54.785] (**) Mouse: (accel) acceleration threshold: 4
[    54.798] (II) Mouse: SetupAuto: hw.iftype is 3, hw.model is 0
[    54.798] (II) Mouse: SetupAuto: protocol is PS/2
[    55.238] (II) Mouse: ps2EnableDataReporting: succeeded
[    57.456] (**) NVIDIA(0): Using HorizSync/VertRefresh ranges from the EDID for display
[    57.456] (**) NVIDIA(0):     device AU Optronics Corporation (DFP-0) (Using EDID
[    57.456] (**) NVIDIA(0):     frequencies has been enabled on all display devices.)
$
 

pit234a

Well-Known Member
#17
xinit startet einen Xserver und den twm, wenn ich nicht irre.
startxfce4 ist ein startscript für den xfce4, der sicherlich ein weiteres Programm aufruft, nachdem er einige Dinge passend eingerichtet hat.
Also, was ich tun würde: sicher stellen, dass nicht sddm oder irgendwer sonst startet und damit schon X erzeugt. X darf nicht laufen.
In einer ~/.xinitrc eintragen, was ich denn aufgerufen habe möchte. Vielleicht exec /usr/local/bin/startxfce4 oder vielleicht /usr/local/bin/xfce4-session oder wie das bei xfce auch immer heißen mag. Wenn deine Pfade bekannt sind, kannst du sie auch weg lassen.
Also, meine eigene .xinitrc sieht zb so aus:
Code:
exec openbox-session
und damit starte ich OpenBox. Und zwar mit dem Befehl startx aus der Konsole.
Auf diese Weise werden alle Mechanismen in der vorgesehenen Reihenfolge benutzt und man muss nicht irgendetwas sonst verändern oder Befehle kombinieren, deren Verhalten man dann nicht so ohne weiteres vorhersagen kann.
startx startet X von der Konsole und dazu ruft es ganz von selbst xinit auf und sieht in der ~/.xinitrc nach, was es sonst noch starten soll, also etwa das gewünschte DE.
Rufst du direkt xinit auf, ohne das Script startx, weiß das womöglich nicht wirklich, was es alles tun soll, insbesondere, welche Display-Variablen denn benutzt werden. Außerdem sieht es immer noch nach deiner lokalen xinitrc und wenn dort nichts eingetragen ist, nach der globalen xinitrc (ich glaube, weiter oben habe ich das schon mal erwähnt) und startet deshalb twm.
Also, startx ohne alle weiteren Maßnahmen, startet twm un das ist zunächst mal gar nicht so übel, weil auch das dann zeigt, dass X grundsätzlich funktioniert und weil: aus einem der automatisch gestarteten Terminals kannst du nun ebenfalls dein startxfce4 & oder was auch immer absetzen, denn da läuft nun ein X und kennt seine DISPLAY und startet innerhalb dieses Displays dein DE. Wenn es denn funktioniert und nicht ein Schaden genau hier und an dieser Stelle liegt, was wir ja herausfinden wollen.
 
Themenstarter #18
Also, was ich tun würde: sicher stellen, dass nicht sddm oder irgendwer sonst startet und damit schon X erzeugt. X darf nicht laufen
Das hatte ich ja getan und auch ausdrücklich dargestellt. Ich habe kurz noch openbox installiert und ich kann OHNE DASS SDDM GESTARTET ist hier genauso "xinit openbox" oder "xinit openbox-session". Ich bekomme dann einen schwarzen, aber funktionierenden Bildschirm mit einem Terminal links oben, ohne Fehlermeldung. Funktionierend, weil ich mit der Maus einen Rechtsklick machen kann, so dass ein Menü erscheint, mit dem ich z.B. Firefox starten oder openbox wieder verlassen kann.

Eine .xinitrc habe ich nicht und will ich nicht. Ich bin jahrelang ohne ausgekommen, das scheint nicht das Problem zu sein. Ich habe auch gesagt, dass auf meinem Hauptrechner mit 12.0 und älteren Paketen ein "xinit startxfce4" funktioniert. Ich habe auch devel/dbus neu kompiliert, daran lag es also auch nicht. Ich vermute, irgendein Paket, welches für mehrere DE's zuständig ist, ist faul.

Übrigens funktioniert kodi-standalone auch nach dem Upgrade weiterhin und wird ebenfalls von sddm aus gestartet. Weiterhin lässt sich xfce auch einfach mittles "startxfce4" aus der Konsole heraus starten. Hier das selbe Problem: Schwarzer Bildschirm mit Mauszeiger.
 
Zuletzt bearbeitet:

turrican

Well-Known Member
#19
Das startxfce4 is ein eher kurzes Script und startet nur den xfce, sonst machts eigentlich nicht viel, sofern ich mich korrekt erinnere (hab grad keine BSD Maschine mehr parat, um nachzusehen)

@cabriofahrer Da fluxbox ohne weiteres funktioniert (wie du oben schriebst) würde ich ein Problem mit dem Grafik-Subsystem bzw X generell eher ausschließen.

Du meintest, du hast dbus neu kompiliert, aber startet das auch beim Systemstart,sprich: ist in /etc/rc.conf die Zeile
Code:
dbus_enable="YES"
mit drin (ggf ging die beim Update verloren)?

Alternativ sysrc dbus_enable=YES in der lfd Session durchführen.
 

pit234a

Well-Known Member
#21
Eine .xinitrc habe ich nicht und will ich nicht. Ich bin jahrelang ohne ausgekommen,
sollst du auch weiterhin.
Es geht hier um Fehlersuche
Ich bekomme dann einen schwarzen, aber funktionierenden Bildschirm mit einem Terminal links oben
und das ist NICHT OpenBox, denn damit bekommst du einen schwarzen Bildschirm mit nichts und dem Menü, also dem hier:
Funktionierend, weil ich mit der Maus einen Rechtsklick machen kann, so dass ein Menü erscheint, mit dem ich z.B. Firefox starten oder openbox wieder verlassen kann.
Ich habe auch gesagt, dass auf meinem Hauptrechner mit 12.0 und älteren Paketen ein "xinit startxfce4" funktioniert.
Ja, hast du.
Und ich habe gesagt, was ich an deiner Stelle machen würde. Ich weiß nicht, ob das zum Erfolg führt. Keine Ahnung, wo das Problem bei deiner Installation liegt. Du wirst das womöglich selbst und für dich alleine herausfinden müssen.

Ein einziges Terminal ist für twm zu wenig und für OpenBox zu viel.
Ich habe deine Xorg.0.log nur überflogen und nichts negatives gesehen.
Was soll ich sagen: alles gut! Geht doch!
Offenbar geht ja nicht alles in deiner Installation und DU musst herausfinden, was nicht geht. Dabei versuche ich zu helfen, soweit ich eben kann und das ist nicht besonders weit. Wenn aber der twm in einer Art und Weise gestartet wird, dass nur eines der drei Terminals sichtbar ist, spricht das schon mal dafür, dass zumindest die Auflösung suboptimal ist.
Aber: ist das nun so?
Was hast du gestartet? was läuft und wie?

ein "xinit startxfce4" funktioniert
weil verkürzt zitiert: es funktionierte in deinen Augen bisher so, wie du das erwartet hattest. Nun offenbar nicht mehr. Was willst du dagegen tun?
Meine Hinweise kannst du in den Wind schreiben, ich bin inkompetent.
Und dann?
Geht es dir dadurch besser? bist du der Lösung deines Problems näher?
 
Themenstarter #22
Funktioniert denn startxfce4 ohne das xinit?
Nein, habe ich gerade in der Zwischenzeit noch ausprobiert und in meinem letzten Post ergänzt.
Da fluxbox ohne weiteres funktioniert (wie du oben schriebst) würde ich ein Problem mit dem Grafik-Subsystem bzw X generell eher ausschließen.
Das ist ja von Anfang an meine Vermutung.

Du meintest, du hast dbus neu kompiliert, aber startet das auch beim Systemstart,sprich: ist in /etc/rc.conf die Zeile
Ja, die Zeile in der /etc/rc.conf war immer drin.
 
Themenstarter #23
Und ich habe gesagt, was ich an deiner Stelle machen würde. Ich weiß nicht, ob das zum Erfolg führt.
Ich bin mir eben nicht sicher, ob ich Deinen Lösungsansatz richtig verstanden habe. Aber es ging um das Starten über .xinirc, oder?

weil verkürzt zitiert: es funktionierte in deinen Augen bisher so, wie du das erwartet hattest. Nun offenbar nicht mehr. Was willst du dagegen tun?
Meine Hinweise kannst du in den Wind schreiben, ich bin inkompetent.
Und dann?
Geht es dir dadurch besser? bist du der Lösung deines Problems näher?
Ich will Deine Hinweise nicht in den Wind schreiben, aber das Problem taucht offensichtlich bei zwei verschiedenen Rechnern mit unterschiedlicher Hardware und unterschiedlichen Versionen von FreeBSD auf und auch bei einem anderen Forummitglied mit KDE.
Wenn die meisten User hier aber nur ganz einfache Fenstermanager benutzen und möglicherweise alles aus Ports kompilieren, wird sich für diese das Problem natürlich gar nicht ergeben.
 

pit234a

Well-Known Member
#25
Wenn die meisten User hier aber nur ganz einfache Fenstermanager benutzen und möglicherweise alles aus Ports kompilieren, wird sich für diese das Problem natürlich gar nicht ergeben.
klar.

aber das Problem taucht offensichtlich bei zwei verschiedenen Rechnern mit unterschiedlicher Hardware und unterschiedlichen Versionen von FreeBSD auf und auch bei einem anderen Forummitglied mit KDE.
aber nicht Weltweit und nicht bei sehr vielen Nutzern, sonst würde man mehr davon hören.

Kann natürlich trotzdem ein Problem mit FreeBSD und seinen Pakten sein.
Lechzt aber geradezu danach, mögliche Fehler in der eigenen Installation zu finden.
Jedenfalls sicher machen, was denn eigentlich genau genommen geht und was denn nicht.
Dabei blicke ich derzeit nicht durch, was aber auch nichts heißen mag. Ich bin dumm und habe keine Ahnung.
Und habe offenbar Kommunikationsdefizite und bin sozial inkompatibel.

Sei's drum.
Ich wiederhole:
Wenn die meisten User hier aber nur ganz einfache Fenstermanager benutzen und möglicherweise alles aus Ports kompilieren, wird sich für diese das Problem natürlich gar nicht ergeben.
Laut Umfragen hier im Forum war das definitiv nicht so.
Die meisten User nutzten KDE!
Und ich behaupte mal, als Paket. Ich nutze nur Pakte, allerdings auch kein DE.

Deshalb kann dir womöglich niemand helfen. weil es niemand so macht, wie du das machst oder machen möchtest!
[Das ist eine der großen Erkenntnisse, wenn man man mit Freien Systemen umgeht]
Wenn du Hilfe möchtest, also nicht von mir, Gott bewahre, sondern ganz allgemein, ist es gut, wenn du verstehst, was genau du tust und welche Ergebnisse das jeweils zeitigt.
In deinen bisherigen Antworten lese ich keine eindeutige und Fehler-orientierte Vorgehensweise und obwohl ich selbst keine Ahnung habe, fällt mir das auf und ich denke, dass ich Vorschläge machen konnte, mit denen man eindeutigere Aussagen erhalten könnte. Diese Vorschläge teile ich dir mit. Keine Lösungswege.
Du kannst natürlich andere Wege gehen, aber du musst beantworten können, was du genau gestartet hast und was du womit tust, wenn fremde Leute dir helfen können sollen. Und dass bisher ein bestimmter Vefehl doch immer Erfolg hatte, ist nun mal keine wirklich gute, qualifizierte Aussage.