I tried to open a new user for testing KDE stuff. I find that the default user, is now on [ctrl-Alt-F8] and that a new user gets put on [Ctl-Alt-F7] When did this change? And why?
This never has been changed on purpose.
And I have the default user running on VT-7 here, and a new session will be created on VT-8.
There has been a bug in plymouth (or was it KDM? Maybe both) that caused the first session to be created on VT-8 because plymouth still locked VT-7 when KDM started up, but that should have been fixed a year ago.
Still, try to disable plymouth as a test and see whether the X session is started on VT-7 then. You can do this by adding “plymouth.enable=0” to the boot options. For a one-time change press ‘e’ at the boot menu, search for the line starting with “linux”, and append this to the end of that line, then press ‘F10’ to boot.
Which display KDM is going to use can also be configured in /usr/share/kde4/config/kdm/kdmrc, but I suppose you haven’t changed that, right?
And also, I now notice that the second user, even idle, is using 100% of of a CPU.
I used KDE ‘switch user’ Logged in as ‘Tessa’. I then found (see above) that for some reason ‘Tessa’ was on ctl-alt-F7 and I (SP) was on ctrl-alt-F8. I switched back to SP, and find that one CPU is maxxed out.
http://i127.photobucket.com/albums/p145/wakou/htoptess_zps67e08d8f.png](Photo Storage)
As a supplementary question, how do I log out a user while NOT at her desktop? I can open a terminal and login as ‘her’, but how do I close her session on another desktop? I can SU as root and ‘kill’ her. But is there a ‘proper’ or ‘better’ way?
I sent
#> killall -u tessa
Which seems to do the trick, but also seems a bit drastic?
Thank you Wolfie…
I just tried again, with the same results, after a reboot.
I have been ‘looking’ at the file, but AFAIK, I have not made any drastic changes there. Here is my other thread, inc. a pastebin of kdmrc
https://forums.opensuse.org/showthread.php/501752-Boot-up-Num-lock?p=2670506#post2670506
I will try that next!
As a FYI here is my current boot options:
initrd=initrd ramdisk_size=512000 ramdisk_blocksize=4096 resume=/dev/sdb1 splash=silent quiet showopts modeset.nouveau=0 elevator=deadline
As another supplementary question, which cmd do I issue to see which vt’s are being used. I have tried
$>users
$>who
$>w
Never seen that either.
I don’t really use my Factory installation much, but I have KDE 4.14 installed on my standard system as well.
Maybe a graphics driver issue?
Does it go away when you disable Desktop Effects?
And since VT switching is involved here, even plymouth might play a role. So did you try to disable it?
As a supplementary question, how do I log out a user while NOT at her desktop? I can open a terminal and login as ‘her’, but how do I close her session on another desktop? I can SU as root and ‘kill’ her. But is there a ‘proper’ or ‘better’ way?
Killing the user’s “ksmserver” process should be enough to log her out.
You cannot really log her out properly, because you would have to know the dbus session address, for which you would have to be inside the X session (at least I know of no way to get this otherwise).
Ok, with value:
plymouth.enable=0
set, the switch user process seems to work as normal, with first user on vt7 and Tessa Mc Test, my beautiful assistant and PA, back in her usual seat at vt8. You say, Wolfie, that this was a previous bug, now thought to be cured?
Should I open a new one, or re-open the old?
Also I notice that user ‘Tessa’ is no longer using up 100% of a CPU.
So you are using the proprietary nvidia driver, I suppose?
This is known to have problems with VT-switching. It even tells so in the Xorg.0.log IIANM…
As another supplementary question, which cmd do I issue to see which vt’s are being used. I have tried
$>users $>who $>w
“who” should show which X display is used:
wolfi@amiga:~> who
wolfi :0 2014-10-23 08:15 (console)
wolfi pts/0 2014-10-23 08:17 (:0)
wolfi pts/1 2014-10-23 08:17 (:0)
test :1 2014-10-23 10:43 (localhost)
test pts/3 2014-10-23 10:44 (:1)
But I guess in your case, display :0 would be on VT-8 then. (I don’t remember exactly, the last time I saw this was about 1.5 years ago, before that bug/race condition was fixed)
kdmctl should help you though:
wolfi@amiga:~> kdmctl list
ok :1,vt8,test,plasma5, :0,vt7,wolfi,default,*
Well, there wasn’t really an explicit bug report about this particular issue AFAIR.
But it was intertwined with another issue, and apparently a symptom of the same issue, i.e. plymouth not releasing the VT in time.
http://bugzilla.opensuse.org/show_bug.cgi?id=816942#c30
http://bugzilla.opensuse.org/show_bug.cgi?id=811185#c10
Should I open a new one, or re-open the old?[/QUOTE]
I guess it’s better to open a new one, as it’s not really the same issue (although the underlying problem seems to be the same). (you might mention the old report though)
But, as I don’t see this in my VM, the nvidia driver might play a role here as well.
Can you try recovery mode and see if you can reproduce it there?
Btw, your kdmrc does contain this:
ServerVTs=-7
So KDM should start on VT-7 if it is available, and only use VT-8 (or higher) when VT-7 is in use already.
Thanks again Wolfie.
I am indeed using the NVidia driver. Nouveau does not work at all with my machine on 13.2. Locks, freezes panics or crashes. Seemingly random, after 30 seconds or ten minutes or anywhere between.
It did work OK on 13.1. Indeed, I thought that NVidia were no longer issuing drivers for my ancient graphics sub-system (in sig), so I had been using nouveau for some time. It was only in desperation with the freezing, crashing etc, that I went to the NVidia site, and found that they had issued a driver. I installed it the ‘hard’ way, and apart from some problems blacklisting nouveau, it compiled and runs perfectly.
I can’t find any reference, although my grepping skillz are not great!
linux:~ # cat /var/log/Xorg.0.log |grep -C 5 "VT"
1194.446] (II) Module nvidia: vendor="NVIDIA Corporation"
1194.446] compiled for 4.0.2, module version = 1.0.0
1194.446] Module class: X.Org Video Driver
1194.446] (II) NVIDIA dlloader X Driver 304.123 Wed Jul 2 11:01:29 PDT 2014
1194.446] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
1194.446] (++) using VT number 7
1194.453] (II) Loading sub module "fb"
1194.453] (II) LoadModule: "fb"
1194.453] (II) Loading /usr/lib64/xorg/modules/libfb.so
1194.454] (II) Module fb: vendor="X.Org Foundation"
just FYI, here is Xorg.0.log:
http://paste.opensuse.org/75391735
This is with the plymouth.enable=0 setting, btw.
! Now, rebooted without the plymouth.enable=0, this is from the Xorg.0.log:
linux:~ # cat /var/log/Xorg.0.log |grep -C 5 "VT"
6.174] (II) Module nvidia: vendor="NVIDIA Corporation"
6.174] compiled for 4.0.2, module version = 1.0.0
6.174] Module class: X.Org Video Driver
6.177] (II) NVIDIA dlloader X Driver 304.123 Wed Jul 2 11:01:29 PDT 2014
6.177] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
*** 6.178] (++) using VT number 8***
6.186] (II) Loading sub module "fb"
6.186] (II) LoadModule: "fb"
6.187] (II) Loading /usr/lib64/xorg/modules/libfb.so
6.193] (II) Module fb: vendor="X.Org Foundation"
So, Wolfie (as usual) was excellent in identifying the cause of this strange re-seating behaviour!
Here is the whole log, in case it is of any help…
Ok, actually I’m not sure about that, but I have seen it in the past.
Maybe the warning is not there because you use nouveau.modeset=0?
Try to remove that, blacklisting nouveau should be sufficient and is actually the preferred way to prevent nouveau from loading.
To do this create some file in /etc/modprobe.conf.d/ (the exact name doesn’t matter, use nvidia.conf e.g.) with the content:
blacklist nouveau
You could even append it to some existing file, 50-blacklist.conf e.g., but personally I prefer to create new files. Easier to remove again then.
Afterwards you would have to call “sudo mkinitrd” to copy the blacklist to the initrd (maybe dracut is smart enough to not copy nouveau to the initrd if nvidia is installed, but I’m not sure)
Maybe this would even fix your problem, but I cannot guarantee you that.
This is with the plymouth.enable=0 setting, btw.
Yes, the kernel command line is included in the Xorg log… 
Well, actually the nvidia driver only tells on which VT the graphical session is started. It’s not the nvidia driver that decides which VT to use, it’s KDM (or whoever starts the Xorg session).
What I meant was that maybe the nvidia driver is involved in causing plymouth to act up.
We are tappety-typing away at the same tie…
I have posted this:
IIRC, the Nvidia install script puts the blacklist in automagically. But I could not get the machine to boot until I added the nouveau.modeset=0
It is possible that I did not do a mkinitrd, so I will have another try…
I may be some time!
I do not have /etc/modprobe.conf.d/ dir.
linux:~ # ls -o /etc/ |grep modpr
drwxr-xr-x 2 root 4096 Oct 20 00:13 modprobe.d
I have /etc/modprobe.d/ I shall have a tinker about in there!
ls -o /etc/modprobe.d/
total 52
-rw-r--r-- 1 root 3647 Sep 25 09:10 00-system.conf
-rw-r--r-- 1 root 532 Nov 14 2012 10-unsupported-modules.conf
-rw-r--r-- 1 root 181 Oct 2 07:54 50-alsa.conf
-rw-r--r-- 1 root 4602 Oct 20 00:26 50-blacklist.conf
-rw-r--r-- 1 root 128 Sep 29 18:41 50-bluetooth.conf
-rw-r--r-- 1 root 33 Sep 25 11:13 50-ipw2200.conf
-rw-r--r-- 1 root 34 Sep 25 11:13 50-iwl3945.conf
-rw-r--r-- 1 root 18 Sep 25 11:13 50-prism54.conf
-rw-r--r-- 1 root 111 Oct 19 12:46 50-sound.conf
-rw-r--r-- 1 root 0 Oct 19 12:46 50-sound.conf.YaST2save
-rw-r--r-- 1 root 47 Nov 22 2011 99-local.conf
-rw-r--r-- 1 root 76 Oct 20 00:13 nvidia-installer-disable-nouveau.conf
-rw-r--r-- 1 root 18 Oct 20 00:36 nvidia.conf
linux:~ # cat /etc/modprobe.d/nvidia-installer-disable-nouveau.conf
# generated by nvidia-installer
blacklist nouveau
options nouveau modeset=0
Also:
linux:~ # cat /etc/modprobe.d/50-blacklist.conf |tail
# For some bridges both intel-agp and i82875p_edac are loaded. If i82875p_edac
# is loaded first it will grab the device. Then intel-agp doesn't work.
# Therefore we disable automatic loading of 82875p_edac. (Bug 213840)
blacklist i82875p_edac
#
# Blacklist the IBM s390 module for I/O dynamic configuration support
# Bug bnc#478601
blacklist chsc_sch
blacklist nouveau
And even!
linux:~ # cat /etc/modprobe.d/nvidia.conf
blacklist nouveau
So, I guess that nouveau SHOULD know that it is not required ATM!
I will try now without the boot setting…
So with this:
5.764] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.3-1.gd2bbe7f-desktop root=UUID=b9d62acb-8fc4-4a91-8f11-57fe9d5e3aed initrd=initrd ramdisk_size=512000 ramdisk_blocksize=4096 resume=/dev/sdb1 splash=silent quiet showopts elevator=deadline vga=normal
I am still allocated VT:8
linux:~ # cat /var/log/Xorg.0.log |grep -C 5 "VT"
6.096] (II) Module nvidia: vendor="NVIDIA Corporation"
6.097] compiled for 4.0.2, module version = 1.0.0
6.097] Module class: X.Org Video Driver
6.100] (II) NVIDIA dlloader X Driver 304.123 Wed Jul 2 11:01:29 PDT 2014
6.100] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
6.101] (++) using VT number 8
6.110] (II) Loading sub module "fb"
6.110] (II) LoadModule: "fb"
6.110] (II) Loading /usr/lib64/xorg/modules/libfb.so
6.112] (II) Module fb: vendor="X.Org Foundation"
Am trying now with that line ## out from the file /etc/modprobe.d/nvidia-installer-disable-nouveau.conf…
And still VT:8
But, at least, the nvidia driver seems to be happy without the nouveau.modeset=0 in the boot settings. I shall remove it.
Yes, that was a typo, sorry.
/etc/modprobe.d/ is correct, of course.
linux:~ # cat /etc/modprobe.d/nvidia-installer-disable-nouveau.conf # generated by nvidia-installer blacklist nouveau options nouveau modeset=0
Ok, so the nvidia installer did add it.
But I think it only does so if it detects nouveau running, i.e. if you run it in graphics mode and have not disabled modesetting (or are using recovery mode).
So, I guess that nouveau SHOULD know that it is not required ATM!
Right. The modeset=0 should definitely not be necessary then.
Probably your problem was the initrd.
And just to mention the obvious: it’s of course sufficient if there only is one “blacklist nouveau”. You could remove two of them if you want.
But then, having it more than once does not harm either. It might cause confusion if one day you would decide to use nouveau instead and uninstall the nvidia driver though…
Yeah, commenting out that one blacklist shouldn’t change anything.
Or do you meant “options nouveau modeset=0”?
This actually achieves the same as “nouveau.modeset=0” on the kernel command line.
Maybe remove that file completely (you have two other blacklists anyway) and run mkinitrd again.
But then, I don’t know at all whether modesetting on/off could possibly have an influence on your issue.