Bug 133908

Summary: Preload prevenst earlykdm from working propery when hardware changes between boots.
Product: [openSUSE] SUSE LINUX 10.0 Reporter: Patrick Hernandez <phernandez>
Component: OtherAssignee: Stephan Kulow <coolo>
Status: RESOLVED WONTFIX QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: werner
Version: Final   
Target Milestone: ---   
Hardware: x86-64   
OS: SuSE Linux 10.0   
Whiteboard:
Found By: Customer Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: Output of strace in earlykdm

Description Patrick Hernandez 2005-11-15 20:25:36 UTC
I have noticed an bug in the way preload interacts with the system.  I am running SUSE 10.0 Retail on a HP ZV5410US Athlon64 laptop computer which I sometimes place in a docking station.  The bug seemed to appear after the following sequence of events. 

1. I performed a fresh install and all the current updates through YOU.
2. I placed the laptop in the dock which has a USB keyboard and mouse attached. The dock also has volume controls, a serial port, additional audio ports (line out, SPDIF, etc.) USB hubs and power.
3. I ran the system for a few days in the dock.
4. When I removed the laptop from the dock, the system seemed to boot normally except KDM (XDM) didn't start with out any errors in the log except the statement that kdm timed out.

I was able to reproduce the bug consistently whenever the hardware seemed to change between boots.  After digging around the system configs and trying different things, I believe the problem is with preload.  I de-installed preload and the bug seemed to disappear.  I then found that another annoying bug appeared: the network configs didn't get activated at every boot on a random basis.  I re-installed preload and the network config problem went away and the first bug reappeared.  After digging some more, I found that earlykdm depends on preload.  I disabled earlykdm, and the problems seem to have disappeared and KDM comes up at every boot now.  I scanned all of the logs and couldn't find any errors being reported except the one mentioned above.
Comment 1 Michael Gross 2005-11-17 14:03:20 UTC
Stephan? Something for you?
Comment 2 Stephan Kulow 2005-11-17 14:15:33 UTC
this has nothing to do with preload exactly. This is a timing problem that is triggered depending on preload being there. I'm clueless how to debug this remotely ;(
Comment 3 Dr. Werner Fink 2005-11-17 14:21:29 UTC
Maybe this is related to bug #130451.  Please apply the YOU update
for insserv and execute as root the command insserv. After this
please redo you checks and report if the problem(s) stay around.
Comment 4 Patrick Hernandez 2005-11-17 18:25:23 UTC
I have already installed all relevant patches before this problem occured and I looked to see if insserv was included and it was.  I don't know if it occurred before the patches as I didn't start using the system until everything was installed.  I noticed in bug #130451 that there is mention of third party init scripts being a possible issue.  I do have the flexlm license manager for MATLAB set to start at boot and I did have to edit it to add the lines to make it work with innserv properly as just creating a link to it in the rc directory didn't work.  I'll try running the innserv command after re-enabling earykdm as you suggest and if the problem re-occurs, I will try disabling flexlm in init to see if that might be it.
Comment 5 Patrick Hernandez 2005-11-17 19:33:59 UTC
The suggestions didn't work as removing flexlm from init didn't either.  The only thing that seems to work around the problem is disabling earlykdm in init.  I have deduced that it may be related to using an external USB mouse as that is the hardware that seems to make the problem appear.  It isn't brand specific as I tried a couple of different mice and had the same problem.  The system will also come up normally after rebooting once or twice until the mouse changes again between boots.  The mice also work fine with no apparent problems or errors in the logs while the system is running.
Comment 6 Stephan Kulow 2005-11-30 13:38:47 UTC
I suggest you try adding a "strace -f -p $$ -o /tmp/somewhere &" in earlykdm - so far my only fix would be to trigger a sdb article as you seem to be the only one with such a problem.
Comment 7 Patrick Hernandez 2005-11-30 17:04:41 UTC
Should I place it at the beginning of the process or at the beginning of the start portion?
Comment 8 Stephan Kulow 2005-11-30 17:27:15 UTC
shouldn't matter
Comment 9 Patrick Hernandez 2005-12-01 19:36:52 UTC
Created attachment 59610 [details]
Output of strace in earlykdm
Comment 10 Patrick Hernandez 2005-12-01 19:39:28 UTC
The attachment was captured when the problem occurred after re-enabling earlykdm.  It seemed to occur at random this time.
Comment 11 Stephan Kulow 2006-02-04 18:41:41 UTC
ok, I have no idea what this is about and the workaround is simple (chkconfig earlykdm off) - and you're the only one reporting similiar problems.