[Ltsp-discuss] TFTP: Open Timeout error on client (or Transfer timed out error on server)

[John Hupp]

I had a thread named "LTSP-PNP on Lubuntu: Chromium
ERR_NAME_RESOLUTION_FAILED," but am starting a new thread to accurately
reflect the problem I'm now wrestling with.

I'm trying to troubleshoot an LTSP (the new LTSP-PNP) client boot
problem under Quantal. I installed with a single NIC per
https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp

The problem is that the LTSP client, after successfully getting DHCP
assignments, fails to download the pxelinux boot image. It reports
"PXE-E32: TFTP open timeout."

To be more specific on the DHCP assignments, it identifies my hardware
router as the DHCP server and the default gateway. It identifies the
LTSP server as proxy and boot server.

I can also run this on the server itself to get a similar failure:
$ cd /tmp
$ tftp 192.168.1.102 -v -m binary -c get /ltsp/i386/pxelinux.0
mode set to octet
Connected to 192.168.1.102 (192.168.1.102), port 69
getting from 192.168.1.102:/var/lib/tftpboot/ltsp/i386/pxelinux.0 to
pxelinux.0 [octet]
Transfer timed out.

A CRITICAL NOTE: This is using the default network-manager to configure
the network interface (using the default DHCP configuration, and the
connection is "Available to all users"). Apparently network-manager
also runs or works with dnsmasq, which provide DHCP and TFTP servers.

When I had TFTP and DHCP errors booting the client under LTSP5 and
Precise, I learned that the usual work-around was to configure the
network interface(s) via /etc/network/interfaces. I think this solved
some sort of a timing problem with the relevant services during bootup.

But that approach is apparently deprecated under Quantal and LTSP-PNP.
In fact, I can use that approach to get the client to boot successfully,
but it introduces a new problem on server and client: DNS resolution
fails. I understand that this happens because a non-default
/etc/network/interfaces causes ifupdown to configure network interfaces
instead of network-manager, but now network-manager is being relied upon
to provide DNS resolutionwith dnsmasq.

I can fix the DNS resolution problem by creating
/etc/resolvconf/resolv.conf.d/tail with contents:
nameserver (my nameserver 1)
nameserver (my nameserver 2)

-----------------------

But instead of patching up the old approach, I'd like to get the new
approach working right.

Looking for others who have dealt with the same problem, I have not
found much, but there was this 2010 thread:
http://ubuntuforums.org/showthread.php?t=1503710

