opS 13.1 (x86_64), KDE 4.11.5, Kernel 3.16.7-38.gba87edb-desktop
opS Leap 42.1 (x86_64) KDE Plasma 5.4.3, Qt-Vers. 5.5.1, Kernel 4.3.3-9.gda39cbd-default
w7
(grub2) boot aus sep. Bootpartition
mein 13.1 ist stabil, fit und gut
Frage 1:
starte ich Mc und wähle
opS Leap 42.1 so ist (weil verbose-mode) der “vga-Wert = 0x31a” im ablaufenden Startprotokoll ab Beginn richtig (gefunden oder eingestellt)
wähle opS 13.1 so ist (ebenso verbose) der “vga-Wert” nicht ab Beginn Startproto gefunden, erst nach Ablauf von ca. 1/3, stellt der Schirm richtig um.
> also prüfte ich /etc/sysconfig/bootloader (in 13.1) > tatsächlich steht dort DEFAULT_VGA""
(ich meine zu wissen, dass ich auch via graphisch-YaST > Eintrag /etc/sysconfig die selbe Datei modifizieren kann, nur läuft dann beim safen eine auto-bootloader-config ab was ich nicht will, denn würde aus dem Leap heraus die grub.cfg neu geschrieben so resultiert ein unschönes/unbrauchbares “Grub2-Select-Menü”, denn im Leap [ebenso wenn neuer Kernel kommt] schreibt es ständig im grub.cfg für alle Einträge [ausser w7] suche und starte Festplattenpartition von Leap mit Kernel 4.3.3-9 obwohl ich opS 13.1 wählte, den SWAP setzt es richtig > natürlich habe ich mir eine korrekte grub.cfg modifiziert und sep. gespeichert > hab ja kein Bock dies jedesmal neu zu mutieren)
ist es richtig, dass ich dort als root einfach “0x31a” hineinschreiben kann/soll > speichern, Neustart und damit ist gut?
Gilt dies dann auch gleich für Leap 42.1? (verwendet Leap die selbe …bootloader-Datei?
Frage 2:
(betrifft nur Leap 42.1, im 13.1 funkt tadellos)
> allg. Menüeinträge (Programmstart und so) bearbeiten > lege bitte neues Untermenü an > funktioniert nicht, Mc friert ein! weshalb?
meinem Leap scheint was zu fehlen oder ich bastelte irgend ein Konflikt (entweder KDE-Plasma oder Qt, oder Qt und KDE-Plasma geht das auch?, verstehe Qt nicht-etwas trolltech-SW?)
Repos OSS und Update-OSS sind aktuell.
bezüglich Frage 1: > “vga-Wert” fixen, dies habe ich gefunden und war einfach. > in Datei /boot/grub2/grub.cfg einfach bei Linie:
Loading vmlinux …
vmlinuz-3.16.xx… nach showopts > ein Leerschlag und noch den fixen vga-Wert eingeben
bezüglich Frage 2:
Menüeinträge modifizieren im Leap42.1 stürzt ab, verwende/starte ich jedoch mit dem Kernel ca. “4.1.12-1xxx” anstelle von 4.3.3-9xxx > so kann ich beim MenüEditor nicht nur ein neuer Eintrag anlegen sondern sogar das “safen” laufen lassen (jedoch auch kein Menüeintrag in ein Untermenü verschieben > Mc friert ein)
Mehrere graphische Oberfläche parallel sind doch möglich? Qt- und KDE, Gnome usw. (man soll beim Anmelde-Login einfach das eine oder andere auswählen können, ich weiss zwar noch nicht wo ich dies beim Anmeldeschirm selektieren kann, ich muss wohl zuerst das Anmelde-Login einrichten)
Ebenso wenn ich Leap42.1 starte, so startet jeweils (wohl im “was soll Autogestartet sein” zu modifizieren) ein “XKonsole-Fenster” mit X-Log. Wo ich das steuern kann, weiss ich noch nicht.
Ja, nur wird diese Datei automatisch generiert, und deine Änderungen werden deshalb beim Installieren von Updates verloren gehen.
Die richtige Stelle um die Kernel-Kommandozeile zu ändern ist /etc/default/grub (Option GRUB_CMDLINE_LINUX_DEFAULT), bzw. YaST->System->Bootloader.
Übrigens, “vga=xxx” ist schon lange veraltet, unterstützt nur VESA-Bildschirmmodi, und wird mit “Kernel Mode Setting” (KMS) das normalerweise aktiv ist außer du hast einen proprietären Grafiktreiber installiert (nvidia, fglrx), komplett ignoriert.
Du solltest vielleicht eher die “video=XXXxYYY” Option verwenden…
Übrigens: /etc/sysconfig/bootloader wird von grub2 überhaupt nicht verwendet, und von grub1 auch nur dann wenn noch kein Bootmenü vorhanden ist. Es dort zu ändern hat also absolut keinen Sinn.
bezüglich Frage 2:
Menüeinträge modifizieren im Leap42.1 stürzt ab, verwende/starte ich jedoch mit dem Kernel ca. “4.1.12-1xxx” anstelle von 4.3.3-9xxx > so kann ich beim MenüEditor nicht nur ein neuer Eintrag anlegen sondern sogar das “safen” laufen lassen (jedoch auch kein Menüeintrag in ein Untermenü verschieben > Mc friert ein)
Hm, mit mc meinst du aber schon den “Midnight Commander”? (Kommandozeilen-Dateimanager)
Ich sehe absolut keinen Zusammenhang zwischen dem MenüEditor deines Desktops und mc…
Mehrere graphische Oberfläche parallel sind doch möglich? Qt- und KDE, Gnome usw.
Ja.
(man soll beim Anmelde-Login einfach das eine oder andere auswählen können, ich weiss zwar noch nicht wo ich dies beim Anmeldeschirm selektieren kann, ich muss wohl zuerst das Anmelde-Login einrichten)
Einrichten musst du da gar nichts. Der Anmeldebildschirm sollte automatisch eine Auswahlmöglichkeit bieten den Desktop zu wählen.
Wie genau das ausschaut hängt natürlich vom benutzten Anmeldebildschirm ab…
Wenn du gar keinen Anmeldebildschirm bekommst, has to Auto-Login aktiviert (das ist der Fall bei einer neuen Installation).
In dem Fall logge einfach aus um zum Anmeldebildschirm zu kommen.
Auto-Login kannst du in YaST->Benutzer- und Gruppenverwaltung abschalten, klicke auf den “Experten-Optionen” Knopf rechts unten und wähle “Login-Einstellungen”.
Welche Sitzung beim Auto-Login verwendet wird lässt sich auch einstellen, wie genau hängt aber davon ab welchen Anmeldemanager du verwendest. Bei einer Standard Leap 42.1 KDE Installation ist das sddm, dessen Einstellungen findest du in KDE’s “Systemeinstellungen” (Starten und Beenden->Anmeldebildschirm (SDDM)).
Ebenso wenn ich Leap42.1 starte, so startet jeweils (wohl im “was soll Autogestartet sein” zu modifizieren) ein “XKonsole-Fenster” mit X-Log. Wo ich das steuern kann, weiss ich noch nicht.
Hört sich an als ob du eine “Failsafe” Sitzung benutzt, die startet automatisch eine XKonsole zur Ausgabe von Fehlermeldungen und Debugausgaben. Logge aus und wähle was anderes bzw. ändere die benutzte Sitzung für Auto-Login.
bezüglich vga-, resp. video-setting während Startprotokoll:
dass die /etc/sysconfig/bootloader manuell zu modifizieren wenig Sinn ergibt hatte ich zwischenzeitlich selbst bemerkt.
die Änderung in /boot/grub2/grub.cfg liefert mir zwar das gewünschte Resultat > jedoch wie Du schreibst, ist nur modal bis next update
Für den Hinweis zur richtigen Datei /etc/default/grub, besten Dank.
übrigens, verwende ich keine Graka/proprietäre Treiber, sondern integrierte Indel-Graphik mit zugeteiltem-RAM ca. 512MB (für mein Zeug glaub genug) und mein Bildschirm ist “älteres Zeugs” (ohne DisplayPort/HDMI-Anschluss, max.Resol.1280x1024)
bezüglich Menüeinträge modifizieren:
ich sollte mich an die übliche Terminologie halten, nein mit Mc meinte ich Maschine und nicht Midnight-Comma mc, sorry.
dies funktioniert bei mir im Leap42.1 noch nicht > PC friert ein! Weshalb weiss ich nicht.
bezüglich Qt, KDE, sddm und “XKonsole-xlog-Anwendung”:
welchen Anmeldemanager ich verwende weiss ich nicht. In YaST>Benutzer/Gruppe und so, meine ich mich im Normalfall schon zurecht zu finden.
es ist KEIN Auto-Login aktiv (Leap, evtl. fehlen irgenwelche SW-Pakete die ich wohl ursprünglich bei der Inst. gleich vorab meinte abwählen zu können).
Dein Hinweis bezüglich sddm, super, denn vor Wochen fand ich im /tmp ca. 6 sddm-Dateien, wusste nicht was die sollen und hab sie gleich mal gelöscht. :). Hat sddm nicht etwas mit “Lightweiht QML-based display manager” zu tun. Ich möchte aber kein schlanker-lightwight wie xfce usw., es sind auch keine spez. SW-Pakete dafür installiert. Ich will zuerst mal einfach KDE (und evtl. Qt sofern dies eine eigenständiges DeskEnvironm ist). Benötigt KDE etwa Qt oder könnte ich theoretisch alles mit Qt auch deinst.?)
Du schreibst, dass SDDM bei KDE > Systemeinstellungen > Starten/Beenden zu wählen sei (oder bei Verwendung dort angezeigt wird, resp. Standard ist). Ich bin gerade mit opS 13.1 hier und meine, dass ich unter KDE-Settings > Start/Beenden bereits versuchte die Einstellungen zu setzen. Ich werde es gleich noch mal verifizieren-probieren. Evtl. fehlt dafür ein SW-Paket.
Eine “failsafe-Startoption” habe ich nicht gewählt > die XKonsole mit xlog kommt trotzdem automatisch > eben etwas ist an meiner Leap-Inst. noch nicht koscher. Überhauupt, es kommt bloss ein einfacher/primitiver User-Anmeldscreen, den ich nirgendwo selektiert habe. :))
vielen Dank und beste Grüsse (i glaub i brauch ein Mocca)
Problematik Menüeinträge modifizieren:
> gelöst
KDE-Systemsettings > KDE-Dienste beim Start (Hintergrunddienste) > Dienst für Anwendungsmenüs war “nicht gestartet”. Einerseits peinlich für mich, andererseits weshalb war das bei einer Grundinst. nicht autoselected-gesetzt? > damit auch ich das kennenlerne und verifiziere!
Nachtrag bezüglich /boot/grub2/grub.cfg:
als ich diese Datei mit “vga=0a31” ausstattete, so funktionierte wie gesagt die Auflösung im Startproto (auch wieder im 13.1) ab Beginn. Was ich jetzt mit Konsultation von /etc/default/grub erkannte > es generierte eine grub.old (evtl. durch Neustart) und schrieb ohne mein Zutun in die Datei /etc/default/grub den vga-Wert welchen ich in /boot/grub2/grub.cfg einfügte (oder sonst war es via YaST > Bootloader, schrieb Bootloader-Settings neu).
Soeben konnte ich noch ein Patch (openSUSE 2016-45) einspielen lassen (von wegen verwende für jeden OS-Select-Menüeintrag dieselbe root-Partition und denselben Kernel). Dies habe ich oder ist jetzt ebenfalls auch gelöst.
es verbleibt mir vorerst noch dieses Anmeldemanager-Problem (mit der xconsole@…)
> KDE > Systemsettings > Anmelde/Beende > Autostart (automatisch zu startende Anwendungen), dort steht bloss:
Einrichtungs-Datei (.desktop)
Skriptdatei
ich meine das dies “standardmässig” und richtig ist, weiss es aber nicht?
zuvor (vor Tagen) fror mir bei nahezu allen Anwendungen der PC ein. Mit YaST im Textmodus konnte ich erstmals etliche Updates einspielen und jetzt friert er auch nicht mehr ein wenn ich YaST-grafisch nutze.
mein Anmeldeschirm sieht etwa so aus:
Hintergrund grau
oben openSUSE-Logo
Welcome at dhcp…, Login:
unten links die xconsole log for dhcp…
Tja, dann sollte meines Wissens nach “vga=” überhaupt keine Wirkung zeigen.
Außer du verwendest auch “nomodeset”, was im Endeffekt den Intel-Grafiktreiber abschaltet.
Vermutlich nicht die beste Idee…
Kann sein dass das in 13.1 noch anders war, ich glaube aber nicht, vor allem wenn du Kernel 4.3.3 verwendest.
bezüglich Menüeinträge modifizieren:
ich sollte mich an die übliche Terminologie halten, nein mit Mc meinte ich Maschine und nicht Midnight-Comma mc, sorry.
dies funktioniert bei mir im Leap42.1 noch nicht > PC friert ein! Weshalb weiss ich nicht.
Also bei “Mc” denke ich wirklich nicht an “Maschine”, sorry.
“Midnight Commander” war für mich das naheliegendste, weil sowohl das Paket, als auch der Startbefehl “mc” heißen.
Dann verdeutliche bitte trotzdem, was das Problem ist. Also mit “Menüeditor” meinst du den von KDE, mit dem du die Einträge im Anwendungsmenü bearbeiten kannst, richtig?
Wenn du da was änderst und auf OK klickst, friert das System komplett ein? Oder was passiert genau?
Probier mal einen neuen Benutzer, oder lösche den Ordner ~/.cache/, bzw. im speziellen die Dateien ~/.cache/ksycoca* (dort cached KDE alle Menüeinträge um schneller darauf zugreifen zu können)
bezüglich Qt, KDE, sddm und “XKonsole-xlog-Anwendung”:
welchen Anmeldemanager ich verwende weiss ich nicht.
Bei einer Leap KDE Installation ists normalerweise SDDM, wenn du von einer früheren KDE Installation upgegradet hast, ists vermutlich kdm.
Sh. /etc/sysconfig/displaymanager, im Zweifelsfall kannst du ja ein Foto posten bzw. das Aussehen beschreiben.
In YaST>Benutzer/Gruppe und so, meine ich mich im Normalfall schon zurecht zu finden.
es ist KEIN Auto-Login aktiv (Leap, evtl. fehlen irgenwelche SW-Pakete die ich wohl ursprünglich bei der Inst. gleich vorab meinte abwählen zu können).
Ok, vielleicht hast du ja den Anmeldebildschirm abgewählt, dann wird Xorg’s Fallback xdm verwendet, der tatsächlich keine Auswahlmöglichkeit bietet.
Poste also zuerst mal den Inhalt von /etc/sysconfig/displaymanager, speziell den Wert von “DISPLAYMANAGER”.
Hat sddm nicht etwas mit “Lightweiht QML-based display manager” zu tun.
Nicht ganz, SDDM ist die Abkürzung von “Simple Desktop Display Manager”…
Ich möchte aber kein schlanker-lightwight wie xfce usw., es sind auch keine spez. SW-Pakete dafür installiert. Ich will zuerst mal einfach KDE
Zuerst mal, der Anmeldebildschirm (Display Manager) hat absolut nichts mit dem Desktop Environment (KDE, XFCE, …) zu tun. Es ist eben der Anmeldebildschirm.
Aber wenn sddm nicht installiert ist, aber in /etc/sysconfig/displaymanager gesetzt ist, wird stattdessen xdm verwendet.
Ich würde dir raten sddm wieder zu installieren, dann wirst du am Anmeldebildschirm auch den gewünschten Desktop auswählen können.
Oder installier kdm und setze den in /etc/sysconfig/displaymanager, den verwendest du wahrscheinlich in 13.1.
(und evtl. Qt sofern dies eine eigenständiges DeskEnvironm ist)
Nein, ist es nicht.
Es ist ein Anwendungstoolkit, ähnlich wie GTK.
Benötigt KDE etwa Qt oder könnte ich theoretisch alles mit Qt auch deinst.?)
KDE basiert auf Qt und benötigt es, ja.
KDE4 braucht Qt4, Plasma5/KDE Frameworks5 benötigt Qt5. Und KDE3 benutzt(e) Qt3.
Du schreibst, dass SDDM bei KDE > Systemeinstellungen > Starten/Beenden zu wählen sei (oder bei Verwendung dort angezeigt wird, resp. Standard ist). Ich bin gerade mit opS 13.1 hier und meine, dass ich unter KDE-Settings > Start/Beenden bereits versuchte die Einstellungen zu setzen. Ich werde es gleich noch mal verifizieren-probieren. Evtl. fehlt dafür ein SW-Paket.
SDDM gibt es noch nicht in 13.1, daher gibt es auch das Einstellungsmodul nicht.
In Leap solltest du es aber finden.
Eine “failsafe-Startoption” habe ich nicht gewählt > die XKonsole mit xlog kommt trotzdem automatisch > eben etwas ist an meiner Leap-Inst. noch nicht koscher. Überhauupt, es kommt bloss ein einfacher/primitiver User-Anmeldscreen, den ich nirgendwo selektiert habe. :))
Wie gesagt, das ist vermutlich xdm, logisch wenn kein anderer installiert ist.
Nein, dieser Dienst wird normalerweise nicht benötigt, außer du willst die Anwendungsmenüs global am oberen Bildschirmrand oder in einem Plasmoid am Desktop haben, statt in den Anwendungsfenstern.
Allerdings wird das in Plasma5 sowieso nicht unterstützt.
Nachtrag bezüglich /boot/grub2/grub.cfg:
als ich diese Datei mit “vga=0a31” ausstattete, so funktionierte wie gesagt die Auflösung im Startproto (auch wieder im 13.1) ab Beginn. Was ich jetzt mit Konsultation von /etc/default/grub erkannte > es generierte eine grub.old (evtl. durch Neustart) und schrieb ohne mein Zutun in die Datei /etc/default/grub den vga-Wert welchen ich in /boot/grub2/grub.cfg einfügte (oder sonst war es via YaST > Bootloader, schrieb Bootloader-Settings neu).
Ja, YaST->Boot Loader speichert die Einstellungen in /etc/default/grub.
es verbleibt mir vorerst noch dieses Anmeldemanager-Problem (mit der xconsole@…)
> KDE > Systemsettings > Anmelde/Beende > Autostart (automatisch zu startende Anwendungen), dort steht bloss:
Einrichtungs-Datei (.desktop)
Skriptdatei
ich meine das dies “standardmässig” und richtig ist, weiss es aber nicht?
Das ist das falsche Modul.
Wie angedeutet, die xconsole wird nicht von KDE gestartet.
Wechsle den Anmeldebildschirm zu kdm oder sddm (oder jeden anderen den du willst), und stell sicher dass nicht “failsafe” ausgewählt ist, dann sollte die xconsole “verschwinden”.
zuvor (vor Tagen) fror mir bei nahezu allen Anwendungen der PC ein. Mit YaST im Textmodus konnte ich erstmals etliche Updates einspielen und jetzt friert er auch nicht mehr ein wenn ich YaST-grafisch nutze.
Hört sich nach einem Grafiktreiberproblem an.
Wenn jetzt alles passt, scheints von einem Update behoben worden sein…
mein Anmeldeschirm sieht etwa so aus:
Hintergrund grau
oben openSUSE-Logo
Welcome at dhcp…, Login:
unten links die xconsole log for dhcp…
Ja, das hört sich nach xdm an.
muss jetzt wohl im KDE-Settings und dem YaST2 den Anmeldeschirm einrichten.
Here you can set the default Display manager (kdm/xdm/gdm/wdm/entrance/console).
all changes in this file require a restart of the displaymanager
DISPLAYMANAGER=“sddm”
Type: yesno
Default: no
Allow remote access (XDMCP) to your display manager (xdm/kdm/gdm). Please note
that a modified kdm or xdm configuration, e.g. by KDE control center
will not be changed. For gdm, values will be updated after change.
XDMCP service should run only on trusted networks and you have to disable
firewall for interfaces, where you want to provide this service.
DISPLAYMANAGER_REMOTE_ACCESS=“no”
Type: yesno
Default: no
Allow remote access of the user root to your display manager. Note
that root can never login if DISPLAYMANAGER_SHUTDOWN is “auto” and
System/Security/Permissions/PERMISSION_SECURITY is “paranoid”
DISPLAYMANAGER_ROOT_LOGIN_REMOTE=“no”
Type: yesno
Default: yes
Let the displaymanager start a local Xserver.
Set to “no” for remote-access only.
Set to “no” on architectures without any Xserver (e.g. s390/s390x).
DISPLAYMANAGER_STARTS_XSERVER=“yes”
Type: yesno
Default: no
TCP port 6000 of Xserver. When set to “no” (default) Xserver is
started with “-nolisten tcp”. Only set this to “yes” if you really
need to. Remote X service should run only on trusted networks and
you have to disable firewall for interfaces, where you want to
provide this service. Use ssh X11 port forwarding whenever possible.
DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN=“no”
Type: string
Default:
Define the user whom should get logged in without request. If string
is empty, display standard login dialog.
DISPLAYMANAGER_AUTOLOGIN=""
Type: yesno
Default: no
Allow all users to login without password, but ask for the user, if
DISPLAYMANAGER_AUTOLOGIN is empty.
DISPLAYMANAGER_PASSWORD_LESS_LOGIN=“no”
Type: yesno
Default: no
Display a combobox for Active Directory domains.
DISPLAYMANAGER_AD_INTEGRATION=“no”
Type: list(root,all,none,auto)
Default: auto
Determine who will be able to shutdown or reboot the system in kdm. Valid
values are: “root” (only root can shutdown), “all” (everybody can shutdown),
“none” (nobody can shutdown from displaymanager), “auto” (follow
System/Security/Permissions/PERMISSION_SECURITY to decide: “easy local” is
equal to “all”, everything else is equal to “root”). gdm respects the
PolicyKit settings for ConsoleKit. Shutdown configuration can be done via
the polkit-default-privs mechanism.
DISPLAYMANAGER_SHUTDOWN=“all”
also sind, resp. waren die sddm-Pakete nicht installed
> habe ich nachgeholt (wollte ich mit YaST2 mache, aber PC wieder eingefrore, resp. Plasma abgesturzt) somit via YaST im Textmodi plus Neustart
SW-Pakete sind:
kcm_sddm
kcm_sddm-lang
sddm
sddm-branding-openSUSE
alle von Leap42.1 Update-OSS (daher wurde noch automatisch von Leap42.1 Distro-OSS notwendiges mitselektioniert)
das sddm, resp. Anmeldemanager-Problem scheint gelöst, denn tatsächlich, ein neuer Anmeldemanger ist verfügbar (mit den Optionen: Plasma5, KDE PlasmaWorkspace und TWM) doch jetzt wieder PC friert beim starten von Anwendungen ein! Weshalb? (klar i ben zu blöd)
Wie füge ich hier ein Bild/Snapshot (Plasma-Absturzmeldung, doch irgend mit … ) ein? mein Browser: Konqueror und der WYSG-irgendwas-Editor ist in diesem Forum aktiviert. Absturzmeldung in Worten:
Es tut uns sehr leid; das Programm Plasma wurde unerwartet beendet (sie können uns mal …)
Ausführbare Datei: plasmashell PID: 1816 Signal: Segmentation fault (11)****
jetzt geht auf einmal fast alles, auch im Plasma5einzig das Symbol für Kwrite ist im Anwendungsmenü verschwunden (auch für Kate gibts keines unter Symbole > Programme)ist ja nur noch ein Symbolsatz-Problem oder so :)TWM ist etwas Besonderes (am linken Rand erscheint dann so ein Menü), wohl nix für mich.Besten Dank und gute Woche.
[QUOTE=Alexander_Search;2749363]Wie füge ich hier ein Bild/Snapshot (Plasma-Absturzmeldung, doch irgend mit …
Du musst das Bild auf irgendeinem öffentlich zugänglichen Ort ablegen (es gibt diverse sharing/pasting sites genau dafür, z.B. paste.opensuse.org), dann kannst du den entsprechenden Link entweder hier einfach posten, oder ihn in
Komisch. Eigentlich sind “KDE Plasma Workspace” und “Plasma 5” exakt das selbe (bis auf den Namen). Das erstere existiert nur um Probleme bei Upgrades von KDE4 (dessen Desktopsitzung ebenfalls “KDE Plasma Workspace” hieß) zu vermeiden.
D.h. eigtl. sollten entweder beide funktionieren, bzw. beide das gleiche Problem haben.
Andererseits haben auch schon andere Benutzer eine ähnliche Erfahrung gepostet, also dürfte was dran sein. Ich habe aber keine Ahnung warum das so sein sollte (wie gesagt, der einzige Unterschied ist der Name), und hab hier auch kein Problem mit irgendeinem von den beiden.
Jedenfalls würd ich sagen: wenn du mit “KDE Plasma Workspace” keine Probleme hast, mit “Plasma5” aber schon, bleibe eben bei “KDE Plasma Workspace”.
Beide starten den selben Desktop mit den selben Einstellungen.
TWM ist ein extrem alter und simpler “Desktop”, sollte aber auch in jedem Fall problemlos laufen, selbst wenn z.B. KDE den Dienst versagt. Ist für den Notfall gedacht. https://de.wikipedia.org/wiki/Twm
Nur eins noch: da ja scheinbar der vga=xxx Kernelparameter bei dir funktioniert, könnte es sein dass du gar nicht den Inteltreiber benutzt. Genau das könnte aber auch Probleme verursachen, bzw. ist auch nicht unbedingt empfehlenswert.
Schau also bitte mal nach welcher Treiber jetzt tatsächlich läuft. Z.B. in KInfozentrum, oder YaST, oder /var/log/Xorg.0.log oder mit “glxinfo|grep render”.
Jetzt bin ich mit Leap42.1 und Konqueror hier (soweit friert noch nichts ein, starte ich den Anwendungsmenü-Editor > so vermute ich, dass PC wieder einfrieren wird und zwar unabhängig von Plasma5 oder KDE-Plasma-Workspace, war nur kurz anscheinend i.O., wie du schreibst beide gleich und deswegen friert auch ab und wann bei beiden das DesktopEnvironm ein)
KDE-Infozentrum > Grafik: OpenGL > Renderer “Mesa DRI Intel Hswell”, Vers. “3.0 Mesa 11.0.8”, Kernel Modul “unbekannt” (ist ein i3 mit HD-Grafik 4400 onboard)
X-Server > “Vers. 11.0”
und im log sieht es auch nicht so unstimmig aus:
verwendet “VT 7”, LoadModule “glx”, AIGLX enabled, LoadModule “intel”
DRI-driver: i965
VDPAU-driver: i965
rendering: DRI enabled
und am Schluss backt Xorg auch noch eine robuste, für meinen Schirm richtige Auflösung
AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
AIGLX: enabled GLX_ARB_create_context_robustness
AIGLX: Loaded and initialized i965
GLX: Initialized DRI2 GL provider for screen 0
intel(0): switch to mode 1280x1024@60.0 on VGA1 using pipe 0, position (0, 0), rotation normal, reflection none
ich vermute, dass grafisch kein grundlegendes Problem vorliegt
Der Intel-Treiber ist in Verwendung, ja.
Allerdings hat (bzw. hatte) der einen argen Bug, der auf bestimmten Systemen unter anderem Abstürze von Plasma5 und anderen Anwendungen die OpenGL verwenden verursachen konnte.
Es wäre vielleicht einen Versuch wert auf die ältere (aber stabile) UXA-Beschleunigung zurückzuschalten. Dazu einfach eine Datei /etc/X11/xorg.conf.d/20-intel.conf anlegen, mit folgendem Inhalt:
Danach neu starten.
Falls es nicht hilft, lösche die Datei besser wieder, normalerweise läuft die neue SNA Beschleunigung besser, und vor allem schneller.
Ich weiß aber nicht sicher, ob die Version in Leap 42.1 davon betroffen ist oder nicht.
Und wenn ich dich richtig verstehe, hast du das Problem nur mit dem Menüeditor, richtig? Wär dann eher unwahrscheinlich dass es mit dem Grafiktreiber zusammenhängt.
Wie schonmal geschrieben, könnte es aber mit KDE’s “Systemkonfigurations-Cache” zusammenhängen, der eben u.a. die Menüeinträge enthält, und neu aufgebaut wird wenn du diese änderst.
Deswegen wäre es interessant zu wissen, ob das Problem auch mit einem frischen Benutzeraccount auftritt.
Und/oder lösche mal wie gesagt testweise den Ordner ~/.cache/, bzw. im speziellen die Dateien ~/.cache/ksycoca*.
auf eine UXA-Beschleunigung, oder generell an der Grafik möchte ich (vorerst) nicht rumfimmeln, mir scheint dies i.O. Trotzdem lieben Dank für den Tipp.
Und wenn ich dich richtig verstehe, hast du das Problem nur mit dem Menüeditor, richtig?
Nein, wollte den User-Cache mit Dolphin (as user) löschen > PC eingefroren (wobei dort gibts wohl auch Dateirechte only for root). Ich werde das nachholen aus der root-Konsole (inkl. ~/.cache/ksycoca* sofern vorhanden) sämtlichen user-Cache löschen.
Kwrite z.B. über das Anwendungsmenü (as user) gestartet, friert ebenso ein, sobald ich z.B. “Bearbeiten > einfügen/speichern/usw.” möchte. Starte ich hingegen kwrite aus der root-Konsole so meine ich dass es funktioniert. (Berechtigungsgeschichte? komisch)
danach setze ich mal sämtliche Einstellungen > KDE > Systemeinstellungen soweit möglich (dies habe/konnte ich im Leap weitgehenst noch nicht gemacht, Systemschrift, Design, usw.) plus Neustart.
Deswegen wäre es interessant zu wissen, ob das Problem auch mit einem frischen Benutzeraccount auftritt.
danach (falls erforderlich), werde ich einen zusätzlichen User anlegen
Sollte nicht so sein. Obwohl, wenn du Dateien da drin hast die root gehören, kann genau das deine Probleme verursachen.
Das ist ein Benutzer-Cache.
Ich werde das nachholen aus der root-Konsole (inkl. ~/.cache/ksycoca* sofern vorhanden) sämtlichen user-Cache löschen.
Wenn du als root angemeldet bist, ist ~/.cache/ natürlich der Cache für root, nicht des normalen Benutzers.
In dem Fall lösche /home/username/.cache/.
Kwrite z.B. über das Anwendungsmenü (as user) gestartet, friert ebenso ein, sobald ich z.B. “Bearbeiten > einfügen/speichern/usw.” möchte. Starte ich hingegen kwrite aus der root-Konsole so meine ich dass es funktioniert. (Berechtigungsgeschichte? komisch)
Vermutlich. Könnte auf ein Berechtigungsproblem in ~/.cache/ (des Benutzers) hindeuten.
Sollte nicht so sein. Obwohl, wenn du Dateien da drin hast die root gehören, kann genau das deine Probleme verursachen.
Das ist ein Benutzer-Cache.
Ist auch nicht so > dort gehört alles dem “user1”
Wenn du als root angemeldet bist, ist ~/.cache/ natürlich der Cache für root
das weiss ich ausnahmsweise
Vermutlich. Könnte auf ein Berechtigungsproblem in ~/.cache/ (des Benutzers) hindeuten.
Nein, damit gibts kein Problem
ein Zwischenbericht:
~/.cache/ksycoca* (des “user1”) habe ich gelöscht
“user1” besitzt in ~/.config/session/ eine Datei “Kwin_1011acc9ede000…402732” (ist irgend eine Kwin-Fensterverhalten-Datei)
“user1” besitzt in ~/.config/ eine Datei “plasma-locale-settings.sh” (sollte wohl kein Problem darstellen)
Inzwischen habe ich ein “user2” (neuer Nutzer) angelegt (aufgrund des Einfrierens, jeweils mit YaST)
die beiden “user” besitzen verschiedene UID (was doch sein muss, user1 ca. 1417 und user2 ca. 1000) und beide sind Mitglied der Gruppe users
im ~/ des “user1” (der mal bei dieser mal bei der anderen Anwendung einfriert) gibt es:
~/.java (sollte soweit noch kein Problem darstellen, jedoch im ~/ des “user2” gibt es noch kein .java-Ordner, liegt wohl daran, dass ich als “user2” noch kein libreOffice/Calligra gestartet habe, resp. noch keine Office-Einrichtung-Optionen angewählt habe)
~/.recently-used (was wohl auch normal ist)
~/.hugin (diese SW-Pakete habe ich deinst. und somit kann ich diesen Ordner getrost löschen, denn dies kommt noch vor der Deinst. der Hugin-Pakete)
beim “user1” hatte ich die Ordner Öffentlich, public_html und Vorlagen gelöscht (sind keine Speicherorte in > KDE > Systemeinstellungen, somit kein Problem)
interessanter ist wohl folgendes
~/.ptbt0 (eine Datei, geöffnet mit Kwrite > steht eine 1 und sonst nix > werde ich löschen)
~/.xdg_menu_cache (könnte dies ein Blocker-Einfrierer sein?)
“user2” besitzt all die vorab erwähnten Dateien/Ordner nicht (dafür Folgende)
die Ordner Öffentlich, public_html, Vorlage (=standard)
und eine Datei ~/.gnu-emacs (“user1” besitzt die nicht, hingegen besitzen beide ~/.emacs)
Inzwischen funktioniert das Anwendungs-Menü-Editieren bei beiden usern relativ stabil (meist i.O.) und erfreulicherweise funktioniert YaST2 bei “user2” 100% und bei “user1” inzwischen glaub auch, bin mir jedoch nicht sicher.
Dolphin als Super-User fror auch beim “user2” ein!
beim Einrichten von Konqueror als “user2” fror der PC ebenfalls ein!
> KDE > Systemeinstellungen sind inzwischen bei beiden sehr ähnlich (Oxygen-Design, Plastik-Fenster, Systemschrift/Schriften Nimbus Sans L, Standardanwendungen für Dateiverwaltung/Mail/Browsen/ usw.)
ich habe noch keine Desktop-Oberfläche für root eingerichtet und auch nicht im Anmeldemanager gelistet, Anmeldemanager funktioniert ganz gut.
ich muss bei “user2” zuerst noch weiter einrichten. z.B. Konqueror-Profile, Unterordner und Einträge für das Anwendungsstartmenü angleichen (Symbolsatz-Zeug ist kein Problem)
interessant ist noch dies:
im /tmp sind immer noch diese Dateien
> sddm-i0-jkhpuB
> sddm-auth… (davon ca. 18 Stk., heute und gestern generiert)
die kann ich obwohl der Anmeldemanager inzwische funktioniert noch nicht löschen, oder doch?
und im / sind noch
> klauncherXMxxxxxx.1.slave-socket (0 Byte Dateien, 4 Stk. von heute und 2 vom 14.1.2016, davon sollte es pro user und root doch max. eine geben, wenn überhaupt?)
und last bot not least
im Startprotokoll läuft ein “a job-stop is running” dauert ca. 2-3 sec. > das ist nicht koscher.
Also doch nicht?
Oder hast du inzwischen alles gelöscht?
“user1” besitzt in ~/.config/session/ eine Datei “Kwin_1011acc9ede000…402732” (ist irgend eine Kwin-Fensterverhalten-Datei)
Kannst du löschen, sollte aber auch kein Problem darstellen.
Das sind die Dateien von der Sitzungsverwaltung, wo die Anwendungen beim Logout ihren aktuellen Status speichern.
“user1” besitzt in ~/.config/ eine Datei “plasma-locale-settings.sh” (sollte wohl kein Problem darstellen)
Nein, das setzt die Benutzersprache.
im ~/ des “user1” (der mal bei dieser mal bei der anderen Anwendung einfriert) gibt es:
~/.java (sollte soweit noch kein Problem darstellen, jedoch im ~/ des “user2” gibt es noch kein .java-Ordner, liegt wohl daran, dass ich als “user2” noch kein libreOffice/Calligra gestartet habe, resp. noch keine Office-Einrichtung-Optionen angewählt habe)
Ja. Oder irgendeine andere Java-Anwendung.
~/.recently-used (was wohl auch normal ist)
Beinhaltet zuletzt geöffnete Dokumente/Programme, wird aber von KDE nicht verwendet soweit ich weiß.
~/.hugin (diese SW-Pakete habe ich deinst. und somit kann ich diesen Ordner getrost löschen, denn dies kommt noch vor der Deinst. der Hugin-Pakete)
Richtig. Aber sollte auch keine Probleme in KDE verursachen.
beim “user1” hatte ich die Ordner Öffentlich, public_html und Vorlagen gelöscht (sind keine Speicherorte in > KDE > Systemeinstellungen, somit kein Problem)
Sollten auch keine Probleme verursachen.
Übrigens, sie würden sowieso automatisch angelegt wenn sie in KDE’s Systemeinstellungen als Speicherorte festgelegt wurden…
interessanter ist wohl folgendes
~/.ptbt0 (eine Datei, geöffnet mit Kwrite > steht eine 1 und sonst nix > werde ich löschen)
Keine Ahnung was das sein könnte, wird aber sicher nicht von KDE verwendet. Ich hab sie auf meinem System jedenfalls nicht.
~/.xdg_menu_cache (könnte dies ein Blocker-Einfrierer sein?)
Theoretisch könnte das sein. Da es nur ein Cache des Anwendungsmenü ist, kannst du den Ordner bedenkenlos löschen.
Bin mir nicht sicher, aber ich glaube dass das von KDE eher auch nicht verwendet wird (KDE hat ja sowieso seinen eigenen Cache).
“user2” besitzt all die vorab erwähnten Dateien/Ordner nicht (dafür Folgende)
die Ordner Öffentlich, public_html, Vorlage (=standard)
und eine Datei ~/.gnu-emacs (“user1” besitzt die nicht, hingegen besitzen beide ~/.emacs)
Ist aber auch nur eine Einstellungsdatei für Emacs, irrelevant für KDE.
Inzwischen funktioniert das Anwendungs-Menü-Editieren bei beiden usern relativ stabil (meist i.O.) und erfreulicherweise funktioniert YaST2 bei “user2” 100% und bei “user1” inzwischen glaub auch, bin mir jedoch nicht sicher.
Ist ja zumindest ein Fortschritt.
YaST läuft als root, sollte also egal sein unter welchem Benutzer du es ausführst.
Dolphin als Super-User fror auch beim “user2” ein!
beim Einrichten von Konqueror als “user2” fror der PC ebenfalls ein!
Hm. Konqueror ist eine KDE4 Anwendung, die Caches sind in /var/tmp/kde-user1 oder ähnlich.
Lösche die auch mal, eigtl. kannst du alles in /tmp/ oder /var/tmp/ löschen.
Aber so ein Problem in KDE4 wär mir neu.
> KDE > Systemeinstellungen sind inzwischen bei beiden sehr ähnlich (Oxygen-Design, Plastik-Fenster, Systemschrift/Schriften Nimbus Sans L, Standardanwendungen für Dateiverwaltung/Mail/Browsen/ usw.)
Ich habe davon gehört das gewisse Leute mit der Plastik Dekoration Probleme hatten (Abstürze).
Probier mal was anders (Breeze oder Oxygen), vielleicht hilfts.
interessant ist noch dies:
im /tmp sind immer noch diese Dateien
> sddm-i0-jkhpuB
> sddm-auth… (davon ca. 18 Stk., heute und gestern generiert)
die kann ich obwohl der Anmeldemanager inzwische funktioniert noch nicht löschen, oder doch?
Sind temporäre Dateien, und werden vom Anmeldemanager angelegt.
und im / sind noch
> klauncherXMxxxxxx.1.slave-socket (0 Byte Dateien, 4 Stk. von heute und 2 vom 14.1.2016, davon sollte es pro user und root doch max. eine geben, wenn überhaupt?)
Nein, die werden immer angelegt wenn du ein KDE5 Programm als root startest. Ist ein Bug, würde ich sagen, aber ein harmloser.
und last bot not least
im Startprotokoll läuft ein “a job-stop is running” dauert ca. 2-3 sec. > das ist nicht koscher.
2-3 Sekunden ist ja nicht so viel.
Ob das koscher ist oder nicht, hängt davon ab was für ein Dienst das ist.
Du siehst also, 2-3 Sekunden ist nicht wirklich ungewöhnlich, hängt eben vom Dienst ab und natürlich auch von deinem System.
Die Dienste werden sowieso parallel gestartet, also verzögert das auch nicht unbedingt den Bootvorgang.
ich werds hinkriegen, vielen Dank.
Ich hoffe doch…
Da fällt mir ein: lösche auch mal ~/.kde4/share/apps/kbookmarks/, ~/.local/share/kbookmarks/ und ~/.local/share/user-places.xbel, die enthalten die Benutzer-“Orte” für dolphin und dem Dateidialog.
Es gab Fälle wo die immer größer wurden (Gigabytes), und Dolphin/Konqueror oder sogar Plasma zum Absturz bzw. Einfrieren brachten.
