On 1/1/2014 5:15 PM, John Hupp wrote:
> Hi, all, my first post here.
>
> I'm trying to locate the source of a problem with Linux Terminal Server
> Project (LTSP), which uses NBD (the new name-based protocol, not
> port-based) to boot client computers.
>
> It worked fine through Ubuntu 13.04 (Raring), but with Ubuntu 13.10
> (Saucy), the clients fail to boot, displaying:
> Error: socket failed: connection refused
> Exiting
> I have suspected that the error is NBD-related.
>
> Regardless of the cause, I found that the bug appears between Ubuntu
> kernel 3.10.0-4.13 and 3.10.0-5.14. But I am thwarted when trying to
> commit bisect the Ubuntu kernel. The very first bisect attempt results
> in the message "A merge base must be tested," which apparently results
> from non-linear tags.
>
> I am advised that, instead of trying further to bisect the Ubuntu
> kernel, I should switch to trying to bisect the mainline kernel. The
> above Ubuntu kernels map to mainline kernels 3.10.1 and 3.10.2. But it
> turns out that LTSP in Ubuntu is using overlayfs or aufs, which are not
> part of the mainline kernel. So I can't use LTSP to test the mainline
> kernels.
>
> I am advised that I should just test NBD, without involving LTSP or
> netbooting.
>
> But I don't know much about how to do that. I have the LTSP client
> image located on the server at /opt/ltsp/images/i386.img. The LTSP NBD
> configuration file sets up a reference to that with the name
> "/opt/ltsp/i386." On another computer on the network running Ubuntu
> standalone, I issued:
> $ nbd-client <server IP> -N /opt/ltsp/i386 /dev/nbd0
>
> This resulted in output:
> Negotiation: ..sz = 1586MB
> bs = 1024 sz = 1663057920 bytes
>
> I think (but don't know) that this indicates NBD is working, at least to
> some extent. In a *working Ubuntu 13.04 setup,* the above output on the
> client would be followed by "* starting system logging daemon" and other
> daemon startup messages.
>
> I don't know if my two slim lines of output partly or completely
> exonerate NBD as the source of my bug.
>
> Can someone evaluate what I've done so far, and give me further or
> better testing instructions if needed? Kindly keep in mind that I am
> just a somewhat-experienced end-user, so don't assume too much.
I think I figured it out.
I ran these commands on the client:
# Set up the connection to the remote device, the NBD image:
sudo nbd-client <server IP> -N /opt/ltsp/i386 /dev/nbd0
# Check the connection:
$ sudo nbd-client -c /dev/nbd0 ; echo $?
2377 # the PID of the nbd-client instance
0 # indicates that a connection exists
# Check the size of the remote device:
sudo blockdev --getsize64 /dev/nbd0
1663057920
# Make the directory (with a name of your choosing) where the remote
device will be mounted as a local device:
cd /mnt
sudo mkdir ltspimg
# Mount the remote device as a local device:
sudo mount /dev/nbd0 /mnt/ltspimg
# Browse ltspimg in the file manager or do other read-only operations
within that file system
# When finished testing, unmount the device:
sudo umount /dev/nbd0
# Close the connection; successful output as below:
sudo nbd-client -d /dev/nbd0
Disconnecting: que, disconnect, sock, done
------------------------------------------------------------------------------
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
_______________________________________________
Nbd-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nbd-general
