I have 11 virtual consoles and if I try to start gdm >=2.26.1 it seems to want to use console 7 and this can cause me to reboot because sometimes I cannot escape the damaged console. Reproducible: Always Steps to Reproduce: Use more than 6 virtual consoles -- I am in baselayout2. Upgrade gdm -- I tried 2.26.1 and 2.28.0. start gdm.1. 2. 3. Actual Results: A mess. gdm tries to take over console 7 and sometimes alt control-alt-f1 or whatever does not let me get out. Also, the keyboard can be messed up you type a letter and get something else. Expected Results: In my case gdm should go to console 12 and I should be able to log in.
Created attachment 206948 [details] emerge info
console 12 is already occupied by syslog output by default. There is a patch in gentoo's gdm that fixes earlier bugs with console detection, but it's only been testing with a number of console <10, so if you could forward this issue on the upstream bug that is noted in the ebuild, that'd be nice.
That was a hack to work around broken VT detection; which is still broken apparently. So the proper fix is not that old patch.
OK, I don't see where the previous fix for broken VT detection went in gdm; so maybe it went in X? @remi: what do you say?
Honestly, I have _no_ idea how VT detection works. IIRC, gdm should now rely on ConsoleKit for that, but I don't know what X does on its own. Thanks
@reporter: Q1: Did it work with gdm-2.20? Q2: Does VT detection work with startx ? Q3: Does restarting X via Ctrl-Alt-Backspace make gdm select the correct VT?
(In reply to comment #6) > @reporter: > Q1: Did it work with gdm-2.20? Yep, in fact it worked with gdm24.x, but that got pulled for some reason. > Q2: Does VT detection work with startx ? Not tested, will have to wait till I can have an environment where I can reboot if necessary. > Q3: Does restarting X via Ctrl-Alt-Backspace make gdm select the correct VT? Never will be able to tell, because I have to reboot immediately because my keyboard goes all weird -- is there some other reason for that or because of the conflict.
@reporter please open an upstream bug about this if it is still reproduceable with newer X and gdm Removing blocking 2.26 release since >=gdm-2.24 is masked
(In reply to comment #8) > @reporter please open an upstream bug about this if it is still reproduceable > with newer X and gdm > Removing blocking 2.26 release since >=gdm-2.24 is masked OK, where should I report this bug, then?
please keep the blockers around, it helps keeping track of "not so critical" bugs and it doesn't mean it'll stop gnome 2.26 from getting stable anyway as gdm is masked like you said.
I want to refer to http://bugs.gentoo.org/show_bug.cgi?id=215628#c5. The plain gdm-2.28 just doesn't care on which vt the Xorg runs (was FirstVT in /etc/X11/gdm/custom.conf). Free VT Detection is a kernel function (/usr/src/linux/include/linux/vt.h) with ioctl( "/dev/tty0", VT_OPENQRY, int *). Xorg autodetects what's free (xorg-server-1.6.5/hw/xfree86/os-support/linux/lnx_int.c:145), typically vt2 next to the /sbin/init output, and the hard coded agettys do interfere with the X servers. gdm und subsequent Xorg is started during runlevel 3 init from /sbin/init before the agettys defined inittab were started afterafter all runlevel-scripts were finished. In the past with rc_parallel=NO and daemonized xdm/gdm as last runlevel script to start, the startup of gdm/Xorg to long enough to start the agettys and grab the vt1..vt6. The gpm-2.28.2 from the tree - patched with the attachment of http://bugs.gentoo.org/show_bug.cgi?id=261339 - forces every Xorg instance to vt7, which is fine for single Xorg logins but crashes (most) Xorg/videodrivers on "switch user" scenarios. I've removed this patch from mine ebuild http://svn.xmw.de/gentoo-overlay/, is see the "greedy" behavior with first X on vt2 before every agetty.
Please see http://bugs.gentoo.org/show_bug.cgi?id=312017#c9 for a new patch, witch works on gdm versions 2.30.0, 2.29.92, 2.28.2 (minor mod). 2.26 has to be tested.
(In reply to comment #12) > Please see http://bugs.gentoo.org/show_bug.cgi?id=312017#c9 for a new patch, > witch works on gdm versions 2.30.0, 2.29.92, 2.28.2 (minor mod). 2.26 has to be > tested. I got it to work on 2.28.2 but the patches to the makefile and to the .conf file were wrong. It does properly detect the console now.
What's the status with 2.32 ebuild ?
Please get back to us.
portage will not let me emerge the gdm-2.32.0 due to lots of things being masked -- gtk+ and others. Should I wait till all thee are unmasked or are things in a state where I should go through and unmask what I need?
gnome 2.32 was unmasked a few weeks ago, it should be easy to unmask gdm for tests now.
I tried to use gdm-2.32.0. However the vtdetection patch was not included. I developed a patch, but either the patch did not work, or there is some other problem as when I sarted gdm, it did get the correct console, but I could not change my virtual console and had to reboot. I was able to downgrade to gdm2.28.2 with my patch with some difficulty, and this is now working.
Please do not stick with gdm-2.28 as I'm about to remove it from the tree.
On 3.0.0 (from gnome-overlay) it keeps opening on tty2 during startup (I use openrc)
There is a patch for this in the gnome overlay now, it will be added to the tree after some more testing.
When is this patch comming out? Is it just for gdm-3.0.0 or even version 2.X?
This is fixed with 2.32.1-r1, thanks for reporting.
It is not fixed! Problem still exists. Please leave it open.
(In reply to comment #24) > It is not fixed! Problem still exists. Please leave it open. If it's not fixed, please make sure you upgraded to 2.32.1-r1, and then open a new bug describing the problem since that would be a separate problem.
