[opensuse] Failing to get login screen or desktops
Hi - I kinda suspect a recent batch of update did not go well with one of my computers and my efforts to research and figure out what has gone wrong are failing, so once again I am in need of the assistance of the openSuSE/KDE gurus... I am running openSuSE 42.2 x64, my displaymanager is set to sddm and my windowmanager is set to kde4. My system is booting up OK and all of my system services run fine, the only thing wrong is that I do not get a login screen, or a desktop. It simply comes up with a black screen. I can do a CTRL-ALT F3 to bring up a single shell console but so far no joy in getting my desktop or any graphical process to work. FWIW my video is built in to my motherboard and is the Intel HD Graphics 530. Xorg.0.log is giving me the following ominous message that to my untrained eyes seem bad but I don't know what they mean.. bigbang:/var/log # cat Xorg.0.log | grep EE (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 547.062] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied [ 547.067] (EE) Screen 0 deleted because of no matching config section. [ 547.067] (EE) Screen 0 deleted because of no matching config section. [ 547.067] (EE) [ 547.067] (EE) Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices [ 547.067] (EE) and in the warn log I found the following ominous messages that also don't seem to bod well... 2017-07-18T13:34:37.744641-07:00 bigbang sddm-helper[3034]: Could not open stderr to ".xsession-errors" 2017-07-18T13:34:37.946289-07:00 bigbang sddm[2949]: Auth: sddm-helper exited with 11 2017-07-18T13:34:39.707022-07:00 bigbang systemd-coredump[3040]: Process 3034 (sddm-greeter) of user 483 dumped core. There is a .xsessions-errors file in my home directory. In my efforts to resolve this, I did try fooling around with different display and window managers but so far no joy getting anything that resembles a graphical desktop. With some combinations I did get a popup dialog saying - could not start kdeinit5. check the installation but clicking on the OK button to dismiss the dialog simply results in a black/blank screen. So this is where I have gotten to... Googling is showing me lots of people are having similar/related problems on other distros, but no joy so far in finding a solution or anything relevant to exactly what I am experiencing... Thanks again in advance for any and all offers to help and I will be happy to provide any additional info, log files, config files etc... Marc... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Marc Chamberlin <marc@marcchamberlin.com> [07-18-17 17:39]:
Hi - I kinda suspect a recent batch of update did not go well with one of my computers and my efforts to research and figure out what has gone wrong are failing, so once again I am in need of the assistance of the openSuSE/KDE gurus...
I am running openSuSE 42.2 x64, my displaymanager is set to sddm and my windowmanager is set to kde4. My system is booting up OK and all of my system services run fine, the only thing wrong is that I do not get a login screen, or a desktop. It simply comes up with a black screen. I can do a CTRL-ALT F3 to bring up a single shell console but so far no joy in getting my desktop or any graphical process to work.
FWIW my video is built in to my motherboard and is the Intel HD Graphics 530.
Xorg.0.log is giving me the following ominous message that to my untrained eyes seem bad but I don't know what they mean..
bigbang:/var/log # cat Xorg.0.log | grep EE (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 547.062] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied [ 547.067] (EE) Screen 0 deleted because of no matching config section. [ 547.067] (EE) Screen 0 deleted because of no matching config section. [ 547.067] (EE) [ 547.067] (EE) Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices [ 547.067] (EE)
and in the warn log I found the following ominous messages that also don't seem to bod well...
2017-07-18T13:34:37.744641-07:00 bigbang sddm-helper[3034]: Could not open stderr to ".xsession-errors" 2017-07-18T13:34:37.946289-07:00 bigbang sddm[2949]: Auth: sddm-helper exited with 11 2017-07-18T13:34:39.707022-07:00 bigbang systemd-coredump[3040]: Process 3034 (sddm-greeter) of user 483 dumped core.
There is a .xsessions-errors file in my home directory.
In my efforts to resolve this, I did try fooling around with different display and window managers but so far no joy getting anything that resembles a graphical desktop. With some combinations I did get a popup dialog saying -
could not start kdeinit5. check the installation
this is probably the problem, you said you are running kde4 and kdeinit5 is from plasma5/kde5
but clicking on the OK button to dismiss the dialog simply results in a black/blank screen.
So this is where I have gotten to... Googling is showing me lots of people are having similar/related problems on other distros, but no joy so far in finding a solution or anything relevant to exactly what I am experiencing...
Thanks again in advance for any and all offers to help and I will be happy to provide any additional info, log files, config files etc... Marc...
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Patrick Shanahan composed on 2017-07-18 18:13 (UTC-0400):
Marc Chamberlin composed:
FWIW my video is built in to my motherboard and is the Intel HD Graphics 530. ... I think that equates to Skylake.
Xorg.0.log is giving me the following ominous message that to my untrained eyes seem bad but I don't know what they mean.. ... bigbang:/var/log # cat Xorg.0.log | grep EE (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 547.062] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied ... could not start kdeinit5. check the installation
this is probably the problem, you said you are running kde4 and kdeinit5 is from plasma5/kde5
kdeinit can't run because Xorg won't run. "(EE) /dev/dro/card0: failed..." is a fatal Xorg error. OP just worked through a kernel update problem in another thread. In the process it's possible Grub2 and/or initrd got badly reconfigured. We need to know his 'cat /proc/cmdline' output, if not see his entire Xorg.0.log, dmesg and journal to find more clues. It could be nomodeset found its way onto the cmdline, which blocks use of any Xorg driver supported with Intel gfxchips. Is the problem the same booting the previous (4.4.73) kernel? Did the just completed reinstallation and/or updates rebuild both/all initrds? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Patrick Shanahan composed on 2017-07-18 18:13 (UTC-0400):
Marc Chamberlin composed:
FWIW my video is built in to my motherboard and is the Intel HD Graphics 530. ... I think that equates to Skylake.
Xorg.0.log is giving me the following ominous message that to my untrained eyes seem bad but I don't know what they mean.. ... bigbang:/var/log # cat Xorg.0.log | grep EE (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 547.062] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied ... could not start kdeinit5. check the installation this is probably the problem, you said you are running kde4 and kdeinit5 is from plasma5/kde5 Um I will respond to Patrick's thoughts here, instead of in a separate reply... I am using the ncurses version of Yast2 to configure my display and window managers. AFAIK from my Googling, plasma5 is part of
On 07/18/2017 03:42 PM, Felix Miata wrote: the sddm display manager and SDDM seems to be the setting recommended on most of the websites I visited, to use as the display manager. There isn't any settings under either the DISPLAYMANGER or DEFAULT_WM that allow me to select "plasma5". Ditto for "kde5", under DEFAULT_WM I can only select either KDE or KDE4 if I want to use a KDE window manager. I tried both, and on a lark I also typed in KDE5 for the setting, but no joy on any of these... Please advise me on exactly what I should set these two parameters to and/or if I am misunderstanding these settings.
kdeinit can't run because Xorg won't run. "(EE) /dev/dro/card0: failed..." is a fatal Xorg error.
OP just worked through a kernel update problem in another thread. In the process it's possible Grub2 and/or initrd got badly reconfigured. We need to know his 'cat /proc/cmdline' output, Hi Felix, and thanks for replying! OK this request is easy to satisfy -
bigbang:/home/marc # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.4.74-18.20-default root=UUID=ebf32d3d-bbdd-4d70-99e5-c15735bcd81d ro resume=/dev/disk/by-uuid/befcf2d3-8c2c-484b-a196-55be5744a24f splash=silent quiet showopts
if not see his entire Xorg.0.log, dmesg and journal to find more clues. It could be nomodeset found its way onto the cmdline, which blocks use of any Xorg driver supported with Intel gfxchips. Oh wow! I think you are a gluten for punishment! LOL I am not sure how to send you, or the list that much info... Let me know what is best or how to trim it down....
Is the problem the same booting the previous (4.4.73) kernel? Yeah, I tried booting with the previous kernel to see if the desktop would come up, and it didn't... So something that is common to both is now broken... Did the just completed reinstallation and/or updates rebuild both/all initrds? And you just went above my pay grade, I dunno how to answer this..... Marc...
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Marc Chamberlin composed on 2017-07-18 16:30 (UTC-0700):
Felix Miata wrote: ... AFAIK from my Googling, plasma5 is part of the sddm display manager and SDDM seems to be the setting recommended on
All my Plasma 5 installations have either KDM or KDM3, neither lightdm nor sddm anywhere. For the 42.3 I did for my neighbor done Saturday night it's KDM3.
most of the websites I visited, to use as the display manager. There isn't any settings under either the DISPLAYMANGER or DEFAULT_WM that allow me to select "plasma5". Ditto for "kde5", under DEFAULT_WM I can only select either KDE or KDE4 if I want to use a KDE window manager. I tried both, and on a lark I also typed in KDE5 for the setting, but no joy on any of these... Please advise me on exactly what I should set> these two parameters to and/or if I am misunderstanding these settings.
Edit /etc/sysconfig/displaymanager and /etc/sysconfig/windowmanager directly. They are supposedly self-documenting, although the displaymanager I'm looking at ATM on TW, with kdm-4.11.22, for DISPLAYMANAGER= lists neither lightdm nor sddm as options; mine has "kdm" set. For Plasma 5 to be default set "kde-plasma" as DEFAULT_WM= in windowmanager.
...bigbang:/home/marc # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.4.74-18.20-default root=UUID=ebf32d3d-bbdd-4d70-99e5-c15735bcd81d ro resume=/dev/disk/by-uuid/befcf2d3-8c2c-484b-a196-55be5744a24f splash=silent quiet showopts
Hmmm, then your problem probably nothing to do with modesetting. You could try the other Xorg driver, but I do think '(EE) /dev/dri/card0' would apply to either. Xorg.0.log tells you which driver is in use, the large multiplicity of lines with INTEL(0) say intel driver, while MODESET(0) say integral modesetting driver in use. As long as mesa and kernel modesetting are not broken, Xorg will use intel if xf86-video-intel is installed, the integral driver if it is not. Probably we need to see more of Xorg.0.log....
if not see his entire Xorg.0.log, dmesg and journal to find more clues. It could be nomodeset found its way onto the cmdline, which blocks use of any Xorg driver supported with Intel gfxchips.
Oh wow! I think you are a gluten for punishment! LOL I am not sure how to send you, or the list that much info... Let me know what is best or how to trim it down....
A brief start would be journalctl | grep fail and dmesg ! grep fail For voluminous things like Xorg.0.log, journal or full dmesg, share via pastebin, either install (if it isn't already) and use the susepaste command, or use http://susepaste.org/ or http://pastebin.com/ or one of the many others, or the web space provided by your ISP.
Is the problem the same booting the previous (4.4.73) kernel? Yeah, I tried booting with the previous kernel to see if the desktop would come up, and it didn't... So something that is common to both is now broken...
:-( Is there also an older kernel than 4.4.73?
Did the just completed reinstallation and/or updates rebuild both/all initrds?
And you just went above my pay grade, I dunno how to answer this.....
Are the timestamps on /boot/initrd* all fresh? If there is one that is not, can you boot from its kernel and not have the black screen problem? What if anything does /var/lib/systemd/coredump/ contain? Is everything that is there timestamped since you did your updating? Does 'startx -- :1' from vtty login, either normally or as root, avoid the black screen? (I'm guessing not.) What about 'WINDOWMANAGER=/usr/bin/icewm startx -- :1'? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-19 03:26, Felix Miata wrote:
Marc Chamberlin composed on 2017-07-18 16:30 (UTC-0700):
Does 'startx -- :1' from vtty login, either normally or as root, avoid the black screen? (I'm guessing not.)
What about 'WINDOWMANAGER=/usr/bin/icewm startx -- :1'?
I would try that, specially the second one. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Marc Chamberlin composed on 2017-07-18 16:30 (UTC-0700):
Felix Miata wrote: ... AFAIK from my Googling, plasma5 is part of the sddm display manager and SDDM seems to be the setting recommended on All my Plasma 5 installations have either KDM or KDM3, neither lightdm nor sddm anywhere. For the 42.3 I did for my neighbor done Saturday night it's KDM3.
most of the websites I visited, to use as the display manager. There isn't any settings under either the DISPLAYMANGER or DEFAULT_WM that allow me to select "plasma5". Ditto for "kde5", under DEFAULT_WM I can only select either KDE or KDE4 if I want to use a KDE window manager. I tried both, and on a lark I also typed in KDE5 for the setting, but no joy on any of these... Please advise me on exactly what I should set> these two parameters to and/or if I am misunderstanding these settings. Edit /etc/sysconfig/displaymanager and /etc/sysconfig/windowmanager directly. They are supposedly self-documenting, although the displaymanager I'm looking at ATM on TW, with kdm-4.11.22, for DISPLAYMANAGER= lists neither lightdm nor sddm as options; mine has "kdm" set. For Plasma 5 to be default set "kde-plasma" as DEFAULT_WM= in windowmanager. Hi Felix, OK, I followed your instructions and set my DISPLAYMANAGER to kdm, and DEFAULT_WM to kde-plasma. Upon reboot, I now do get a login screen but when I enter my name and password I again get the popup
On 07/18/2017 06:26 PM, Felix Miata wrote: dialog saying " Could not start kdeinit5. Check your installation. ". I cannot get any further than this, if I click on OK it just represents me with the login screen and this cycle repeats. CTRL-ALT-F3 gets me to the command line screen....
...bigbang:/home/marc # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.4.74-18.20-default root=UUID=ebf32d3d-bbdd-4d70-99e5-c15735bcd81d ro resume=/dev/disk/by-uuid/befcf2d3-8c2c-484b-a196-55be5744a24f splash=silent quiet showopts Hmmm, then your problem probably nothing to do with modesetting.
You could try the other Xorg driver, but I do think '(EE) /dev/dri/card0' would apply to either. Xorg.0.log tells you which driver is in use, the large multiplicity of lines with INTEL(0) say intel driver, while MODESET(0) say integral modesetting driver in use. As long as mesa and kernel modesetting are not broken, Xorg will use intel if xf86-video-intel is installed, the integral driver if it is not.
Probably we need to see more of Xorg.0.log....
An interesting change has happened, I am no longer seeing the EE error messages in the Xorg.0.log file after making the changes to the DISPLAYMANAGER and DEFAULT_WM
A brief start would be journalctl | grep fail OK, here is what returned, I cut out some obvious stuff that was not applicable, such as messages about Fail2Ban, vsftpd authentication failures, smartd Prefailure attributes etc.....
bigbang:/boot # journalctl | grep "Jul 19" | grep fail Jul 19 12:29:25 bigbang dbus[1127]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.Avahi.service': Refusing activation, D-Bus is shutting down. Jul 19 12:29:38 bigbang systemd[1]: slash-websites.mount: Unit entered failed state. Jul 19 12:29:38 bigbang systemd[1]: mail.mount: Unit entered failed state. Jul 19 12:29:38 bigbang systemd[1]: SuSE42.1.mount: Unit entered failed state. Jul 19 12:29:38 bigbang systemd[1]: var-run-user-1000.mount: Unit entered failed state. Jul 19 12:29:38 bigbang systemd[1]: slash-srv.mount: Unit entered failed state. Jul 19 12:29:38 bigbang systemd[1]: home.mount: Unit entered failed state. Jul 19 12:29:38 bigbang systemd[1]: slash-data.mount: Unit entered failed state. Jul 19 12:29:38 bigbang systemd[1]: SuSE12.3.mount: Unit entered failed state. Jul 19 12:29:38 bigbang systemd[1]: slash-boot-efi.mount: Unit entered failed state. Jul 19 12:29:38 bigbang systemd[1]: slash-data1.mount: Unit entered failed state. Jul 19 12:29:38 bigbang systemd[1]: slash-var-run-user-1000.mount: Unit entered failed state. Jul 19 12:29:38 bigbang systemd[1]: slash-tmp.mount: Unit entered failed state. Jul 19 12:29:56 bigbang kernel: Ignoring BGRT: failed to map image memory Jul 19 12:29:56 bigbang kernel: acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM Jul 19 12:29:56 bigbang kernel: [drm] failed to retrieve link info, disabling eDP Jul 19 12:30:12 bigbang systemd[1]: Dependency failed for Network Manager Wait Online. Jul 19 12:30:12 bigbang systemd[1]: NetworkManager-wait-online.service: Job NetworkManager-wait-online.service/start failed with result 'dependency'. Jul 19 12:30:18 bigbang bash[1172]: channel: no 'mirrors.updates.spamassassin.org' record found, channel failed Jul 19 12:30:47 bigbang server[1855]: log4j:ERROR setFile(null,true) call failed. Jul 19 12:30:47 bigbang server[1855]: 19-Jul-2017 12:30:47.878 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal One or more Filters failed to start. Full details will be found in the appropriate container log file Jul 19 12:30:47 bigbang server[1855]: 19-Jul-2017 12:30:47.878 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal Context [/JSPWiki] startup failed due to previous errors
and
dmesg ! grep fail
bigbang:/boot # dmesg | grep fail [ 0.040310] Ignoring BGRT: failed to map image memory [ 0.252121] acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM [ 1.527930] [drm] failed to retrieve link info, disabling eDP
For voluminous things like Xorg.0.log, journal or full dmesg, share via pastebin, either install (if it isn't already) and use the susepaste command, or use http://susepaste.org/ or http://pastebin.com/ or one of the many others, or the web space provided by your ISP. I posted my Xorg.0.log file at http://susepaste.org/38204685 Enjoy! ;-)
Is the problem the same booting the previous (4.4.73) kernel? Yeah, I tried booting with the previous kernel to see if the desktop would come up, and it didn't... So something that is common to both is now broken... :-( Is there also an older kernel than 4.4.73?
No, it appears that I only have 2 kernels...
Did the just completed reinstallation and/or updates rebuild both/all initrds? And you just went above my pay grade, I dunno how to answer this..... Are the timestamps on /boot/initrd* all fresh? If there is one that is not, can you boot from its kernel and not have the black screen problem?
Here is what I see in /boot bigbang:/boot # ls -al total 54112 drwxr-xr-x 4 root root 4096 Jul 18 12:29 . drwxr-xr-x 38 root root 4096 Jul 6 16:38 .. -rw-r--r-- 1 root root 1725 Oct 7 2016 boot.readme -rw-r--r-- 1 root root 178511 Jun 24 06:32 config-4.4.73-18.17-default -rw-r--r-- 1 root root 178538 Jul 1 00:46 config-4.4.74-18.20-default drwxrwxr-x 3 root root 16384 Dec 31 1969 efi drwxr-xr-x 7 root root 4096 Jul 18 12:27 grub2 lrwxrwxrwx 1 root root 27 Jul 18 12:26 initrd -> initrd-4.4.74-18.20-default -rw------- 1 root root 9923568 Jul 14 21:15 initrd-4.4.73-18.17-default -rw------- 1 root root 9865028 Jul 18 12:27 initrd-4.4.74-18.20-default -rw-r--r-- 1 root root 500736 Dec 30 2016 message -rw-r--r-- 1 root root 1007254 Jun 24 07:28 symtypes-4.4.73-18.17-default.gz -rw-r--r-- 1 root root 1007576 Jul 1 01:18 symtypes-4.4.74-18.20-default.gz -rw-r--r-- 1 root root 356735 Jun 24 07:19 symvers-4.4.73-18.17-default.gz -rw-r--r-- 1 root root 356845 Jul 1 01:17 symvers-4.4.74-18.20-default.gz -rw-r--r-- 1 root root 377 Jun 24 07:19 sysctl.conf-4.4.73-18.17-default -rw-r--r-- 1 root root 377 Jul 1 01:17 sysctl.conf-4.4.74-18.20-default -rw-r--r-- 1 root root 3194167 Jun 24 07:07 System.map-4.4.73-18.17-default -rw-r--r-- 1 root root 3194251 Jul 1 01:13 System.map-4.4.74-18.20-default -rw-r--r-- 1 root root 6889858 Jun 24 07:29 vmlinux-4.4.73-18.17-default.gz -rw-r--r-- 1 root root 6888845 Jul 1 01:18 vmlinux-4.4.74-18.20-default.gz lrwxrwxrwx 1 root root 28 Jul 18 12:26 vmlinuz -> vmlinuz-4.4.74-18.20-default -rw-r--r-- 1 root root 5895880 Jun 24 08:14 vmlinuz-4.4.73-18.17-default -rw-r--r-- 1 root root 65 Jun 24 08:14 .vmlinuz-4.4.73-18.17-default.hmac -rw-r--r-- 1 root root 5895368 Jul 1 01:45 vmlinuz-4.4.74-18.20-default -rw-r--r-- 1 root root 65 Jul 1 01:45 .vmlinuz-4.4.74-18.20-default.hmac
What if anything does /var/lib/systemd/coredump/ contain? Is everything that is there timestamped since you did your updating?
bigbang:/boot # ls -al /var/lib/systemd/coredump/ total 2000 drwxr-xr-x 2 root root 16384 Jul 19 12:31 . drwxr-xr-x 8 root root 4096 Jul 4 09:16 .. -rw-r-----+ 1 root root 122736 Jul 19 12:31 core.kdeinit5.1000.f90aa36c75fa45f5b6925fe316117ee6.3360.1500492668000000.xz -rw-r-----+ 1 root root 269164 Jul 19 12:31 core.ksplashqml.1000.f90aa36c75fa45f5b6925fe316117ee6.3335.1500492668000000.xz -rw-r----- 1 root root 212664 Jul 18 13:43 core.sddm.0.6af6c36197af451f8c71854a8bafbc87.2949.1500410580000000.xz -rw-r----- 1 root root 169720 Jul 18 12:29 core.sddm-greeter.483.087a9332de504ef5a1140dfddca8c23b.3104.1500406176000000.xz -rw-r----- 1 root root 169560 Jul 18 14:29 core.sddm-greeter.483.516ece7fa9ad447b9ca78f10d8e98b69.3076.1500413381000000.xz -rw-r----- 1 root root 169440 Jul 18 15:42 core.sddm-greeter.483.61f03715e74749a5b47df3745f0b2157.3105.1500417723000000.xz -rw-r----- 1 root root 169728 Jul 18 13:18 core.sddm-greeter.483.6ac4b14ea0a8405e9c9c1ad0d686d345.3087.1500409127000000.xz -rw-r----- 1 root root 169548 Jul 18 13:34 core.sddm-greeter.483.6af6c36197af451f8c71854a8bafbc87.3034.1500410077000000.xz -rw-r----- 1 root root 169708 Jul 18 13:27 core.sddm-greeter.483.b9bb167aa2de4f58a10f149a1fa7c407.3058.1500409652000000.xz -rw-r----- 1 root root 169736 Jul 18 15:48 core.sddm-greeter.483.ba982bdf727a421c8a63d03b3f4c0537.3045.1500418122000000.xz -rw-r----- 1 root root 169264 Jul 18 11:33 core.sddm-greeter.483.c490cd1e96c84ea5b0cb762c7e01902c.3047.1500402826000000.xz
Does 'startx -- :1' from vtty login, either normally or as root, avoid the black screen? (I'm guessing not.)
No, it simply gave me the popup dialog error message about startx and then I lost the ability to show my key strokes... Just get output but no echo of keystrokes... But I did manage to capture the output from this startx command and saved it to a file. bigbang:/home/marc # cat startx.log xauth: file /home/marc/.serverauth.17979 does not exist X.Org X Server 1.18.3 Release Date: 2016-04-04 X Protocol Version 11, Revision 0 Build Operating System: openSUSE SUSE LINUX Current Operating System: Linux bigbang 4.4.74-18.20-default #1 SMP Fri Jun 30 19:01:19 UTC 2017 (b5079b8) x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.4.74-18.20-default root=UUID=ebf32d3d-bbdd-4d70-99e5-c15735bcd81d ro re sume=/dev/disk/by-uuid/befcf2d3-8c2c-484b-a196-55be5744a24f splash=silent quiet showopts Build Date: 14 July 2017 05:36:29PM Current version of pixman: 0.34.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/home/marc/.local/share/xorg/Xorg.1.log", Time: Wed Jul 19 13:28:32 2017 (==) Using config directory: "/etc/X11/xorg.conf.d" (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE) Fatal server error: (EE) xf86OpenConsole: Switching VT failed (EE) (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. (EE) Please also check the log file at "/home/marc/.local/share/xorg/Xorg.1.log" for additional information. (EE) VGA Arbitration: Cannot restore default device. (EE) Server terminated with error (1). Closing log file. xinit: giving up xinit: unable to connect to X server: Cannot assign requested address xinit: server error ------------------------------------------------------------------------------------------- xinit failed. /usr/bin/Xorg is not setuid, maybe that's the reason? If so either use a display manager (strongly recommended) or adjust /etc/permissions.local and run "chkstat --system -- set" afterwards
What about 'WINDOWMANAGER=/usr/bin/icewm startx -- :1'?
WINDOWMANAGER ??? Are you asking me to set DEFAULT_WM to this value, or something else? I will await your reply before I do anything. Again, thanks for helping me, I know this is a LOT of info to grok! Marc... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/19/2017 01:41 PM, Marc Chamberlin wrote:
Does 'startx -- :1' from vtty login, either normally or as root, avoid the black screen? (I'm guessing not.) No, it simply gave me the popup dialog error message about startx and
On 07/18/2017 06:26 PM, Felix Miata wrote: then I lost the ability to show my key strokes... Just get output but no echo of keystrokes... But I did manage to capture the output from this startx command and saved it to a file.
bigbang:/home/marc # cat startx.log xauth: file /home/marc/.serverauth.17979 does not exist
X.Org X Server 1.18.3 Release Date: 2016-04-04 X Protocol Version 11, Revision 0 Build Operating System: openSUSE SUSE LINUX Current Operating System: Linux bigbang 4.4.74-18.20-default #1 SMP Fri Jun 30 19:01:19 UTC 2017 (b5079b8) x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.4.74-18.20-default root=UUID=ebf32d3d-bbdd-4d70-99e5-c15735bcd81d ro re sume=/dev/disk/by-uuid/befcf2d3-8c2c-484b-a196-55be5744a24f splash=silent quiet showopts Build Date: 14 July 2017 05:36:29PM
Current version of pixman: 0.34.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/home/marc/.local/share/xorg/Xorg.1.log", Time: Wed Jul 19 13:28:32 2017 (==) Using config directory: "/etc/X11/xorg.conf.d" (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE) Fatal server error: (EE) xf86OpenConsole: Switching VT failed (EE) (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. (EE) Please also check the log file at "/home/marc/.local/share/xorg/Xorg.1.log" for additional information. (EE) VGA Arbitration: Cannot restore default device. (EE) Server terminated with error (1). Closing log file. xinit: giving up xinit: unable to connect to X server: Cannot assign requested address xinit: server error -------------------------------------------------------------------------------------------
xinit failed. /usr/bin/Xorg is not setuid, maybe that's the reason? If so either use a display manager (strongly recommended) or adjust /etc/permissions.local and run "chkstat --system -- set" afterwards
Felix - I noted that the output from the startx -- :1 made a reference to another Xorg log file - "(EE) Please also check the log file at "/home/marc/.local/share/xorg/Xorg.1.log" for additional information. " I posted this at - http://susepaste.org/84812068 HTHs Marc. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Marc Chamberlin composed on 2017-07-19 13:41 (UTC-0700):
Felix Miata wrote:
Edit /etc/sysconfig/displaymanager and /etc/sysconfig/windowmanager directly. They are supposedly self-documenting, although the displaymanager I'm looking at ATM on TW, with kdm-4.11.22, for DISPLAYMANAGER= lists neither lightdm nor sddm as options; mine has "kdm" set. For Plasma 5 to be default set "kde-plasma" as DEFAULT_WM= in windowmanager.
Hi Felix, OK, I followed your instructions and set my DISPLAYMANAGER to kdm, and DEFAULT_WM to kde-plasma. Upon reboot, I now do get a login screen but when I enter my name and password I again get the popup dialog saying " Could not start kdeinit5. Check your installation. ". I cannot get any further than this, if I click on OK it just represents me with the login screen and this cycle repeats. CTRL-ALT-F3 gets me to the command line screen....
From the above and the other info you posted I'm now of the belief that Patrick could have been on the right track with his answer yesterday. I'm now thinking yours is either a login authorization problem and/or a Plasma/KDE problem, and that the help you need might be better asked among those focused on Plasma/KDE, in the opensuse-kde mailing list. Point to the archive of this list thread if you proceed there so anyone who tries to help won't have to ask for the same info.
Have you tried using the greeter to select an IceWM session instead of Plasma? That will probably define whether you have a KDE problem or an Xorg problem - unless maybe yours is an authorization problem. 'WINDOWMANAGER=/usr/bin/icewm startx -- :1' which AFAICT you didn't try as root login, would have served the same purpose. Maybe 'zypper ve' (verify) is called for here. Maybe something among your updates didn't complete correctly. Other than trying to use lightdm, sddm, kdebase3-kdm, gdm or some other greeter, I don't know what else to suggest given the content shown in your /var/lib/systemd/coredump/ and the could not start kdeinit5 errors. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/19/2017 04:44 PM, Felix Miata wrote:
Marc Chamberlin composed on 2017-07-19 13:41 (UTC-0700):
Edit /etc/sysconfig/displaymanager and /etc/sysconfig/windowmanager directly. They are supposedly self-documenting, although the displaymanager I'm looking at ATM on TW, with kdm-4.11.22, for DISPLAYMANAGER= lists neither lightdm nor sddm as options; mine has "kdm" set. For Plasma 5 to be default set "kde-plasma" as DEFAULT_WM= in windowmanager. Hi Felix, OK, I followed your instructions and set my DISPLAYMANAGER to kdm, and DEFAULT_WM to kde-plasma. Upon reboot, I now do get a login screen but when I enter my name and password I again get the popup
Felix Miata wrote: dialog saying " Could not start kdeinit5. Check your installation. ". I cannot get any further than this, if I click on OK it just represents me with the login screen and this cycle repeats. CTRL-ALT-F3 gets me to the command line screen.... From the above and the other info you posted I'm now of the belief that Patrick could have been on the right track with his answer yesterday. I'm now thinking yours is either a login authorization problem and/or a Plasma/KDE problem, and that the help you need might be better asked among those focused on Plasma/KDE, in the opensuse-kde mailing list. Point to the archive of this list thread if you proceed there so anyone who tries to help won't have to ask for the same info.
Have you tried using the greeter to select an IceWM session instead of Plasma? That will probably define whether you have a KDE problem or an Xorg problem - unless maybe yours is an authorization problem. 'WINDOWMANAGER=/usr/bin/icewm startx -- :1' which AFAICT you didn't try as root login, would have served the same purpose. Hello again Felix, (sorry for the delay getting back with a response, had to spend the day canning peaches! ;-) )
The WINDOWMANAGER command does indeed work and I do get a desktop with it, regardless of whether I login in as root or as me! Not the desktop I want to use however as it does not run any of the KDE tools that I am familiar with. But at least this is some progress... I am not sure how to use the greeter to select an IceWM session instead of Plasma. When using KDM as my DISPLAYMANAGER all I see is a prompt for my login name, and then another for my password. Perhaps I don't understand what you mean by "greeter"? I will be happy to switch this thread over to the opensuse-kde mail list (and subscribe to it I guess) if you still think that is appropriate.
Maybe 'zypper ve' (verify) is called for here. Maybe something among your updates didn't complete correctly. Other than trying to use lightdm, sddm, kdebase3-kdm, gdm or some other greeter, I don't know what else to suggest given the content shown in your /var/lib/systemd/coredump/ and the could not start kdeinit5 errors.
bigbang:/home/marc # zypper ve Loading repository data... Reading installed packages... 7 Problems: Problem: nothing provides appdata(org.kde.akregator.appdata.xml) needed by application:Akregator-.noarch Problem: nothing provides appdata(org.kde.korganizer.appdata.xml) needed by application:KOrganizer-.noarch Problem: nothing provides appdata(org.kde.kleopatra.appdata.xml) needed by application:Kleopatra-.noarch Problem: nothing provides appdata(org.kde.kaddressbook.appdata.xml) needed by application:KAddressBook-.noarch Problem: nothing provides appdata(org.kde.kontact.appdata.xml) needed by application:Kontact-.noarch Problem: nothing provides appdata(org.kde.knotes.appdata.xml) needed by application:KNotes-.noarch Problem: nothing provides appdata(org.kde.kmail.appdata.xml) needed by application:KMail-.noarch Problem: nothing provides appdata(org.kde.akregator.appdata.xml) needed by application:Akregator-.noarch Solution 1: deinstallation of application:Akregator-.noarch Solution 2: break application:Akregator-.noarch by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c): c Not sure what to do about these issues so I just bailed out... Marc... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Marc Chamberlin <marc@marcchamberlin.com> [07-20-17 18:04]: [...]
bigbang:/home/marc # zypper ve Loading repository data... Reading installed packages... 7 Problems: Problem: nothing provides appdata(org.kde.akregator.appdata.xml) needed by application:Akregator-.noarch Problem: nothing provides appdata(org.kde.korganizer.appdata.xml) needed by application:KOrganizer-.noarch Problem: nothing provides appdata(org.kde.kleopatra.appdata.xml) needed by application:Kleopatra-.noarch Problem: nothing provides appdata(org.kde.kaddressbook.appdata.xml) needed by application:KAddressBook-.noarch Problem: nothing provides appdata(org.kde.kontact.appdata.xml) needed by application:Kontact-.noarch Problem: nothing provides appdata(org.kde.knotes.appdata.xml) needed by application:KNotes-.noarch Problem: nothing provides appdata(org.kde.kmail.appdata.xml) needed by application:KMail-.noarch
Problem: nothing provides appdata(org.kde.akregator.appdata.xml) needed by application:Akregator-.noarch Solution 1: deinstallation of application:Akregator-.noarch Solution 2: break application:Akregator-.noarch by ignoring some of its dependencies
Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c): c
Not sure what to do about these issues so I just bailed out... Marc...
just hazarding a guess from what you have provided that I read, appears you have removed a repository that provided the missing packages, or... you ok'ed the install of apps (forced) with missing dependencies, or... you have installed apps from a repository that does not fit your distro, or... you have upgraded from a previous distro w/o providing matching repositories and haven't advised us of that small fact. since you *can* reach a graphics mode with icewm, I would guess the last and a possible solution, again guessing, would be to search of the necessary repo to satisfy the missing dependencies and reinstall those apps, ie: zypper -v in --force kontact kaddressbook .... bearing in mind that *any* action may further bork your presently borked system. gud luk, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-21 00:02, Marc Chamberlin wrote:
On 07/19/2017 04:44 PM, Felix Miata wrote:
Have you tried using the greeter to select an IceWM session instead of Plasma? That will probably define whether you have a KDE problem or an Xorg problem - unless maybe yours is an authorization problem. 'WINDOWMANAGER=/usr/bin/icewm startx -- :1' which AFAICT you didn't try as root login, would have served the same purpose. Hello again Felix, (sorry for the delay getting back with a response, had to spend the day canning peaches! ;-) )
The WINDOWMANAGER command does indeed work and I do get a desktop with it, regardless of whether I login in as root or as me! Not the desktop I want to use however as it does not run any of the KDE tools that I am familiar with. But at least this is some progress...
I am not sure how to use the greeter to select an IceWM session instead of Plasma. When using KDM as my DISPLAYMANAGER all I see is a prompt for my login name, and then another for my password. Perhaps I don't understand what you mean by "greeter"?
That is the "greeter". The official name is "display manager". The place where you login to X. There should be a point to click where you wold get a list of desktop choices, sometimes after entering the user name.
I will be happy to switch this thread over to the opensuse-kde mail list (and subscribe to it I guess) if you still think that is appropriate.
I think you should stay here for the moment.
Maybe 'zypper ve' (verify) is called for here. Maybe something among your updates didn't complete correctly. Other than trying to use lightdm, sddm, kdebase3-kdm, gdm or some other greeter, I don't know what else to suggest given the content shown in your /var/lib/systemd/coredump/ and the could not start kdeinit5 errors.
bigbang:/home/marc # zypper ve
Comment. Use "su -" instead of just "su".
Loading repository data... Reading installed packages... 7 Problems: Problem: nothing provides appdata(org.kde.akregator.appdata.xml) needed by application:Akregator-.noarch Problem: nothing provides appdata(org.kde.korganizer.appdata.xml) needed by application:KOrganizer-.noarch Problem: nothing provides appdata(org.kde.kleopatra.appdata.xml) needed by application:Kleopatra-.noarch Problem: nothing provides appdata(org.kde.kaddressbook.appdata.xml) needed by application:KAddressBook-.noarch Problem: nothing provides appdata(org.kde.kontact.appdata.xml) needed by application:Kontact-.noarch Problem: nothing provides appdata(org.kde.knotes.appdata.xml) needed by application:KNotes-.noarch Problem: nothing provides appdata(org.kde.kmail.appdata.xml) needed by application:KMail-.noarch
Problem: nothing provides appdata(org.kde.akregator.appdata.xml) needed by application:Akregator-.noarch Solution 1: deinstallation of application:Akregator-.noarch Solution 2: break application:Akregator-.noarch by ignoring some of its dependencies
Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c): c
Not sure what to do about these issues so I just bailed out... Marc...
Solution 2. I don't recall the correct explanation for this type of error, it is caused by "applications" support not being completed in zypper. You can ignore it. The real solution is to delete an xml file somewhere, but I'm unsure of it this instant in the night (3 AM). -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 07/20/2017 06:28 PM, Carlos E. R. wrote:
On 2017-07-21 00:02, Marc Chamberlin wrote:
On 07/19/2017 04:44 PM, Felix Miata wrote:
Have you tried using the greeter to select an IceWM session instead of Plasma? That will probably define whether you have a KDE problem or an Xorg problem - unless maybe yours is an authorization problem. 'WINDOWMANAGER=/usr/bin/icewm startx -- :1' which AFAICT you didn't try as root login, would have served the same purpose. Hello again Felix, (sorry for the delay getting back with a response, had to spend the day canning peaches! ;-) )
The WINDOWMANAGER command does indeed work and I do get a desktop with it, regardless of whether I login in as root or as me! Not the desktop I want to use however as it does not run any of the KDE tools that I am familiar with. But at least this is some progress...
I am not sure how to use the greeter to select an IceWM session instead of Plasma. When using KDM as my DISPLAYMANAGER all I see is a prompt for my login name, and then another for my password. Perhaps I don't understand what you mean by "greeter"? That is the "greeter". The official name is "display manager". The place where you login to X.
There should be a point to click where you wold get a list of desktop choices, sometimes after entering the user name. Hi again Carlos, no I am not seeing anything that allows me to select from a list of desktops... :-(
I will be happy to switch this thread over to the opensuse-kde mail list (and subscribe to it I guess) if you still think that is appropriate. I think you should stay here for the moment.
OK
Maybe 'zypper ve' (verify) is called for here. Maybe something among your updates didn't complete correctly. Other than trying to use lightdm, sddm, kdebase3-kdm, gdm or some other greeter, I don't know what else to suggest given the content shown in your /var/lib/systemd/coredump/ and the could not start kdeinit5 errors. bigbang:/home/marc # zypper ve Comment.
Use "su -" instead of just "su".
Actually, I have been doing an "su root" and then type in root's password. Makes it easier for me since I tend to want to stay in root's context for awhile when doing administrative stuff. When I get ready to go back to being me, I just type "exit"
Loading repository data... Reading installed packages... 7 Problems: Problem: nothing provides appdata(org.kde.akregator.appdata.xml) needed by application:Akregator-.noarch Problem: nothing provides appdata(org.kde.korganizer.appdata.xml) needed by application:KOrganizer-.noarch Problem: nothing provides appdata(org.kde.kleopatra.appdata.xml) needed by application:Kleopatra-.noarch Problem: nothing provides appdata(org.kde.kaddressbook.appdata.xml) needed by application:KAddressBook-.noarch Problem: nothing provides appdata(org.kde.kontact.appdata.xml) needed by application:Kontact-.noarch Problem: nothing provides appdata(org.kde.knotes.appdata.xml) needed by application:KNotes-.noarch Problem: nothing provides appdata(org.kde.kmail.appdata.xml) needed by application:KMail-.noarch
Problem: nothing provides appdata(org.kde.akregator.appdata.xml) needed by application:Akregator-.noarch Solution 1: deinstallation of application:Akregator-.noarch Solution 2: break application:Akregator-.noarch by ignoring some of its dependencies
Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c): c
Not sure what to do about these issues so I just bailed out... Marc...
Solution 2.
OK I can do that! I like easy answers!
I don't recall the correct explanation for this type of error, it is caused by "applications" support not being completed in zypper. You can ignore it. The real solution is to delete an xml file somewhere, but I'm unsure of it this instant in the night (3 AM).
Hope you got a good nights sleep and slept in late! Marc.. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-21 04:39, Marc Chamberlin wrote:
On 07/20/2017 06:28 PM, Carlos E. R. wrote:
That is the "greeter". The official name is "display manager". The place where you login to X.
There should be a point to click where you wold get a list of desktop choices, sometimes after entering the user name. Hi again Carlos, no I am not seeing anything that allows me to select from a list of desktops... :-(
It should be there, but sometimes it is difficult to identify.
bigbang:/home/marc # zypper ve Comment.
Use "su -" instead of just "su".
Actually, I have been doing an "su root" and then type in root's password. Makes it easier for me since I tend to want to stay in root's context for awhile when doing administrative stuff. When I get ready to go back to being me, I just type "exit"
Then use "su - root". The dash is important. The "root" part is optional: if a user name is not entered, the default is "root". -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Marc Chamberlin composed on 2017-07-20 19:39 (UTC-0700):
Carlos E. R. wrote:
There should be a point to click where you wold get a list of desktop choices, sometimes after entering the user name.
Hi again Carlos, no I am not seeing anything that allows me to select from a list of desktops... :-(
Assuming you are in fact using kdm, find kdmrc, probably in /usr/share/kde4/config/kdm/. Late in the file you'll see useTheme=true Change true to false and reboot. Then you should be able to spot "Menu" near the center of the screen and choose from among various session types. If you don't, you are not using KDM and I don't know what to suggest other than zypper or yast removing *dm except for xdm and kdm and trying to install kdm again. With gdm, lightdm and sddm I can't help. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Marc Chamberlin composed on 2017-07-20 15:02 (UTC-0700):
Felix Miata wrote: ...
Have you tried using the greeter to select an IceWM session instead of Plasma? That will probably define whether you have a KDE problem or an Xorg problem - unless maybe yours is an authorization problem. 'WINDOWMANAGER=/usr/bin/icewm startx -- :1' which AFAICT you didn't try as root login, would have served the same purpose. ... The WINDOWMANAGER command does indeed work and I do get a desktop with
WINDOWMANAGER is not a command. It's a peculiar form of startup option for startx (only? on openSUSE).
it, regardless of whether I login in as root or as me! Not the desktop I want to use however as it does not run any of the KDE tools that I am familiar with. But at least this is some progress...
I am not sure how to use the greeter to select an IceWM session instead of Plasma. When using KDM as my DISPLAYMANAGER all I see is a prompt for my login name, and then another for my password. Perhaps I don't understand what you mean by "greeter"? Somewhere on the login screen there are supposed to be options other than username and password, things like shutting down, rebooting, and selecting the desktop to start. There should be a desktop select list somewhere where IceWM is offered along with Plasma and others, like maybe LxDE, Gnome or XFCE. If you can't find IceWM anywhere on the login screen, it's almost certainly broken.
Greeter == login manager. Login manager used to say "Welcome to..." before theming became standard. My installations don't use greeter theming (useTheme=false in ?dmrc), so they all still include "Welcome to..." (KDM, KDM3, TDM and none other), and I always know where to look for DE selections and other options. :-)
Maybe 'zypper ve' (verify) is called for here. Maybe something among your updates didn't complete correctly. Other than trying to use lightdm, sddm, kdebase3-kdm, gdm or some other greeter, I don't know what else to suggest given the content shown in your /var/lib/systemd/coredump/ and the could not start kdeinit5 errors.
bigbang:/home/marc # zypper ve Loading repository data... Reading installed packages... 7 Problems: ... Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c): c
Not sure what to do about these issues so I just bailed out... Marc...
You obviously have KDE/Plasma package problems. :-( If you have a file /etc/zypp/locks, what packages are in it ('zypper ll')? Do as Patrick told you. Verify the content in /etc/zypp/repos.d/ is all appropriate. One or more repos are, or at least at the time you updated, were, inappropriate or otherwise broken. That 'zypper ve' now says there are problems suggests most likely your repo configuration is bad (some kind of mismatch). If any of *.repo contain any version number other than the one you are running (42.2?) it needs to be fixed. All are plain text files. Follow that up with 'zypper ref; zypper ve' and reboot. If the greeter still can't give you a working Plasma session (or any other session type), and you are sure your repos are correctly configured, it's time to either take it to opensuse-kde, or if you are brave enough, give 'zypper -v dup' a try. (Here it would be the latter first. ;-) ) -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-21 03:44, Felix Miata wrote:
Marc Chamberlin composed on 2017-07-20 15:02 (UTC-0700):
Maybe 'zypper ve' (verify) is called for here. Maybe something among your updates didn't complete correctly. Other than trying to use lightdm, sddm, kdebase3-kdm, gdm or some other greeter, I don't know what else to suggest given the content shown in your /var/lib/systemd/coredump/ and the could not start kdeinit5 errors.
bigbang:/home/marc # zypper ve Loading repository data... Reading installed packages... 7 Problems: ... Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c): c
Not sure what to do about these issues so I just bailed out... Marc...
You obviously have KDE/Plasma package problems. :-(
No, that particular problem is not relevant. Just noise. Read this thread for more info: https://lists.opensuse.org/opensuse/2017-01/msg00146.html Run "zypper se -t application", you can see those "applications". Then run: zypper info --requires -t application 'Akregator' I'll do it with the conflict I see: #### YaST2 conflicts list - generated 2017-06-14 11:39:45 #### nothing provides appdata(vmware-player.appdata.xml) needed by application:VMware Player-.noarch [ ] deinstallation of application:VMware Player-.noarch [ ] break application:VMware Player-.noarch by ignoring some of its dependencies #### YaST2 conflicts list END ### zypper info --requires -t application 'VMware Player' And I get: Information for application VMware Player: ------------------------------------------ Repository : @System Name : VMware Player Version : Arch : noarch Vendor : Summary : Run a virtual machine Description : Requires : appdata(vmware-player.appdata.xml) <====== Then I do (Andrei guessed this): cer@Telcontar:~> ls -l /usr/share/appdata/vmware-player.appdata.xml -rw-r--r-- 1 root root 812 Jun 7 22:31 /usr/share/appdata/vmware-player.appdata.xml cer@Telcontar:~> rpm -qf /usr/share/appdata/vmware-player.appdata.xml file /usr/share/appdata/vmware-player.appdata.xml is not owned by any package cer@Telcontar:~> The solution is to delete that file directly. In Marc case, the problem is find what file to delete in /usr/share/appdata/. Probably one related to "Akregator".
If you have a file /etc/zypp/locks, what packages are in it ('zypper ll')?
Do as Patrick told you. Verify the content in /etc/zypp/repos.d/ is all appropriate.
Just post here "zypper lr --details". If lines wrap when pasting, add it as a text attachment to the post. zypper lr --details > repolist.txt and we'll have a look at it. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [07-20-17 22:21]:
On 2017-07-21 03:44, Felix Miata wrote:
Marc Chamberlin composed on 2017-07-20 15:02 (UTC-0700):
Maybe 'zypper ve' (verify) is called for here. Maybe something among your updates didn't complete correctly. Other than trying to use lightdm, sddm, kdebase3-kdm, gdm or some other greeter, I don't know what else to suggest given the content shown in your /var/lib/systemd/coredump/ and the could not start kdeinit5 errors.
bigbang:/home/marc # zypper ve Loading repository data... Reading installed packages... 7 Problems: ... Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c): c
Not sure what to do about these issues so I just bailed out... Marc...
You obviously have KDE/Plasma package problems. :-(
No, that particular problem is not relevant. Just noise.
Read this thread for more info:
https://lists.opensuse.org/opensuse/2017-01/msg00146.html
Run "zypper se -t application", you can see those "applications".
maybe better "zypper se -si -t application" to see *only* installed ...
Then run:
zypper info --requires -t application 'Akregator'
I'll do it with the conflict I see:
#### YaST2 conflicts list - generated 2017-06-14 11:39:45 ####
nothing provides appdata(vmware-player.appdata.xml) needed by application:VMware Player-.noarch
[ ] deinstallation of application:VMware Player-.noarch
[ ] break application:VMware Player-.noarch by ignoring some of its dependencies
#### YaST2 conflicts list END ###
zypper info --requires -t application 'VMware Player'
And I get:
Information for application VMware Player: ------------------------------------------ Repository : @System Name : VMware Player Version : Arch : noarch Vendor : Summary : Run a virtual machine Description : Requires : appdata(vmware-player.appdata.xml) <======
Then I do (Andrei guessed this):
cer@Telcontar:~> ls -l /usr/share/appdata/vmware-player.appdata.xml -rw-r--r-- 1 root root 812 Jun 7 22:31 /usr/share/appdata/vmware-player.appdata.xml cer@Telcontar:~> rpm -qf /usr/share/appdata/vmware-player.appdata.xml file /usr/share/appdata/vmware-player.appdata.xml is not owned by any package cer@Telcontar:~>
The solution is to delete that file directly.
In Marc case, the problem is find what file to delete in /usr/share/appdata/. Probably one related to "Akregator".
If you have a file /etc/zypp/locks, what packages are in it ('zypper ll')?
Do as Patrick told you. Verify the content in /etc/zypp/repos.d/ is all appropriate.
Just post here "zypper lr --details". If lines wrap when pasting, add it as a text attachment to the post.
zypper lr --details > repolist.txt
and we'll have a look at it.
-- Cheers / Saludos,
Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/20/2017 07:07 PM, Carlos E. R. wrote:
On 2017-07-21 03:44, Felix Miata wrote:
Marc Chamberlin composed on 2017-07-20 15:02 (UTC-0700):
Maybe 'zypper ve' (verify) is called for here. Maybe something among your updates didn't complete correctly. Other than trying to use lightdm, sddm, kdebase3-kdm, gdm or some other greeter, I don't know what else to suggest given the content shown in your /var/lib/systemd/coredump/ and the could not start kdeinit5 errors. bigbang:/home/marc # zypper ve Loading repository data... Reading installed packages... 7 Problems: ... Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c): c Not sure what to do about these issues so I just bailed out... Marc... You obviously have KDE/Plasma package problems. :-( No, that particular problem is not relevant. Just noise.
Read this thread for more info:
https://lists.opensuse.org/opensuse/2017-01/msg00146.html
Run "zypper se -t application", you can see those "applications".
Then run:
zypper info --requires -t application 'Akregator'
I'll do it with the conflict I see:
#### YaST2 conflicts list - generated 2017-06-14 11:39:45 ####
nothing provides appdata(vmware-player.appdata.xml) needed by application:VMware Player-.noarch
[ ] deinstallation of application:VMware Player-.noarch
[ ] break application:VMware Player-.noarch by ignoring some of its dependencies
#### YaST2 conflicts list END ###
zypper info --requires -t application 'VMware Player'
And I get:
Information for application VMware Player: ------------------------------------------ Repository : @System Name : VMware Player Version : Arch : noarch Vendor : Summary : Run a virtual machine Description : Requires : appdata(vmware-player.appdata.xml) <======
Then I do (Andrei guessed this):
cer@Telcontar:~> ls -l /usr/share/appdata/vmware-player.appdata.xml -rw-r--r-- 1 root root 812 Jun 7 22:31 /usr/share/appdata/vmware-player.appdata.xml cer@Telcontar:~> rpm -qf /usr/share/appdata/vmware-player.appdata.xml file /usr/share/appdata/vmware-player.appdata.xml is not owned by any package cer@Telcontar:~>
The solution is to delete that file directly.
In Marc case, the problem is find what file to delete in /usr/share/appdata/. Probably one related to "Akregator".
Hi again Carlos - OK, so I gather I should locate and delete all these xml files that "zypper ve" is complaining about? Incidentally, when I ran zypper ve again, I followed your advice to choose solution 2 - break application:xxx-.noarch by ignoring some of its dependencies, and ran into something that made me hesitant to do, it wanted to remove a couple packages and one of them kernel-default-4.4.74-18.20.1 scared me into bailing out. Here is the output, see what you think? bigbang:/etc/zypp # zypper ve Loading repository data... Reading installed packages... 7 Problems: Problem: nothing provides appdata(org.kde.akregator.appdata.xml) needed by application:Akregator-.noarch Problem: nothing provides appdata(org.kde.korganizer.appdata.xml) needed by application:KOrganizer-.noarch Problem: nothing provides appdata(org.kde.kleopatra.appdata.xml) needed by application:Kleopatra-.noarch Problem: nothing provides appdata(org.kde.kaddressbook.appdata.xml) needed by application:KAddressBook-.noarch Problem: nothing provides appdata(org.kde.kontact.appdata.xml) needed by application:Kontact-.noarch Problem: nothing provides appdata(org.kde.knotes.appdata.xml) needed by application:KNotes-.noarch Problem: nothing provides appdata(org.kde.kmail.appdata.xml) needed by application:KMail-.noarch Problem: nothing provides appdata(org.kde.akregator.appdata.xml) needed by application:Akregator-.noarch Solution 1: deinstallation of application:Akregator-.noarch Solution 2: break application:Akregator-.noarch by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c): 2 Problem: nothing provides appdata(org.kde.korganizer.appdata.xml) needed by application:KOrganizer-.noarch Solution 1: deinstallation of application:KOrganizer-.noarch Solution 2: break application:KOrganizer-.noarch by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c): 2 Problem: nothing provides appdata(org.kde.kleopatra.appdata.xml) needed by application:Kleopatra-.noarch Solution 1: deinstallation of application:Kleopatra-.noarch Solution 2: break application:Kleopatra-.noarch by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c): 2 Problem: nothing provides appdata(org.kde.kaddressbook.appdata.xml) needed by application:KAddressBook-.noarch Solution 1: deinstallation of application:KAddressBook-.noarch Solution 2: break application:KAddressBook-.noarch by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c): 2 Problem: nothing provides appdata(org.kde.kontact.appdata.xml) needed by application:Kontact-.noarch Solution 1: deinstallation of application:Kontact-.noarch Solution 2: break application:Kontact-.noarch by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c): 2 Problem: nothing provides appdata(org.kde.knotes.appdata.xml) needed by application:KNotes-.noarch Solution 1: deinstallation of application:KNotes-.noarch Solution 2: break application:KNotes-.noarch by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c): 2 Problem: nothing provides appdata(org.kde.kmail.appdata.xml) needed by application:KMail-.noarch Solution 1: deinstallation of application:KMail-.noarch Solution 2: break application:KMail-.noarch by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c): 2 Resolving dependencies... The following 2 packages are going to be REMOVED: brscan4 kernel-default-4.4.74-18.20.1 2 packages to remove. After the operation, 238.2 MiB will be freed. Some of the dependencies of installed packages are broken. In order to fix these dependencies, the following actions need to be taken: Continue? [y/n/...? shows all options] (y): n
If you have a file /etc/zypp/locks, what packages are in it ('zypper ll')?
Do as Patrick told you. Verify the content in /etc/zypp/repos.d/ is all appropriate. Just post here "zypper lr --details". If lines wrap when pasting, add it as a text attachment to the post.
zypper lr --details > repolist.txt
and we'll have a look at it.
OK I attached repolist.txt to this posting... Marc...
Marc Chamberlin composed on 2017-07-20 20:19 (UTC-0700):
OK I attached repolist.txt to this posting... Marc...
Looks good to me. Unless you are a developer, there's no reason I can think of at this point to have source enabled. I would try this first zypper -v dup -D And report the messages you get, unless any you do see do not scare you, in which case go ahead and let zypper fix whatever got broken zypper -v dup That said, are you sure you're running KDM? Why did you find it necessary to mess with /etc/sysconfig files in YaST? Initially you wrote "my displaymanager is set to sddm", but since then we've been referring to kdm, yet your greeter is apparently not offering you the DE options it should be. What do ps -A | grep dm and rpm -qa | grep dm and systemctl status display-manager report? These need a clear answer before dup'ing is warranted. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/20/2017 08:53 PM, Felix Miata wrote:
Marc Chamberlin composed on 2017-07-20 20:19 (UTC-0700):
OK I attached repolist.txt to this posting... Marc... Looks good to me. Unless you are a developer, there's no reason I can think of at this point to have source enabled. I would try this first
zypper -v dup -D
bigbang:/etc/zypp/repos.d # zypper -v dup -D Verbosity: 1 Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Initializing Target Checking whether to refresh metadata for Main Repository (NON-OSS) Retrieving: content ......................................................................................................[done] Retrieving: media ........................................................................................................[done] Checking whether to refresh metadata for Update Repository (Non-Oss) Retrieving: repomd.xml ...................................................................................................[done] Checking whether to refresh metadata for Main Repository (OSS) Retrieving: content .........................................................................................[done (15.3 KiB/s)] Retrieving: media ........................................................................................................[done] Checking whether to refresh metadata for Main Update Repository Retrieving: repomd.xml .......................................................................................[done (1.1 KiB/s)] Checking whether to refresh metadata for Packman Repository Retrieving: repomd.xml .......................................................................................[done (1.2 KiB/s)] Checking whether to refresh metadata for openSUSE-Leap-42.2-Source-Non-Oss Retrieving: content ......................................................................................................[done] Retrieving: media ........................................................................................................[done] Loading repository data... Reading installed packages... Computing distribution upgrade... Force resolution: No Computing upgrade... The following NEW package is going to be installed: monitoring-plugins-fail2ban 0.9.7-2.3.1 The following package is going to be REMOVED: nagios-plugins-fail2ban 0.9.5-1.4 The following 6 packages are going to be upgraded: catdoc 0.95-7.3.1 -> 0.95-7.6.1 flash-player 26.0.0.126-1.1 -> 26.0.0.137-1.1 liba52-0 0.7.5+svn613-3.1 -> 0.7.5+svn613-4.1 libquicktime0 1.2.4cvs20150223-8.3.1 -> 1.2.4cvs20150223-8.9.1 oxygen5-icon-theme 5.26.0-1.2 -> 5.26.0-2.3.1 oxygen5-icon-theme-large 5.26.0-1.2 -> 5.26.0-2.3.1 6 packages to upgrade, 1 new, 1 to remove. Overall download size: 42.0 MiB. Already cached: 0 B. No additional space will be used or freed after the operation. Continue? [y/n/...? shows all options] (y): n
And report the messages you get, unless any you do see do not scare you, in which case go ahead and let zypper fix whatever got broken
zypper -v dup
I don't see anything scary, but I am going to hold off for the moment. I have made some progress, see below....
That said, are you sure you're running KDM?
Why did you find it necessary to mess with /etc/sysconfig files in YaST? I used YaST to make changes to the /etc/sysconfig files because that was
Initially you wrote "my displaymanager is set to sddm", but since then we've been referring to kdm, yet your greeter is apparently not offering you the DE options it should be. When I first started having troubles with not getting a login screen, or a desktop, my explorations led me to look in /etc/sysconfig via YaST and I discovered that my displaymanager was set to sddm. So I assumed that I was using sddm in the past, and I was happy with it. And I assumed that I probably wanted to get it going again. Folks on here, and other places suggested I use KDM instead as well as trying some of the other display manager possibilities. So that is how I switched to talking about KDM. As far as I am concerned, KDM seems like a fine choice also to use for
Well no, apparently I wasn't running KDM, the "ps -A | grep dm" command showed that I was running XDM! That got me to wondering why, so I did some investigating and discovered that the KDM package was not even installed. (Don't laugh, I am struggling to grok a lot of stuff and don't know what gets installed by default and what doesn't...) Anyhow I remedied that and installed KDM and the openSuSE extensions for it. So now, when I reboot, I do get what is apparently the KDM fancy login screen, and yes I now do have the ability to select different window managers from it! the only way I found, from doing Google/Internet searches that allowed me to make the selections for the display and window managers. I wasn't aware that I should, or even able to make such changes from the login screen, because I wasn't being presented with such an option. So I used YaST, which seemed like a reasonable thing to do. But apparently changing the displaymanager via editing /etc/sysconfig in YaST did not result in producing any error messages, even though the KDM package was not installed. So I didn't know that there was even a problem. I am going to guess that when such a failure occurs, the setup scripts silently fall back to using XDM? the login screen. I am not particularly vested in using sddm. What I am more concerned about is getting the KDE desktop, with the plasma extensions working again. I am most familiar with the various KDE tools and use them a lot. So on that note, now that I have KDM working, I have again tried to bring up the various different window managers, using the menu selection that KDM is now giving me in the login window. All but the icewm are still failing, giving me the error message that KDEINIT5 failed.
What do
ps -A | grep dm and rpm -qa | grep dm and systemctl status display-manager
report? These need a clear answer before dup'ing is warranted.
Do you still want this info? I think I got this piece of the puzzle figured out and working now.... Baby steps!!! Now back to figuring out why my KDE desktop is still sick... ;-) Marc... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Marc Chamberlin composed on 2017-07-20 23:48 (UTC-0700):
Felix Miata wrote:
What I am more concerned about is getting the KDE desktop, with the plasma extensions working again. I am most familiar with the various KDE tools and use them a lot. So on that note, now that I have KDM working, I have again tried to bring up the various different window managers, using the menu selection that KDM is now giving me in the login window. All but the icewm are still failing, giving me the error message that KDEINIT5 failed.
What do
ps -A | grep dm and rpm -qa | grep dm and systemctl status display-manager
report? These need a clear answer before dup'ing is warranted.
Do you still want this info? I think I got this piece of the puzzle
Still might help.
figured out and working now.... Baby steps!!! Now back to figuring out why my KDE desktop is still sick... ;-) Marc...
Nothing in zypper output suggests to me that zypper dup would fix the kdeinit5 failure. If sddm remains installed, it could be playing a part in kdeinit5 failure, but this is only guessing. If it's still installed, remove it and try again. If it doesn't help, I'd go ahead and ping the experts on the opensuse-kde list for what to try next. When you do, remind them what /var/lib/systemd/coredump contains when you point to this thread, and attach the output from 'journalctl -b | grep kdeinit' taken after one try to login to Plasma after a fresh boot. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/21/2017 12:07 AM, Felix Miata wrote:
Marc Chamberlin composed on 2017-07-20 23:48 (UTC-0700):
Felix Miata wrote: What I am more concerned about is getting the KDE desktop, with the plasma extensions working again. I am most familiar with the various KDE tools and use them a lot. So on that note, now that I have KDM working, I have again tried to bring up the various different window managers, using the menu selection that KDM is now giving me in the login window. All but the icewm are still failing, giving me the error message that KDEINIT5 failed.
What do ps -A | grep dm and rpm -qa | grep dm and systemctl status display-manager report? These need a clear answer before dup'ing is warranted. Do you still want this info? I think I got this piece of the puzzle Still might help.
OK, here is the scoop.... bigbang:/etc/zypp/repos.d # ps -A | grep dm 2960 ? 00:00:00 kdm 7512 ? 00:00:00 kdm bigbang:/etc/zypp/repos.d # rpm -qa | grep dm xdm-1.1.11-13.1.x86_64 libdmtx0-0.7.4-15.4.x86_64 liblightdm-gobject-1-0-1.19.5-1.1.x86_64 libquadmath0-6.2.1+r239768-5.5.2.x86_64 dmz-icon-theme-cursors-11.2.0-18.2.noarch lightdm-gtk-greeter-2.0.2-1.1.x86_64 phpMyAdmin-4.4.15.10-33.6.1.noarch libdmx1-1.1.3-6.3.x86_64 kdm-branding-openSUSE-42.1-8.1.noarch sddm-0.13.0-8.1.x86_64 nfsidmap-0.25-8.3.x86_64 gdmflexiserver-3.14.2-16.1.noarch kdm-4.11.22-3.24.x86_64 lightdm-gtk-greeter-lang-2.0.2-1.1.noarch libXdmcp6-1.1.2-3.3.1.x86_64 dmraid-1.0.0.rc16-38.6.x86_64 xdm-xsession-1.1.11-13.1.x86_64 kcm_sddm-5.8.2-1.1.x86_64 lightdm-1.19.5-1.1.x86_64 libmodman1-2.0.1-18.3.x86_64 libloudmouth-1-0-1.4.3-25.4.x86_64 sddm-theme-openSUSE-42.1.1-12.1.noarch xmodmap-1.0.9-2.4.x86_64 lightdm-gtk-greeter-branding-openSUSE-1.3-9.3.noarch mdadm-3.4-6.2.x86_64 sddm-branding-openSUSE-0.13.0-8.1.x86_64 kcm_sddm-lang-5.8.2-1.1.noarch dmidecode-3.0-2.3.x86_64 tomcat-admin-webapps-8.0.43-6.10.3.noarch lightdm-lang-1.19.5-1.1.noarch xdmbgrd-0.6-219.3.x86_64 bigbang:/etc/zypp/repos.d # systemctl status display-manager ● display-manager.service - X Display Manager Loaded: loaded (/usr/lib/systemd/system/display-manager.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2017-07-20 21:41:24 PDT; 11h ago Process: 2890 ExecStart=/usr/lib/X11/display-manager start (code=exited, status=0/SUCCESS) Main PID: 2960 (kdm) Tasks: 2 (limit: 512) CGroup: /system.slice/display-manager.service ├─2960 /usr/bin/kdm └─7504 /usr/bin/Xorg -br :0 vt7 -nolisten tcp -seat seat0 -auth /var/lib/kdm/AuthFiles/A:0-mC6NQa Jul 20 21:50:24 bigbang kdm[2960]: plymouth should quit after server startup Jul 20 21:50:24 bigbang kdm[2960]: Quitting Plymouth with transition Jul 20 21:50:24 bigbang kdm[2960]: Is Plymouth still running? no Jul 20 21:50:24 bigbang kdm_greet[7273]: Cannot load /usr/share/kde4/apps/kdm/faces/.default.face: No such file or directory Jul 20 21:50:43 bigbang kdm[7272]: :0[7272]: pam_unix(xdm:session): session opened for user root by (uid=0) Jul 20 21:50:47 bigbang kdm[2960]: plymouth should quit after server startup Jul 20 21:50:48 bigbang kdm[2960]: Quitting Plymouth with transition Jul 20 21:50:48 bigbang kdm[2960]: Is Plymouth still running? no Jul 20 21:50:48 bigbang kdm_greet[7513]: Cannot load /usr/share/kde4/apps/kdm/faces/.default.face: No such file or directory Jul 20 21:51:11 bigbang kdm[7512]: :0[7512]: pam_unix(xdm:session): session opened for user marc by (uid=0)
figured out and working now.... Baby steps!!! Now back to figuring out why my KDE desktop is still sick... ;-) Marc... Nothing in zypper output suggests to me that zypper dup would fix the kdeinit5 failure. If sddm remains installed, it could be playing a part in kdeinit5 failure, but this is only guessing. If it's still installed, remove it and try again. No joy after removing sddm packages... :-(
If it doesn't help, I'd go ahead and ping the experts on the opensuse-kde list for what to try next. When you do, remind them what /var/lib/systemd/coredump contains when you point to this thread, and attach the output from 'journalctl -b | grep kdeinit' taken after one try to login to Plasma after a fresh boot.
Okdokey! Will start a thread on the opensuse-kde list... Hopefully will get to the bottom of this eventually! And will keep monitoring this thread in this list as well, in case there are any more bright ideas that spring up... Thanks for all your help... Marc.. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op vrijdag 21 juli 2017 18:47:05 CEST schreef Marc Chamberlin:
Okdokey! Will start a thread on the opensuse-kde list... Hopefully will get to the bottom of this eventually! And will keep monitoring this thread in this list as well, in case there are any more bright ideas that spring up... Thanks for all your help... Marc..
Mark, try https://forums.opensuse.org , wolffi323 is one of our KDE packagers, to me he seems to have an answer to everything KDE related. -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Knurpht - Gertjan Lettink composed on 2017-07-21 18:51 (UTC+0200):
Mark, try https://forums.opensuse.org , wolffi323 is one of our KDE packagers, to me he seems to have an answer to everything KDE related.
I think wolffi323 is Wolfgang Bauer, a subscriber and contributor on opensuse-kde as well as a kde maintainer/packager. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Knurpht - Gertjan Lettink composed on 2017-07-21 12:51 (UTC-0400):
Marc Chamberlin composed:
Okdokey! Will start a thread on the opensuse-kde list... Hopefully will get to the bottom of this eventually! And will keep monitoring this thread in this list as well, in case there are any more bright ideas that spring up... Thanks for all your help... Marc..
Mark, try https://forums.opensuse.org , wolffi323 is one of our KDE packagers, to me he seems to have an answer to everything KDE related.
He did one on 3 July, which you and others responded to: https://forums.opensuse.org/showthread.php/525758-could-not-start-kdeinit5-c... His KDM now works, and IceWM works, but not Plasma. No other DEs are installed (unless TWM counts). -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/21/2017 10:38 PM, Felix Miata wrote:
Knurpht - Gertjan Lettink composed on 2017-07-21 12:51 (UTC-0400):
Marc Chamberlin composed:
Okdokey! Will start a thread on the opensuse-kde list... Hopefully will get to the bottom of this eventually! And will keep monitoring this thread in this list as well, in case there are any more bright ideas that spring up... Thanks for all your help... Marc.. Mark, try https://forums.opensuse.org , wolffi323 is one of our KDE packagers, to me he seems to have an answer to everything KDE related. He did one on 3 July, which you and others responded to: https://forums.opensuse.org/showthread.php/525758-could-not-start-kdeinit5-c...
His KDM now works, and IceWM works, but not Plasma. No other DEs are installed (unless TWM counts).
Just want to report back to this list that I give kudos to Wolfgang, he solved this problem! Turns out I apparently had some corrupt libraries and replacing them did the trick. For future reference, in case anyone else runs into this, this was the magic solution - Wolfgang said " Maybe some library got corrupted? I would try to reinstall the core ones at least (the ones that are used by kdeinit5):" sudo zypper in -f libQt5Core5 libQt5Gui5 libQt5Widgets5 libQt5X11Extras5 Thanks Wolfgang, Marc... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-22 18:29, Marc Chamberlin wrote:
On 07/21/2017 10:38 PM, Felix Miata wrote:
Knurpht - Gertjan Lettink composed on 2017-07-21 12:51 (UTC-0400):
Marc Chamberlin composed:
Just want to report back to this list that I give kudos to Wolfgang, he solved this problem! Turns out I apparently had some corrupt libraries and replacing them did the trick. For future reference, in case anyone else runs into this, this was the magic solution -
Good :-)
Wolfgang said " Maybe some library got corrupted? I would try to reinstall the core ones at least (the ones that are used by kdeinit5):"
sudo zypper in -f libQt5Core5 libQt5Gui5 libQt5Widgets5 libQt5X11Extras5
Well, what I suggested in my last post was precisely to reinstall everything in the kde patterns ;-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 07/22/2017 11:49 AM, Carlos E. R. wrote:
On 2017-07-22 18:29, Marc Chamberlin wrote:
On 07/21/2017 10:38 PM, Felix Miata wrote:
Knurpht - Gertjan Lettink composed on 2017-07-21 12:51 (UTC-0400):
Marc Chamberlin composed:
Just want to report back to this list that I give kudos to Wolfgang, he solved this problem! Turns out I apparently had some corrupt libraries and replacing them did the trick. For future reference, in case anyone else runs into this, this was the magic solution - Good :-)
Wolfgang said " Maybe some library got corrupted? I would try to reinstall the core ones at least (the ones that are used by kdeinit5):"
sudo zypper in -f libQt5Core5 libQt5Gui5 libQt5Widgets5 libQt5X11Extras5 Well, what I suggested in my last post was precisely to reinstall everything in the kde patterns ;-)
Thanks Carlos, and kudos to you as well! I suspect all great minds think alike! ;-) Marc -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Marc Chamberlin composed on 2017-07-22 20:46 (UTC-0700):
Carlos E. R. wrote:
Marc Chamberlin wrote: ...
Wolfgang said " Maybe some library got corrupted? I would try to reinstall the core ones at least (the ones that are used by kdeinit5):"
sudo zypper in -f libQt5Core5 libQt5Gui5 libQt5Widgets5 libQt5X11Extras5
Well, what I suggested in my last post https://lists.opensuse.org/opensuse/2017-07/msg00826.html suggested more or less reinstalling all of KDE (patternS). ;-)
was precisely to reinstall everything in the kde patterns ;-)
I wrote https://lists.opensuse.org/opensuse/2017-07/msg00814.html about 4 hours before (after Carlos finally went to bed? Friday morning when, after 6AM?), which explained what Marc should share with the "experts", which he eventually did in the forum. An hour later Wolfgang was able to make that suggestion without asking Marc for any additional information. :-D
Thanks Carlos, and kudos to you as well! I suspect all great minds think alike! ;-) Marc
I don't suspect all that much, except when it comes to Carlos and me. Both of us are relentless once we get started in any given help thread. :-| I still wonder: 1-what went wrong updating to cause the bad libQt5* package(s) installation. That we'll probably never know, unless there's something hiding in the monster /var/log/zypper.log that Marc might dig out. His zypper.log or zypper.log*.xz could contain libQt lines well into 4 digits, maybe even 5, and not worth trying. 2-when exactly the updating occurred that went bad. This mailing list thread started on Tuesday, but Marc started a forum thread about this 15 days earlier. 3-Are Axigen and Fail2Ban still broken? Anything else? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Marc Chamberlin composed on 2017-07-22 20:46 (UTC-0700):
Carlos E. R. wrote:
Marc Chamberlin wrote: ...
Wolfgang said " Maybe some library got corrupted? I would try to reinstall the core ones at least (the ones that are used by kdeinit5):" sudo zypper in -f libQt5Core5 libQt5Gui5 libQt5Widgets5 libQt5X11Extras5 Well, what I suggested in my last post https://lists.opensuse.org/opensuse/2017-07/msg00826.html suggested more or less reinstalling all of KDE (patternS). ;-)
was precisely to reinstall everything in the kde patterns ;-) I wrote https://lists.opensuse.org/opensuse/2017-07/msg00814.html about 4 hours before (after Carlos finally went to bed? Friday morning when, after 6AM?), which explained what Marc should share with the "experts", which he eventually did in the forum. An hour later Wolfgang was able to make that suggestion without asking Marc for any additional information. :-D
Thanks Carlos, and kudos to you as well! I suspect all great minds think alike! ;-) Marc I don't suspect all that much, except when it comes to Carlos and me. Both of us are relentless once we get started in any given help thread. :-| And I really appreciate your help as well Felix, I suspect all the experts were converging on the same solution as we got more data and
On 07/22/2017 10:14 PM, Felix Miata wrote: details... It is really wonderful that all of you are willing to take time to help the rest of us and share your expertise....
I still wonder:
1-what went wrong updating to cause the bad libQt5* package(s) installation. That we'll probably never know, unless there's something hiding in the monster /var/log/zypper.log that Marc might dig out. His zypper.log or zypper.log*.xz could contain libQt lines well into 4 digits, maybe even 5, and not worth trying.
Just for grins, I did a "cat zypper.log | grep libQt" and yep there is a lot of hits! Unfortunately I have a cron job that I run weekly to remove the excess *.xz files in /var/log, so at the moment there is only 1 zypper.log*.xz file... I am more that willing to share these if you think it would be helpful.
2-when exactly the updating occurred that went bad. This mailing list thread started on Tuesday, but Marc started a forum thread about this 15 days earlier.
Yeah, initially when things went bad on me, I first asked and started a thread on https://forums.opensuse.org but hit a lull in getting responses so I decided to start a second thread here on this mail list. Both groups have people that have been very helpful in the past so I tend to "flip a coin" in choosing where to ask a question first.
3-Are Axigen and Fail2Ban still broken? Anything else?
Fail2Ban has started working again also, and I didn't need to do anything special for it once the KDE desktop came back up. So I suspect it's problem was related. Axigen is a bit more disconcerting, what I discovered about it was that all of my configurations for it, in its configuration files had disappeared. These are located under /var/opt/axigen. What the Axigen server did, when it cannot find it's configuration files was to reconstruct them with default values, but that breaks its ability to support all the various domains and users that I had configured it for, and my ability to connect to it from anywhere except from localhost. My solution was to simply restore all of its configuration files from a backup recorded about 2 week prior to this failure. I have no idea why these configuration files were lost and had to be recreated. As for anything else, time will tell.. At the moment it looks good but I have not tested all my other services yet. The ones I use the most (daily) are working. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-21 18:47, Marc Chamberlin wrote:
Okdokey! Will start a thread on the opensuse-kde list... Hopefully will get to the bottom of this eventually! And will keep monitoring this thread in this list as well, in case there are any more bright ideas that spring up... Thanks for all your help... Marc..
I saw your thread on the forum. I see there that first you tried "zypper dup --no-allow-vendor-change". This is not recommended. But doing "zypper dup" which you did later is much worse! In the second case, with several active repos, you get a totum revolutum of packages. A package from one repo, a library from a conflicting repo... A "zypper dup" can only be done when there are only repos from the same vendor enabled (or taking some other complex measures which some people here do). This is avoided by adding the option "--no-allow-vendor-change", which is much safer. But still, unsafe. You must never do any kind of "zypper dup" on a stable release like leap. It is needed on rolling releases, like leap beta or tumbleweed. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 2017-07-21 05:19, Marc Chamberlin wrote:
On 07/20/2017 07:07 PM, Carlos E. R. wrote:
Hi again Carlos - OK, so I gather I should locate and delete all these xml files that "zypper ve" is complaining about?
My guess is yes. Just don't delete them but move them some temporary place: use your newly discovered 'mc' for it.
Incidentally, when I ran zypper ve again, I followed your advice to choose solution 2 - break application:xxx-.noarch by ignoring some of its dependencies, and ran into something that made me hesitant to do, it wanted to remove a couple packages and one of them kernel-default-4.4.74-18.20.1 scared me into bailing out. Here is the output, see what you think?
I think WTF? :-o I have no idea why, there is no previous message about the kernel. Unless there is a newer kernel installed as well, I see no reason, no conflict. Just move those xml files and try again. It is possible that you are missing some KDE component, so I would suggest to fire up YaST, software module, display patterns, and remove/add the KDE patterns so that its components are selected for installation if they were not.
Just post here "zypper lr --details". If lines wrap when pasting, add it as a text attachment to the post.
zypper lr --details > repolist.txt
and we'll have a look at it.
OK I attached repolist.txt to this posting... Marc...
Good. There are no major problems there, only cosmetics. Repo 5 and 14 are the same one, so delete one, say number 5 (Main Repository (Sources)). It is not enabled, so has no effect. Remove also number 7 (openSUSE:Leap:42.1). Use YaST for that, or zypper if you wish. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 07/21/2017 04:10 AM, Carlos E. R. wrote:
On 2017-07-21 05:19, Marc Chamberlin wrote:
On 07/20/2017 07:07 PM, Carlos E. R. wrote:
Hi again Carlos - OK, so I gather I should locate and delete all these xml files that "zypper ve" is complaining about? My guess is yes. Just don't delete them but move them some temporary place: use your newly discovered 'mc' for it. All righty, I moved all those offending xml files from /usr/share/metainfo to /usr/share/metainfo_saved.. But no joy with "zypper ve" after doing so. I got exactly the same behavior as before! Even after a reboot, it still complained about them and still wants to remove the same two packages. :-( BUT see below, I did manage to make some progress!
Incidentally, when I ran zypper ve again, I followed your advice to choose solution 2 - break application:xxx-.noarch by ignoring some of its dependencies, and ran into something that made me hesitant to do, it wanted to remove a couple packages and one of them kernel-default-4.4.74-18.20.1 scared me into bailing out. Here is the output, see what you think? I think WTF? :-o
I have no idea why, there is no previous message about the kernel. Unless there is a newer kernel installed as well, I see no reason, no conflict.
Just move those xml files and try again. Yeah, like I said, this didn't appear to work... (but see below!)
It is possible that you are missing some KDE component, so I would suggest to fire up YaST, software module, display patterns, and remove/add the KDE patterns so that its components are selected for installation if they were not.
OK, I think I did this right. Apparently it is not possible to remove a pattern per say, I had to select the "KDE Desktop Environment" pattern and then did a Delete All in this list. That lead to a number of dependency conflicts (5 of em) so for each I simply kept the package that something else was dependent on. (I didn't want to get into a dependency hell! ;-) ) Then I just reinstalled the "KDE Desktop Environment" pattern. So while I didn't break my system, still no joy getting a KDE desktop up and running... I could try the same for the "Plasma 5 Desktop" pattern? Apparently that solved the appdata.xml issues however! :-) marc@bigbang:~> su - Password: bigbang:~ # zypper ve Loading repository data... Reading installed packages... The following 2 packages are going to be REMOVED: brscan4 kernel-default-4.4.74-18.20.1 2 packages to remove. After the operation, 238.2 MiB will be freed. Some of the dependencies of installed packages are broken. In order to fix these dependencies, the following actions need to be taken: Continue? [y/n/...? shows all options] (y): n Still wants to remove these two packages however, and I don't think that is such a good idea so I haven't let it do so...
Just post here "zypper lr --details". If lines wrap when pasting, add it as a text attachment to the post.
zypper lr --details > repolist.txt
and we'll have a look at it.
OK I attached repolist.txt to this posting... Marc...
Good. There are no major problems there, only cosmetics. Repo 5 and 14 are the same one, so delete one, say number 5 (Main Repository (Sources)). It is not enabled, so has no effect.
Remove also number 7 (openSUSE:Leap:42.1).
Use YaST for that, or zypper if you wish.
I blew those two repos away... Marc... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-21 21:04, Marc Chamberlin wrote:
On 07/21/2017 04:10 AM, Carlos E. R. wrote:
On 2017-07-21 05:19, Marc Chamberlin wrote:
On 07/20/2017 07:07 PM, Carlos E. R. wrote:
Hi again Carlos - OK, so I gather I should locate and delete all these xml files that "zypper ve" is complaining about? My guess is yes. Just don't delete them but move them some temporary place: use your newly discovered 'mc' for it. All righty, I moved all those offending xml files from /usr/share/metainfo to /usr/share/metainfo_saved.. But no joy with "zypper ve" after doing so. I got exactly the same behavior as before! Even after a reboot, it still complained about them and still wants to remove the same two packages. :-( BUT see below, I did manage to make some progress!
Maybe because the complaint is that something wants those files, but does not find how to install them. I still have the same problem, but with "vmware-player.appdata.xml". I also tried "deinstallation of application...", which does nothing. I saw you got that part solved.
It is possible that you are missing some KDE component, so I would suggest to fire up YaST, software module, display patterns, and remove/add the KDE patterns so that its components are selected for installation if they were not.
OK, I think I did this right. Apparently it is not possible to remove a pattern per say, I had to select the "KDE Desktop Environment" pattern and then did a Delete All in this list. That lead to a number of dependency conflicts (5 of em) so for each I simply kept the package that something else was dependent on. (I didn't want to get into a dependency hell! ;-) ) Then I just reinstalled the "KDE Desktop Environment" pattern. So while I didn't break my system, still no joy getting a KDE desktop up and running... I could try the same for the "Plasma 5 Desktop" pattern?
Ah. My intention was to remove the pattern from the list of installed patterns, but not really to remove the contents, the packages. But nevermind. As that operation was successful, I would try the same for Plasma. Removing and installing the packages again is a good idea, though. You could use right click on the list of packages panel, then select "update unconditionally", which actually means reinstall if there are no updates.
Apparently that solved the appdata.xml issues however! :-)
Good!
marc@bigbang:~> su - Password: bigbang:~ # zypper ve Loading repository data... Reading installed packages...
The following 2 packages are going to be REMOVED: brscan4 kernel-default-4.4.74-18.20.1
2 packages to remove. After the operation, 238.2 MiB will be freed. Some of the dependencies of installed packages are broken. In order to fix these dependencies, the following actions need to be taken: Continue? [y/n/...? shows all options] (y): n
Still wants to remove these two packages however, and I don't think that is such a good idea so I haven't let it do so...
I don't understand why that happens. Try: cp /var/lib/rpm/Packages /dev/null rpm -q kernel* (the first line speeds up the second one on some computers) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Marc Chamberlin composed on 2017-07-20 15:02 (UTC-0700):
Felix Miata wrote: ...
Have you tried using the greeter to select an IceWM session instead of Plasma? That will probably define whether you have a KDE problem or an Xorg problem - unless maybe yours is an authorization problem. 'WINDOWMANAGER=/usr/bin/icewm startx -- :1' which AFAICT you didn't try as root login, would have served the same purpose. ... The WINDOWMANAGER command does indeed work and I do get a desktop with WINDOWMANAGER is not a command. It's a peculiar form of startup option for startx (only? on openSUSE). Oh, OK... Lots of nuances for me to learn, and keep it all stuffed in my poor ol head... Thanks for the info... it, regardless of whether I login in as root or as me! Not the desktop I want to use however as it does not run any of the KDE tools that I am familiar with. But at least this is some progress... I am not sure how to use the greeter to select an IceWM session instead of Plasma. When using KDM as my DISPLAYMANAGER all I see is a prompt for my login name, and then another for my password. Perhaps I don't understand what you mean by "greeter"? Somewhere on the login screen there are supposed to be options other than username and password, things like shutting down, rebooting, and selecting the desktop to start. There should be a desktop select list somewhere where IceWM is offered along with Plasma and others, like maybe LxDE, Gnome or XFCE. If you can't find IceWM anywhere on the login screen, it's almost certainly broken. Ouch! Like I mentioned to Carlos, on the KDM login screen I don't see anything that allows me to select a desktop... So yeah, if it should be
On 07/20/2017 06:44 PM, Felix Miata wrote: there then something is certainly broken, or I am missing something...
Greeter == login manager. Login manager used to say "Welcome to..." before theming became standard. My installations don't use greeter theming (useTheme=false in ?dmrc), so they all still include "Welcome to..." (KDM, KDM3, TDM and none other), and I always know where to look for DE selections and other options. :-)
Aw, OK... Interesting!
Maybe 'zypper ve' (verify) is called for here. Maybe something among your updates didn't complete correctly. Other than trying to use lightdm, sddm, kdebase3-kdm, gdm or some other greeter, I don't know what else to suggest given the content shown in your /var/lib/systemd/coredump/ and the could not start kdeinit5 errors. bigbang:/home/marc # zypper ve Loading repository data... Reading installed packages... 7 Problems: ... Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c): c Not sure what to do about these issues so I just bailed out... Marc... You obviously have KDE/Plasma package problems. :-(
If you have a file /etc/zypp/locks, what packages are in it ('zypper ll')? bigbang:/etc/zypp # ls apt-packagemap.d multiversion.d services.d systemCheck.d zypp.conf credentials.d repos.d systemCheck vendors.d zypper.conf bigbang:/etc/zypp # zypper ll
Do as Patrick told you. Verify the content in /etc/zypp/repos.d/ is all appropriate. One or more repos are, or at least at the time you updated, were, inappropriate or otherwise broken. That 'zypper ve' now says there are problems suggests most likely your repo configuration is bad (some kind of mismatch). If any of *.repo contain any version number other than the one you are running (42.2?) it needs to be fixed. All are plain text files. Does this include repo's that are disabled? I think I see a couple for 42.1 but I also think they are not enabled...
Follow that up with 'zypper ref; zypper ve' and reboot. If the greeter still can't give you a working Plasma session (or any other session type), and you are sure your repos are correctly configured, it's time to either take it to opensuse-kde, or if you are brave enough, give 'zypper -v dup' a try. (Here it would be the latter first. ;-) ) zypper ref; zypper ve and rebooting did not change anything... :-( Um, not sure how brave I am, I got my hands slapped a while back for having done a zypper -v dup when I should have done a simple zypper up... I was following some advice I got on another thread and learned
There are no package locks defined. that was not such a good idea... So let me know and if you still think I should, I will give it a shot... Thanks, Marc.. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-21 04:58, Marc Chamberlin wrote:
On 07/20/2017 06:44 PM, Felix Miata wrote:
Follow that up with 'zypper ref; zypper ve' and reboot. If the greeter still can't give you a working Plasma session (or any other session type), and you are sure your repos are correctly configured, it's time to either take it to opensuse-kde, or if you are brave enough, give 'zypper -v dup' a try. (Here it would be the latter first. ;-) ) zypper ref; zypper ve and rebooting did not change anything... :-( Um, not sure how brave I am, I got my hands slapped a while back for having done a zypper -v dup when I should have done a simple zypper up... I was following some advice I got on another thread and learned that was not such a good idea... So let me know and if you still think I should, I will give it a shot...
No, I would never use "zypper dup" on Leap. "never" can be qualified with "well, in that case..." but not yet. It is an emergency measure. We have to see "zypper lr --detail" without line wrapp first. Only in case of dramatic breakage, because results can also be dramatic. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Marc Chamberlin composed on 2017-07-20 19:58 (UTC-0700):
Felix Miata wrote:
Do as Patrick told you. Verify the content in /etc/zypp/repos.d/ is all appropriate. One or more repos are, or at least at the time you updated, were, inappropriate or otherwise broken. That 'zypper ve' now says there are problems suggests most likely your repo configuration is bad (some kind of mismatch). If any of *.repo contain any version number other than the one you are running (42.2?) it needs to be fixed. All are plain text files.
Does this include repo's that are disabled? I think I see a couple for 42.1 but I also think they are not enabled...
Do not guess. Inspect. Open MC. Install it with zypper if command-not-found results. It provides built in view, edit, facilitated filesystem navigation and much more while maintaining shell prompt at the ready. Each .repo that is disabled will contain an enabled=0 line. Given your current trouble, each you have that has 42.1 in it and does not have a corresponding file with 42.2 to supersede it should probably be edited to read 42.2 and contain enabled=1.
Follow that up with 'zypper ref; zypper ve' and reboot. If the greeter still can't give you a working Plasma session (or any other session type), and you are sure your repos are correctly configured, it's time to either take it to opensuse-kde, or if you are brave enough, give 'zypper -v dup' a try. (Here it would be the latter first. ;-) )
zypper ref; zypper ve and rebooting did not change anything... :-( Um, not sure how brave I am, I got my hands slapped a while back for having done a zypper -v dup when I should have done a simple zypper up... I was following some advice I got on another thread and learned that was not such a good idea... So let me know and if you still think I should, I will give it a shot...
zypper dup is only appropriate if you know the repos are appropriately configured and there is brokenness not otherwise readily or at all repairable. We are waiting to see your 'zypper lr --detail' output.... -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/20/2017 08:15 PM, Felix Miata wrote:
Marc Chamberlin composed on 2017-07-20 19:58 (UTC-0700):
Felix Miata wrote:
Do as Patrick told you. Verify the content in /etc/zypp/repos.d/ is all appropriate. One or more repos are, or at least at the time you updated, were, inappropriate or otherwise broken. That 'zypper ve' now says there are problems suggests most likely your repo configuration is bad (some kind of mismatch). If any of *.repo contain any version number other than the one you are running (42.2?) it needs to be fixed. All are plain text files. Does this include repo's that are disabled? I think I see a couple for 42.1 but I also think they are not enabled... Do not guess. Inspect. Open MC. Install it with zypper if command-not-found results. It provides built in view, edit, facilitated filesystem navigation and much more while maintaining shell prompt at the ready.
Each .repo that is disabled will contain an enabled=0 line. Given your current trouble, each you have that has 42.1 in it and does not have a corresponding file with 42.2 to supersede it should probably be edited to read 42.2 and contain enabled=1. Now that is an interesting tool! Never used Midnight Commander, will take a bit of getting use to it, but certainly looks promising! Thanks for the tip!
Anywise, only one of the .repo files references 42.1 - http-download.opensuse.org-f9bbad0f.repo bigbang:/etc/zypp/repos.d # cat http-download.opensuse.org-f9bbad0f.repo [http-download.opensuse.org-f9bbad0f] name=openSUSE:Leap:42.1 enabled=0 autorefresh=0 baseurl=http://download.opensuse.org/distribution/leap/42.1/repo/oss/ type=yast2 keeppackages=0 All the rest are for 42.2 though not all are enabled. Should I change this file? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Marc Chamberlin composed on 2017-07-20 22:49 (UTC-0700):
Anywise, only one of the .repo files references 42.1 - http-download.opensuse.org-f9bbad0f.repo
bigbang:/etc/zypp/repos.d # cat http-download.opensuse.org-f9bbad0f.repo [http-download.opensuse.org-f9bbad0f] name=openSUSE:Leap:42.1 enabled=0 autorefresh=0 baseurl=http://download.opensuse.org/distribution/leap/42.1/repo/oss/ type=yast2 keeppackages=0
All the rest are for 42.2 though not all are enabled. Should I change this file?
I can't think of any good reason not to delete the whole file. You are not using 42.1. Why a file with such a name exists at all I have no idea. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-19 22:41, Marc Chamberlin wrote:
On 07/18/2017 06:26 PM, Felix Miata wrote:
Marc Chamberlin composed on 2017-07-18 16:30 (UTC-0700):
Edit /etc/sysconfig/displaymanager and /etc/sysconfig/windowmanager directly. They are supposedly self-documenting, although the displaymanager I'm looking at ATM on TW, with kdm-4.11.22, for DISPLAYMANAGER= lists neither lightdm nor sddm as options; mine has "kdm" set. For Plasma 5 to be default set "kde-plasma" as DEFAULT_WM= in windowmanager.
Hi Felix, OK, I followed your instructions and set my DISPLAYMANAGER to kdm, and DEFAULT_WM to kde-plasma. Upon reboot, I now do get a login screen but when I enter my name and password I again get the popup dialog saying " Could not start kdeinit5. Check your installation. ". I cannot get any further than this, if I click on OK it just represents me with the login screen and this cycle repeats. CTRL-ALT-F3 gets me to the command line screen....
You should try to start a non kde desktop. Like icewm.
A brief start would be journalctl | grep fail OK, here is what returned, I cut out some obvious stuff that was not applicable, such as messages about Fail2Ban, vsftpd authentication failures, smartd Prefailure attributes etc.....
bigbang:/boot # journalctl | grep "Jul 19" | grep fail
There is a better command than grep for the current boot session. Simply use "journalctl -b | grep -i fail". As it is, I don't know if the failures to mount /home are during start or during halt today:
Jul 19 12:29:25 bigbang dbus[1127]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.Avahi.service': Refusing activation, D-Bus is shutting down. Jul 19 12:29:38 bigbang systemd[1]: slash-websites.mount: Unit entered failed state. Jul 19 12:29:38 bigbang systemd[1]: mail.mount: Unit entered failed state. Jul 19 12:29:38 bigbang systemd[1]: SuSE42.1.mount: Unit entered failed state. Jul 19 12:29:38 bigbang systemd[1]: var-run-user-1000.mount: Unit entered failed state. Jul 19 12:29:38 bigbang systemd[1]: slash-srv.mount: Unit entered failed state. Jul 19 12:29:38 bigbang systemd[1]: home.mount: Unit entered failed state. Jul 19 12:29:38 bigbang systemd[1]: slash-data.mount: Unit entered failed state. Jul 19 12:29:38 bigbang systemd[1]: SuSE12.3.mount: Unit entered failed state. Jul 19 12:29:38 bigbang systemd[1]: slash-boot-efi.mount: Unit entered failed state. Jul 19 12:29:38 bigbang systemd[1]: slash-data1.mount: Unit entered failed state. Jul 19 12:29:38 bigbang systemd[1]: slash-var-run-user-1000.mount: Unit entered failed state. Jul 19 12:29:38 bigbang systemd[1]: slash-tmp.mount: Unit entered failed state. Jul 19 12:29:56 bigbang kernel: Ignoring BGRT: failed to map image memory Jul 19 12:29:56 bigbang kernel: acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM Jul 19 12:29:56 bigbang kernel: [drm] failed to retrieve link info, disabling eDP Jul 19 12:30:12 bigbang systemd[1]: Dependency failed for Network Manager Wait Online. Jul 19 12:30:12 bigbang systemd[1]: NetworkManager-wait-online.service: Job NetworkManager-wait-online.service/start failed with result 'dependency'.
Did the just completed reinstallation and/or updates rebuild both/all initrds? And you just went above my pay grade, I dunno how to answer this..... Are the timestamps on /boot/initrd* all fresh? If there is one that is not, can you boot from its kernel and not have the black screen problem? Here is what I see in /boot
bigbang:/boot # ls -al total 54112 drwxr-xr-x 4 root root 4096 Jul 18 12:29 . drwxr-xr-x 38 root root 4096 Jul 6 16:38 .. -rw-r--r-- 1 root root 1725 Oct 7 2016 boot.readme -rw-r--r-- 1 root root 178511 Jun 24 06:32 config-4.4.73-18.17-default -rw-r--r-- 1 root root 178538 Jul 1 00:46 config-4.4.74-18.20-default drwxrwxr-x 3 root root 16384 Dec 31 1969 efi drwxr-xr-x 7 root root 4096 Jul 18 12:27 grub2 lrwxrwxrwx 1 root root 27 Jul 18 12:26 initrd -> initrd-4.4.74-18.20-default -rw------- 1 root root 9923568 Jul 14 21:15 initrd-4.4.73-18.17-default -rw------- 1 root root 9865028 Jul 18 12:27 initrd-4.4.74-18.20-default
initrd-4.4.73 was not regenerated. But this seems to be normal, looking at mine.
What about 'WINDOWMANAGER=/usr/bin/icewm startx -- :1'?
WINDOWMANAGER ??? Are you asking me to set DEFAULT_WM to this value, or something else? I will await your reply before I do anything.
No, just type that line and press enter, in the console, as root. The variable is set for this command only, not saved to file, and not even for later commands. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [07-19-17 19:50]:
On 2017-07-19 22:41, Marc Chamberlin wrote: [...]
WINDOWMANAGER ??? Are you asking me to set DEFAULT_WM to this value, or something else? I will await your reply before I do anything.
No, just type that line and press enter, in the console, as root. The variable is set for this command only, not saved to file, and not even for later commands.
startx /usr/bin/icewm -- :1 doesn't change anything and will use ice as wm -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Patrick Shanahan composed on 2017-07-19 20:34 (UTC-0400):
Carlos E. R. composed:
On 2017-07-19 22:41, Marc Chamberlin wrote: [...]
WINDOWMANAGER ??? Are you asking me to set DEFAULT_WM to this value, or something else? I will await your reply before I do anything.
No, just type that line and press enter, in the console, as root. The variable is set for this command only, not saved to file, and not even for later commands.
startx /usr/bin/icewm -- :1
doesn't change anything and will use ice as wm
See https://bugzilla.opensuse.org/show_bug.cgi?id=929016#c6 for the authority for my suggestion to use 'WINDOWMANAGER=/usr/bin/icewm startx -- :1' rather than 'startx /usr/bin/icewm -- :1'. I expect any difference in result between the two would be irrelevant or non-existant for purposes of OP's problem. Thinking about comments in OP about using YaST to reconfigure windowmanager and displaymanager in /etc/sysconfig/, I wonder how OP decided it was appropriate to do so in the first place? Could it be the change to/from kdm or lightdm or sddm to another has broken systemd's dm or pam configuration? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Felix Miata <mrmazda@earthlink.net> [07-19-17 21:15]:
Patrick Shanahan composed on 2017-07-19 20:34 (UTC-0400):
Carlos E. R. composed:
On 2017-07-19 22:41, Marc Chamberlin wrote: [...]
WINDOWMANAGER ??? Are you asking me to set DEFAULT_WM to this value, or something else? I will await your reply before I do anything.
No, just type that line and press enter, in the console, as root. The variable is set for this command only, not saved to file, and not even for later commands.
startx /usr/bin/icewm -- :1
doesn't change anything and will use ice as wm
See https://bugzilla.opensuse.org/show_bug.cgi?id=929016#c6 for the authority for my suggestion to use 'WINDOWMANAGER=/usr/bin/icewm startx -- :1' rather than 'startx /usr/bin/icewm -- :1'.
I expect any difference in result between the two would be irrelevant or non-existant for purposes of OP's problem.
Thinking about comments in OP about using YaST to reconfigure windowmanager and displaymanager in /etc/sysconfig/, I wonder how OP decided it was appropriate to do so in the first place? Could it be the change to/from kdm or lightdm or sddm to another has broken systemd's dm or pam configuration?
the last comment in the bug report you cite states, (on fedora 24) 'WINDOWMANAGER=/usr/bin/icewm startx -- :1' starts a KDE session startx /usr/bin/icewm -- :1 starts an icewm session in screen :1 specifying the wm env var stops xinitrc from being called and since I have added nothing to ~/.xinitrc, they result in the same display. but it difinitely does not start a kde/plasma session ??? but then I have openSUSE Tw, not fedora -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/19/2017 04:49 PM, Carlos E. R. wrote:
On 2017-07-19 22:41, Marc Chamberlin wrote:
On 07/18/2017 06:26 PM, Felix Miata wrote:
Marc Chamberlin composed on 2017-07-18 16:30 (UTC-0700):
Hi Felix, OK, I followed your instructions and set my DISPLAYMANAGER to kdm, and DEFAULT_WM to kde-plasma. Upon reboot, I now do get a login screen but when I enter my name and password I again get the popup dialog saying " Could not start kdeinit5. Check your installation. ". I cannot get any further than this, if I click on OK it just represents me with the login screen and this cycle repeats. CTRL-ALT-F3 gets me to the command line screen.... You should try to start a non kde desktop. Like icewm.
Hi Carlos, I think I just did and it seems to have worked, see my previous reply to Felix... I am still hoping to get my trusty KDE desktop back however...
A brief start would be journalctl | grep fail OK, here is what returned, I cut out some obvious stuff that was not applicable, such as messages about Fail2Ban, vsftpd authentication failures, smartd Prefailure attributes etc.....
bigbang:/boot # journalctl | grep "Jul 19" | grep fail
There is a better command than grep for the current boot session. Simply use "journalctl -b | grep -i fail".
As it is, I don't know if the failures to mount /home are during start or during halt today:
Nice!!! I can do that... Some of this is obviously not relevant, but I will show everything just in case... bigbang:/home/marc # journalctl -b | grep -i fail Jul 20 14:52:08 bigbang kernel: Ignoring BGRT: failed to map image memory Jul 20 14:52:08 bigbang kernel: acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM Jul 20 14:52:08 bigbang kernel: [drm] failed to retrieve link info, disabling eDP Jul 20 14:52:20 bigbang systemd[1]: Dependency failed for Network Manager Wait Online. Jul 20 14:52:20 bigbang systemd[1]: NetworkManager-wait-online.service: Job NetworkManager-wait-online.service/start failed with result 'dependency'. Jul 20 14:52:21 bigbang smartd[1132]: Device: /dev/sdc [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 99 to 100 Jul 20 14:52:25 bigbang bash[1159]: channel: no 'mirrors.updates.spamassassin.org' record found, channel failed Jul 20 14:52:33 bigbang systemd[1]: Starting Fail2Ban Service... Jul 20 14:52:40 bigbang fail2ban-client[2449]: 2017-07-20 14:52:40,347 fail2ban.server [2792]: INFO Starting Fail2ban v0.9.7 Jul 20 14:52:40 bigbang fail2ban-client[2449]: 2017-07-20 14:52:40,347 fail2ban.server [2792]: INFO Starting in daemon mode Jul 20 14:52:42 bigbang systemd[1]: Started Fail2Ban Service. Jul 20 14:52:51 bigbang server[1852]: log4j:ERROR setFile(null,true) call failed. Jul 20 14:52:51 bigbang server[1852]: 20-Jul-2017 14:52:51.943 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal One or more Filters failed to start. Full details will be found in the appropriate container log file Jul 20 14:52:51 bigbang server[1852]: 20-Jul-2017 14:52:51.943 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal Context [/JSPWiki] startup failed due to previous errors
Here is what I see in /boot
bigbang:/boot # ls -al total 54112 drwxr-xr-x 4 root root 4096 Jul 18 12:29 . drwxr-xr-x 38 root root 4096 Jul 6 16:38 .. -rw-r--r-- 1 root root 1725 Oct 7 2016 boot.readme -rw-r--r-- 1 root root 178511 Jun 24 06:32 config-4.4.73-18.17-default -rw-r--r-- 1 root root 178538 Jul 1 00:46 config-4.4.74-18.20-default drwxrwxr-x 3 root root 16384 Dec 31 1969 efi drwxr-xr-x 7 root root 4096 Jul 18 12:27 grub2 lrwxrwxrwx 1 root root 27 Jul 18 12:26 initrd -> initrd-4.4.74-18.20-default -rw------- 1 root root 9923568 Jul 14 21:15 initrd-4.4.73-18.17-default -rw------- 1 root root 9865028 Jul 18 12:27 initrd-4.4.74-18.20-default initrd-4.4.73 was not regenerated. But this seems to be normal, looking at mine.
What about 'WINDOWMANAGER=/usr/bin/icewm startx -- :1'? WINDOWMANAGER ??? Are you asking me to set DEFAULT_WM to this value, or something else? I will await your reply before I do anything.
No, just type that line and press enter, in the console, as root. The variable is set for this command only, not saved to file, and not even for later commands.
Thanks Carlos, yeah Felix straighten me out, I am not a Linux guru, by any means, and am still learning a lot of the ropes... I tried this and it did indeed bring up a desktop, just not one I like or want to use... But it is progress! Marc... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-21 00:56, Marc Chamberlin wrote:
On 07/19/2017 04:49 PM, Carlos E. R. wrote:
There is a better command than grep for the current boot session. Simply use "journalctl -b | grep -i fail".
As it is, I don't know if the failures to mount /home are during start or during halt today:
Nice!!! I can do that... Some of this is obviously not relevant, but I will show everything just in case...
Nothing relevant in that log, at least not regarding desktop.
Jul 20 14:52:08 bigbang kernel: [drm] failed to retrieve link info, disabling eDP suspicious.
Jul 20 14:52:20 bigbang systemd[1]: Dependency failed for Network Manager Wait Online. Jul 20 14:52:20 bigbang systemd[1]: NetworkManager-wait-online.service: Job NetworkManager-wait-online.service/start failed with result 'dependency'.
Unknown.
Jul 20 14:52:51 bigbang server[1852]: 20-Jul-2017 14:52:51.943 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal One or more Filters failed to start. Full details will be found in the appropriate container log file
Something regarding apache. :-? -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 07/20/2017 06:17 PM, Carlos E. R. wrote:
On 2017-07-21 00:56, Marc Chamberlin wrote:
On 07/19/2017 04:49 PM, Carlos E. R. wrote:
There is a better command than grep for the current boot session. Simply use "journalctl -b | grep -i fail".
As it is, I don't know if the failures to mount /home are during start or during halt today:
Nice!!! I can do that... Some of this is obviously not relevant, but I will show everything just in case... Nothing relevant in that log, at least not regarding desktop.
Thanks Carlos for your feedback....
Jul 20 14:52:08 bigbang kernel: [drm] failed to retrieve link info, disabling eDP suspicious. Yeah I dunno what this is either... Will do a Google search on it to see if anything pops...
Jul 20 14:52:20 bigbang systemd[1]: Dependency failed for Network Manager Wait Online. Jul 20 14:52:20 bigbang systemd[1]: NetworkManager-wait-online.service: Job NetworkManager-wait-online.service/start failed with result 'dependency'. Unknown.
I think I get this because I use wicked and not the KDE NetworkManager... I have seen complaints about NetworkManager since I switched back to using wicked some time ago. It hasn't cause any real problems so far, and my network connections work fine.
Jul 20 14:52:51 bigbang server[1852]: 20-Jul-2017 14:52:51.943 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal One or more Filters failed to start. Full details will be found in the appropriate container log file Something regarding apache. :-?
Yeah this is another fire I am fighting, one of my Apache/Tomcat webapp connections has a problem. I don't think it has anything to do with this desktop issue, in fact I have tried disabling all my optional services, such as Apache and Tomcat to see if it made any difference. No joy, it didn't. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Marc Chamberlin composed on 2017-07-20 19:31 (UTC-0700):
Carlos E. R. wrote:
Marc Chamberlin wrote:
Jul 20 14:52:08 bigbang kernel: [drm] failed to retrieve link info, disabling eDP
suspicious.
Yeah I dunno what this is either... Will do a Google search on it to see if anything pops...
eDP shouldn't exist except on a laptop. eDP means "embedded DisplayPort". Is this thread about a laptop? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/20/2017 08:00 PM, Felix Miata wrote:
Marc Chamberlin composed on 2017-07-20 19:31 (UTC-0700):
Marc Chamberlin wrote:
Jul 20 14:52:08 bigbang kernel: [drm] failed to retrieve link info, disabling eDP suspicious. Yeah I dunno what this is either... Will do a Google search on it to see if anything pops... eDP shouldn't exist except on a laptop. eDP means "embedded DisplayPort". Is
Carlos E. R. wrote: this thread about a laptop?
No this is a desktop system. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I found a bit more info that looks relevant to this thread/issue, that I thought I would also post. In my home directory, there is apparently a .xsession-errors file that also contains ominous looking info - bigbang:/home/marc # cat .xsession-errors-\:0 startkde: Starting up... /usr/bin/startkde: line 353: 3445 Segmentation fault (core dumped) LD_BIND_NOW=true /usr/lib64/libexec/kf5/start_kdeinit_wrapper --kded +kcminit_startup startkde: Could not start kdeinit5. Check your installation. but perhaps this is a result of the error reported by Xorg. Looking at line 353 in /usr/bin/startkde I see the following code - 350 351# We set LD_BIND_NOW to increase the efficiency of kdeinit. 352# kdeinit unsets this variable before loading applications. 353LD_BIND_NOW=true /usr/lib64/libexec/kf5/start_kdeinit_wrapper --kded +kcminit_startup 354if test $? -ne 0; then 355 # Startup error 356 echo 'startkde: Could not start kdeinit5. Check your installation.' 1>&2 357 test -n "$ksplash_pid" && kill "$ksplash_pid" 2>/dev/null 358 xmessage -geometry 500x100 "Could not start kdeinit5. Check your installation." 359 exit 1 360fi 361 FWIW this is apparently the source of the pop-up dialog message, that I sometimes was seeing, about failing to start kdeinit5... I dunno how to pursue this line of research any further however, start_kdeinit_wrapper is not a script but a binary file... Marc... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/18/2017 07:24 PM, Marc Chamberlin wrote:
startkde: Could not start kdeinit5. Check your installation.
Marc, This seems rather explicit. Can you confirm you can manually find kdeinit5? E.g. $ locate kdeinit5 or $ which kdeinit5, and a ls -al on the result to show permissions, etc.. And confirm the wrapper is present: $ ls -al /usr/lib64/libexec/kf5/start_kdeinit_wrapper I don't run plasma/fw5, so those are just educated guesses to confirm the files causing the failure are actually there and found. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/18/2017 11:08 PM, David C. Rankin wrote:
On 07/18/2017 07:24 PM, Marc Chamberlin wrote:
startkde: Could not start kdeinit5. Check your installation. Marc,
This seems rather explicit. Can you confirm you can manually find kdeinit5? E.g. $ locate kdeinit5 or $ which kdeinit5, and a ls -al on the result to show permissions, etc.. Hi David - And thank you for jumping it to try and help. Sure -
bigbang:/usr/bin # ls -al kdeinit5 -rwxr-xr-x 1 root root 57024 Oct 8 2016 kdeinit5
And confirm the wrapper is present:
$ ls -al /usr/lib64/libexec/kf5/start_kdeinit_wrapper
bigbang:/usr/bin # ls -al /usr/lib64/libexec/kf5/start_kdeinit_wrapper -rwxr-xr-x 1 root root 10520 Oct 8 2016 /usr/lib64/libexec/kf5/start_kdeinit_wrapper
I don't run plasma/fw5, so those are just educated guesses to confirm the files causing the failure are actually there and found.
Appreciate it, and HTHs... Marc.. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (7)
-
Carlos E. R. -
Carlos E. R. -
David C. Rankin -
Felix Miata -
Knurpht - Gertjan Lettink -
Marc Chamberlin -
Patrick Shanahan