2 questions - ltsp sound and unreliable booting

[Gavin McCullagh]

Hi,

On Wed, 15 Nov 2006, Rob Shugg wrote:

> yep looks good
> ~$ echo $ESPEAKER
> 192.168.0.150:16001
> 
> but I did plug my headphones into the server and tested alsa from the
> sound preferences - and yes the sound was comming out of the server
> sound card...
> Next I tried xmms from the command line and surpisingly it worked, i
> could hear the mp3 playing from the client. So I thought Id give totem
> a go- that worked too... 

It sort of sounds like the ESPEAKER environment variable is not set for
programs launched from the gnome menus.  I'm not certain where it gets set
and I don't have edubuntu to hand just at the minute.

I think you can test it like this.   /usr/bin/firefox should be a wrapper
script.  Open it up with an editor (you'll need sudo) and add this line to
the start of the script 

	export >/tmp/firefox_env_vars

Then launch firefox from the menus and take a look at /tmp/firefox_env_vars
which should contain all the env vars as they are for firefox.  If the
ESPEAKER is set, you should see a line something like:

	declare -x ESPEAKER="192.168.0.150:16001".

if not, that's a problem.  The same env vars should be available to other
programs run from the menus.  Then try running firefox from the command
line and you should see the ESPEAKER line in the file.

> but after closing these down and restarting
> them I get nothing again :-(
> totem gives me :
> video_out_xshm: received X error event: BadAccess (attempt to access
> private resource denied) and no sound

The fact that it didn't work a second time sounds sort of like a problem
with esd hanging or something.  Is this repeatable?  Does any program
produce sound at that point or is the problem just with totem?  

I would have thought the xshm error was an X issue, which shouldn't really
affect sound.  It might be that totem stops playing due to it I guess.

> on the other issue- this seems to be the last point the boot gets to
> before the hang. I have googled a few references to it but so for
> nothing definitive for edgy:
> RPC: failed to contact portmap (errno -5)

Sounds like the portmapper's failing to start on the client for some
reason.  This would prevent any nfs file sharing from working, which would
prevent the thin client from booting.  That it only happens sometimes might
suggest a race condition in the init scripts, ie that portmapper has not
started _yet_ at the point the nfs mount is called.

Gavin