On 12/7/2013 8:20 PM, John Hupp wrote:
On 12/6/2013 6:54 PM, John Hupp wrote:
On 12/6/2013 6:16 PM, John Hupp wrote:
On 11/30/2013 1:39 PM, John Hupp wrote:
On 11/25/2013 7:30 PM, John Hupp wrote:
On 11/21/2013 11:26 AM, John Hupp wrote:
On 11/20/2013 12:37 PM, John Hupp wrote:
On 11/20/2013 12:24 PM, John Hupp wrote:
On 11/11/2013 10:31 AM, Jay Goldberg wrote:
On Fri, Nov 8, 2013 at 3:48 PM, John Hupp <l...@prpcompany.com
<mailto:l...@prpcompany.com>> wrote:
On 11/8/2013 1:42 PM, Jay Goldberg wrote:
On Fri, Nov 8, 2013 at 11:51 AM, John Hupp
<l...@prpcompany.com <mailto:l...@prpcompany.com>> wrote:
On 11/7/2013 4:23 PM, David Burgess wrote:
On Thu, Nov 7, 2013 at 1:18 PM, John Hupp
<l...@prpcompany.com <mailto:l...@prpcompany.com>>
wrote:
On 11/6/2013 5:53 PM, John Hupp wrote:
> I finished a new installation of LTSP-PNP on
Lubuntu 13.10, but I find
> that clients won't boot.
>
> After the Plymouth splash screen, a text
screen reads:
>
> Error: socket failed: connection refused.
> Exiting.
Forgive me for not combing through all of the
machine output, but at a glance your symptoms look
like something I have encountered where the nbd
server does not start automatically on the server.
The quick fix was to start the service, and then I
don't recall if it started automatically after a
reboot or if I had to turn that on in a config file
somewhere. Try 'netstat -lt' to see what ports
you're listening on.
db
Thanks for a good lead (though it leads to more
questions rather than an immediate solution).
I find that nbd-server is running, but comparing the
output of 'netstat -lt' on a Lubuntu 13.04 LTSP
server that works fine, and the misbehaving 13.10
server, I find that on
13.04 nbd-server listens on *: 60603, but on 13.10 it
listens on *:nbd.
Otherwise the output is the same for tcp on both
servers (I don't list the tcp6 results):
tcp 0 0 *:9571 *:* LISTEN
tcp 0 0 localhost:55213 *:* LISTEN
tcp 0 0 Lubuntu:domain *:* LISTEN
tcp 0 0 192.168.1.117:domain *:* LISTEN
tcp 0 0 localhost:domain *:* LISTEN
tcp 0 0 *:ssh *:* LISTEN
tcp 0 0 localhost:ipp *:* LISTEN
The nbd-server configuration file
(/etc/nbd-server/conf.d/ltsp_i386.conf) has the same
contents on both installations.
The script that launches nbd-server appears to be
/etc/init.d/nbd-server, and it does not specify ip
addresses or ports to listen to. At least for the ip
addresses,
http://manpages.ubuntu.com/manpages/saucy/man1/nbd-server.1.html
states that when the ip address parameter is not
specified, nbd-server will listen on all local
addresses on both IPv4 and IPv6.
I don't know how to interpret the difference in how
nbd-server is listening.
Forgive me if I seem out of the loop, I have not used
LTSP in over a year
However, it does look like a port issue. Looking at my
Debian system, /etc/services reports that NBD is on port
10809
nbd 10809/tcp # Linux Network Block Device
And in the man page for nbd-server for the -port option:
The port on which to listen for new-style
nbd-client connections. If not specified, the
IANA-assigned port of 10809 is used.
The netstat output will replace port numbers with
friendly names if it can match up ports with entries in
/etc/services
I recall that LTSP does use its own NBD server on a
non-standard port with a config file in a non-standard
location as well, so it would seem that your 13.10 system
should not show listening on *:nbd.
Check that the nbd-server is running on the port that the
client expects. "Connection refused" would support that
the port the client is connecting to is "closed".
For fun, also post the output of # iptables -L to make
sure there are no firewall rules filtering things.
Cheers,
--
Jay Goldberg | AvianBLUE Network Systems
I don't know how to check that the nbd-server is running
on the port that the client expects. Can you tell me?
But perhaps related to this, even though the topic was NBD
Swap, Alkis Georgopoulos wrote in
http://osdir.com/ml/LTSP-cluster-thin-clients/2012-08/msg00047.html
that for Ubuntu 12.04, the NBD_PORT section [for NBD Swap]
is obsolete since NBD is now using the IANA assigned port
10809 and name-based exports instead of port-based.
------------------------------
Iptables -L shows the default, no-rules setup:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Unfortunately I have not run LTSP in awhile, yet alone the new
"simple" LTSP. As I recall, the config files for the
standalone NDB server for LTSP is stored in /etc/ltsp/ and
when you change config files you must update the ltsp image
because the NDB server connection happens very early in the
boot process and needs to be hard coded in the client's initramfs.
I can get a test environment running tomorrow if you still
would like assistance.
--
Jay Goldberg
Other work has been demanding attention, but I'm returning to
this today a little.
In /etc/ltsp I only find dhcpd.conf, update-kernels.conf and
ltsp-update-image.excludes -- with none of those containing
anything that seems to bear on nbd-server configuration.
There are also these:
/etc/nbd-server/config
/etc/nbd-server/conf.d/ltsp_i386.conf
/etc/nbd-server/conf.d/swap.conf
But again, I don't see anything there that would seem to affect
where nbd-server is listening.
So yes, if you're still game for it, I'm happy for all the
further help I can get.
A little later I'm thinking that I will install Lubuntu 13.10
(with no updates and no other programs installed) + LTSP_PNP in
VMWare Player and test that. Of course if that worked it should
give me some clues. But if someone else in possession of Ubuntu
13.10 were to run a similar test, that could help to narrow the
field of inquiry to something in LXDE. I know that there have
been changes to LXSession manager and related parts in 13.10,
but as far as I know these would not bear on nbd-server (which I
have seen above is running -- at least one instance of it).
That Lubuntu vs Ubuntu 13.10 is blunt-object troubleshooting
however, and I'm open to finer ideas if someone can tell me how.
For instance, since the client machine has an initramfs that
seems to be working at the point of failure (there is a working
prompt), can I run something useful from there?
I installed Lubuntu 13.10 (with no updates and no other programs)
+ LTSP-PNP in a VMWare Player virtual machine, but when tested
with a client, its PXE booter fails with the error: "No boot
filename received."
So in this setup I so far find out nothing useful. At least in
the real metal install I have a clean PXE boot.
If someone can help me get past this obstacle I may be able to
find out a something.
-------------------------------
I also copied and pasted the output of the LTSP install commands
into a file which you can download at
http://www.prpcompany.com/ltsp/vm_ltsp_install_log.zip (I tried
just pasting it in here but it made the post run afoul of a size
limit.)
Perhaps of immediate interest from that log is the output of the
installation of ltsp-server-standalone. It includes this:
########################################
Setting up nbd-server (1:3.3-3ubuntu1) ...
Creating config file /etc/nbd-server/config with new version
Adding system user `nbd' (UID 110) ...
Adding new group `nbd' (GID 119) ...
Adding new user `nbd' (UID 110) with group `nbd' ...
Not creating home directory `/etc/nbd-server'.
** (process:3234): WARNING **: Could not parse config file: The
config file does not specify any exports
** Message: No configured exports; quitting.
nbd-server.
########################################
Is that normal?
I did not figure out why the LTSP setup in VMWare Player fails.
But I did reinstall 13.04 on real hardware in order to copy the
output of the LTSP installation commands and compare them to the
results under 13.10. I did not discover anything very
illuminating, but I did find the same nbd-server setup messages in
both, so in light of the fact that LTSP works under 13.04, the
above WARNING is insignificant.
I have duplicated the LTSP setup on a fresh install of Ubuntu
13.10, and I find the very same failure.
So the problem does not appear to be connected to the desktop
environment or to changes in the desktop environment between 13.04
(where LTSP worked) and 13.10.
I found out that the Busybox shell supports 'dmesg' and entered that
at the working initramfs prompt.
I think the last few lines of the output support the premise that
this is an nbd problem:
block nbd0: Attempted send on closed socket
end_request: I/O error, dev nbd0, sector 2
EXT3-fs (nbd0): error: unable to read superblock
block nbd0: Attempted send on closed socket
end_request: I/O error, dev nbd0, sector 2
EXT4-fs (nbd0): error: unable to read superblock
block nbd0: Attempted send on closed socket
end_request: I/O error, dev nbd0, sector 2
FAT-fs (nbd0): unable to read boot sector
As I reported in another thread here, I now have copies of the
presumably-relevant initramfs startup scripts (/init,
/scripts/local-top/nbd, /scripts/local-top/nbd-ltsp and
/sbin/nbd-client-proxy), but I don't know how to read them to
determine what nbd-client command is being used, or how I might run
an nbd-client command in the Busybox shell for testing.
I just started a 13.04 Lubuntu LTSP server and booted the same test
client successfully (as before).
The interesting thing is that 'dmesg | grep nbd' does not yield any
of the messages that I reported above for the 13.10 server. There is
an 'nbd0: unknown partition table' message, but that seems to be
insignificant.
Could this be a problem with kernel-level nbd support?
If that were the case, then it would not matter what nbd-client
command was being issued by the init scripting. I could stop trying
to figure that out and push in a different direction.
I think I have good evidence now that this is a bug in kernel-level
nbd support.
Saucy uses kernel 3.11.0-12.19 in its initial default configuration,
and the error occurs under this kernel.
But I installed 3.9.0-4.9 (which was also published for Saucy), and
the client boots normally when it uses that kernel.
Testing has been hampered by the fact that some of the
pre-3.11.0-12.19 kernels break networking (e.g. 3.11.0-0.3 and
3.10.0-2.10), and I don't know if/how to test for working kernel nbd
support except by booting an LTSP client. Nonetheless I'll try to
narrow down where the failure occurs.
I'm finally finished with the Ubuntu kernel bisection. I find that LTSP
works on Ubuntu kernel 3.10.0-4.13 and fails on the next release,
3.10.0-5.14.
The changelog at https://launchpad.net/ubuntu/+source/linux/3.10.0-5.14
includes "rebase to v3.10.2." I don't know exactly what that means but
suspect that whatever it entailed is related to the failure.
I'll see if I can get started on commit bisecting the Ubuntu kernels.
I have not filed a bug report yet. Should I do that now, or do the
commit bisection first?
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net
