The install was fresh with no burden from prior versions. I fixed the keyboard layout, my concern with it is that it doesn’t work right out of the box after install.
After a sucessful boot into KDE, the system is back to the same faulty state as before, i.e. after reboot it fails to startx with the same error messages as before. The pam-config command no longer solves the issue.
Ok. KDE should respect the system setting then.
As I wrote, I am not aware of a general problem regarding this currently.
It was broken in Tumbleweed roughly a year ago, but got fixed back then.
I haven’t tried a fresh install recently, but I haven’t noticed any bug reports or user complaints here either.
What I wanted to point out though: there are two settings in the installer (unless this has changed recently):
One for the locale/language, and one for the keyboard layout.
Changing the locale doesn’t affect the keyboard layout and vice-versa.
Although setting a different language should initially also set a matching keyboard layout too.
After a sucessful boot into KDE, the system is back to the same faulty state as before, i.e. after reboot it fails to startx with the same error messages as before.
Are you booting to text mode and run startx manually, or what?
Did you change anything? (other than the keyboard layout)
Is it still the same error message from startx?
The pam-config command no longer solves the issue.
That’s to be expected.
This was a one-off problem, running the command once should fix the problem completely and it should not reappear.
So running it again won’t help.
You likely have a different, unrelated, problem now.
Maybe post the file /var/log/Xorg.0.log for further clues.
(use http://susepaste.org or similar if it is too big)
I was only fiddling with desktop settings, logging out and logging in to make changes take effect. I wanted to get the desktop go back to the “old classic dark” theme with monochrome “leave” icons as it was last summer for Plasma 5. I ended up with a white panel (the bar at the bottom) that is supposed to be dark when installing arquetype-breeze. So I decided to do a reboot to see if the “kickoff panel” will change and ended up with the same situation as before. The keyboard layout is now changed with YaST as per your instructions.
The challenge with retrieving the log files are not their size but how to get them out of the VM when the guest system is in such a crippled state. After a brief research I found termbin to be the right tool as I do have a working network connection inside the VM. The Xorg.o.log file:
You can get the output by entering ‘curl http://termbin.com/8q16’ inside a terminal window in Linux. Output of “sysctl status display-manager -l”:
These pastes will expire one month after submission, i.e. today.
Ok, shouldn’t cause this problem.
But did you install any updates, e.g.?
The challenge with retrieving the log files are not their size but how to get them out of the VM when the guest system is in such a crippled state. After a brief research I found termbin to be the right tool as I do have a working network connection inside the VM. The Xorg.o.log file:
Thanks anyway.
This basically just shows the same as you reported you get with startx though, unfortunately.
I have no idea what might cause this then, at the moment.
But some suggestions for now:
sudo rpm -e --allmatches virtualbox-guest-kmp-default
or:
Does either one help?
Switching to xdm doesn’t help. I had to uninstall virtualbox-guest-tools and virtualbox-guest-x11 before I could get to uninstall kmp-default. That made the system start “normally” again.
I tried to reinstall the drivers through the virtualbox guest additions cd but that reverted the system back to its faulty state.
Try to rename the Directory .gnupg in your home-directory.
Ok, so it seems to be a problem with the guest drivers…
You could do without, I suppose.
Otherwise I would suggest to remove openSUSE’s one, and install the latest ones from virtualbox.org.
If you need help with that, feel free to ask of course.
PS: What version of VirtualBox are actually using?
It might be an incompatibility between the host and the guest…
I’m using VirtualBox 4.3.36 and I got the same problem after running the installer on the virtualbox guest additions CD that you insert virtually into the VM, and it has a matching version number with the hypervisor. I suspect that the issue is that X somehow lost the capability of handling vendor-specific drivers.
Sure I could stick with VESA but the screen resolution is now 640x480 and I cannot change it in KDE “Monitor and DIsplay” settings. Also the mouse pointer is difficult to handle due to some strange “clipping issues”, or shall we call them “parallax issues” between guest mouse position and host mouse position? It is quite convenient to be able to have the desktop adjust automatically after the size of the window the VM is running in.
I have an experimental Archlinux install that works fine with VirtualBox and a Gentoo install that I use frequently, and it works just fine with VirtualBox. It was updated about 40 days ago and I’m not that keen on updating as KDE5 gets more and more crippled after each update.
Just inserting the guest additions CD is not enough.
You have to actually install them in the guest.
Tumbleweed does come with the guest additions (as you noticed), but they are the latest version (5.0.20) of course.
Normally it should still work, but there have been massive changes in the video driver in 5.0.20, so I’m not sure.
Even the virtualbox.org homepage recommends to install the 5.0.16 guest additions in case of problems.
I suspect that the issue is that X somehow lost the capability of handling vendor-specific drivers.
Definitely not.
Can you please post /var/log/Xorg.0.log? That should show what’s going wrong.
KDE5 gets more and more crippled after each update.
Sorry, but that’s nonsense IMHO.
Do you have any particular examples that would support that statement?
PS: you might have run in the pam-config problem that occured last week in Tumbleweed.
https://lists.opensuse.org/opensuse-factory/2016-06/msg00113.html
This can cause Xorg not starting with the vboxvideo driver because of insufficient privileges.
Try to run this and see if the vboxvideo driver works then:
sudo pam-config --add --systemd
Yes, KDE is getting more and more crippled. For example, they have removed the “Details” tab under Desktop Theme in system settings, and I expect more functionality to get removed in the future. It’s not first time I have had update problems and seeing things get corrupted.
I did not only “insert” the guest additions CD, I also ran the installer in it.
I have done an update right now and the same errors persist. And indeed the “pam-config” command does still not work and has already been suggested earlier in this thread.
The same errors persist. For logs, I’ll refer to the logs already posted. The current Xorg log file and ‘sysctl display-manager’ outputs are identicle to the termbin pastes I have submitted here earlier in this thread. I have verified manually, line by line that they are the same.
If uninstalling the VBox video drivers, be it 5.0.22, 5.0.20 or 4.3.36 and instead using the standard VESA drivers I can get into sddm and plasma so problem arises when using device specific drivers. Xorg doesn’t seem to be able to handle such drivers.