Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 215628 - x11-apps/xinit + gdm + baselayout-2 = dead keyboard
Summary: x11-apps/xinit + gdm + baselayout-2 = dead keyboard
Status: RESOLVED DUPLICATE of bug 261339
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo X packagers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-03-31 19:15 UTC by Zdenek Behan
Modified: 2009-03-29 18:36 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zdenek Behan 2008-03-31 19:15:20 UTC
This bug is only valid for when using the /etc/init.d/xdm rc-script in DEFAULT runlevel, configured to use gdm, on a baselayout-2 system.

The rc script correctly fires gdm. This starts before the runlevel is finished, and some other services keep starting in the background. When gdm is up, the keyboard control is then usurped by agetty on tty1, but display stays on gdm, leaving the system unusable. This can be gotten out of only by using interactive boot and skipping the xdm service.
It happens for all versions of baselayout-2 that i have tried, and surprisingly is no problem when using kdm, which retains keyboard input.

It may also be simply a timing problem, and if X was starting a few seconds longer, it would remove the issue. However, adding "before *" into /etc/init.d/xdm didn't solve the problem, either.

--------------------
Simple workaround (without any modifications):
Don't add xdm into any runlevel, after bootup login as root, and start the service manually. In this case, it will keep the keyboard input.

--------------------
As a more complex workaround, i tried using the delayed X startup, using "/sbin/telinit a" and startDM.sh, simply by adding the appropriate line into inittab to start another agetty on the desired X terminal (tty10 in my case).
I found out that this feature is broken in baselayout-2 because:

1) xdm first collects some information about the desired DM, the binary, and its options, and then exports it using:
    save_options "service" "${EXE}"
    save_options "name"    "${NAME}"
    save_options "pidfile" "${PIDFILE}"
2) xdm checks whether the desired VT is being used in inittab, if so, it does "telinit a" to make init run "startDM.sh" after runlevel is done, otherwise it starts "startDM.sh" manually.
3) startDM.sh uses similar commands as in 1 to import the information about desired DM, and attempts to start it:
EXEC="$(get_options service)"
NAME="$(get_options name)"
PIDFILE="$(get_options pidfile)"

Since save_options and get_options seem to work through enviroment rather than temporary files, this only works if startDM.sh was invoked by /etc/init.d/xdm. If /sbin/init invokes the same script after runlevel is finished, it only produces couple of error messages and dies.

--------------------
My very crude fix:

1) Make startDM.sh wait on a lockfile (/tmp/.xdmlock) at startup
2) Make xdm always a) "touch /tmp/.xdmlock", b) "/sbin/telinit a", c) run "startDM.sh &" instead of the current logic
(because i didn't see any advantage in starting X before all consoles are up anyway)
3) In inittab, instead of "/etc/X11/startDM.sh", start "rm /tmp/.xdmlock"

This pretty much works in all situations relevant for me. I can supply patches for the relevant files, altough they are mostly trivial and i can think of 100 nicer solutions.
Comment 1 Harald Urkan 2008-09-29 15:40:34 UTC
> However, adding "before *" into
> /etc/init.d/xdm didn't solve the problem, either.

Try:

depend() {
    # yada yada
    after *
}
 
You might get some circular dependencies warning if other initscripts use "after *" as well, but the system should sort this out by itself.

I'd be interested in how to properly fix this, too.
Comment 2 Andreas Duering 2008-11-15 12:24:38 UTC
Does your gdm log (normally /var/log/gdm/:0.log say anything interesting?

I had a similar problem, it said I am missing a evdev module.
After I emerged x11-drivers/xf86-input-evdev everything worked again
Comment 3 Zdenek Behan 2008-11-15 12:55:29 UTC
(In reply to comment #2)
> Does your gdm log (normally /var/log/gdm/:0.log say anything interesting?
> 
> I had a similar problem, it said I am missing a evdev module.
> After I emerged x11-drivers/xf86-input-evdev everything worked again

I should probably re-try this bug again, because it's been a few months since i reported it. However, i'm pretty sure i was already using evdev back then.

I basically "fixed" it for myself the "crude" way i described in my initial post, and i can transform that into nice wooly cuddly patches, if anyone's interested. However, it's just a workaround.
Comment 4 Gilles Dartiguelongue gentoo-dev 2009-01-04 11:07:13 UTC
hi there, I started hitting this on my macbook after openrc-0.4 and xorg-server-1.5.3 updates on 21 december. I have rc_parallel set to no for what it's worth.
Comment 5 Michael Weber (RETIRED) gentoo-dev 2009-02-19 04:09:03 UTC
Hi, yeah, funny thing.

I've tried following setup with RC_PARALLEL_STARTUP="yes":
terminals on tty1 to 10, syslog-ng on 11 and gdm/X on 12.

With xdm started by runlevel default ended up with an X on vt7 without keyboard interaction (the agetty thing).
xdm restarted via ssh resulted in an X on vt12, perfect.
Some tests and dangling with /etc/X11startDM.sh and /etc/conf.d/xdm 
(CHECKVT=7 or 12) ended in the awareness, that CHECKVT is just ... crap.

Later I've tried to start xdm from local.start and got X on random vt's ...
there's a race condition between the fork/exec in the backgrounded gdm to X
and the startup of the agetty instances after the last init-script.

Some straces and strings /usr/bin/gdm revealed a hard coded FirstVT=7 in gdm

My solution is /etc/X11/gdm/custom.config:

[daemon]
FirstVT=12
VTAllocation=true

n8
Comment 6 Xavier Miller gentoo-dev 2009-03-02 19:45:13 UTC
Same problem for my Acer Aspire One laptop (intel 945) in ~x86, with xf86-intel driver. Tested with and without uvesafb, it doesn't matter.

On my nVidia + uvesafb ~amd64 desktop, I don't have the problem.
Comment 7 Gilles Dartiguelongue gentoo-dev 2009-03-29 18:36:32 UTC

*** This bug has been marked as a duplicate of bug 261339 ***