Description of problem: ldm on some machines gets stuck in some cyclic failure. The login screen doesn't appear. We can switch to a console shell, but its still cyclically interrupted. /var/log/messages shows repeated: Jan 21 11:29:31 sol xinetd[2343]: START: ldminfod pid=5158 from=::ffff:172.31.100.101 Jan 21 11:29:31 sol xinetd[2343]: EXIT: ldminfod status=0 pid=5158 duration=0(sec) We have multiple ltsp clients, and we've seen this problem on different clients, but strangely never more than one at a time! Version-Release number of selected component (if applicable): ldminfod-2.0.27-1.fc10.x86_64 How reproducible: Seems to depend on client machine and the state of the weather ;-) Steps to Reproduce: 1. reboot ltsp client 2. 3. Actual results: /var/log/messages shows repeated: Jan 21 11:29:31 sol xinetd[2343]: START: ldminfod pid=5158 from=::ffff:172.31.100.101 Jan 21 11:29:31 sol xinetd[2343]: EXIT: ldminfod status=0 pid=5158 duration=0(sec) Expected results: ldm login screen Additional info:
I have been working with John on this. The cycle of the display is approximately on for one half second, off one and a half seconds. The message the clients display is this: ------------------------- NET: Registered protocol family 10 lo: Disabled Privacy Extensions hda-intel: Invalid position buffer, using LPIB read method instead. ------------------------- Similar behaviour occurs on both 32-bit and 64-bit clients. The message is not always visible, as quite often (particularly on clients connected with a VGA cable vs. DVI) the display does not sync to the signal from the machine before the display cycles off. Switching to the local shell running on the client machine while this is happening does not cause the flashing to change. Instead, the period of the flashing stays the same but the shell text flashes. While it is off it seems to buffer a characters or two -- but not during the first half second that it is off. Finally, when this does *not* happen, what appears to be the same message as above flashes for a VERY short time just prior to the display of the K12Linux login screenappears.
Disable ldm in lts.conf. Boot switch to a VT shell Run "X" manually Does X run and display the grey pattern?
In this file: /var/lib/tftpboot/ltsp/x86_64/lts.conf I changed SCREEN_01=ldm to SCREEN_01=shell When the system started I ran "X" and that resulted in the expected grey screen (and nothing else). When I reset the client and fixed lts.conf to turn ldm back on, I got the problem on the first boot of the client (it does this more than half the time). I then switched to screen 5 (which we have enabled for a local shell). Then, between the on/off screens I ran "X" and got the same grey screen -- that flashed just the same.(In reply to comment #2) > Disable ldm in lts.conf. > Boot > switch to a VT shell > Run "X" manually > Does X run and display the grey pattern?
We're still seeing this problem on occasion. A reboot of the LTSP server seems to cure it for a while.
I was able to get one particular x86_64 client to come up by turning off the LCD monitor during client reboot. We had thought that this issue was only with VGA connected monitors, but this one was DVI connected.
Hi John, I think that the problem might be that ldm is crashing rather than a problem with X. Could you please set "LDM_SYSLOG=True" and "SYSLOG_HOST=ip.addr.of.server", and then make sure that the server that SYSLOG_HOST points to has remote syslogging turned on? and then the next time this happens please send the syslog output to this bug report. If that still reveals nothing, could you try switching your SCREEN_01 back to shell and running /usr/share/ltsp/screen.d/ldm manually from the shell? Rather than starting and crashing, and starting and crashing, and so on it will only run and crash once, and hopefully have some useful output. Thanks, Ryan
Hello, I got the same problem. Server:Fedora 9, 2.6.27.19-78.2.30.fc9.i686, Lts 5, installed via packet-manager. After disabling ldm in the lts.conf file, I start X on the client manually and receive following error: xauth: error in locking authority file /.Xauthority
David, your post is almost completely meaningless garbage. > After disabling ldm in the lts.conf file, I start X on the client manually and > receive following error: > xauth: error in locking authority file /.Xauthority This is expected and has nothing to do with the ldm failure.
I got this problem with a TC Neoware e140. I was unable to boot the TC with ldm enabled. I changed the cable connection, from DVI to ANALOGIC, between the TC and the monitor and the problem was solved. Anyway, the: "EXIT: ldminfod status=0 pid=22507 duration=0(sec)" warning in the log file is still there.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Ignore me - I'm just trying to clear the "needinfo" spam on this closed bug.