I tracked this down on the KDE bug system and a temporary workaround is to put
RandomDevice=/dev/urandom in the [General] section of /etc/kde3/kdm/kdmrc. The reason for the failure to start is that by default /dev/random is used and that will block if there isn't enough randomness available. /dev/urandom will not block but will return less random results. I expect it's kdm that is trying to generate a random XAuth number before starting X which is why the XServer isn't even run and tweaking the timeouts won't help. I don't know where to place the blame for this bug. /etc/init.d/urnadom sets up /dev/random to have some randomness at startup but a quick test on my system shows that it is easy to use up all the random numbers and they don't get replenished until I type or move the mouse. This script indicates how much randomness is available: while true do dd if=/dev/random of=/dev/null bs=512 count=1 done Performing a find on a locally mounted disk gives around 10 bytes/s, waggling the mouse gets about 30 byte/s, find on the NFS mounted root disk gives 0 bytes/s. Maybe that is the bug, if the NFS system or the networking stuff could add to the randomness this bug wouldn't happen. I'm using TCP for NFS and I used to use UDP and they both stop kdm starting. If you have a local disk then a "find $mount-point > /dev/null &" just before /etc/init.d/kdm might help or just stick to /dev/urandom. I think this is either a Debian bug in not getting enough randomness in the system at startup or a Linux bug in not generating randomness from the network. Cheers, TIm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