One of the posters (#6) says that when he disabled NAT, TFTP started
working. I don't know what that means for me in my setup. But it did
get me to thinking about my little network running from my
consumer-class hardware router. Is dnsmasq in conflict with a service
being provided by the router? Is my router's firewall blocking FTP
communication between LTSP client and server?

If those are fruitless questions, then I would wonder why TFTP works
when I use /etc/network/interfaces and ifupdown to configure the network
interface, and it fails when network-manager governs instead.

By the way, this installation has seen very little modification. I
installed Quantal on a newly-formatted hard drive, allowing it to use
its default partitioning. I installed LTSP-PNP. I set up a scanner via
already-installed SANE. Also apcupsd for the sake of use with a UPS. I
installed HPLIP and an HP Laserjet printer.

-----------------------------

My (as-installed default) ltsp-server-dnsmasq.confin case that is of
interest:

# Configures dnsmasq for PXE client booting.
# All the files in /etc/dnsmasq.d/ override the main dnsmasq
configuration in
# /etc/dnsmasq.conf.
# You may modify this file to suit your needs, or create new ones in
dnsmasq.d/.

# Log lots of extra information about DHCP transactions.
#log-dhcp

# IP ranges to hand out.
dhcp-range=192.168.67.20,192.168.67.250,8h

# If another DHCP server is present on the network, you may use a proxy
range
# instead. This makes dnsmasq provide boot information but not IP leases.
# (needs dnsmasq 2.48+)
dhcp-range=192.168.1.0,proxy

# The rootpath option is used by both NFS and NBD.
dhcp-option=17,/opt/ltsp/i386

# Define common netboot types.
dhcp-vendorclass=etherboot,Etherboot
dhcp-vendorclass=pxe,PXEClient
dhcp-vendorclass=ltsp,"Linux ipconfig"

# Set the boot filename depending on the client vendor identifier.
# The boot filename is relative to tftp-root.
dhcp-boot=net:pxe,/ltsp/i386/pxelinux.0
dhcp-boot=net:etherboot,/ltsp/i386/nbi.img
dhcp-boot=net:ltsp,/ltsp/i386/lts.conf

# Kill multicast.
dhcp-option=vendor:pxe,6,2b

# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override

# We don't want a PXE menu since we're using a graphical PXELinux menu.
#pxe-prompt="Press F8 for boot menu", 3

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
pxe-service=X86PC, "Boot from network", /ltsp/i386/pxelinux

# A boot service type of 0 is special, and will abort the
# net boot procedure and continue booting from local media.
#pxe-service=X86PC, "Boot from local hard disk", 0

# Comment the following to disable the TFTP server functionality of dnsmasq.
enable-tftp

# The TFTP directory. Sometimes /srv/tftp is used instead.
tftp-root=/var/lib/tftpboot/

# Disable the DNS server functionality of dnsmasq by setting port=0
port=0

# Don't listen on lo, to prevent conflicts with Ubuntu's local resolver
hack (LP: #959037).
#except-interface=lo
#bind-interfaces

[John Hupp]

Post by John Hupp
I had a thread named "LTSP-PNP on Lubuntu: Chromium
ERR_NAME_RESOLUTION_FAILED," but am starting a new thread to
accurately reflect the problem I'm now wrestling with.
I'm trying to troubleshoot an LTSP (the new LTSP-PNP) client boot
problem under Quantal. I installed with a single NIC per
https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp
The problem is that the LTSP client, after successfully getting DHCP
assignments, fails to download the pxelinux boot image. It reports
"PXE-E32: TFTP open timeout."
To be more specific on the DHCP assignments, it identifies my hardware
router as the DHCP server and the default gateway. It identifies the
LTSP server as proxy and boot server.
$ cd /tmp
$ tftp 192.168.1.102 -v -m binary -c get /ltsp/i386/pxelinux.0
mode set to octet
Connected to 192.168.1.102 (192.168.1.102), port 69
getting from 192.168.1.102:/var/lib/tftpboot/ltsp/i386/pxelinux.0 to
pxelinux.0 [octet]
Transfer timed out.
A CRITICAL NOTE: This is using the default network-manager to
configure the network interface (using the default DHCP configuration,
and the connection is "Available to all users"). Apparently
network-manager also runs or works with dnsmasq, which provide DHCP
and TFTP servers.
When I had TFTP and DHCP errors booting the client under LTSP5 and
Precise, I learned that the usual work-around was to configure the
network interface(s) via /etc/network/interfaces. I think this solved
some sort of a timing problem with the relevant services during bootup.
But that approach is apparently deprecated under Quantal and
LTSP-PNP. In fact, I can use that approach to get the client to boot
DNS resolution fails. I understand that this happens because a
non-default /etc/network/interfaces causes ifupdown to configure
network interfaces instead of network-manager, but now network-manager
is being relied upon to provide DNS resolution with dnsmasq.
I can fix the DNS resolution problem by creating
nameserver (my nameserver 1)
nameserver (my nameserver 2)
-----------------------
But instead of patching up the old approach, I'd like to get the new
approach working right.
Looking for others who have dealt with the same problem, I have not
http://ubuntuforums.org/showthread.php?t=1503710
One of the posters (#6) says that when he disabled NAT, TFTP started
working. I don't know what that means for me in my setup. But it did
get me to thinking about my little network running from my
consumer-class hardware router. Is dnsmasq in conflict with a service
being provided by the router? Is my router's firewall blocking FTP
communication between LTSP client and server?
If those are fruitless questions, then I would wonder why TFTP works
when I use /etc/network/interfaces and ifupdown to configure the
network interface, and it fails when network-manager governs instead.
By the way, this installation has seen very little modification. I
installed Quantal on a newly-formatted hard drive, allowing it to use
its default partitioning. I installed LTSP-PNP. I set up a scanner
via already-installed SANE. Also apcupsd for the sake of use with a
UPS. I installed HPLIP and an HP Laserjet printer.
-----------------------------
My (as-installed default) ltsp-server-dnsmasq.conf in case that is of
# Configures dnsmasq for PXE client booting.
# All the files in /etc/dnsmasq.d/ override the main dnsmasq
configuration in
# /etc/dnsmasq.conf.
# You may modify this file to suit your needs, or create new ones in
dnsmasq.d/.
# Log lots of extra information about DHCP transactions.
#log-dhcp
# IP ranges to hand out.
dhcp-range=192.168.67.20,192.168.67.250,8h
# If another DHCP server is present on the network, you may use a
proxy range
# instead. This makes dnsmasq provide boot information but not IP leases.
# (needs dnsmasq 2.48+)
dhcp-range=192.168.1.0,proxy
# The rootpath option is used by both NFS and NBD.
dhcp-option=17,/opt/ltsp/i386
# Define common netboot types.
dhcp-vendorclass=etherboot,Etherboot
dhcp-vendorclass=pxe,PXEClient
dhcp-vendorclass=ltsp,"Linux ipconfig"
# Set the boot filename depending on the client vendor identifier.
# The boot filename is relative to tftp-root.
dhcp-boot=net:pxe,/ltsp/i386/pxelinux.0
dhcp-boot=net:etherboot,/ltsp/i386/nbi.img
dhcp-boot=net:ltsp,/ltsp/i386/lts.conf
# Kill multicast.
dhcp-option=vendor:pxe,6,2b
# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override
# We don't want a PXE menu since we're using a graphical PXELinux menu.
#pxe-prompt="Press F8 for boot menu", 3
# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
pxe-service=X86PC, "Boot from network", /ltsp/i386/pxelinux
# A boot service type of 0 is special, and will abort the
# net boot procedure and continue booting from local media.
#pxe-service=X86PC, "Boot from local hard disk", 0
# Comment the following to disable the TFTP server functionality of dnsmasq.
enable-tftp
# The TFTP directory. Sometimes /srv/tftp is used instead.
tftp-root=/var/lib/tftpboot/
# Disable the DNS server functionality of dnsmasq by setting port=0
port=0
# Don't listen on lo, to prevent conflicts with Ubuntu's local
resolver hack (LP: #959037).
#except-interface=lo
#bind-interfaces

Trying to make some further progress on this, I have been looking at the
dnsmasq man page (it's big!).

It seems to me that I need to get into position to examine whether
dnsmasq started up with the right configuration. Does LTSP-PNP start
its own instance of dnsmasq? If so, can I restart that particular
instance, and where does it launch from?

[Alkis Georgopoulos]

Post by John Hupp
$ cd /tmp
$ tftp 192.168.1.102 -v -m binary -c get /ltsp/i386/pxelinux.0

If that doesn't work for you, then it's a dnsmasq configuration problem, ...

Post by John Hupp
Does LTSP-PNP start its own instance of dnsmasq? If so, can I restart
that particular instance, and where does it launch from?

No. It just has a dependency on the dnsmasq package, which installs
dnsmasq as a service. So, you can use
$ sudo service dnsmasq restart
etc.


I'm only using LTS Ubuntu releases so I've no idea what's wrong with
dnsmasq on Quantal, but I fear that this too might be caused by the
"local resolver" hack that Ubuntu devs put in their dnsmasq package:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/959037

I.e. I'm talking about the "bind-interfaces" etc options that they added
in the default dnsmasq installation.

If the _only_ thing that you need to do to make dnsmasq work is to
switch from network-manager to /etc/network/interfaces,
then I'd mention the problem in that bug report above, not in ltsp-discuss.

Check also the workaround mentioned in that bug report about commenting
#dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf.


If you happen to post to ltsp-discuss again, the output of those
commands would be interesting:
$ sudo netstat -nap | grep dnsmasq
$ ps aux | grep dnsmasq
$ egrep -rv '^#|^$' /etc/dnsmasq.*

[John Hupp]

Post by Alkis Georgopoulos
$ sudo netstat -nap | grep dnsmasq
udp 0 0 127.0.0.1:69
0.0.0.0:* 887/dnsmasq
udp 0 0 127.0.0.1:69
0.0.0.0:* 1967/dnsmasq
udp 0 0 192.168.1.102:69
0.0.0.0:* 1967/dnsmasq

As you can see dnsmasq only binds to localhost on boot, not to
192.168.1.102. Mention that in the dnsmasq bug report in launchpad.

Post by Alkis Georgopoulos
$ egrep -rv '^#|^$' /etc/dnsmasq.*
/etc/dnsmasq.d/network-manager:bind-interfaces

I would also try removing the network-manager configuration file from
the dnsmasq.d dir, and restarting the server. I think that was the main
change from 12.04 to 12.10.
I think the rest of your input should go directly to the dnsmasq
launchpad bug report, not to the ltsp-discuss ML... :)

Removing /etc/dnsmasq.d/network-manager and restarting allows client
bootup to operate normally.

WOW, THANKS!

I'll see about adding some information to the dnsmasq bug report.

[John Hupp]

The client-server implementation of the UPS manager daemon apcupsd
relies on configuring /etc/apcupsd/apcupsd.conf differently on client
and server machines.

Under standard LTSP5 with a chroot this was accomplished
straightforwardly enough.

Can I somehow achieve the same result with LTSP-PNP?

After a quick re-read of the Ubuntu LTSP-PNP wiki and the man page for
lts.conf, it seems like /etc/ltsp/ltsp-update-image.excludes might come
into play, perhaps the CRONTAB parameter from lts.conf, perhaps a script
placed somewhere.

But it would be helpful if someone could give me a definitive push in a
certain direction.

[Alkis Georgopoulos]

Post by John Hupp
The client-server implementation of the UPS manager daemon apcupsd
relies on configuring /etc/apcupsd/apcupsd.conf differently on client
and server machines.
Under standard LTSP5 with a chroot this was accomplished
straightforwardly enough.
Can I somehow achieve the same result with LTSP-PNP?

The usual LTSP way to configure files on the client is to declare
variables in lts.conf, for example
SCANNER=True,
and then to have boot-time scripts that process them, e.g.
$ cat /usr/share/ltsp/init-ltsp.d/50-saned
# This file is sourced
if boolean_is_true "$SCANNER" ; then
[ -w "/etc/default/saned" ] && sed -i -e 's/RUN=no/RUN=yes/'
/etc/default/saned
fi

So what you need is a /usr/share/ltsp/init-ltsp.d/50-apcupsd script.

[John Hupp]

Post by Alkis Georgopoulos

Post by John Hupp
The client-server implementation of the UPS manager daemon apcupsd
relies on configuring /etc/apcupsd/apcupsd.conf differently on client
and server machines.
Under standard LTSP5 with a chroot this was accomplished
straightforwardly enough.
Can I somehow achieve the same result with LTSP-PNP?

The usual LTSP way to configure files on the client is to declare
variables in lts.conf, for example
SCANNER=True,
and then to have boot-time scripts that process them, e.g.
$ cat /usr/share/ltsp/init-ltsp.d/50-saned
# This file is sourced
if boolean_is_true "$SCANNER" ; then
[ -w "/etc/default/saned" ] && sed -i -e 's/RUN=no/RUN=yes/'
/etc/default/saned
fi
So what you need is a /usr/share/ltsp/init-ltsp.d/50-apcupsd script.

Thanks, I'll give that a try!

[John Hupp]

Post by Alkis Georgopoulos

Post by John Hupp
The client-server implementation of the UPS manager daemon apcupsd
relies on configuring /etc/apcupsd/apcupsd.conf differently on client
and server machines.
Under standard LTSP5 with a chroot this was accomplished
straightforwardly enough.
Can I somehow achieve the same result with LTSP-PNP?

The usual LTSP way to configure files on the client is to declare
variables in lts.conf, for example
SCANNER=True,
and then to have boot-time scripts that process them, e.g.
$ cat /usr/share/ltsp/init-ltsp.d/50-saned
# This file is sourced
if boolean_is_true "$SCANNER" ; then
[ -w "/etc/default/saned" ] && sed -i -e 's/RUN=no/RUN=yes/'
/etc/default/saned
fi
So what you need is a /usr/share/ltsp/init-ltsp.d/50-apcupsd script.

I hadn't known that lts.conf could be used to set variables other than
the ones defined for its usage, but I added "ISLTSPCLIENT=True" and then
created /usr/share/ltsp/init-ltsp.d/50-apcupsd.

[After a while I also realized that I needed to set that to executable.
Newbies!]

Initial content was:

# For ISLTSPCLIENT=True set in LTS.conf, this modifies server
apcupsd.conf for booting on clients

if "$ISLTSPCLIENT" ; then
[ -w "/etc/apcupsd/apcupsd.conf" ] && sed -i \
-e 's/UPSCABLE usb/UPSCABLE ether' \
-e 's/UPSTYPE usb/UPSTYPE net' \
-e 's/DEVICE/DEVICE Lubuntu1:3551' \
-e 's/TIMEOUT 105/TIMEOUT 60' \
-e 's/NETSERVER on/NETSERVER off' \
-e 's/NISIP 0.0.0.0/NISIP 127.0.0.1' \
/etc/apcupsd/apcupsd.conf
fi

When that didn't work, I thought, "Wait, for LTSP clients, we always
want this behavior. No need to check a variable." So I simplified to:

sed -i /etc/apcupsd/apcupsd.conf \
-e 's/UPSCABLE usb/UPSCABLE ether' \
-e 's/UPSTYPE usb/UPSTYPE net' \
-e 's/DEVICE/DEVICE Lubuntu1:3551' \
-e 's/TIMEOUT 105/TIMEOUT 60' \
-e 's/NETSERVER on/NETSERVER off' \
-e 's/NISIP 0.0.0.0/NISIP 127.0.0.1'

That didn't work either (manifested most clearly by the fact that the
client does not initiate shutdown 45 seconds before the server, as the
above configuration would dictate, but tries -- and fails -- to shut
down when the server shuts down). Anyone know why I'm not getting results?

[John Hupp]

Post by John Hupp

Post by Alkis Georgopoulos

Post by John Hupp
The client-server implementation of the UPS manager daemon apcupsd
relies on configuring /etc/apcupsd/apcupsd.conf differently on client
and server machines.
Under standard LTSP5 with a chroot this was accomplished
straightforwardly enough.
Can I somehow achieve the same result with LTSP-PNP?

The usual LTSP way to configure files on the client is to declare
variables in lts.conf, for example
SCANNER=True,
and then to have boot-time scripts that process them, e.g.
$ cat /usr/share/ltsp/init-ltsp.d/50-saned
# This file is sourced
if boolean_is_true "$SCANNER" ; then
[ -w "/etc/default/saned" ] && sed -i -e 's/RUN=no/RUN=yes/'
/etc/default/saned
fi
So what you need is a /usr/share/ltsp/init-ltsp.d/50-apcupsd script.

I hadn't known that lts.conf could be used to set variables other than
the ones defined for its usage, but I added "ISLTSPCLIENT=True" and
then created /usr/share/ltsp/init-ltsp.d/50-apcupsd.
[After a while I also realized that I needed to set that to
executable. Newbies!]
# For ISLTSPCLIENT=True set in LTS.conf, this modifies server
apcupsd.conf for booting on clients
if "$ISLTSPCLIENT" ; then
[ -w "/etc/apcupsd/apcupsd.conf" ] && sed -i \
-e 's/UPSCABLE usb/UPSCABLE ether' \
-e 's/UPSTYPE usb/UPSTYPE net' \
-e 's/DEVICE/DEVICE Lubuntu1:3551' \
-e 's/TIMEOUT 105/TIMEOUT 60' \
-e 's/NETSERVER on/NETSERVER off' \
-e 's/NISIP 0.0.0.0/NISIP 127.0.0.1' \
/etc/apcupsd/apcupsd.conf
fi
When that didn't work, I thought, "Wait, for LTSP clients, we always
sed -i /etc/apcupsd/apcupsd.conf \
-e 's/UPSCABLE usb/UPSCABLE ether' \
-e 's/UPSTYPE usb/UPSTYPE net' \
-e 's/DEVICE/DEVICE Lubuntu1:3551' \
-e 's/TIMEOUT 105/TIMEOUT 60' \
-e 's/NETSERVER on/NETSERVER off' \
-e 's/NISIP 0.0.0.0/NISIP 127.0.0.1'
That didn't work either (manifested most clearly by the fact that the
client does not initiate shutdown 45 seconds before the server, as the
above configuration would dictate, but tries -- and fails -- to shut
down when the server shuts down). Anyone know why I'm not getting results?

Continuing to puzzle over this, I realize that, as usual, I barely know
enough to ask a good question. But to review some bits I have gathered:

Background: The apcupsd master-slave configuration (I called it
client-server above, but that is not apcupsd's nomenclature) relies on
an instance of apcupsd running on each machine, and it functions in
master mode or slave mode depending on entries in /etc/apcupsd/apcupsd.conf.

On the LTSP server, apcapsd loads from the symlink in the appropriate

[Vagrant Cascadian]

But I find no documentation regarding scripts in /usr/share/ltsp/init-ltsp.d.
Is this an LTSP-PNP innovation?

The general ltsp documentation probably needs a bit of updating.

The init-ltsp.d hooks are executed from /sbin/init-ltsp, which is a fairly
recent LTSP development (5.3+). It is used in recent LTSP versions, regardless
of how you create the LTSP boot environment (i.e. thin client, fat client,
LTSP-PNP).

/sbin/init-ltsp is run in the place of /sbin/init, as the first process to run,
and then hands it over to the *real* /sbin/init. The kernel boot parameter "init"
is used to select the init process, and with LTSP, it passes "init=/sbin/init-ltsp".

This hopefully allows more shared code and consistancy between different
distros without relying on the same sort of initramfs, or in theory, no
initramfs at all.

Could it be that these scripts are executed
after apcupsd has already started in the client environment? If that is so,
then using a /usr/share/ltsp/init-ltsp.d/50-apcupsd script to edit /etc/
apcupsd/apcupsd.conf would have no effect.

It will definitely run before any daemons or other processes are started, so
you shouldn't worry about that.


live well,
vagrant

[John Hupp]

Alkis G wrote withmuch of the same information. Thanksto both of you
for the clarifications.

Post by Vagrant Cascadian

But I find no documentation regarding scripts in /usr/share/ltsp/init-ltsp.d.
Is this an LTSP-PNP innovation?

The general ltsp documentation probably needs a bit of updating.
The init-ltsp.d hooks are executed from /sbin/init-ltsp, which is a fairly
recent LTSP development (5.3+). It is used in recent LTSP versions, regardless
of how you create the LTSP boot environment (i.e. thin client, fat client,
LTSP-PNP).
/sbin/init-ltsp is run in the place of /sbin/init, as the first process to run,
and then hands it over to the *real* /sbin/init. The kernel boot parameter "init"
is used to select the init process, and with LTSP, it passes "init=/sbin/init-ltsp".
This hopefully allows more shared code and consistancy between different
distros without relying on the same sort of initramfs, or in theory, no
initramfs at all.

Could it be that these scripts are executed
after apcupsd has already started in the client environment? If that is so,
then using a /usr/share/ltsp/init-ltsp.d/50-apcupsd script to edit /etc/
apcupsd/apcupsd.conf would have no effect.

It will definitely run before any daemons or other processes are started, so
you shouldn't worry about that.
live well,
vagrant
------------------------------------------------------------------------------
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net
_____________________________________________________________________
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net

[John Hupp]

My xterm windows on client machines are weird-looking under Lubuntu
Quantal. The characters are tinged with all the colors of the rainbow,
and nothing appears as I type.

Anyone else experience this?

[John Hupp]

I have been wondering how sed commands can be used in ltsp init scripts
to modify configuration files before services are run and before there
is an ssh session on the server. Which is to say, how does that work
with a read-only NBD boot image?

I have seen some mention of the use of a union filesystem with a
writable overlay directory (such as in a RAM disk or in the mounted /var
directory on the server). Or else in a similar scheme, with the use of
a Copy-on-Write scheme which again directs writes to another destination.

Anyone care to scribe a few linesabout how LTSP accomplishes this?

[John Hupp]

Post by John Hupp
My xterm windows on client machines are weird-looking under Lubuntu
Quantal. The characters are tinged with all the colors of the
rainbow, and nothing appears as I type.
Anyone else experience this?

Following is a screen shot. Note the colors in the characters, the
vertical gray bar, and no window controls. And again, nothing appears
as I type, though if I hit Enter, what I typed is executed.

If I instead run "ltsp-localapps lxterm" to bring up a terminal within
the native client session, that terminal is normal.

[Jay Goldberg]

Looks like the window manager is not running and sub-pixel
hinting<https://en.wikipedia.org/wiki/Subpixel_rendering>has gone
awry. The reason nothing appears when you type is because focus is
not in the foremost window. When a window manager is not running, input
goes to the most recently launched program, and not the foreground window
as you'd expect.

Post by John Hupp
My xterm windows on client machines are weird-looking under Lubuntu
Quantal. The characters are tinged with all the colors of the rainbow, and
nothing appears as I type.
Anyone else experience this?
Following is a screen shot. Note the colors in the characters, the
vertical gray bar, and no window controls. And again, nothing appears as
I type, though if I hit Enter, what I typed is executed.
If I instead run "ltsp-localapps lxterm" to bring up a terminal within the
native client session, that terminal is normal.
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_____________________________________________________________________
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net

[John Hupp]

Except for the bit about focus, I have only a bare idea of what you just
said, though as a technical explanation I hope it will move things
toward a solution.

But noting that other programs launch and run without such aberrations,
it did cause me consider that I was launching lxterm via Ctrl-Alt-T.
When I launch with Alt-F2 + "xterm" the terminal window is normal.

Between your explanation and this additional fact, does this gain us
something(other than a workaround)?

Looks like the window manager is not running and sub-pixel hinting
<https://en.wikipedia.org/wiki/Subpixel_rendering> has gone awry. The
reason nothing appears when you type is because focus is not in the
foremost window. When a window manager is not running, input goes to
the most recently launched program, and not the foreground window as
you'd expect.

Post by John Hupp
My xterm windows on client machines are weird-looking under
Lubuntu Quantal. The characters are tinged with all the colors
of the rainbow, and nothing appears as I type.
Anyone else experience this?

Following is a screen shot. Note the colors in the characters,
the vertical gray bar, and no window controls. And again, nothing
appears as I type, though if I hit Enter, what I typed is executed.
If I instead run "ltsp-localapps lxterm" to bring up a terminal
within the native client session, that terminal is normal.
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_____________________________________________________________________
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net
<http://irc.freenode.net>
--
Jay Goldberg | AvianBLUE Network Systems
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_____________________________________________________________________
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net